After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 302044 - Filename selection on F2/Rename stops at first '.'
Filename selection on F2/Rename stops at first '.'
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: File and Folder Operations
2.11.x
Other All
: Normal enhancement
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-04-26 14:01 UTC by Brandon Williams
Modified: 2005-07-15 21:23 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12



Description Brandon Williams 2005-04-26 14:01:27 UTC
Presumably, when selecting a file and pressing 'F2' to rename the file, the text
selection stops at the first '.' to preserve the filename extension and make
renaming quicker/easier. However, many files have multiple '.' (periods) and
Nautilus auto-selects only up to the first one.

ie: Given the filename 'foo.Bar.so', when selecting this file and pressing 'F2',
only 'foo' will be highlighted.

My suggestion is that the text be auto-selected up to the LAST period (ie:
foo.Bar), in that the file's extension is more likely to be found in that
location rather than at the first instance of '.'.

Other information:
Comment 1 Sebastien Bacher 2005-05-05 17:07:42 UTC
not sure that's a good idea, what about .tar.gz or .tar.bz2 by example?
Comment 2 Brandon Williams 2005-05-05 17:27:54 UTC
Good point -- I guess it could be argued as valid either way. I can see renaming
something like 'foo.so.2' as preferring the existing method. The question is,
what makes more sense for the default behavior?
Comment 3 Sebastien Bacher 2005-05-05 17:37:14 UTC
I think that filenames with a "." are not really current compared to .tar.gz or
.tar.bz2 files by example
Comment 4 Brandon Williams 2005-05-05 18:27:53 UTC
I'm inclined to think that the average desktop user would work most commonly
with files using the typical '.xxx' format - ie: .jpg, .mpg, .cpp, etc. As you
pointed out, there are certain exceptions, but I can think of more examples
where my suggested behavior would make more sense than the current implementation.
Comment 5 Sebastien Bacher 2005-05-05 19:38:55 UTC
right for the extensions, but I don't think they filenames with a "." (which is
the bug concern) are common (ie: "one.file.jpg")
Comment 6 Alexander Larsson 2005-06-02 10:49:57 UTC
Obviously no method is ideal. However, i don't think "normal" filenames with a
dot in anywhere but the extension part are very common. This is the reason
nautilus behaves as it does.
Comment 7 Christian Neumair 2005-07-14 10:14:29 UTC
Note that in Nautilus 2.11 you can also use shift-f2 to select the whole
filename when renaming. If people really want this, we can bind ctrl-f2 or
ctrl-shift-f2 to "select everything til' we reach the last dot". Usability
squad, any suggestions? :)
Comment 8 Calum Benson 2005-07-15 17:30:59 UTC
I don't suppose there's any way the mimetype stuff could work out which part of
the filename was the extension, based on the type of file it's known to be?  Is
there any way it can tell that a file of type application/x-compressed-tar
*might* have '.tar.gz' at the end of its filename?  I don't know how much the
mimetype stuff knows or cares about filename extensions as opposed to sniffing
these days.

If we can't be clever about it, I'd personally be inclined just to leave it the
way it is.... I think F2 and Shift+F2 offer enough options to be useful 99% of
the time.  (I didn't know about Shift-F2 though... doesn't work for me in
2.11.4.  How will the user find out about this if it's not on a menu, as it
presumably isn't?)
Comment 9 Sebastien Bacher 2005-07-15 20:18:29 UTC
all that seems to be complicate for almost no use, I agree with Alex, this bug
should be closed
Comment 10 Christian Neumair 2005-07-15 21:23:32 UTC
Calum: The problem is indeed that this would get very complicated, since the
mime spec provides primitive pattern matching, like "foo*bar", and doesn't know
the concept of extensions at all. Question is really whether it is worth the pain.