From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 28 15:38:29 2021 Received: (at submit) by debbugs.gnu.org; 28 Jul 2021 19:38:30 +0000 Received: from localhost ([127.0.0.1]:55894 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m8pNt-0000HH-F2 for submit@debbugs.gnu.org; Wed, 28 Jul 2021 15:38:29 -0400 Received: from lists.gnu.org ([209.51.188.17]:44976) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m8p8l-0008J7-Qq for submit@debbugs.gnu.org; Wed, 28 Jul 2021 15:22:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33162) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m8p8l-00039i-KF for bug-gnu-emacs@gnu.org; Wed, 28 Jul 2021 15:22:51 -0400 Received: from mail-ot1-x334.google.com ([2607:f8b0:4864:20::334]:42821) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m8p8j-0006y2-Pb for bug-gnu-emacs@gnu.org; Wed, 28 Jul 2021 15:22:51 -0400 Received: by mail-ot1-x334.google.com with SMTP id 68-20020a9d0f4a0000b02904b1f1d7c5f4so3215019ott.9 for ; Wed, 28 Jul 2021 12:22:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brightbytes.net; s=google; h=mime-version:from:date:message-id:subject:to; bh=TbUvkSjv3o1ykcNyFCPEVR5nD6hGOXacqx74NfvMkgA=; b=BDsiRqUH/B9hqjdJIcI8geyvwDqAhYeROoSP43tP4TiyvhnUh1P/znvjAuReL8o87f ie1AmGSMph76u+xFiIBKG/EitX45zUZ6cU0N29msdhNVwzxEr8l193X8RHzcc+/hfa5Q yEkwIk7QhZ+JIRyDz8jqcj5Noz8TcjzB1Cq1g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TbUvkSjv3o1ykcNyFCPEVR5nD6hGOXacqx74NfvMkgA=; b=Xi331yJKWjWPIlGW0e6nYih9gBYIONlId939n8zyhXSxLWpr63H+uT/hUzlrjQfOT2 qFsT/DaJ82jm+tI9hpwfj3uXZqxWSwcHRspdzRuXRoCuyrAUcMEsmggYuCik+ugXhedK lNhhH8lIrDnXSUYj8uI1jNUlgrSa5exqkWazt2kyePNZRlLHLh/Q4X3PiaxN4Ulj6fBv NMaw4oK2aFgrHJHzmYr0fXUMwmIFJtlxM8cVeaD+z/Xl56NDCs5fr6u9WoVPXTAmn7zh 5uQ2wo8g7c6eL1x3snIQH9tSIMwdc3YTbnBQDMXPTYNF/Ea+TIzp1TmYvzWnrmVV4oi3 5AQA== X-Gm-Message-State: AOAM533Aw9S49EOrgb1AAFtuYGRjYGTcXcNNh12HtqPawPNVGutJYhBa qp+DGYayl1VrTD8IfEpv0rfJ+v0qgRn2bJgg+F8kIj/I9aeB6a54 X-Google-Smtp-Source: ABdhPJx176kYnahUQe/EGHeckBdJmKI4EwVDoEhNNhyV1g9ulLFz3MeSgPKWktC/f0pNVsEtnhQLMTRCrJ4AZ5vPczE= X-Received: by 2002:a9d:74c1:: with SMTP id a1mr1079657otl.129.1627500167523; Wed, 28 Jul 2021 12:22:47 -0700 (PDT) MIME-Version: 1.0 From: Aaron Cohen Date: Wed, 28 Jul 2021 12:22:12 -0700 Message-ID: Subject: file-cache-minibuffer-complete has become unusable for duplicate file names in MacOSX 27.x emacs To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary="0000000000005b884b05c833e9e9" Received-SPF: pass client-ip=2607:f8b0:4864:20::334; envelope-from=aaron@brightbytes.net; helo=mail-ot1-x334.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Wed, 28 Jul 2021 15:38:28 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --0000000000005b884b05c833e9e9 Content-Type: text/plain; charset="UTF-8" In previous versions of emacs for the last decade, ` file-cache-minibuffer-complete` (C-Tab) worked well for me. But in the MacOSX 27.x emacs series, it ceased to be able to handle duplicate file names with extensions. (It could never handle duplicate file names with no extension, but that never bothered me much, as the only files without extensions I need to visit are the Procfile and Gemfile in the root of the project trees, which are easy to find manually.) For example, I usually have around 5 projects in my file cache, and currently across those 5 projects there are 8 files named `dashboard.rb`. Previously, as soon as I'd gotten C-Tab to complete the file name to `dashboard.rb`, continuing to hit C-Tab would cycle through the 8 files in their various directories. But starting in the 27.x series, C-Tab gets "stuck" on the first file named `dashboard.rb`, and refuses to cycle through the remaining files with that name. (And again, this is always the behavior it has exhibited for files without extensions: it gets stuck on the first instance, refusing to cycle through additional instances.) Also, perhaps relevantly, the behavior of the point while hitting C-Tab repeatedly on an incomplete file name changed in version 27: it now jumps to the beginning of the file name while the name is partially complete. (In previous versions, it would remain at the end of incomplete file names, or wherever I'd moved it to in the minibuffer.) Thanks for any assistance you can provide!! --0000000000005b884b05c833e9e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In previous versions of emacs for the last d= ecade, `file-cache-minibuffer-complete` (C-Tab) worked well for me.
=

But in the MacOSX 27.x emacs series, = it ceased to be able to handle duplicate file names with extensions. =C2=A0= (It could never handle duplicate file names with no extension, but that nev= er bothered me much,=C2=A0as the only files without extensions I need to vi= sit are the Procfile and Gemfile in the root of the project trees, which ar= e easy to find manually.)

For ex= ample, I usually have around 5 projects in my file cache, and currently acr= oss those 5 projects there are 8 files named=C2=A0`dashboard.rb`.

Previously, as soon as I'd gotten C-T= ab to complete the file name to `dashboard.rb`, continuing to hit C-Tab wou= ld cycle through the 8 files in their various directories.

But starting in the 27.x series, C-Tab gets &qu= ot;stuck" on the first file named=C2=A0`dashboard.rb`, and refuses to = cycle through the remaining files with that name. =C2=A0(And again, this is= always the behavior it has exhibited for files without extensions: it gets= stuck on the first instance, refusing to cycle through additional instance= s.)

