From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#64656: 29.0.91; Doc of minibuffer histories and completing-read - automatic addition of completions to DEFAULT list Date: Fri, 10 Nov 2023 10:15:45 +0200 Message-ID: <83sf5exbv2.fsf@gnu.org> References: <83y1jga0nr.fsf@gnu.org> <83o7kb9a40.fsf@gnu.org> <86bkg84de3.fsf@mail.linkov.net> <86jzrhlrub.fsf_-_@mail.linkov.net> <867cmw83zb.fsf@mail.linkov.net> <867cmvcpco.fsf@mail.linkov.net> <86a5rmanrn.fsf@mail.linkov.net> <83edgyzxcx.fsf@gnu.org> <86jzqqj1u2.fsf@mail.linkov.net> <838r76zpsw.fsf@gnu.org> <86v8aakq69.fsf@mail.linkov.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8820"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 64656@debbugs.gnu.org, drew.adams@oracle.com To: Juri Linkov , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Nov 10 09:16:37 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1r1Mgu-00026A-T5 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 10 Nov 2023 09:16:36 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1Mgh-0000iK-NV; Fri, 10 Nov 2023 03:16:23 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r1Mgg-0000hv-Jm for bug-gnu-emacs@gnu.org; Fri, 10 Nov 2023 03:16:22 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r1Mgg-0006xh-6n for bug-gnu-emacs@gnu.org; Fri, 10 Nov 2023 03:16:22 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r1MhJ-0000yF-Ox for bug-gnu-emacs@gnu.org; Fri, 10 Nov 2023 03:17:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Nov 2023 08:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64656 X-GNU-PR-Package: emacs Original-Received: via spool by 64656-submit@debbugs.gnu.org id=B64656.16996042033700 (code B ref 64656); Fri, 10 Nov 2023 08:17:01 +0000 Original-Received: (at 64656) by debbugs.gnu.org; 10 Nov 2023 08:16:43 +0000 Original-Received: from localhost ([127.0.0.1]:49502 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r1Mh0-0000xa-JN for submit@debbugs.gnu.org; Fri, 10 Nov 2023 03:16:42 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37102) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r1Mgx-0000x8-JR for 64656@debbugs.gnu.org; Fri, 10 Nov 2023 03:16:40 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r1MgC-0006qn-SE; Fri, 10 Nov 2023 03:15:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=OAQaDHN1mgejnm6r0/0XWK/vE83/5YuSNpdTEkPGZPw=; b=rC+thpVlqo8X xCfvG1c+S5LFHocZ6Ej8Qmp4g6UuI9hh/JDNAQ129LLx08mQHuaUaLfT/MONz7UskjCC3Pl5EvS0t Z8pjG9BE3Ct99AacHJ2f5jUCwYUt6kJ2MN/eSQfVLHn3DQ5kNQTf1MYeidZktp3IuTSmHJt5WM/K4 19H2h/7CXXBZbF58XQeZjKEfNLby9CO9uqeolYnbCVFfw5pbOzOWlyk9vvf4yeUYJH71O5iPD4V9Y xXeiq3kqqWPqXCSJC5nBvqi6QiIa0zSDFnoM7esI8mhUXMoJvcYa68jiKGYAV5wrdfIr00G0KmQCG cy85GaRH/+enUeyo04Nrlg==; In-Reply-To: <86v8aakq69.fsf@mail.linkov.net> (message from Juri Linkov on Fri, 10 Nov 2023 09:45:02 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:274101 Archived-At: > From: Juri Linkov > Cc: drew.adams@oracle.com, 64656@debbugs.gnu.org > Date: Fri, 10 Nov 2023 09:45:02 +0200 > > >> A recipe is to customize `completions-sort' to nil ("No sorting"), > >> then first call `M-& ls -U RET' and afterwards `C-x C-f TAB TAB' > >> and compare the contents of two buffers *Async Shell Command* > >> and *Completions*. The order of files is reversed. > > > > OK, I see it now, thanks. > > > > But IMO this raises several issues: > > > > . completions-sort affects all completions, not just completions of > > file names, right? So why the change only for file names? > > I'm trying various completions after customizing completions-sort to nil, > so currently noticed a problem in the completions of file names. So you agree that the problem is wider than that? > > . who said that the order we get file names from readdir is the > > "unsorted order", and not its reverse? > > 'readdir' returns the order of the file system, That is not true in general. For example, on MS-Windows, it returns the file names in alphabetical order. In general, we don't know what is the relation between the order in which readdir returns file names and the order of the file entries in the directory on disk, as that is an implementation detail. > > . in any case, I think we should reverse only when completions-sort > > is nil, because otherwise we could adversely affect the sorting > > performed on the results > > This means bringing 'Qcompletions_sort' to 'file_name_completion'? Yes. > Probably not worth the trouble. Why not? It's just a single simple test. > Better to declare the value nil of `completions-sort' as > unsupported. I don't see why. > Anyway this was just an experiment to see how useful is the > no sorting option for completions. > > And the conclusion is that it's useful only for part of completion types, > and not useful for others. It's useless for obarray and file names. I added Stefan to this discussion, in case he has an opinion or comments.