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

[TAKAHASHI Yoshio <yfb02119@nifty.com>]

Eli-san,

Thank you for your replay.

>> I encounter an inconsistent sort result.  The position of "01.0" and/or
>> "01.2" seems wrong.
>> 
>> 
>> $ cat /tmp/test.el
>> (require 'ls-lisp)
>> (print (sort (vector "01.0" "10" "010" "01.2")
>>              (lambda (x y)
>>                (ls-lisp-version-lessp x y))))
>> $ emacs -Q --batch -l /tmp/test.el
>> 
>> ["01.0" "10" "010" "01.2"]
>
> Why do you think this is wrong?  This function is not meant to compare
> dotted versions with undotted ones, only dotted to dotted or undotted
> to undotted.  The strings are supposed to be file names, where a dot
> begins an extension.
> 
> See the node "More details about version sort" in the GNU Coreutils
> manual for more info.

I report this "inconsistency" because ls-lisp does not sort files as ls
program does when `dired-listing-switches' has 'v', such as "-alGv".

# "01.0", "10", ... is minimal reproducible pattern that I stlipped down
# my real filenames pattern.

I'm not aware that `ls-lisp-version-lessp' does not support
dotted-undotted mixed cases.  Doc string says it acts as `strverscmp', I
expect the same result (order) in dired buffer.  And in below example,
the result seems to act like `strverscmp'.

    (print (sort (vector "01.0" "10" "01.2") ; no "010" in arg.
                 (lambda (x y)
                   (ls-lisp-version-lessp x y))))
    ["01.0" "01.2" "10"]


> If you want a general-purpose version-comparison function, use
> version< instead.

Umm, do I need to use `version<' in `ls-lisp-handle-switches' with
extracting numerical part from filename argument?

-- 
tkh