Also, perhaps relevantly, th= e behavior of the point while hitting C-Tab repeatedly on an incomplete fil= e name changed in version 27: it now jumps to the beginning of the file nam= e while the name is partially complete. =C2=A0(In previous versions, it wou= ld remain at the end of incomplete file names, or wherever I'd moved it= to in the minibuffer.)

Thanks f= or any assistance you can provide!!
--0000000000005b884b05c833e9e9-- From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 29 13:57:51 2021 Received: (at 49761) by debbugs.gnu.org; 29 Jul 2021 17:57:51 +0000 Received: from localhost ([127.0.0.1]:58222 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9AI3-0004aA-Cx for submit@debbugs.gnu.org; Thu, 29 Jul 2021 13:57:51 -0400 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:47651) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9AHz-0004Zi-S3 for 49761@debbugs.gnu.org; Thu, 29 Jul 2021 13:57:48 -0400 Received: (Authenticated sender: juri@linkov.net) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 62DDAC0005; Thu, 29 Jul 2021 17:57:39 +0000 (UTC) From: Juri Linkov To: Aaron Cohen Subject: Re: bug#49761: file-cache-minibuffer-complete has become unusable for duplicate file names in MacOSX 27.x emacs Organization: LINKOV.NET References: Date: Thu, 29 Jul 2021 20:55:29 +0300 In-Reply-To: (Aaron Cohen's message of "Wed, 28 Jul 2021 12:22:12 -0700") Message-ID: <87o8alvwby.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 49761 Cc: 49761@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > Thanks for any assistance you can provide!! It would be nice to have a minimal reproducible test case. What I've tried is to create a minimal set of files with: mkdir -p /tmp/a/ ; touch /tmp/a/Procfile /tmp/a/dashboard.rb mkdir -p /tmp/b/ ; touch /tmp/b/Procfile /tmp/b/dashboard.rb mkdir -p /tmp/c/ ; touch /tmp/c/Procfile /tmp/c/dashboard.rb Then after adding them to the cache with: (file-cache-add-directory-list '("/tmp/a" "/tmp/b" "/tmp/c")) typing 'C-x C-f d C-TAB' cycles them correctly: Find file: /tmp/c/dashboard.rb [1 of 3] Find file: /tmp/b/dashboard.rb [2 of 3] Find file: /tmp/a/dashboard.rb [3 of 3] The same for 'C-x C-f P C-TAB' that cycles the files without file extensions correctly as well: Find file: /tmp/c/Procfile [1 of 3] Find file: /tmp/b/Procfile [2 of 3] Find file: /tmp/a/Procfile [3 of 3] This works in the development version 28.0.50 without any significant changes in filecache.el for a long time. Do you see the same problems when running emacs with -Q without customization? From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 29 14:14:39 2021 Received: (at 49761) by debbugs.gnu.org; 29 Jul 2021 18:14:39 +0000 Received: from localhost ([127.0.0.1]:58235 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9AYI-0004yh-Tq for submit@debbugs.gnu.org; Thu, 29 Jul 2021 14:14:39 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58436) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9AYI-0004yR-3d for 49761@debbugs.gnu.org; Thu, 29 Jul 2021 14:14:38 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44584) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m9AYB-0003VV-RC; Thu, 29 Jul 2021 14:14:31 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3642 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m9AYB-0003tx-E7; Thu, 29 Jul 2021 14:14:31 -0400 Date: Thu, 29 Jul 2021 21:14:10 +0300 Message-Id: <83bl6lrnrh.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <87o8alvwby.fsf@mail.linkov.net> (message from Juri Linkov on Thu, 29 Jul 2021 20:55:29 +0300) Subject: Re: bug#49761: file-cache-minibuffer-complete has become unusable for duplicate file names in MacOSX 27.x emacs References: <87o8alvwby.fsf@mail.linkov.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49761 Cc: 49761@debbugs.gnu.org, aaron@brightbytes.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Juri Linkov > Date: Thu, 29 Jul 2021 20:55:29 +0300 > Cc: 49761@debbugs.gnu.org > > Do you see the same problems when running emacs with -Q > without customization? What about the second part of the report, with cursor positioning after typing an incomplete file name followed by C-TAB: do you see that problem in your testing? From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 29 14:32:58 2021 Received: (at 49761) by debbugs.gnu.org; 29 Jul 2021 18:32:58 +0000 Received: from localhost ([127.0.0.1]:58263 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9Aq2-0005RJ-JN for submit@debbugs.gnu.org; Thu, 29 Jul 2021 14:32:58 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:55029) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9Aq1-0005R5-SX for 49761@debbugs.gnu.org; Thu, 29 Jul 2021 14:32:58 -0400 Received: (Authenticated sender: juri@linkov.net) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 6DF5860002; Thu, 29 Jul 2021 18:32:49 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#49761: file-cache-minibuffer-complete has become unusable for duplicate file names in MacOSX 27.x emacs Organization: LINKOV.NET References: <87o8alvwby.fsf@mail.linkov.net> <83bl6lrnrh.fsf@gnu.org> Date: Thu, 29 Jul 2021 21:31:52 +0300 In-Reply-To: <83bl6lrnrh.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 29 Jul 2021 21:14:10 +0300") Message-ID: <878s1pvunb.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 49761 Cc: 49761@debbugs.gnu.org, aaron@brightbytes.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> Do you see the same problems when running emacs with -Q >> without customization? > > What about the second part of the report, with cursor positioning > after typing an incomplete file name followed by C-TAB: do you see > that problem in your testing? No problem with cursor positioning. filecache.el uses minibuffer-message, and it works fine in testing with 'emacs -Q'. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 29 15:29:36 2021 Received: (at 49761) by debbugs.gnu.org; 29 Jul 2021 19:29:36 +0000 Received: from localhost ([127.0.0.1]:58296 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9Bip-0006jV-VF for submit@debbugs.gnu.org; Thu, 29 Jul 2021 15:29:36 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45342) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9Bin-0006jI-RH for 49761@debbugs.gnu.org; Thu, 29 Jul 2021 15:29:34 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46390) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m9Bii-0003zP-BA; Thu, 29 Jul 2021 15:29:28 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4236 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m9Bih-0002ZD-IX; Thu, 29 Jul 2021 15:29:28 -0400 Date: Thu, 29 Jul 2021 22:29:06 +0300 Message-Id: <838s1osyv1.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <878s1pvunb.fsf@mail.linkov.net> (message from Juri Linkov on Thu, 29 Jul 2021 21:31:52 +0300) Subject: Re: bug#49761: file-cache-minibuffer-complete has become unusable for duplicate file names in MacOSX 27.x emacs References: <87o8alvwby.fsf@mail.linkov.net> <83bl6lrnrh.fsf@gnu.org> <878s1pvunb.fsf@mail.linkov.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49761 Cc: 49761@debbugs.gnu.org, aaron@brightbytes.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Juri Linkov > Cc: aaron@brightbytes.net, 49761@debbugs.gnu.org > Date: Thu, 29 Jul 2021 21:31:52 +0300 > > >> Do you see the same problems when running emacs with -Q > >> without customization? > > > > What about the second part of the report, with cursor positioning > > after typing an incomplete file name followed by C-TAB: do you see > > that problem in your testing? > > No problem with cursor positioning. Strange, that's not what I see. If I type "C-x C-f", type a few characters that should match several file names, then press C-TAB, the cursor is placed on the first character I typed, making more typing cumbersome, because I need first type C-e or somesuch to get to the end of what I typed. Isn't that what you see? From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 29 15:41:31 2021 Received: (at 49761) by debbugs.gnu.org; 29 Jul 2021 19:41:31 +0000 Received: from localhost ([127.0.0.1]:58309 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9BuN-00071f-8g for submit@debbugs.gnu.org; Thu, 29 Jul 2021 15:41:31 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:43141) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9BuM-00071N-Ba for 49761@debbugs.gnu.org; Thu, 29 Jul 2021 15:41:30 -0400 Received: (Authenticated sender: juri@linkov.net) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 0E8D460005; Thu, 29 Jul 2021 19:41:22 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#49761: file-cache-minibuffer-complete has become unusable for duplicate file names in MacOSX 27.x emacs Organization: LINKOV.NET References: <87o8alvwby.fsf@mail.linkov.net> <83bl6lrnrh.fsf@gnu.org> <878s1pvunb.fsf@mail.linkov.net> <838s1osyv1.fsf@gnu.org> Date: Thu, 29 Jul 2021 22:40:44 +0300 In-Reply-To: <838s1osyv1.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 29 Jul 2021 22:29:06 +0300") Message-ID: <87y29ovrgj.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 49761 Cc: 49761@debbugs.gnu.org, aaron@brightbytes.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> > What about the second part of the report, with cursor positioning >> > after typing an incomplete file name followed by C-TAB: do you see >> > that problem in your testing? >> >> No problem with cursor positioning. > > Strange, that's not what I see. If I type "C-x C-f", type a few > characters that should match several file names, then press C-TAB, the > cursor is placed on the first character I typed, making more typing > cumbersome, because I need first type C-e or somesuch to get to the > end of what I typed. Isn't that what you see? In my testing the cursor is placed at the end of the minibuffer. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 29 18:51:09 2021 Received: (at 49761) by debbugs.gnu.org; 29 Jul 2021 22:51:09 +0000 Received: from localhost ([127.0.0.1]:58444 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9Ert-0005Go-7Z for submit@debbugs.gnu.org; Thu, 29 Jul 2021 18:51:09 -0400 Received: from relay9-d.mail.gandi.net ([217.70.183.199]:57983) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9Ers-0005GZ-65 for 49761@debbugs.gnu.org; Thu, 29 Jul 2021 18:51:08 -0400 Received: (Authenticated sender: juri@linkov.net) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id 3E9A2FF802; Thu, 29 Jul 2021 22:51:00 +0000 (UTC) From: Juri Linkov To: Aaron Cohen Subject: Re: bug#49761: file-cache-minibuffer-complete has become unusable for duplicate file names in MacOSX 27.x emacs Organization: LINKOV.NET References: <87o8alvwby.fsf@mail.linkov.net> <83bl6lrnrh.fsf@gnu.org> <878s1pvunb.fsf@mail.linkov.net> <838s1osyv1.fsf@gnu.org> <87y29ovrgj.fsf@mail.linkov.net> Date: Fri, 30 Jul 2021 01:49:18 +0300 In-Reply-To: (Aaron Cohen's message of "Thu, 29 Jul 2021 14:37:41 -0700") Message-ID: <87v94su45t.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 49761 Cc: Eli Zaretskii , 49761@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > The `-Q` option wasn't working for me, so I stripped everything out of my > `init.el` except a few `global-set-key` forms and the initialization of the > file cache, presented below. > > Both the new cursor behavior and the failure to cycle through duplicate > file names still reproduce. > > Here's the start of how I load `filecache`: the same procedure is followed > for 4 other projects: > [...] > (file-cache-add-directory "~/git/clarity_early_warning") > (file-cache-add-directory-using-find "~/git/clarity_early_warning/app") > ;; ... etc ... Thanks, now I tried to add two separate emacs/lisp trees with file-cache-add-directory-using-find that gives such results: 1. 'filec C-TAB' cycles between 2 filecache.el files from both Emacs repos; 2. 'README C-TAB' cycles between 4 README files, two files from each tree, that shows that it can cycle between duplicate files without extensions; 3. 'TAGS C-TAB' gets stuck with the message [File Cache: complete but not unique] Do you see the same message? 4. 'make C-TAB' then the completions buffer is displayed and the cursor jumps to the beginning because there are completions that don't begin with the same prefix "make" such as flymake.el, pmake.el, ob-makefile.el. But the cursor doesn't jump to the beginning when all completions share the same prefix, e.g. 'fly C-TAB' that displays flymake.el and flyspell.el. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 29 18:52:13 2021 Received: (at 49761) by debbugs.gnu.org; 29 Jul 2021 22:52:13 +0000 Received: from localhost ([127.0.0.1]:58447 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9Esu-0005IM-HQ for submit@debbugs.gnu.org; Thu, 29 Jul 2021 18:52:13 -0400 Received: from mail-oi1-f178.google.com ([209.85.167.178]:37498) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9DjT-0003XD-36 for 49761@debbugs.gnu.org; Thu, 29 Jul 2021 17:38:23 -0400 Received: by mail-oi1-f178.google.com with SMTP id u10so10304530oiw.4 for <49761@debbugs.gnu.org>; Thu, 29 Jul 2021 14:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brightbytes.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4/97KEdI3yRt8ChJQln/jpRDGv2aISAsDOlJwj1jrnw=; b=WlND9/gx1CzvgJ3IvbHsViZkxo79YBizFPdPTWR4q8KaX8dTvmj2G1ej9ssBkHKTmi UgQydUCJv0bBz9O0dMtIjdBQnZEWMVkz5/DM2BXjD1hxhy+0y3z/axoO8VhedfpV7Ewj nrVmP9lF7fJpUEieJKafUCP2NEtfZRw+SvcA0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4/97KEdI3yRt8ChJQln/jpRDGv2aISAsDOlJwj1jrnw=; b=ATTYZGv0Fe0r3Bp4RNSfZUN4UdraiXZutnUncpJNMyVpfqXU1v7CG9Zgs8YToJUOd6 Ok55bfsOtCVOhByhf50JktRznmjzsjf7V7RmX5yoBJfJVtLTsm65ap841iUATdPI+B5e 7SoxUGaDf4slmku0LMiEZwdciKUonvm/N8KYgDSOreT0TVvNhEwzs4c7fLTfiSmpw06P FgHkCcTLdNUZSNjX/afA4UcC41MMszzd2jig6k1IatgpzP5s95i0Au/O+nvCufAlHwmZ M6H0Ycm7OFMlcif3dO/lr9LMqaxBDIImBNDzBc9RESjNRCmPUPtZtvrd5zM5Fo/4e2Oo 4Haw== X-Gm-Message-State: AOAM531xbpcqc5Gk0CO0IY0ySQbbbHCBqeYW4mU95dNejoy6954mdG+D KIELYwtlyPQHkAPUuXToGDPJkK/SefI8rOSLSo4hFw== X-Google-Smtp-Source: ABdhPJx0zFbZ1UFekJpkfrSnKtztIz+LKwpq+Pcq792cCMBmZfI3OS8ht9BzA9ZxOufsjoyERO62mKaCkUvy/eu3Rg8= X-Received: by 2002:aca:2b07:: with SMTP id i7mr11732124oik.97.1627594697351; Thu, 29 Jul 2021 14:38:17 -0700 (PDT) MIME-Version: 1.0 References: <87o8alvwby.fsf@mail.linkov.net> <83bl6lrnrh.fsf@gnu.org> <878s1pvunb.fsf@mail.linkov.net> <838s1osyv1.fsf@gnu.org> <87y29ovrgj.fsf@mail.linkov.net> In-Reply-To: <87y29ovrgj.fsf@mail.linkov.net> From: Aaron Cohen Date: Thu, 29 Jul 2021 14:37:41 -0700 Message-ID: Subject: Re: bug#49761: file-cache-minibuffer-complete has become unusable for duplicate file names in MacOSX 27.x emacs To: Juri Linkov Content-Type: multipart/alternative; boundary="000000000000c636f505c849eb7d" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 49761 X-Mailman-Approved-At: Thu, 29 Jul 2021 18:52:11 -0400 Cc: Eli Zaretskii , 49761@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000c636f505c849eb7d Content-Type: text/plain; charset="UTF-8" The `-Q` option wasn't working for me, so I stripped everything out of my `init.el` except a few `global-set-key` forms and the initialization of the file cache, presented below. Both the new cursor behavior and the failure to cycle through duplicate file names still reproduce. Here's the start of how I load `filecache`: the same procedure is followed for 4 other projects: ``` ;; NOTE - WHEN THE FILECACHE GOES BAD, NUKE ALL FILES MATCHING THE PATTERN .#* IN THESE DIRECTORY TREES (require 'filecache) ;; Add all files under dir to file (eval-after-load "filecache" '(progn (file-cache-add-directory "~/git/clarity_early_warning") (file-cache-add-directory-using-find "~/git/clarity_early_warning/app") (file-cache-add-directory-using-find "~/git/clarity_early_warning/bin") (file-cache-add-directory-using-find "~/git/clarity_early_warning/config") (file-cache-add-directory-using-find "~/git/clarity_early_warning/db") (file-cache-add-directory-using-find "~/git/clarity_early_warning/lib") (file-cache-add-directory-using-find "~/git/clarity_early_warning/spec") ;; ... etc ... ``` On Thu, Jul 29, 2021 at 12:41 PM Juri Linkov wrote: > >> > What about the second part of the report, with cursor positioning > >> > after typing an incomplete file name followed by C-TAB: do you see > >> > that problem in your testing? > >> > >> No problem with cursor positioning. > > > > Strange, that's not what I see. If I type "C-x C-f", type a few > > characters that should match several file names, then press C-TAB, the > > cursor is placed on the first character I typed, making more typing > > cumbersome, because I need first type C-e or somesuch to get to the > > end of what I typed. Isn't that what you see? > > In my testing the cursor is placed at the end of the minibuffer. > --000000000000c636f505c849eb7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The `-Q` option wasn't working for me, s= o I stripped everything out of my `init.el` except a few `global-set-key` f= orms and the initialization of the file cache, presented below.

Both the new cursor behavior and the failur= e to cycle through duplicate file names still reproduce.

Here's the start of how I load `filecache`: th= e same procedure is followed for 4 other projects:

<= /div>
```
;; NOTE - WHEN THE FILECACHE GOES= BAD, NUKE ALL FILES MATCHING THE PATTERN .#* IN THESE DIRECTORY TREES
(= require 'filecache)
;; Add all files under dir to file
(eval-afte= r-load
=C2=A0 =C2=A0 "filecache"
=C2=A0 '(progn

= =C2=A0 =C2=A0 =C2=A0(file-cache-add-directory "~/git/clarity_early_war= ning")
=C2=A0 =C2=A0 =C2=A0(file-cache-add-directory-using-find &qu= ot;~/git/clarity_early_warning/app")
=C2=A0 =C2=A0 =C2=A0(file-cach= e-add-directory-using-find "~/git/clarity_early_warning/bin")
= =C2=A0 =C2=A0 =C2=A0(file-cache-add-directory-using-find "~/git/clarit= y_early_warning/config")
=C2=A0 =C2=A0 =C2=A0(file-cache-add-direct= ory-using-find "~/git/clarity_early_warning/db")
=C2=A0 =C2=A0= =C2=A0(file-cache-add-directory-using-find "~/git/clarity_early_warni= ng/lib")
=C2=A0 =C2=A0 =C2=A0(file-cache-add-directory-using-find &= quot;~/git/clarity_early_warning/spec")

;; = ... etc ...
```


=
On Thu, Ju= l 29, 2021 at 12:41 PM Juri Linkov <j= uri@linkov.net> wrote:
>> > What = about the second part of the report, with cursor positioning
>> > after typing an incomplete file name followed by C-TAB: do yo= u see
>> > that problem in your testing?
>>
>> No problem with cursor positioning.
>
> Strange, that's not what I see.=C2=A0 If I type "C-x C-f"= ;, type a few
> characters that should match several file names, then press C-TAB, the=
> cursor is placed on the first character I typed, making more typing > cumbersome, because I need first type C-e or somesuch to get to the > end of what I typed.=C2=A0 Isn't that what you see?

In my testing the cursor is placed at the end of the minibuffer.
--000000000000c636f505c849eb7d-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 30 01:50:30 2021 Received: (at 49761) by debbugs.gnu.org; 30 Jul 2021 05:50:30 +0000 Received: from localhost ([127.0.0.1]:58792 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9LPi-0006tR-03 for submit@debbugs.gnu.org; Fri, 30 Jul 2021 01:50:30 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47442) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9LPh-0006tG-1Q for 49761@debbugs.gnu.org; Fri, 30 Jul 2021 01:50:29 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:33072) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m9LPb-0002V1-4I; Fri, 30 Jul 2021 01:50:23 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2317 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m9LPa-0007Kc-PH; Fri, 30 Jul 2021 01:50:23 -0400 Date: Fri, 30 Jul 2021 08:50:06 +0300 Message-Id: <8335rws641.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <87v94su45t.fsf@mail.linkov.net> (message from Juri Linkov on Fri, 30 Jul 2021 01:49:18 +0300) Subject: Re: bug#49761: file-cache-minibuffer-complete has become unusable for duplicate file names in MacOSX 27.x emacs References: <87o8alvwby.fsf@mail.linkov.net> <83bl6lrnrh.fsf@gnu.org> <878s1pvunb.fsf@mail.linkov.net> <838s1osyv1.fsf@gnu.org> <87y29ovrgj.fsf@mail.linkov.net> <87v94su45t.fsf@mail.linkov.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49761 Cc: 49761@debbugs.gnu.org, aaron@brightbytes.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Juri Linkov > Cc: Eli Zaretskii , 49761@debbugs.gnu.org > Date: Fri, 30 Jul 2021 01:49:18 +0300 > > 4. 'make C-TAB' then the completions buffer is displayed and the cursor > jumps to the beginning because there are completions that don't begin > with the same prefix "make" such as flymake.el, pmake.el, ob-makefile.el. Is this reasonable behavior? It seems to try second-guessing what the user will do next, but that guess is not necessarily correct. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 30 03:02:24 2021 Received: (at 49761) by debbugs.gnu.org; 30 Jul 2021 07:02:24 +0000 Received: from localhost ([127.0.0.1]:58868 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9MXH-0000EY-Po for submit@debbugs.gnu.org; Fri, 30 Jul 2021 03:02:24 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55910) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9MXF-0000EA-2A for 49761@debbugs.gnu.org; Fri, 30 Jul 2021 03:02:22 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:33950) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m9MX8-0004yf-UH; Fri, 30 Jul 2021 03:02:14 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2883 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m9MX7-0000hZ-Dr; Fri, 30 Jul 2021 03:02:14 -0400 Date: Fri, 30 Jul 2021 10:01:54 +0300 Message-Id: <83r1fgqo7x.fsf@gnu.org> From: Eli Zaretskii To: Aaron Cohen In-Reply-To: (message from Aaron Cohen on Thu, 29 Jul 2021 23:41:12 -0700) Subject: Re: bug#49761: file-cache-minibuffer-complete has become unusable for duplicate file names in MacOSX 27.x emacs References: <87o8alvwby.fsf@mail.linkov.net> <83bl6lrnrh.fsf@gnu.org> <878s1pvunb.fsf@mail.linkov.net> <838s1osyv1.fsf@gnu.org> <87y29ovrgj.fsf@mail.linkov.net> <87v94su45t.fsf@mail.linkov.net> <8335rws641.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49761 Cc: 49761@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Aaron Cohen > Date: Thu, 29 Jul 2021 23:41:12 -0700 > Cc: Juri Linkov , 49761@debbugs.gnu.org > > In any case, the larger issue is that a prefix overlap is now causing C-Tab to get stuck. The point goes > where it should to assist the User in resolving the overlap. It's not where the point goes but rather that > Emacs gets stuck on the common suffix that is the new issue. I suggest to play with your value of completion-styles: perhaps by reordering it or by removing the more-aggressive styles from there you will be able to get your desired behavior. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 30 10:22:17 2021 Received: (at 49761) by debbugs.gnu.org; 30 Jul 2021 14:22:17 +0000 Received: from localhost ([127.0.0.1]:60660 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9TOy-0005fV-Kc for submit@debbugs.gnu.org; Fri, 30 Jul 2021 10:22:17 -0400 Received: from mail-oi1-f181.google.com ([209.85.167.181]:41689) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9MDS-00086X-6P for 49761@debbugs.gnu.org; Fri, 30 Jul 2021 02:41:55 -0400 Received: by mail-oi1-f181.google.com with SMTP id 21so11838569oin.8 for <49761@debbugs.gnu.org>; Thu, 29 Jul 2021 23:41:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brightbytes.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=puIynhILMeBIPLIjtWstV5/FFsjcb7bhsPzxfdX2GCM=; b=DQNzj9e1WJH/6J152TE8kPsCR70TkRTElReXoOCprIkWb6gSNbQJG5uUQJon7/45SB 7d476a6gvAwEY6iTEK0SWvImGBWiqVaJyDXl2ejbU/Lf3Ztuh8tD+bw/W26nwaKT6UVH 1tO3RgkLF4IkxRc2ttVgisXAibXVhqqvFEHng= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=puIynhILMeBIPLIjtWstV5/FFsjcb7bhsPzxfdX2GCM=; b=qAibBbkxDDqDetix/iOUc+b+iEbj4TN8SNiAv36uoIMwsU8Z7Zr+f7g9y0rYzOEVJS WO9jrQN3FPB0nlbIVbOdyNb2jsQRHXySSMmq/OC1X6EF0FwA+jpq6w2TpwU49tijJc1w gyzJDBUt0LjDvA6KPa25ORgQZO5E+TTebox1VgwqR/k88ziCb1LJyBHqkuEPG9NwckcQ zWiyAGUy80/Puk3/jgCHZR2lzi3tVtpZBaSyn4SS+T5gWZ1/bk3fwLqquKzYHGUQ1JPw FS2KGRn6JZsaqfUOroydXrqpzyIZeY+7poQHkKNWDdjrE1nAvaCEoh0n+fYrlGbl6LDT UttA== X-Gm-Message-State: AOAM530v+Nd18RP9VDixq86pfCkVoqdEB8L1nuxlsbvfyvUC+Xepg74M oXkbAH4n/KUY7PoZhbURPhxtvMEoqVT25Lrt+dkguA== X-Google-Smtp-Source: ABdhPJyBVThVuaLavAGserswRs8jt+bjO8ZsHAMh/JU0mVBqFEDhYmIzsAwPkMx4Erf7xHAkCZ0JVDF5S5w0dwMoNKQ= X-Received: by 2002:a05:6808:144a:: with SMTP id x10mr852810oiv.68.1627627308371; Thu, 29 Jul 2021 23:41:48 -0700 (PDT) MIME-Version: 1.0 References: <87o8alvwby.fsf@mail.linkov.net> <83bl6lrnrh.fsf@gnu.org> <878s1pvunb.fsf@mail.linkov.net> <838s1osyv1.fsf@gnu.org> <87y29ovrgj.fsf@mail.linkov.net> <87v94su45t.fsf@mail.linkov.net> <8335rws641.fsf@gnu.org> In-Reply-To: <8335rws641.fsf@gnu.org> From: Aaron Cohen Date: Thu, 29 Jul 2021 23:41:12 -0700 Message-ID: Subject: Re: bug#49761: file-cache-minibuffer-complete has become unusable for duplicate file names in MacOSX 27.x emacs To: Eli Zaretskii Content-Type: multipart/alternative; boundary="0000000000008ae33405c8518310" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 49761 X-Mailman-Approved-At: Fri, 30 Jul 2021 10:22:15 -0400 Cc: 49761@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000008ae33405c8518310 Content-Type: text/plain; charset="UTF-8" Comments: 2. The cycling is broken if you have one file without an extension with a given name and another file with the same name and an extension. For example, all 5 of my projects are currently Ruby on Rails repos. Every RoR project has a `Gemfile` and a `Gemfile.lock`. When I try to find a particular Gemfile, C-Tab gets stuck on the first one. This has always been the case with C-Tab, so it doesn't bother me, though if there is a workaround I'd love to know it. 3. Yes, I see the message "[File Cache: complete but not unique]" whenever it gets stuck. This has always been the case for 2, above, and in Emacs 27.x (and presumably 28.x) it is the case when a duplicated file has a duplicate and also another file with a similar ending. In my case, there are 9 files named `dashboard.rb` across several projects, and even more files across several projects that follow the pattern `*_dashboard.rb`. 4. The cursor-jumping-to-the-beginning-of-the-filename behavior is new in Emacs 27.x. It doesn't happen in case 2, above ... though that's because the overlap termination location in that case is at the end of the completed file name (the dot in `Gemfile.lock`). Whereas in the new behavior, the overlap termination location is at the beginning (e.g. in my project, the underscore in `db_dashboard.rb` or `homepage_dashboard.rb`). In any case, the larger issue is that a prefix overlap is now causing C-Tab to get stuck. The point goes where it should to assist the User in resolving the overlap. It's not where the point goes but rather that Emacs gets stuck on the common suffix that is the new issue. On Thu, Jul 29, 2021 at 10:50 PM Eli Zaretskii wrote: > > From: Juri Linkov > > Cc: Eli Zaretskii , 49761@debbugs.gnu.org > > Date: Fri, 30 Jul 2021 01:49:18 +0300 > > > > 4. 'make C-TAB' then the completions buffer is displayed and the cursor > > jumps to the beginning because there are completions that don't begin > > with the same prefix "make" such as flymake.el, pmake.el, > ob-makefile.el. > > Is this reasonable behavior? It seems to try second-guessing what the > user will do next, but that guess is not necessarily correct. > --0000000000008ae33405c8518310 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Comments:

