GNU bug report logs - #1206
double slash // in read-shell-command completion

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 1206 in the body.
You can then email your comments to 1206 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.60; read-shell-command completion problem
Date: Sun, 19 Oct 2008 17:24:24 +0200

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug <at> gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

  emacs -Q
  M-!
  ls d:/gnu/emacs/lisp

Move point so that the cursor is on the slash between "emacs" and
"lisp", and type TAB.  At this point, the *Completions* buffer pops up
with the following possibilities:

  Click <mouse-2> on a completion to select it.
  In this buffer, type RET to select the completion near point.

  Possible completions are:
  emacs-21.4/            emacs-22-branch/      emacs-22.x/
  emacs-23.pre-unicode/  emacs-bidi/           emacs-rtf/
  emacs/

(Depending on your system, you will see something different.)
Clicking on "emacs-22-branch/" produces this in the minibuffer:

  emacs-22-branch//lisp

But I expected it to replace only the "emacs" part (because this is
what it evidently produced the possible completions for), so that I
will see "ls d:/gnu/emacs-22-branch/lisp".

This was on MS-Windows, but I see the same behavior on GNU/Linux:
picking up a completion replaces the whole input, up to the position
of point.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
d:/gnu/emacs/etc/DEBUG for instructions.


In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-10-19 on HOME-C4E4A596F7
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1255
  default-enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
  shell-dirtrack-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
s e c o n d SPC C - x SPC a n d SPC w a n t e d SPC 
t o SPC b a i l SPC o u t . SPC SPC I S-SPC e x p e 
c t e d SPC t o SPC s e e SPC " Q u i t " , SPC n o 
t SPC a SPC f a t a l SPC <M-backspace> <M-backspace> 
a n SPC e r r o r . ) M-q <C-home> C-SPC <down> C-SPC 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> M-w C-x b <return> C-x 1 C-x <return> c u n 
d e c <tab> <return> C-x C-g <help-echo> <help-echo> 
C-x b * C o m <tab> <return> C-x b <return> M-! l s 
SPC d : / g n u / e m a c s / l i s p <left> <left> 
<left> <left> <left> <tab> <help-echo> <help-echo> 
<help-echo> <down-mouse-1> <mouse-2> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> C-SPC C-e 
M-w <help-echo> <help-echo> <help-echo> C-g C-x b <up> 
<up> <return> <up> <up> <up> <up> C-a C-SPC <down> 
<down> <down> <down> <down> <down> <down> M-w <help-echo> 
C-x b <return> M-x <up> <return>

Recent messages:
Quit [2 times]
universal-coding-system-argument: Wrong type argument: commandp, nil
Mark set [4 times]
Auto-saving...done
Mark set [3 times]
Saved text from "To: emacs-pretest-bug <at> gnu.org
Subject: 2"
universal-coding-system-argument: Wrong type argument: commandp, nil
Quit
Mark set

Message #10 received at 1206 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 1206 <at> debbugs.gnu.org
Subject: Re: 23.0.60; read-shell-command completion problem
Date: Sat, 15 Aug 2009 19:57:13 -0400

>   emacs -Q
>   M-!
>   ls d:/gnu/emacs/lisp
>
> Move point so that the cursor is on the slash between "emacs" and
> "lisp", and type TAB.  At this point, the *Completions* buffer pops up
>
>   Click <mouse-2> on a completion to select it.
>   In this buffer, type RET to select the completion near point.
>
>   Possible completions are:
>   emacs-21.4/            emacs-22-branch/      emacs-22.x/
>   emacs-23.pre-unicode/  emacs-bidi/           emacs-rtf/
>   emacs/
>
> Clicking on "emacs-22-branch/" produces this in the minibuffer:
>
>   emacs-22-branch//lisp

Could you test the following patch (admittedly a bit of a hack)?

*** trunk/lisp/simple.el.~1.1003.~	2009-08-13 10:30:54.000000000 -0400
--- trunk/lisp/simple.el	2009-08-15 19:53:04.000000000 -0400
***************
*** 5843,5849 ****
--- 5843,5857 ----
  	(if base-size
  	    (delete-region (+ base-size (field-beginning)) (point))
  	  (choose-completion-delete-max-match choice))
