bug#55787: 29.0.50; inconsistent sort order with ls-lisp-version-lessp

[TAKAHASHI Yoshio]

Eli-san,

With further tests, this ls-lisp behavior occurs only on my Mingw64
Windows Emacs environment.  I can not reproduce it on my WSL2 Ubuntu
environemnt.

> What do you see with 'ls' and what do you see with ls-lisp?  Also, in
> which locale are you trying this with 'ls'?

I include my trial to hope it can be reproduced on your environment.  In
this scenario, I use alittle more real filenames instead of just number.

================================================================

On my Windows machine, output from "M-! (shell-command) env"

OS=Windows_NT
LANG=ja_JP.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_TIME=C


================================================================

tkh$ cat ../createfiles.sh
touch "34 アルバム-300dpi.jpg"
touch "34 アルバム-300dpi.png"
touch "054_交換機.jpg"
touch "054_交換機.png"
touch "91 部分カット.jpg"
touch "91 部分カット.png"
touch "0717-パソコン.jpg"
touch "0717-パソコン.png"
touch "1935 社屋.jpg"
touch "1935 社屋.png"
touch "FFFF_縁カット.jpg"
touch "FFFF_縁カット.png"
touch "hhhh.jpg"
touch "hhhh.png"
tkh$ sh ../createfiles.sh
tkh$ ls -l
total 0
-rw-r--r-- 1 tkh 0 Jun  5 10:45 054_交換機.jpg
-rw-r--r-- 1 tkh 0 Jun  5 10:45 054_交換機.png
-rw-r--r-- 1 tkh 0 Jun  5 10:45 0717-パソコン.jpg
-rw-r--r-- 1 tkh 0 Jun  5 10:45 0717-パソコン.png
-rw-r--r-- 1 tkh 0 Jun  5 10:45 1935 社屋.jpg
-rw-r--r-- 1 tkh 0 Jun  5 10:45 1935 社屋.png
-rw-r--r-- 1 tkh 0 Jun  5 10:45 34 アルバム-300dpi.jpg
-rw-r--r-- 1 tkh 0 Jun  5 10:45 34 アルバム-300dpi.png
-rw-r--r-- 1 tkh 0 Jun  5 10:45 91 部分カット.jpg
-rw-r--r-- 1 tkh 0 Jun  5 10:45 91 部分カット.png
-rw-r--r-- 1 tkh 0 Jun  5 10:45 FFFF_縁カット.jpg
-rw-r--r-- 1 tkh 0 Jun  5 10:45 FFFF_縁カット.png
-rw-r--r-- 1 tkh 0 Jun  5 10:45 hhhh.jpg
-rw-r--r-- 1 tkh 0 Jun  5 10:45 hhhh.png
tkh$ ls -lv
total 0
-rw-r--r-- 1 tkh 0 Jun  5 10:45 34 アルバム-300dpi.jpg
-rw-r--r-- 1 tkh 0 Jun  5 10:45 34 アルバム-300dpi.png
-rw-r--r-- 1 tkh 0 Jun  5 10:45 054_交換機.jpg
-rw-r--r-- 1 tkh 0 Jun  5 10:45 054_交換機.png
-rw-r--r-- 1 tkh 0 Jun  5 10:45 91 部分カット.jpg
-rw-r--r-- 1 tkh 0 Jun  5 10:45 91 部分カット.png
-rw-r--r-- 1 tkh 0 Jun  5 10:45 0717-パソコン.jpg
-rw-r--r-- 1 tkh 0 Jun  5 10:45 0717-パソコン.png
-rw-r--r-- 1 tkh 0 Jun  5 10:45 1935 社屋.jpg
-rw-r--r-- 1 tkh 0 Jun  5 10:45 1935 社屋.png
-rw-r--r-- 1 tkh 0 Jun  5 10:45 FFFF_縁カット.jpg
-rw-r--r-- 1 tkh 0 Jun  5 10:45 FFFF_縁カット.png
-rw-r--r-- 1 tkh 0 Jun  5 10:45 hhhh.jpg
-rw-r--r-- 1 tkh 0 Jun  5 10:45 hhhh.png
tkh$


================================================================

On my Windows machine, "054_交換機.{jpg,png}" are wrongly listed in
dired buffer.

  drwxrwxrwx  1 0 Jun  5 10:45 .
  drwxrwxrwx  1 0 Jun  5 10:45 ..
  -rw-rw-rw-  1 0 Jun  5 10:45 34 アルバム-300dpi.jpg
  -rw-rw-rw-  1 0 Jun  5 10:45 34 アルバム-300dpi.png
  -rw-rw-rw-  1 0 Jun  5 10:45 054_交換機.png
  -rw-rw-rw-  1 0 Jun  5 10:45 91 部分カット.jpg
  -rw-rw-rw-  1 0 Jun  5 10:45 91 部分カット.png
  -rw-rw-rw-  1 0 Jun  5 10:45 0717-パソコン.jpg
  -rw-rw-rw-  1 0 Jun  5 10:45 0717-パソコン.png
  -rw-rw-rw-  1 0 Jun  5 10:45 054_交換機.jpg
  -rw-rw-rw-  1 0 Jun  5 10:45 1935 社屋.jpg
  -rw-rw-rw-  1 0 Jun  5 10:45 1935 社屋.png
  -rw-rw-rw-  1 0 Jun  5 10:45 FFFF_縁カット.jpg
  -rw-rw-rw-  1 0 Jun  5 10:45 FFFF_縁カット.png
  -rw-rw-rw-  1 0 Jun  5 10:45 hhhh.jpg
  -rw-rw-rw-  1 0 Jun  5 10:45 hhhh.png

================================================================

When I drilled down to understand this listing, I encountered sort order
inconsistency, from my point of view, reported in my original mail.


>> # "01.0", "10", ... is minimal reproducible pattern that I stlipped down
>> # my real filenames pattern.
>
> I'd prefer to see the real file names instead, since that's what
> ls-lisp-version-lessp was written to handle.

I did too simplification in my original mail.  It was not good for
report, sorry.


> The exact spec of strverscmp is not known, AFAIK, and the
> implementation is a state machine, which is somewhat hard to
> reverse-engineer.  I'm only aware of the documentation in the glibc
> manual; did you read it?

I saw strverscmp man page, then source.  And no attempt to understand
the state machine implemantation.


> Comparing with 'ls' is also somewhat problematic, because in UTF-8
> locales its collation rules ignore some punctuation characters --
> again, because that's how glibc implements that.  Emacs on MS-Windows
> can emulate this behavior if you set w32-collate-ignore-punctuation to
> a non-nil value.

I think `w32-collate-ignore-punctuation' seems not to affect my test
case.  In my trial, the dired buffer listing is same with t / nil of
`w32-collate-ignore-punctuation'.

-- 
tkh