2. The cycling is broken if you have one file without an extension= with a given name and another file with the same name and an extension.=C2= =A0 For example, all 5 of my projects are currently Ruby on Rails repos.=C2= =A0 Every RoR project has a `Gemfile` and a `Gemfile.lock`.=C2=A0 When I tr= y to find a particular Gemfile, C-Tab gets stuck on the first one.=C2=A0 Th= is has always been the case with C-Tab, so it doesn't bother me, though= if there is a workaround I'd love to know it.

<= /div>
3. Yes, I see the message "[File Cache: complete but not unique]= " whenever it gets stuck.=C2=A0 This has always been the case for 2, a= bove, and in Emacs 27.x (and presumably 28.x) it is the case when a duplica= ted file has a duplicate and also another file with a similar ending.=C2=A0= In my case, there are 9 files named `dashboard.rb` across several projects= , and even more files across several projects that follow the pattern `*_da= shboard.rb`.

4. The cursor-jumpi= ng-to-the-beginning-of-the-filename behavior is new in Emacs 27.x.=C2=A0 It= doesn't happen in case 2, above ... though=C2=A0that's because the= overlap termination location in that case is at the end of the completed f= ile name (the dot in `Gemfile.lock`). Whereas in the new behavior, the over= lap termination location is at the beginning (e.g. in my project, the under= score in `db_dashboard.rb` or `homepage_dashboard.rb`). =C2=A0

