Dired deleted the wrong file for me, IRL!

But, I guess I don't know if this qualifies as a bug.

Maybe the emacs user is supposed to be forewarned -  "Buyer beware, dired
uses regexps, duh! heuristics always have fail cases"?

On the other hand, if it's a "buyer beware", maybe we need to communicate
this better? I have been an emacs "power?" user for upwards of two decades,
and I never knew or thought about it till I encountered this real-life
corruption.


TIL after lots of debugging - dired uses heuristics, and this means you can
delete/rename/edit the wrong file.

Example - touch two files in tmp/
"09 aa 3333 kk.mmn" and "kk.mmn".

Now, do some operation on the first file using any of dired (or wdired)
operations, example delete it d and x.

Guess which file you actually deleted?

And you can see why it happens - the regexes it uses in dired-get-filename
(and other places).

I reproduced these on my emacs 28.2 on debian stable, and reproduced on
27.1 ubunutu.

Mekeor (irc) couldn't reproduce this on 30.0.50 build.

Have the regexps changed?  I see from github that the structure and
mechanism is still very much the same  in the bleeding edge -

dired-get-filename
directory-listing-before-filename-regexp

.. to get the file name.

When you have regexps, the problem always remains? And, it did bit me IRL.


Lots of fun curiosities as you play around with the filenames  - it stops
working if you make the first number too large, say 43.  but, i guess 32,
still looks like a date to the regexp. The regexp probably likes to 0-3 to
filter for dates, etc.

(If you are curious - I had a file that started with 07 ... had the date in
it, and a version of it without the date in it. dired deleted the wrong
version for me!)


Is there a way for dired to dtrt? Is regexp the only way?