Bug 452587

Summary: File renaming with newlines does not work very well
Product: [Applications] dolphin Reporter: Ralf Jung <post>
Component: view-engine: generalAssignee: fanzhuyifan
Status: RESOLVED FIXED    
Severity: normal CC: 4wy78uwh, fanzhuyifan, invertedrat, kde-bugs, kfm-devel
Priority: NOR    
Version: 23.08.1   
Target Milestone: ---   
Platform: Other   
OS: Linux   
See Also: https://bugs.kde.org/show_bug.cgi?id=445292
https://bugs.kde.org/show_bug.cgi?id=422998
https://bugs.kde.org/show_bug.cgi?id=444747
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Ralf Jung 2022-04-13 18:02:52 UTC
SUMMARY

I often copy-paste the title of a PDF document into the filename so that I can easily tell what the file contains. However, if the title does not fit on a single line in the document (which is most of the time), that inadvertently inserts a newline into the filename that I then have to remove. The Dolphin rename logic does not handle newlines very well (and over the last year, this got worse).


STEPS TO REPRODUCE
1. Copy-paste some title with a newline into it into the filename
2.  Try to rename the file in dolphin to remove the filename

OBSERVED RESULT

Only one of the multiple lines is ever actually shown while renaming, the other lines are cut off.
Navigating the cursor around this multi-line filename does not work very well.
The up/down arrow keys navigate to neighboring files, so to navigate the multiple lines in the filename one has to use just the left/right arrow keys.



EXPECTED RESULT
I am not sure what the best way to handle this would be. IMO it would make sense to just remove newlines when I Ctrl-V some text into the filename -- one basically never wants a newline in a filename anyway.
Alternatively, maybe there is a way to make the file rename mode better support filenames with newlines.

SOFTWARE/OS VERSIONS
Operating System: Debian GNU/Linux
KDE Plasma Version: 5.24.3
KDE Frameworks Version: 5.90.0
Qt Version: 5.15.2
Kernel Version: 5.16.0-4-amd64 (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Xeon® CPU E3-1505M v5 @ 2.80GHz
Memory: 31,2 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics P530
Comment 1 fanzhuyifan 2023-10-12 03:26:15 UTC
*** Bug 412974 has been marked as a duplicate of this bug. ***
Comment 2 fanzhuyifan 2023-10-12 03:27:12 UTC
(In reply to fanzhuyifan from comment #1)
> *** Bug 412974 has been marked as a duplicate of this bug. ***

412974 is a special case where the filename ends in the new line character.
Comment 3 fanzhuyifan 2023-10-24 20:15:58 UTC
Right now the behavior is as follows:

When rename is started, only a single line is displayed.
(Only in icons view, can the user can use up-down keys to scroll through the different lines.
In other views up down keys changes the file being edited)
As soon as a deletion is made, all the lines are displayed in a multiline text box. (this works in all views).
How do we want to change this behavior? Should we display a multiline text box showing all lines when the user enters edit mode?
Comment 4 Bug Janitor Service 2023-10-25 02:07:09 UTC
A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/641
Comment 5 fanzhuyifan 2023-10-26 01:06:07 UTC
*** Bug 422997 has been marked as a duplicate of this bug. ***
Comment 6 Méven Car 2023-11-08 11:14:54 UTC
Git commit 8297e0a8c97c6e1f6d46b9ecc9c5f495f294d5b8 by Méven Car, on behalf of Yifan Zhu.
Committed on 08/11/2023 at 12:10.
Pushed by meven into branch 'master'.

Improve size adjustment of itemlist editor

Currently multi-line file names in dolphin only display a single
line when renaming. This commit ensures multi-line filenames have
all lines displayed by calling `document()->adjustSize` in
`KItemListRoleEditor::autoAdjustSize`, and by calling the latter
function after setting up the editor.

M  +1    -0    src/kitemviews/kstandarditemlistwidget.cpp
M  +1    -0    src/kitemviews/private/kitemlistroleeditor.cpp
M  +5    -5    src/kitemviews/private/kitemlistroleeditor.h

https://invent.kde.org/system/dolphin/-/commit/8297e0a8c97c6e1f6d46b9ecc9c5f495f294d5b8
Comment 7 Roke Julian Lockhart Beedell 2023-12-10 18:59:16 UTC
(In reply to fanzhuyifan from comment #3)
> How do we want to change this behavior? Should we display a multiline text
> box showing all lines when the user enters edit mode?

I believe so. Has that ever been suggested as an FR here?