From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
Description of problem:
dired doesnt navigate properly and cant open files with names of the form
YYYY-MM-DD <space> foo.bar, for example "2001-01-01 whatever.txt".
it displays the file name fine, but when moving forward and backward through the
directory listing, it positions the cursor incorrectly on the "whatever" (in the
example) rather than at the beginning of the file name as it should. and when i
try to open the file (by typing "f" for find file) it says "File no longer
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. touch "2001-01-01 test.dat"
3. "C-x C-f RET" (open the current directory in dired)
4. "n" until on that file. (note incorrect cursor position.)
5. "f" to open the file. (note failure to open file.)
Actual Results: incorrect cursor position and failure to open file.
Expected Results: normal cursor positioning and successful visit of the file.
GNU Emacs 21.2.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2002-08-28
rpm -q emacs:
i also tried emacs v20 from redhat 7.2 and the bug did NOT occur there.
Reproduced. [FWIW xemacs dired works fine with filenames containing spaces.]
Of course it only occurs because of the iso date in filename...
Is there some particular application generating filenames of this form?
`dired-move-to-filename-regexp' (dired.el) in cvs still has this
problem according to my testing, at least in 21.2.
to answer the question about whether some app
was creating files with names of this form: no.
it was a user-chosen file name.
does emacs/dired have a test suite? if so i'd
be happy to contribute a test case. otherwise,
i'm not much of a regexp hacker, sorry :/
(i did look at dired.el... all i can say is
it looks like it desperately *needs* a test
Btw a workaround is to remove "iso" from the final regexp
(assuming you're not using iso dates in dired that is),
or change your filenames not to have a space or something. ;-)
This whole problem is fixed in emacs cvs (using the --dired option of GNU ls)
and should appear in 21,4 I think, which is still a while off I'm afraid.
See all http://mail.gnu.org/archive/html/emacs-devel/2003-01/msg00828.html
thx. i did try removing "iso" part of the regexp and it did workaround this
particular problem, though as you point out it's hardly a general solution.
i'll look forward to handling of "--dired" output, that would be great (at
least for local listings......). thx again.