In any case, the larger issue is that a pref= ix overlap=C2=A0is now causing C-Tab to get stuck.=C2=A0 The point goes whe= re it should to assist the User in resolving the overlap.=C2=A0 It's no= t where the point goes but rather that Emacs gets stuck on the common suffi= x that is the new issue.





=


On Thu, Jul 29, 2021 at 10:50 PM Eli Zaretskii <= eliz@gnu.org> wrote:
> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,=C2=A0 49761@debbugs.gnu.org
> Date: Fri, 30 Jul 2021 01:49:18 +0300
>
> 4. 'make C-TAB' then the completions buffer is displayed and t= he cursor
>=C2=A0 =C2=A0 jumps to the beginning because there are completions that= don't begin
>=C2=A0 =C2=A0 with the same prefix "make" such as flymake.el,= pmake.el, ob-makefile.el.

Is this reasonable behavior?=C2=A0 It seems to try second-guessing what the=
user will do next, but that guess is not necessarily correct.
--0000000000008ae33405c8518310-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 30 14:03:39 2021 Received: (at 49761) by debbugs.gnu.org; 30 Jul 2021 18:03:39 +0000 Received: from localhost ([127.0.0.1]:60858 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9WrD-0002vZ-EZ for submit@debbugs.gnu.org; Fri, 30 Jul 2021 14:03:39 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:38605) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9WrC-0002vJ-DU for 49761@debbugs.gnu.org; Fri, 30 Jul 2021 14:03:38 -0400 Received: (Authenticated sender: juri@linkov.net) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id D5B7C60008; Fri, 30 Jul 2021 18:03:30 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#49761: file-cache-minibuffer-complete has become unusable for duplicate file names in MacOSX 27.x emacs Organization: LINKOV.NET References: <87o8alvwby.fsf@mail.linkov.net> <83bl6lrnrh.fsf@gnu.org> <878s1pvunb.fsf@mail.linkov.net> <838s1osyv1.fsf@gnu.org> <87y29ovrgj.fsf@mail.linkov.net> <87v94su45t.fsf@mail.linkov.net> <8335rws641.fsf@gnu.org> Date: Fri, 30 Jul 2021 20:58:55 +0300 In-Reply-To: <8335rws641.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 30 Jul 2021 08:50:06 +0300") Message-ID: <87lf5nisyo.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 49761 Cc: 49761@debbugs.gnu.org, aaron@brightbytes.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> 4. 'make C-TAB' then the completions buffer is displayed and the cursor >> jumps to the beginning because there are completions that don't begin >> with the same prefix "make" such as flymake.el, pmake.el, ob-makefile.el. > > Is this reasonable behavior? It seems to try second-guessing what the > user will do next, but that guess is not necessarily correct. I don't know, this is the default behavior for completions that don't share a common prefix. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 30 14:33:06 2021 Received: (at 49761) by debbugs.gnu.org; 30 Jul 2021 18:33:06 +0000 Received: from localhost ([127.0.0.1]:60897 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9XJh-0005nl-OL for submit@debbugs.gnu.org; Fri, 30 Jul 2021 14:33:06 -0400 Received: from mail-ot1-f51.google.com ([209.85.210.51]:39632) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9X8W-0005VR-RX for 49761@debbugs.gnu.org; Fri, 30 Jul 2021 14:21:33 -0400 Received: by mail-ot1-f51.google.com with SMTP id f20-20020a9d6c140000b02904bb9756274cso10440602otq.6 for <49761@debbugs.gnu.org>; Fri, 30 Jul 2021 11:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brightbytes.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DLuZ5MKZABD5/M2PPFgksARdXL6LILbC+cCvSXuJmEg=; b=XvNvMvs52HKwiiVlAe9qOMkQn+nGOrZG3v6eclV8ZGokJfPeWGq0En5syFp6LtdYks gakCBQiCgTnBiPzRw+rDp4llgVgTXUv/WbZQsMZJ4KsuvMhWFmfZwLX2ZfNaiiLn0uSR mLQzd4urk1UB4ayqdlia0qdBxhW1+lZACZJP0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DLuZ5MKZABD5/M2PPFgksARdXL6LILbC+cCvSXuJmEg=; b=g1BeAqmWjU3vFsie2lMsfE/jhJokXUXzvq/RF0qv4d+enOQ7Kpw09Vd8u8M8Z7FIrD oh3sOqQmA6RHsdwdZTNAQbEqwx8LP+W7F2Oxdu8gHnXa/4n+eVu3Wd+ZVq49cnaV4vYn Cp3qR5v29ymO/Sb5XsKQG2skMHoPiSGvagHH51imMPpIEu8QurYkww2qMqaELNept83N bikL6TGb0fSy64zvO/ymeeCb6YCBErbquW3x3qrowHvW3kUkO73ot8bk+kx+Yw3HYngt /0pLARHf8jwngfjpmBBBv77AXS3FXbgC/uA4uvu30VqfspZBwSNV2ZpCdDFvfokI9rUz Liog== X-Gm-Message-State: AOAM530FfLlRGQX9ppQcZZvBURcHm4UxD/a6XNi1HL1y5yKduURy3IGE lwsXdJCk6ruYztHfjkU86JHts/trpr9SHp6hPde4d0UhNgpAo9dn X-Google-Smtp-Source: ABdhPJyUgBvXh7gsJACZvysBKCAKrVKFZwIh9vSN6i9EWqN1q+OiFfscxTD/kpn1XY1XL5Sjvf14M2cbnWeRPV05kBo= X-Received: by 2002:a05:6830:2a0f:: with SMTP id y15mr3100792otu.198.1627669287021; Fri, 30 Jul 2021 11:21:27 -0700 (PDT) MIME-Version: 1.0 References: <87o8alvwby.fsf@mail.linkov.net> <83bl6lrnrh.fsf@gnu.org> <878s1pvunb.fsf@mail.linkov.net> <838s1osyv1.fsf@gnu.org> <87y29ovrgj.fsf@mail.linkov.net> <87v94su45t.fsf@mail.linkov.net> <8335rws641.fsf@gnu.org> <87lf5nisyo.fsf@mail.linkov.net> In-Reply-To: <87lf5nisyo.fsf@mail.linkov.net> From: Aaron Cohen Date: Fri, 30 Jul 2021 11:20:51 -0700 Message-ID: Subject: Re: bug#49761: file-cache-minibuffer-complete has become unusable for duplicate file names in MacOSX 27.x emacs To: Juri Linkov Content-Type: multipart/alternative; boundary="000000000000aa440b05c85b49de" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 49761 X-Mailman-Approved-At: Fri, 30 Jul 2021 14:33:04 -0400 Cc: Eli Zaretskii , 49761@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000aa440b05c85b49de Content-Type: text/plain; charset="UTF-8" Well, it's now the default behavior. It wasn't previously. :-) That is, I haven't changed my completion settings since the mid-90s (except the icomplete-mode, which I set up a decade ago) , and they all worked fine until emacs 27. They look like this: ;;; Shows globs of possible completions in minibuffer (setq-default completion-auto-help t) ;;; Case-insensitive file and buff (setq read-file-name-completion-ignore-case t) (setq read-buffer-completion-ignore-case t) ;;; Show completions in M-x (icomplete-mode 1) Oh, you mean https://www.gnu.org/software/emacs/manual/html_node/emacs/Completion-Styles.html `M-: completion-styles` shows the same thing in Emacs 26 and 27: '(basic partial-completion emacs22) In Emacs 27, I tried `(setq completion-styles '(basic emacs22))` and `(setq completion-styles '(emacs22))`, but the completion behavior remained broken. (Perhaps interestingly, when I tried `(setq completion-styles '(emacs22))` in Emacs 26, while it still got stuck on the first Gemfile, the minibuffer started showing me that the collision was caused by Gemfile.lock, which it never did before.) In any case, it seems like I'll need to stay with Emacs 26 for a while, as C-Tab is by far my most-used minibuffer command. On Fri, Jul 30, 2021 at 11:03 AM Juri Linkov wrote: > >> 4. 'make C-TAB' then the completions buffer is displayed and the cursor > >> jumps to the beginning because there are completions that don't begin > >> with the same prefix "make" such as flymake.el, pmake.el, > ob-makefile.el. > > > > Is this reasonable behavior? It seems to try second-guessing what the > > user will do next, but that guess is not necessarily correct. > > I don't know, this is the default behavior for completions > that don't share a common prefix. > --000000000000aa440b05c85b49de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well, it's = now the default behavior.=C2=A0 It wasn't previously. =C2=A0:-)

