From: TAKAHASHI Yoshio <yfb02119@nifty.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 55787@debbugs.gnu.org
Subject: bug#55787: 29.0.50; inconsistent sort order with ls-lisp-version-lessp
Date: Sat, 04 Jun 2022 23:11:17 +0900 [thread overview]
Message-ID: <87tu90jz7e.fsf@yfb02119.nifty.com> (raw)
In-Reply-To: <83h750c1q3.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 04 Jun 2022 10:44:04 +0300")
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
next prev parent reply other threads:[~2022-06-04 14:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-03 23:21 bug#55787: 29.0.50; inconsistent sort order with ls-lisp-version-lessp TAKAHASHI Yoshio
2022-06-04 7:44 ` Eli Zaretskii
2022-06-04 14:11 ` TAKAHASHI Yoshio [this message]
2022-06-04 14:52 ` Eli Zaretskii
2022-06-05 2:37 ` TAKAHASHI Yoshio
2022-06-05 7:01 ` Eli Zaretskii
2022-06-05 9:38 ` TAKAHASHI Yoshio
2022-06-05 9:48 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tu90jz7e.fsf@yfb02119.nifty.com \
--to=yfb02119@nifty.com \
--cc=55787@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).