Bug 317320 - When pasting a file with a name that exists already in the folder, no space should be inserted in the suggested new name
Summary: When pasting a file with a name that exists already in the folder, no space s...
Status: CLOSED INTENTIONAL
Alias: None
Product: kio
Classification: Unmaintained
Component: general (show other bugs)
Version: 4.10.0
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
: 398830 404559 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-03-25 10:01 UTC by davidblunkett
Modified: 2019-02-20 23:07 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description davidblunkett 2013-03-25 10:01:52 UTC
When dolphin suggests a new name it appends " X" before the extension where X is a number.

The problem is it also inserts a space " " before the number.  Since dolphin is used on a linux filesystem is should be expected that the filename will be used from a shell and this space requires escapes or quotes to use.  

It would be far better is dolphin used an underscore "_" instead of a space " " when suggesting a new name.  At the very least this should be user definable.

Reproducible: Always

Steps to Reproduce:
1. Copy a file to a directory with the same name as an existing file
2. Let dolphin suggest a new name et voila a space appears
3.
Actual Results:  
You get spaces in filenames

Expected Results:  
At more suitable space character should be used (the underscore "_")
Comment 1 Frank Reininghaus 2013-03-25 10:11:02 UTC
Thanks for the report, but I don't see the bug here. It's perfectly possible to use file names with spaces from a shell, the tab auto completion even adds the escaped space for you.
Comment 2 davidblunkett 2013-03-27 11:38:22 UTC
I disagree - using a space is a poor choice for all sorts of a reason, and underscore has none of these disadvantages.

As for completion - it depends on which shell and what context you are using and it is a PITA for scripts.  It should be a user definable option at the very least.

I cannot see any argument for using a " " over a "_" and lots the other way around.
Comment 3 Emmanuel Pescosta 2013-03-27 11:54:37 UTC
I think we should append the number without a prefix.
Comment 4 Nate Graham 2018-04-25 21:15:18 UTC
Sorry, but avoiding spaces at all costs is not a reasonable behavior. Real people use spaces in their file names, and real tools handle them gracefully. Shells and CLI tools that can't handles that aren't worth the bits they're printed on, and you should file bugs against them (or even better, submit patches) to fix that.
Comment 5 davidblunkett 2018-04-30 16:02:34 UTC
Real people and real tools use "_" and 50 years of computing practice uses " " as a token separator which this (annoyingly) breaks. There hasn't been an answer given here as to why not "_" or something else that behaves nicely with the system you're building on!
Comment 6 Nate Graham 2018-04-30 19:44:58 UTC
The people who use underscores in their file names are programmers and command-line power users. We aren't optimizing the system for them; we're optimizing it for people with more normal levels of computer skills, who by and large use spaces in their file names.
Comment 7 davidblunkett 2018-05-01 07:04:48 UTC
Perhaps you should be developing for Windows?
Comment 8 Christoph Feck 2018-05-17 00:07:24 UTC
That's not a helpful comment.

I suggest to simply replace the Space in https://cgit.kde.org/kio.git/tree/src/core/global.cpp#n397 and recompile KIO.
Comment 9 davidblunkett 2018-05-21 09:45:03 UTC
> That's not a helpful comment.

Do you mean Nate's comment above?
Comment 10 Christoph Feck 2018-05-21 10:59:33 UTC
No.
Comment 11 davidblunkett 2018-05-21 11:04:14 UTC
Ok - well I didn't think Nate's comment was useful because I read this as "we're just catering for the computer illiterate". I've fail to see why underscores inconvenience novices!
Comment 12 Nate Graham 2018-09-19 22:12:07 UTC
*** Bug 398830 has been marked as a duplicate of this bug. ***
Comment 13 Christoph Feck 2019-02-20 23:07:50 UTC
*** Bug 404559 has been marked as a duplicate of this bug. ***