That is, = I haven't changed my completion settings since the mid-90s (except the = icomplete-mode, which I set up a decade ago)=C2=A0, and they all worked fine until emacs 27. =C2=A0=

T= hey look like this:

;;; Shows globs of possible completions in minibuffer
= (setq-default completion-auto-help t)

;;; Case-insensitive file and = buff
(setq read-file-name-completion-ignore-case t)
(setq read-buffer= -completion-ignore-case t)

;;; Show completions in M-x
(icomplete= -mode 1)

Oh, you mean https://www.gnu.org/softw= are/emacs/manual/html_node/emacs/Completion-Styles.html

`M-: completion-s= tyles` shows the same thing in Emacs 26 and 27: '(basic partial-complet= ion emacs22)=C2=A0

In Emacs 27, I tried `(setq completion-styles '(basi= c emacs22))` and `(setq completion-styles '(emacs22))`, but the complet= ion behavior remained broken.

<= div class=3D"gmail_default">(Perhaps interestingly, when I tried `(setq com= pletion-styles '(emacs22))` in Emacs 26, while it still got stuck on th= e first Gemfile, the minibuffer started showing me that the collision was c= aused by Gemfile.lock, which it never did before.)

In any case, it seems like= I'll need to stay with Emacs 26 for a while, as C-Tab is by far my mos= t-used minibuffer command.