+ 
+ 	;; Insert the choice.  When reading a file name and the choice
+ 	;; is a directory, avoid having an extra "/" (Bug#1206).
  	(insert choice)
+ 	(and minibuffer-completing-file-name
+ 	     (looking-at "/")
+ 	     (= (aref choice (1- (length choice))) ?/)
+ 	     (delete-char 1))
+ 
  	(remove-text-properties (- (point) (length choice)) (point)
  				'(mouse-face nil))
  	;; Update point in the window that BUFFER is showing in.

Message #15 received at 1206 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 1206 <at> debbugs.gnu.org
Subject: Re: 23.0.60; read-shell-command completion problem
Date: Sat, 31 Oct 2009 17:57:03 -0400

Hi Eli,

Could you test the patch I posted at

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=1206

Thanks!

Message #20 received at 1206 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 1206 <at> debbugs.gnu.org
Subject: Re: 23.0.60; read-shell-command completion problem
Date: Sat, 07 Nov 2009 15:20:24 +0200

> From: Chong Yidong <cyd <at> stupidchicken.com>
> Cc: 1206 <at> emacsbugs.donarmstrong.com
> Date: Sat, 31 Oct 2009 17:57:03 -0400
> 
> Hi Eli,
> 
> Could you test the patch I posted at
> 
>   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=1206

Sorry for the long delay.  I tested the patch now on MS-Windows, and I
still see two slashes, exactly like in the original report.  The
problem seems to be that minibuffer-completing-file-name is nil when
the modified code is run.

Message #23 received at 1206 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 1206 <at> debbugs.gnu.org
Subject: Re: 23.0.60; read-shell-command completion problem
Date: Tue, 01 Mar 2011 23:14:15 -0500

Do you still see this? I don't think I do.

Message #26 received at 1206 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 1206 <at> debbugs.gnu.org
Subject: Re: 23.0.60; read-shell-command completion problem
Date: Wed, 02 Mar 2011 19:57:20 +0200

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: 1206 <at> debbugs.gnu.org
> Date: Tue, 01 Mar 2011 23:14:15 -0500
> 
> 
> Do you still see this? I don't think I do.

No, but it still isn't right: it inserts an extra slash.  That is, I
get something like "d:/gnu/emacs-foo//lisp".  The extra slash in this
situation is really not nice...

This happens both with Emacs 23.3 RC1 and with the development trunk.

Message #33 received at 1206 <at> debbugs.gnu.org (full text, mbox):

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, 1206 <at> debbugs.gnu.org
Subject: Re: bug#1206: double slash // in read-shell-command completion
Date: Sat, 15 Feb 2025 10:33:59 -0300

Hi Eli,

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Glenn Morris <rgm <at> gnu.org>
>> Cc: 1206 <at> debbugs.gnu.org
>> Date: Tue, 01 Mar 2011 23:14:15 -0500
>>
>>
>> Do you still see this? I don't think I do.
>
> No, but it still isn't right: it inserts an extra slash. That is, I
> get something like "d:/gnu/emacs-foo//lisp".  The extra slash in this
> situation is really not nice...
>
> This happens both with Emacs 23.3 RC1 and with the development trunk.

This is an old bug report you filed, that I used to be able to reproduce
years ago when I was looking for old bugs to fix.

Thing is, I'm not able to reproduce it anymore.  I did this:

In a directory that looks like this:
.
├── emacs
│   ├── emacs-27
│   │   ├── lisp
│   ├── emacs-28
│   │   ├── lisp
│   ├── emacs-29
│   │   ├── lisp

emacs -Q
M-!
ls ~/emacs/emacs-2/lisp
Move point to the slash before "lisp".
TAB

Emacs shows:
3 possible completions:
emacs-27/
emacs-28/
emacs-29/

Select one and now the minibuffer shows:
~/emacs/emacs-27/lisp


Emacs 28 shows the behavior you reported.  Then Emacs 29 showed: "No
match", which is wrong.  But then, after the following commit, I can't
reproduce it anymore:

commit ff3f17ca3cdd9e82355942f577e7807acc76ddcd
Author: Dmitry Gutov <dmitry <at> gutov.dev>
Date:   Thu May 9 05:30:32 2024 +0300

    choose-completion: Retain the suffix after completion boundary

    * lisp/minibuffer.el (completion-base-suffix):
    Remove as not optimal after all (bug#48356).
    (completion--replace): Use insert-before-markers-and-inherit.
    (minibuffer-completion-help): Don't set completion-base-affixes,
    implement the same logic more optimally by local search and
    querying for field boundaries.  Also fix the problem with
    completion table, predicate and extra-props being looked up in the
    wrong buffer.
    (minibuffer-next-completion, minibuffer-choose-completion):
    Don't bind completion-use-base-affixes anymore.

    * lisp/simple.el (completion-base-affixes)
    (completion-use-base-affixes): Remove.
    (completion-list-insert-choice-function):
    Don't pass them through anymore.

Message #38 received at 1206-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mauro Aranda <maurooaranda <at> gmail.com>
Cc: 1206-done <at> debbugs.gnu.org
Subject: Re: bug#1206: double slash // in read-shell-command completion
Date: Sat, 15 Feb 2025 17:34:18 +0200

> Date: Sat, 15 Feb 2025 10:33:59 -0300
> From: Mauro Aranda <maurooaranda <at> gmail.com>
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
>  >> From: Glenn Morris <rgm <at> gnu.org>
>  >> Cc: 1206 <at> debbugs.gnu.org
>  >> Date: Tue, 01 Mar 2011 23:14:15 -0500
>  >>
>  >>
>  >> Do you still see this? I don't think I do.
>  >
>  > No, but it still isn't right: it inserts an extra slash. That is, I
>  > get something like "d:/gnu/emacs-foo//lisp".  The extra slash in this
>  > situation is really not nice...
>  >
>  > This happens both with Emacs 23.3 RC1 and with the development trunk.
> 
> This is an old bug report you filed, that I used to be able to reproduce
> years ago when I was looking for old bugs to fix.
> 
> Thing is, I'm not able to reproduce it anymore.  I did this:
> 
> In a directory that looks like this:
> .
> ├── emacs
> │   ├── emacs-27
> │   │   ├── lisp
> │   ├── emacs-28
> │   │   ├── lisp
> │   ├── emacs-29
> │   │   ├── lisp
> 
> emacs -Q
> M-!
> ls ~/emacs/emacs-2/lisp
> Move point to the slash before "lisp".
> TAB
> 
> Emacs shows:
> 3 possible completions:
> emacs-27/
> emacs-28/
> emacs-29/
> 
> Select one and now the minibuffer shows:
> ~/emacs/emacs-27/lisp
> 
> 
> Emacs 28 shows the behavior you reported.  Then Emacs 29 showed: "No
> match", which is wrong.  But then, after the following commit, I can't
> reproduce it anymore:

Yes, this is now fixed in Emacs 30 (Emacs 29.4 is still wrong, albeit
in a different way).

So I'm closing this bug, thanks.  Good riddance!

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.