On Fri, Jul 30, 2021 at 11:= 03 AM Juri Linkov <juri@linkov.net> wrote:
>> 4. 'make C-TAB' the= n the completions buffer is displayed and the cursor
>>=C2=A0 =C2=A0 jumps to the beginning because there are completions = that don't begin
>>=C2=A0 =C2=A0 with the same prefix "make" such as flymake= .el, pmake.el, ob-makefile.el.
>
> Is this reasonable behavior?=C2=A0 It seems to try second-guessing wha= t the
> user will do next, but that guess is not necessarily correct.

I don't know, this is the default behavior for completions
that don't share a common prefix.
--000000000000aa440b05c85b49de-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 30 14:48:25 2021 Received: (at 49761) by debbugs.gnu.org; 30 Jul 2021 18:48:25 +0000 Received: from localhost ([127.0.0.1]:60922 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9XYX-0006BN-6r for submit@debbugs.gnu.org; Fri, 30 Jul 2021 14:48:25 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36526) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9XYV-0006B9-4t for 49761@debbugs.gnu.org; Fri, 30 Jul 2021 14:48:23 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51622) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m9XYP-0007EU-6e; Fri, 30 Jul 2021 14:48:17 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2185 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m9XYO-0001HX-At; Fri, 30 Jul 2021 14:48:16 -0400 Date: Fri, 30 Jul 2021 21:47:59 +0300 Message-Id: <838s1nr63k.fsf@gnu.org> From: Eli Zaretskii To: Aaron Cohen In-Reply-To: (message from Aaron Cohen on Fri, 30 Jul 2021 11:20:51 -0700) Subject: Re: bug#49761: file-cache-minibuffer-complete has become unusable for duplicate file names in MacOSX 27.x emacs References: <87o8alvwby.fsf@mail.linkov.net> <83bl6lrnrh.fsf@gnu.org> <878s1pvunb.fsf@mail.linkov.net> <838s1osyv1.fsf@gnu.org> <87y29ovrgj.fsf@mail.linkov.net> <87v94su45t.fsf@mail.linkov.net> <8335rws641.fsf@gnu.org> <87lf5nisyo.fsf@mail.linkov.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49761 Cc: 49761@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Aaron Cohen > Date: Fri, 30 Jul 2021 11:20:51 -0700 > Cc: Eli Zaretskii , 49761@debbugs.gnu.org > > Well, it's now the default behavior. It wasn't previously. :-) I wasn't trying to find the reason for the change in behavior, I was trying to help you get the behavior you want back. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 30 15:13:22 2021 Received: (at 49761) by debbugs.gnu.org; 30 Jul 2021 19:13:22 +0000 Received: from localhost ([127.0.0.1]:60968 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9Xwc-0006w7-WB for submit@debbugs.gnu.org; Fri, 30 Jul 2021 15:13:22 -0400 Received: from mail-oi1-f169.google.com ([209.85.167.169]:46830) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9Xwa-0006vo-GR for 49761@debbugs.gnu.org; Fri, 30 Jul 2021 15:13:17 -0400 Received: by mail-oi1-f169.google.com with SMTP id o185so14493848oih.13 for <49761@debbugs.gnu.org>; Fri, 30 Jul 2021 12:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brightbytes.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xAGZT466YBL5sKkInpa7fx9GguvbnF3HM1ESaqFTdFA=; b=PnkcqufPzh3IPeEPWdPCX0Nm5MAWvpHTQhIOZOJ8vPWHEkhEalhDxoAVOy1jqSAD56 IYcFIwgVyeIVeFx9PPFROhuUQ1nev7ojA656uMeLjAV/TcVLgtxDSCeEFDKzPnECvXsu 4kjW0/Hykt+6W0kVYIfOOFuCRrpArYmz5CJcY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xAGZT466YBL5sKkInpa7fx9GguvbnF3HM1ESaqFTdFA=; b=Dn1Dd+eLuU+deNCJzb3xBFp0flmljFT1z7IBjA0aLUvwFT0VBwKtDvxNx5gnGof0Uz j3gkqm67CllbaEUEADRLMGfzOpxOkw41iSSDvZcMoFRW5dD1pAZ/JsX0a3r4ZOgF35w4 ADcZMqTLLVcPe/POIWXDG74CPlEv1f1zGE/XnWnJbuLpfJyLAIrTAhHa4k8OXgIR3yew ROXBv4a3QqjWbjAqYOyl7RPU552v+AmutyRGjWjIeJMZ7jbL/G2Lpdj+BHGgG47oW9mX S+BBCTIJFt0eCpkCXbnwN97n9twVCB7V2SzlnfRToLqngaQjHcWQyo/4dIkKo4g8f1eB oFdg== X-Gm-Message-State: AOAM530vFh9OHoqv7HE0PY/O+5T5r3XE+47brvsd6foep+ZAJdGZrjU6 qvMemUOvpqcnehXXHWH+9IahSuCcAIc9qJ2z/jgKwg== X-Google-Smtp-Source: ABdhPJytyJ4YYBYRjH3gj9tNREwJmtv8KizpASV0cWS7jF9USDEo4UxTfuTTa2f8oB4Biman/pFMqrcUmimKH0bn010= X-Received: by 2002:a05:6808:10d5:: with SMTP id s21mr2872394ois.7.1627672390799; Fri, 30 Jul 2021 12:13:10 -0700 (PDT) MIME-Version: 1.0 References: <87o8alvwby.fsf@mail.linkov.net> <83bl6lrnrh.fsf@gnu.org> <878s1pvunb.fsf@mail.linkov.net> <838s1osyv1.fsf@gnu.org> <87y29ovrgj.fsf@mail.linkov.net> <87v94su45t.fsf@mail.linkov.net> <8335rws641.fsf@gnu.org> <87lf5nisyo.fsf@mail.linkov.net> <838s1nr63k.fsf@gnu.org> In-Reply-To: <838s1nr63k.fsf@gnu.org> From: Aaron Cohen Date: Fri, 30 Jul 2021 12:12:34 -0700 Message-ID: Subject: Re: bug#49761: file-cache-minibuffer-complete has become unusable for duplicate file names in MacOSX 27.x emacs To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000aa26d005c85c0272" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 49761 Cc: 49761@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000aa26d005c85c0272 Content-Type: text/plain; charset="UTF-8" Sorry, that remark was a response (with a smile to show benign intent) to Juri's comment: > ... this is the default behavior for completions that don't share a common prefix. ... and not a response to any of your comments. No offense meant - I really appreciate your having spent any time responding to me!! On Fri, Jul 30, 2021 at 11:48 AM Eli Zaretskii wrote: > > From: Aaron Cohen > > Date: Fri, 30 Jul 2021 11:20:51 -0700 > > Cc: Eli Zaretskii , 49761@debbugs.gnu.org > > > > Well, it's now the default behavior. It wasn't previously. :-) > > I wasn't trying to find the reason for the change in behavior, I was > trying to help you get the behavior you want back. > --000000000000aa26d005c85c0272 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry, that remark was a response (with a sm= ile to show benign intent) to Juri's comment:

> ...=C2=A0this is the default behavior for completions=C2=A0that don't share a com= mon prefix.
=
... and not a = response to any of your comments.=C2=A0 No offense meant - I really appreci= ate your having spent any time responding to me!!

On Fri, Jul 30, 2021= at 11:48 AM Eli Zaretskii <eliz@gnu.org= > wrote:
> From: Aaron Cohen <aaron@brightbytes.net<= /a>>
> Date: Fri, 30 Jul 2021 11:20:51 -0700
> Cc: Eli Zaretskii <eliz@gnu.org>, 49761@debbugs.gnu.org
>
> Well, it's now the default behavior.=C2=A0 It wasn't previousl= y.=C2=A0 :-)

I wasn't trying to find the reason for the change in behavior, I was trying to help you get the behavior you want back.
--000000000000aa26d005c85c0272-- From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 01 04:41:17 2021 Received: (at 49761) by debbugs.gnu.org; 1 Aug 2021 08:41:17 +0000 Received: from localhost ([127.0.0.1]:35504 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mA725-0003Ck-Fv for submit@debbugs.gnu.org; Sun, 01 Aug 2021 04:41:17 -0400 Received: from relay9-d.mail.gandi.net ([217.70.183.199]:33675) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mA722-0003CT-R6; Sun, 01 Aug 2021 04:41:15 -0400 Received: (Authenticated sender: juri@linkov.net) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id D7E48FF806; Sun, 1 Aug 2021 08:41:07 +0000 (UTC) From: Juri Linkov To: Aaron Cohen Subject: Re: bug#49761: file-cache-minibuffer-complete has become unusable for duplicate file names in MacOSX 27.x emacs Organization: LINKOV.NET References: <87o8alvwby.fsf@mail.linkov.net> <83bl6lrnrh.fsf@gnu.org> <878s1pvunb.fsf@mail.linkov.net> <838s1osyv1.fsf@gnu.org> <87y29ovrgj.fsf@mail.linkov.net> <87v94su45t.fsf@mail.linkov.net> <8335rws641.fsf@gnu.org> <87lf5nisyo.fsf@mail.linkov.net> Date: Sun, 01 Aug 2021 11:40:50 +0300 In-Reply-To: (Aaron Cohen's message of "Fri, 30 Jul 2021 11:20:51 -0700") Message-ID: <87k0l5j1u1.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 49761 Cc: Eli Zaretskii , 49761@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) tags 49761 fixed close 49761 28.0.50 thanks > Well, it's now the default behavior. It wasn't previously. :-) And new is not always better ;-) So now the new behavior (that became old now) was fixed in the master branch for Emacs 28, and all test cases that you presented work completely as expected. Thanks for helping to understand where the problem was. BTW, after the fix, the following additional information is not necessary, but I discovered that in old versions you can use the prefix argument to force C-TAB cycling. An excerpt from etc/NEWS.20: ** file-cache-minibuffer-complete now accepts a prefix argument. With a prefix argument, it does not try to do completion of the file name within its directory; it only checks for other directories that contain the same file name. Thus, given the file name Makefile, and assuming that a file Makefile.in exists in the same directory, ordinary file-cache-minibuffer-complete will try to complete Makefile to Makefile.in and will therefore never look for other directories that have Makefile. A prefix argument tells it not to look for longer names such as Makefile.in, so that instead it will look for other directories--just as if the name were already complete in its present directory. and a comment from bindings.el: ;; The prefix argument works around a bug in the minibuffer completion. ;; The completion function doesn't distinguish between the states: ;; ;; "Multiple completions of name" (eg, Makefile, Makefile.in) ;; "Name available in multiple directories" (/tmp/Makefile, ~me/Makefile) ;; ;; The default is to do the former; a prefix arg forces the latter. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 02 16:03:31 2021 Received: (at 49761) by debbugs.gnu.org; 2 Aug 2021 20:03:31 +0000 Received: from localhost ([127.0.0.1]:39344 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mAe9q-0002ol-I5 for submit@debbugs.gnu.org; Mon, 02 Aug 2021 16:03:30 -0400 Received: from mail-oi1-f179.google.com ([209.85.167.179]:33685) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mAe9o-0002oX-7v for 49761@debbugs.gnu.org; Mon, 02 Aug 2021 16:03:28 -0400 Received: by mail-oi1-f179.google.com with SMTP id 26so7617784oiy.0 for <49761@debbugs.gnu.org>; Mon, 02 Aug 2021 13:03:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brightbytes.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ANQaqOLekL9CRaN0U4hqBGw80qa5i0sr0XrLm342le0=; b=Y6QzlnoaIJw9nnRXuDRktPN4nuHAlQo1tUuQQlVScc1cBda2zVzzoEGBnkEO4BKo+W uRlbRD/4BsKneEAtDZUueg7EtoE81mTXsRs0nyKmiamyBpVuzU4U5A72D+2rnOn49hAo 7ckEJYY0Qvx4jL4PnSFd2C5d5FafvyV+iKHzk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ANQaqOLekL9CRaN0U4hqBGw80qa5i0sr0XrLm342le0=; b=A6AdDQ7my0V5VuZ/Ym5P4wd/FuBndWdWSwzf3lr7AvgAUpZ0Sbluc9mMLMk94m8zWE +KVt564T+HdGtWpOT5T/hQFcpDOkgGawq/oejEuCxtnbSVeEtl4gosJTy1CeTuAeVohT IooJXFI7x0MVe1VwF4QgcZaEWABL1jBXByIuGIJmw0vjeb9VrhGF3Qg9mDIvwIwjkjcO P+JDfS04gBTD8oCZIIt/wgmNDLpEFNUkfYd1mL8AIbg9Wz2EZqT5Paj6saqMHns8Djdd 08p9guEKKh+hzUYCToMHduj3bP68Ci397GV+5Dhfi8JpM4ZFISVphVCPLqPbEJ9BijEN Lc+A== X-Gm-Message-State: AOAM530oGjQwmuGa9vq4nYfedMQu6GJWQsti4XgvkRoiyytJVkw2yOoa li7jnX8StQwa73oa8H4XGDHVWBxjnQY1T8Ik1FVK9w== X-Google-Smtp-Source: ABdhPJxCm74Wk+81QvzDWnmCqr7h80vA1/4RNMQ+FLxHeyAdPylWF7wAZBMzly9tQgnWg51mTUNAzQ2JkyfolqQEXLk= X-Received: by 2002:a05:6808:10d5:: with SMTP id s21mr11795586ois.7.1627934602510; Mon, 02 Aug 2021 13:03:22 -0700 (PDT) MIME-Version: 1.0 References: <87o8alvwby.fsf@mail.linkov.net> <83bl6lrnrh.fsf@gnu.org> <878s1pvunb.fsf@mail.linkov.net> <838s1osyv1.fsf@gnu.org> <87y29ovrgj.fsf@mail.linkov.net> <87v94su45t.fsf@mail.linkov.net> <8335rws641.fsf@gnu.org> <87lf5nisyo.fsf@mail.linkov.net> <87k0l5j1u1.fsf@mail.linkov.net> In-Reply-To: <87k0l5j1u1.fsf@mail.linkov.net> From: Aaron Cohen Date: Mon, 2 Aug 2021 13:02:46 -0700 Message-ID: Subject: Re: bug#49761: file-cache-minibuffer-complete has become unusable for duplicate file names in MacOSX 27.x emacs To: Juri Linkov Content-Type: multipart/alternative; boundary="000000000000b355b205c8990fdc" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 49761 Cc: Eli Zaretskii , 49761@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000b355b205c8990fdc Content-Type: text/plain; charset="UTF-8" Very much appreciated!! And thank you for investigating and isolating the issue: I had misidentified the actual problem and didn't provide a duplication recipe, making your job much harder. I promise to do better next time, and provide a test case. :-) Thanks again!! On Sun, Aug 1, 2021 at 1:41 AM Juri Linkov wrote: > tags 49761 fixed > close 49761 28.0.50 > thanks > > > Well, it's now the default behavior. It wasn't previously. :-) > > And new is not always better ;-) > > So now the new behavior (that became old now) was fixed > in the master branch for Emacs 28, and all test cases > that you presented work completely as expected. > Thanks for helping to understand where the problem was. > > BTW, after the fix, the following additional information > is not necessary, but I discovered that in old versions > you can use the prefix argument to force C-TAB cycling. > > An excerpt from etc/NEWS.20: > > ** file-cache-minibuffer-complete now accepts a prefix argument. > With a prefix argument, it does not try to do completion of > the file name within its directory; it only checks for other > directories that contain the same file name. > Thus, given the file name Makefile, and assuming that a file > Makefile.in exists in the same directory, ordinary > file-cache-minibuffer-complete will try to complete Makefile to > Makefile.in and will therefore never look for other directories that > have Makefile. A prefix argument tells it not to look for longer > names such as Makefile.in, so that instead it will look for other > directories--just as if the name were already complete in its present > directory. > > and a comment from bindings.el: > > ;; The prefix argument works around a bug in the minibuffer completion. > ;; The completion function doesn't distinguish between the states: > ;; > ;; "Multiple completions of name" (eg, Makefile, Makefile.in) > ;; "Name available in multiple directories" (/tmp/Makefile, > ~me/Makefile) > ;; > ;; The default is to do the former; a prefix arg forces the latter. > --000000000000b355b205c8990fdc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Very much appreciated!!
<= br>
And thank you for investigating and isolating the is= sue: I had misidentified the actual problem and didn't provide a duplic= ation recipe, making your job much harder.

I promise to do better next time, and provide a test case. =C2= =A0:-)

Thanks again!!

On Su= n, Aug 1, 2021 at 1:41 AM Juri Linkov <juri@linkov.net> wrote:
tags 49761 fixed=
close 49761 28.0.50
thanks

> Well, it's now the default behavior.=C2=A0 It wasn't previousl= y.=C2=A0 :-)

And new is not always better ;-)

So now the new behavior (that became old now) was fixed
in the master branch for Emacs 28, and all test cases
that you presented work completely as expected.
Thanks for helping to understand where the problem was.

BTW, after the fix, the following additional information
is not necessary, but I discovered that in old versions
you can use the prefix argument to force C-TAB cycling.

An excerpt from etc/NEWS.20:

=C2=A0 ** file-cache-minibuffer-complete now accepts a prefix argument.
=C2=A0 With a prefix argument, it does not try to do completion of
=C2=A0 the file name within its directory; it only checks for other
=C2=A0 directories that contain the same file name.
=C2=A0 Thus, given the file name Makefile, and assuming that a file
=C2=A0 Makefile.in exists in the same directory, ordinary
=C2=A0 file-cache-minibuffer-complete will try to complete Makefile to
=C2=A0 Makefile.in and will therefore never look for other directories that=
=C2=A0 have Makefile.=C2=A0 A prefix argument tells it not to look for long= er
=C2=A0 names such as Makefile.in, so that instead it will look for other =C2=A0 directories--just as if the name were already complete in its presen= t
=C2=A0 directory.

and a comment from bindings.el:

=C2=A0 ;; The prefix argument works around a bug in the minibuffer completi= on.
=C2=A0 ;; The completion function doesn't distinguish between the state= s:
=C2=A0 ;;
=C2=A0 ;;=C2=A0 =C2=A0"Multiple completions of name" (eg, Makefil= e, Makefile.in)
=C2=A0 ;;=C2=A0 =C2=A0"Name available in multiple directories" (/= tmp/Makefile, ~me/Makefile)
=C2=A0 ;;
=C2=A0 ;; The default is to do the former; a prefix arg forces the latter.<= br>
--000000000000b355b205c8990fdc-- From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 02 16:12:51 2021 Received: (at 49761) by debbugs.gnu.org; 2 Aug 2021 20:12:51 +0000 Received: from localhost ([127.0.0.1]:39348 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mAeIs-000325-MK for submit@debbugs.gnu.org; Mon, 02 Aug 2021 16:12:51 -0400 Received: from mail-oi1-f182.google.com ([209.85.167.182]:35488) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mAeIq-00031t-UT for 49761@debbugs.gnu.org; Mon, 02 Aug 2021 16:12:49 -0400 Received: by mail-oi1-f182.google.com with SMTP id n16so18960170oij.2 for <49761@debbugs.gnu.org>; Mon, 02 Aug 2021 13:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brightbytes.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QwHAVOeDGv0pL+ffC8vvz1K95BuM83YJTiG+fIabHko=; b=AlERTNXmyo3KPBXWgIPZU6egbP8Gzw3imD0O3wKB9e0Y4uF40Yl/t6nE/CdZ0db1EP 5cOJ09oDFksTPhy1UCIW0G2dOcrjW6cZwdKenEj1y4GsbAKV8IHvbhg5d50rLc4mkMPO uc4MefU0GxFEAltG0unHyUEOkfsV5ltsm6qss= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QwHAVOeDGv0pL+ffC8vvz1K95BuM83YJTiG+fIabHko=; b=Y3B7wm2UwGxSTPk66HV/joH9JbhDNbHATfj4S/dNicjrI0v5dRxEZLHDj/bjLA7aIb uTQEJJBn4r9UPPqwjRLaaCpw5+hWZzR7j90n5A2A4CLCrQB6+l5N+ICkrVj9iV/w905K N4xC5WA+YUrYYeCmq3MDrm66sDAYV3IQ9m06R8ok/ghsNX8u89lZALeOJZQaCRja40lx 2S3Yu5m//De2U1KZTabgDVPbTt8syj6bUDX5Ot0YgPpVPx++BLDhjFFlt7qM5NOcYjv+ Or+HqvlcENCAKY5cckcwYZriov1AH/+Ok+eNcZ0q9WwOHRruw6gcXDfKYNPlZ+7bFHgy Uk0A== X-Gm-Message-State: AOAM532bo3WPHZk5ojhQJmufDzlQYUg+Zz0A/167g/pkS1sSxOmaE7YY 0WlkXLirD/vI+ivRc/HK2ZxSh5Wxg/mBvkjueWzBsg== X-Google-Smtp-Source: ABdhPJwlwHJM8JNiWjoTZAEiCSwxaQu7amDLAcpepik+tv9xyKHyaftf6iLXxEWFzX+/aZiKE3b3jPrRctoRQOteMok= X-Received: by 2002:aca:2b07:: with SMTP id i7mr334879oik.97.1627935163472; Mon, 02 Aug 2021 13:12:43 -0700 (PDT) MIME-Version: 1.0 References: <87o8alvwby.fsf@mail.linkov.net> <83bl6lrnrh.fsf@gnu.org> <878s1pvunb.fsf@mail.linkov.net> <838s1osyv1.fsf@gnu.org> <87y29ovrgj.fsf@mail.linkov.net> <87v94su45t.fsf@mail.linkov.net> <8335rws641.fsf@gnu.org> <87lf5nisyo.fsf@mail.linkov.net> <87k0l5j1u1.fsf@mail.linkov.net> In-Reply-To: From: Aaron Cohen Date: Mon, 2 Aug 2021 13:12:07 -0700 Message-ID: Subject: Re: bug#49761: file-cache-minibuffer-complete has become unusable for duplicate file names in MacOSX 27.x emacs To: Juri Linkov Content-Type: multipart/alternative; boundary="00000000000022f22305c8993165" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 49761 Cc: Eli Zaretskii , 49761@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000022f22305c8993165 Content-Type: text/plain; charset="UTF-8" Oh, and I've confirmed that the workaround of `C-u C-Tab` works great for cycling through files when `C-Tab` would otherwise get stuck. So, I'm good until the next official release. On Mon, Aug 2, 2021 at 1:02 PM Aaron Cohen wrote: > Very much appreciated!! > > And thank you for investigating and isolating the issue: I had > misidentified the actual problem and didn't provide a duplication recipe, > making your job much harder. > > I promise to do better next time, and provide a test case. :-) > > Thanks again!! > > On Sun, Aug 1, 2021 at 1:41 AM Juri Linkov wrote: > >> tags 49761 fixed >> close 49761 28.0.50 >> thanks >> >> > Well, it's now the default behavior. It wasn't previously. :-) >> >> And new is not always better ;-) >> >> So now the new behavior (that became old now) was fixed >> in the master branch for Emacs 28, and all test cases >> that you presented work completely as expected. >> Thanks for helping to understand where the problem was. >> >> BTW, after the fix, the following additional information >> is not necessary, but I discovered that in old versions >> you can use the prefix argument to force C-TAB cycling. >> >> An excerpt from etc/NEWS.20: >> >> ** file-cache-minibuffer-complete now accepts a prefix argument. >> With a prefix argument, it does not try to do completion of >> the file name within its directory; it only checks for other >> directories that contain the same file name. >> Thus, given the file name Makefile, and assuming that a file >> Makefile.in exists in the same directory, ordinary >> file-cache-minibuffer-complete will try to complete Makefile to >> Makefile.in and will therefore never look for other directories that >> have Makefile. A prefix argument tells it not to look for longer >> names such as Makefile.in, so that instead it will look for other >> directories--just as if the name were already complete in its present >> directory. >> >> and a comment from bindings.el: >> >> ;; The prefix argument works around a bug in the minibuffer completion. >> ;; The completion function doesn't distinguish between the states: >> ;; >> ;; "Multiple completions of name" (eg, Makefile, Makefile.in) >> ;; "Name available in multiple directories" (/tmp/Makefile, >> ~me/Makefile) >> ;; >> ;; The default is to do the former; a prefix arg forces the latter. >> > --00000000000022f22305c8993165 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Oh, and I've confirmed that the workarou= nd of `C-u C-Tab` works great for cycling through files when `C-Tab` would = otherwise get stuck.=C2=A0 So, I'm good until the next official release= .

On Mon, Aug 2, 2021 at 1:02 PM Aaron Cohen <aaron@brightbytes.net> wrote:
Very much appreciated!!<= /div>

And than= k you for investigating and isolating the issue: I had misidentified the ac= tual problem and didn't provide a duplication recipe, making your job m= uch harder.

I promise to do better next time, and provide a test case. =C2=A0:-)

Thanks a= gain!!

On Sun, Aug 1, 2021 at 1:41 AM Juri Linkov <juri@linkov.net> wrote:
tags 49761 fixed
close 49761 28.0.50
thanks

> Well, it's now the default behavior.=C2=A0 It wasn't previousl= y.=C2=A0 :-)

And new is not always better ;-)

So now the new behavior (that became old now) was fixed
in the master branch for Emacs 28, and all test cases
that you presented work completely as expected.
Thanks for helping to understand where the problem was.

BTW, after the fix, the following additional information
is not necessary, but I discovered that in old versions
you can use the prefix argument to force C-TAB cycling.

An excerpt from etc/NEWS.20:

=C2=A0 ** file-cache-minibuffer-complete now accepts a prefix argument.
=C2=A0 With a prefix argument, it does not try to do completion of
=C2=A0 the file name within its directory; it only checks for other
=C2=A0 directories that contain the same file name.
=C2=A0 Thus, given the file name Makefile, and assuming that a file
=C2=A0 Makefile.in exists in the same directory, ordinary
=C2=A0 file-cache-minibuffer-complete will try to complete Makefile to
=C2=A0 Makefile.in and will therefore never look for other directories that=
=C2=A0 have Makefile.=C2=A0 A prefix argument tells it not to look for long= er
=C2=A0 names such as Makefile.in, so that instead it will look for other =C2=A0 directories--just as if the name were already complete in its presen= t
=C2=A0 directory.

and a comment from bindings.el:

=C2=A0 ;; The prefix argument works around a bug in the minibuffer completi= on.
=C2=A0 ;; The completion function doesn't distinguish between the state= s:
=C2=A0 ;;
=C2=A0 ;;=C2=A0 =C2=A0"Multiple completions of name" (eg, Makefil= e, Makefile.in)
=C2=A0 ;;=C2=A0 =C2=A0"Name available in multiple directories" (/= tmp/Makefile, ~me/Makefile)
=C2=A0 ;;
=C2=A0 ;; The default is to do the former; a prefix arg forces the latter.<= br>
--00000000000022f22305c8993165-- From unknown Wed Jun 18 23:15:36 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 31 Aug 2021 11:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator