bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>

bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>

[Stephen Berman]

0. emacs -Q
1. C-x d / ~ TAB
   This pops up a *Completions* buffer showing directory names of all
   members of (system-users), e.g. steve/
2. Continuing from step 1, when I type any of 's TAB', 'st TAB', 'ste
   TAB' or 'stev TAB', Emacs responds with [No match], but 'steve TAB'
   completes to steve/

The failure only happens with '/~<partial-name>', typing e.g. '~/Downl
TAB' here completes to ~/Downloads/

I tried debugging but only got as far as completion--some; when stepping
through that after '/~stev TAB' *Messages* shows this:

  Result: (closure ((metadata metadata (category . file) (completion--unquote-requote . t)) (point . 6) (pred . file-exists-p) (table . completion-file-name-table) (string . "/~stev") (n . 1) t) (style) (funcall (nth n (assq style completion-styles-alist)) string table pred point))
   [2 times]
  Result: (substring basic partial-completion emacs22)
  
  Result: (substring basic partial-completion emacs22)
  
  Result: substring
  
  Result: nil

In contrast, with '/~steve TAB':

  Result: (closure ((metadata metadata (category . file) (completion--unquote-requote . t)) (point . 6) (pred . file-exists-p) (table . completion-file-name-table) (string . "~steve") (n . 1) t) (style) (funcall (nth n (assq style completion-styles-alist)) string table pred point))
   [2 times]
  Result: (substring basic partial-completion emacs22)
  
  Result: (substring basic partial-completion emacs22)
  
  Result: substring
  
  Result: ("~steve/" . 7)


In GNU Emacs 27.0.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version 3.22.28)
 of 2018-07-18 built on rosalinde
Repository revision: 04a32fa60bead4359bc9353af67f26958c795593
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description: Linux From Scratch

Recent messages:
scroll-up-command: End of buffer
Contacting host: debbugs.gnu.org:443
Opening nndoc server on /tmp/gnus-temp-group-vnhsiy-ephemeral...done
Contacting host: debbugs.gnu.org:443
Opening nndoc server on /tmp/gnus-temp-group-L5CVOB-ephemeral...done
scroll-up-command: End of buffer
Contacting host: debbugs.gnu.org:443
Opening nndoc server on /tmp/gnus-temp-group-GXyYYJ-ephemeral...done
Contacting host: debbugs.gnu.org:443
Opening nndoc server on /tmp/gnus-temp-group-x4tMir-ephemeral...done

Configured using:
 'configure 'CFLAGS=-Og -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GSETTINGS NOTIFY ACL
GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS
GTK3 X11 THREADS LCMS2

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Date: Thu, 19 Jul 2018 19:55:18 +0200
> 
> 0. emacs -Q
> 1. C-x d / ~ TAB
>    This pops up a *Completions* buffer showing directory names of all
>    members of (system-users), e.g. steve/
> 2. Continuing from step 1, when I type any of 's TAB', 'st TAB', 'ste
>    TAB' or 'stev TAB', Emacs responds with [No match], but 'steve TAB'
>    completes to steve/
> 
> The failure only happens with '/~<partial-name>', typing e.g. '~/Downl
> TAB' here completes to ~/Downloads/

Doesn't happen here, FWIW.  Strange.

bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>

[Stephen Berman]

On Thu, 19 Jul 2018 21:19:36 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Date: Thu, 19 Jul 2018 19:55:18 +0200
>> 
>> 0. emacs -Q
>> 1. C-x d / ~ TAB
>>    This pops up a *Completions* buffer showing directory names of all
>>    members of (system-users), e.g. steve/
>> 2. Continuing from step 1, when I type any of 's TAB', 'st TAB', 'ste
>>    TAB' or 'stev TAB', Emacs responds with [No match], but 'steve TAB'
>>    completes to steve/
>> 
>> The failure only happens with '/~<partial-name>', typing e.g. '~/Downl
>> TAB' here completes to ~/Downloads/
>
> Doesn't happen here, FWIW.  Strange.

Strange indeed, assuming you tested on GNU/Linux or another POSIX
system, since IIUC on MS-Windows system-users returns only
user-real-login-name (at least it does here on Emacs 25.3 under Windows
8).  I also tested on another GNU/Linux system I have with Emacs 24.3
and see exactly the same behavior I described above.

Steve Berman

bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>

[Noam Postavsky]

Stephen Berman <stephen.berman@gmx.net> writes:

> On Thu, 19 Jul 2018 21:19:36 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>
>>> From: Stephen Berman <stephen.berman@gmx.net>
>>> Date: Thu, 19 Jul 2018 19:55:18 +0200
>>> 
>>> 0. emacs -Q
>>> 1. C-x d / ~ TAB
>>>    This pops up a *Completions* buffer showing directory names of all
>>>    members of (system-users), e.g. steve/
>>> 2. Continuing from step 1, when I type any of 's TAB', 'st TAB', 'ste
>>>    TAB' or 'stev TAB', Emacs responds with [No match], but 'steve TAB'
>>>    completes to steve/
>>> 
>>> The failure only happens with '/~<partial-name>', typing e.g. '~/Downl
>>> TAB' here completes to ~/Downloads/
>>
>> Doesn't happen here, FWIW.  Strange.
>
> Strange indeed, assuming you tested on GNU/Linux or another POSIX
> system, since IIUC on MS-Windows system-users returns only
> user-real-login-name (at least it does here on Emacs 25.3 under Windows
> 8).  I also tested on another GNU/Linux system I have with Emacs 24.3
> and see exactly the same behavior I described above.

I see it on both Windows and GNU/Linux.  I notice that the after typing
the first letter of the user name, the leading "/" is no longer in
shadow face, i.e., Emacs is looking for a directory starting with "~"
under the root directory.

bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 32215@debbugs.gnu.org
> Date: Thu, 19 Jul 2018 22:11:37 +0200
> 
> >> The failure only happens with '/~<partial-name>', typing e.g. '~/Downl
> >> TAB' here completes to ~/Downloads/
> >
> > Doesn't happen here, FWIW.  Strange.
> 
> Strange indeed, assuming you tested on GNU/Linux or another POSIX
> system

I tested on GNU/Linux, yes.

bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  32215@debbugs.gnu.org
> Date: Thu, 19 Jul 2018 21:02:11 -0400
> 
> I see it on both Windows and GNU/Linux.

What did you type on Windows, exactly?  If I type "C-x d / ~ TAB", I
get a single completion with my user-name, as expected.  How did you
get more than one completion?

bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>

[Stephen Berman]

On Thu, 19 Jul 2018 21:02:11 -0400 Noam Postavsky <npostavs@gmail.com> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> On Thu, 19 Jul 2018 21:19:36 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>>
>>>> From: Stephen Berman <stephen.berman@gmx.net>
>>>> Date: Thu, 19 Jul 2018 19:55:18 +0200
>>>> 
>>>> 0. emacs -Q
>>>> 1. C-x d / ~ TAB
>>>>    This pops up a *Completions* buffer showing directory names of all
>>>>    members of (system-users), e.g. steve/
>>>> 2. Continuing from step 1, when I type any of 's TAB', 'st TAB', 'ste
>>>>    TAB' or 'stev TAB', Emacs responds with [No match], but 'steve TAB'
>>>>    completes to steve/
>>>> 
>>>> The failure only happens with '/~<partial-name>', typing e.g. '~/Downl
>>>> TAB' here completes to ~/Downloads/
>>>
>>> Doesn't happen here, FWIW.  Strange.
>>
>> Strange indeed, assuming you tested on GNU/Linux or another POSIX
>> system, since IIUC on MS-Windows system-users returns only
>> user-real-login-name (at least it does here on Emacs 25.3 under Windows
>> 8).  I also tested on another GNU/Linux system I have with Emacs 24.3
>> and see exactly the same behavior I described above.
>
> I see it on both Windows and GNU/Linux.  

Like Eli, I'm surprised you see it on Windows.

>                                          I notice that the after typing
> the first letter of the user name, the leading "/" is no longer in
> shadow face, 

Yes, I didn't notice that when I tested before but I do now.

>              i.e., Emacs is looking for a directory starting with "~"
> under the root directory.

I suppose so, though it's still surprising that it only completes to
/~steve/ when typing /~steve, not /~stev.  Note that (at least here)
'/home/stev TAB' also completes to /home/steve/.

Steve Berman

bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>

[Noam Postavsky]

On 20 July 2018 at 04:31, Stephen Berman <stephen.berman@gmx.net> wrote:
> On Thu, 19 Jul 2018 21:02:11 -0400 Noam Postavsky <npostavs@gmail.com> wrote:
>
>> Stephen Berman <stephen.berman@gmx.net> writes:
>>
>>> On Thu, 19 Jul 2018 21:19:36 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>>>
>>>>> From: Stephen Berman <stephen.berman@gmx.net>
>>>>> Date: Thu, 19 Jul 2018 19:55:18 +0200
>>>>>
>>>>> 0. emacs -Q
>>>>> 1. C-x d / ~ TAB
>>>>>    This pops up a *Completions* buffer showing directory names of all
>>>>>    members of (system-users), e.g. steve/
>>>>> 2. Continuing from step 1, when I type any of 's TAB', 'st TAB', 'ste
>>>>>    TAB' or 'stev TAB', Emacs responds with [No match], but 'steve TAB'
>>>>>    completes to steve/
>>>>>
>>>>> The failure only happens with '/~<partial-name>', typing e.g. '~/Downl
>>>>> TAB' here completes to ~/Downloads/
>>>>
>>>> Doesn't happen here, FWIW.  Strange.
>>>
>>> Strange indeed, assuming you tested on GNU/Linux or another POSIX
>>> system, since IIUC on MS-Windows system-users returns only
>>> user-real-login-name (at least it does here on Emacs 25.3 under Windows
>>> 8).  I also tested on another GNU/Linux system I have with Emacs 24.3
>>> and see exactly the same behavior I described above.
>>
>> I see it on both Windows and GNU/Linux.
>
> Like Eli, I'm surprised you see it on Windows.

Oh, I skipped the TAB in step 1. With that, all of the leading text
before the ~ is removed, so there is no problem (and it indeed
completes immediately to my current user on Windows).

>
>>                                          I notice that the after typing
>> the first letter of the user name, the leading "/" is no longer in
>> shadow face,
>
> Yes, I didn't notice that when I tested before but I do now.

Ah, so when you hit TAB, the leading "/" is not removed?

bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>

[Stephen Berman]

On Fri, 20 Jul 2018 09:58:10 -0400 Noam Postavsky <npostavs@gmail.com> wrote:

> On 20 July 2018 at 04:31, Stephen Berman <stephen.berman@gmx.net> wrote:
>> On Thu, 19 Jul 2018 21:02:11 -0400 Noam Postavsky <npostavs@gmail.com> wrote:
>>
>>> Stephen Berman <stephen.berman@gmx.net> writes:
>>>
>>>> On Thu, 19 Jul 2018 21:19:36 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>>>>
>>>>>> From: Stephen Berman <stephen.berman@gmx.net>
>>>>>> Date: Thu, 19 Jul 2018 19:55:18 +0200
>>>>>>
>>>>>> 0. emacs -Q
>>>>>> 1. C-x d / ~ TAB
>>>>>>    This pops up a *Completions* buffer showing directory names of all
>>>>>>    members of (system-users), e.g. steve/
>>>>>> 2. Continuing from step 1, when I type any of 's TAB', 'st TAB', 'ste
>>>>>>    TAB' or 'stev TAB', Emacs responds with [No match], but 'steve TAB'
>>>>>>    completes to steve/
>>>>>>
>>>>>> The failure only happens with '/~<partial-name>', typing e.g. '~/Downl
>>>>>> TAB' here completes to ~/Downloads/
>>>>>
>>>>> Doesn't happen here, FWIW.  Strange.
>>>>
>>>> Strange indeed, assuming you tested on GNU/Linux or another POSIX
>>>> system, since IIUC on MS-Windows system-users returns only
>>>> user-real-login-name (at least it does here on Emacs 25.3 under Windows
>>>> 8).  I also tested on another GNU/Linux system I have with Emacs 24.3
>>>> and see exactly the same behavior I described above.
>>>
>>> I see it on both Windows and GNU/Linux.
>>
>> Like Eli, I'm surprised you see it on Windows.
>
> Oh, I skipped the TAB in step 1. With that, all of the leading text
> before the ~ is removed, so there is no problem (and it indeed
> completes immediately to my current user on Windows).
>
>>
>>>                                          I notice that the after typing
>>> the first letter of the user name, the leading "/" is no longer in
>>> shadow face,
>>
>> Yes, I didn't notice that when I tested before but I do now.
>
> Ah, so when you hit TAB, the leading "/" is not removed?

Nothing is removed.  To be explicit, when I start with -Q and type 'C-x
d', the minibuffer displays this:

Dired (directory): ~/

with point after '/'.  When I now type '/', the face of '~/' changes to
shadow, and when I then type '~', the face of the second '/' also
changes to shadow.  When I now type TAB, the minibuffer looks like this:

Dired (directory): ~//~

with '~//' in shadow face, and a *Completions* buffer pops up and shows
the directory names of all members of (system-users).  When I now type
's TAB', the face of the second '/' changes from shadow to default
(black), '[No match]' appears after the cursor and the *Completions*
buffer disappears.  I.e., the minibuffer looks like this on hitting TAB:

Dired (directory): ~//~s█[No match]

with '~/' in shadow face and '/~s' in default face, and after a couple
of seconds, '[No match]' disappears, leaving the rest.

Steve Berman

bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  32215@debbugs.gnu.org
> Date: Fri, 20 Jul 2018 16:28:15 +0200
> 
> Nothing is removed.  To be explicit, when I start with -Q and type 'C-x
> d', the minibuffer displays this:
> 
> Dired (directory): ~/
> 
> with point after '/'.  When I now type '/', the face of '~/' changes to
> shadow, and when I then type '~', the face of the second '/' also
> changes to shadow.  When I now type TAB, the minibuffer looks like this:
> 
> Dired (directory): ~//~
> 
> with '~//' in shadow face, and a *Completions* buffer pops up and shows
> the directory names of all members of (system-users).  When I now type
> 's TAB', the face of the second '/' changes from shadow to default
> (black), '[No match]' appears after the cursor and the *Completions*
> buffer disappears.  I.e., the minibuffer looks like this on hitting TAB:
> 
> Dired (directory): ~//~s█[No match]
> 
> with '~/' in shadow face and '/~s' in default face, and after a couple
> of seconds, '[No match]' disappears, leaving the rest.

Ah, I think I understand why I couldn't reproduce the problem: it
seems to only happen if default-directory is "~/" before starting the
recipe.  If it is something else, the problem doesn't happen.  Can you
confirm?

bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>

[Eli Zaretskii]

> Date: Fri, 20 Jul 2018 17:56:12 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 32215@debbugs.gnu.org, npostavs@gmail.com
> 
> Ah, I think I understand why I couldn't reproduce the problem: it
> seems to only happen if default-directory is "~/" before starting the
> recipe.  If it is something else, the problem doesn't happen.  Can you
> confirm?

And I see this in Emacs 26, 25, and 24, so it isn't a new problem.

bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>

[Stephen Berman]

On Fri, 20 Jul 2018 17:56:12 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  32215@debbugs.gnu.org
>> Date: Fri, 20 Jul 2018 16:28:15 +0200
>> 
>> Nothing is removed.  To be explicit, when I start with -Q and type 'C-x
>> d', the minibuffer displays this:
>> 
>> Dired (directory): ~/
>> 
>> with point after '/'.  When I now type '/', the face of '~/' changes to
>> shadow, and when I then type '~', the face of the second '/' also
>> changes to shadow.  When I now type TAB, the minibuffer looks like this:
>> 
>> Dired (directory): ~//~
>> 
>> with '~//' in shadow face, and a *Completions* buffer pops up and shows
>> the directory names of all members of (system-users).  When I now type
>> 's TAB', the face of the second '/' changes from shadow to default
>> (black), '[No match]' appears after the cursor and the *Completions*
>> buffer disappears.  I.e., the minibuffer looks like this on hitting TAB:
>> 
>> Dired (directory): ~//~s█[No match]
>> 
>> with '~/' in shadow face and '/~s' in default face, and after a couple
>> of seconds, '[No match]' disappears, leaving the rest.
>
> Ah, I think I understand why I couldn't reproduce the problem: it
> seems to only happen if default-directory is "~/" before starting the
> recipe.  If it is something else, the problem doesn't happen.  Can you
> confirm?

I'm afraid not:

0. emacs -Q
1. M-x cd RET /tmp/ RET
2. C-x d /~s TAB

results in this minibuffer display:

Dired (directory): /tmp//~s█[No match]

with '/tmp/' in shadow face and '/~s' in default face.  Same thing with
any other value of default-directory I've tried.

Steve Berman

bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: npostavs@gmail.com,  32215@debbugs.gnu.org
> Date: Fri, 20 Jul 2018 17:08:39 +0200
> 
> > Ah, I think I understand why I couldn't reproduce the problem: it
> > seems to only happen if default-directory is "~/" before starting the
> > recipe.  If it is something else, the problem doesn't happen.  Can you
> > confirm?
> 
> I'm afraid not:
> 
> 0. emacs -Q
> 1. M-x cd RET /tmp/ RET
> 2. C-x d /~s TAB
> 
> results in this minibuffer display:
> 
> Dired (directory): /tmp//~s█[No match]

Try a subdirectory of your home directory.

bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>

[Stephen Berman]

On Fri, 20 Jul 2018 20:22:27 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: npostavs@gmail.com,  32215@debbugs.gnu.org
>> Date: Fri, 20 Jul 2018 17:08:39 +0200
>> 
>> > Ah, I think I understand why I couldn't reproduce the problem: it
>> > seems to only happen if default-directory is "~/" before starting the
>> > recipe.  If it is something else, the problem doesn't happen.  Can you
>> > confirm?
>> 
>> I'm afraid not:
>> 
>> 0. emacs -Q
>> 1. M-x cd RET /tmp/ RET
>> 2. C-x d /~s TAB
>> 
>> results in this minibuffer display:
>> 
>> Dired (directory): /tmp//~s█[No match]
>
> Try a subdirectory of your home directory.

Perhaps I'm misunderstanding what you're suggesting, but with the
following I still get the same behavior:

0. emacs -Q
1. M-x cd RET ~/Downloads/ RET
2. C-x d /~s TAB

results in this minibuffer display:

Dired (directory): ~/Downloads//~s█[No match]

Steve Berman

bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: npostavs@gmail.com,  32215@debbugs.gnu.org
> Date: Fri, 20 Jul 2018 19:30:52 +0200
> 
> > Try a subdirectory of your home directory.
> 
> Perhaps I'm misunderstanding what you're suggesting, but with the
> following I still get the same behavior:
> 
> 0. emacs -Q
> 1. M-x cd RET ~/Downloads/ RET
> 2. C-x d /~s TAB
> 
> results in this minibuffer display:
> 
> Dired (directory): ~/Downloads//~s█[No match]

The original recipe was different:

  0. emacs -Q
  1. M-x cd RET ~/Downloads/ RET
  2. C-x d / ~ TAB s TAB

bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>

[Stephen Berman]

On Fri, 20 Jul 2018 22:03:21 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: npostavs@gmail.com,  32215@debbugs.gnu.org
>> Date: Fri, 20 Jul 2018 19:30:52 +0200
>> 
>> > Try a subdirectory of your home directory.
>> 
>> Perhaps I'm misunderstanding what you're suggesting, but with the
>> following I still get the same behavior:
>> 
>> 0. emacs -Q
>> 1. M-x cd RET ~/Downloads/ RET
>> 2. C-x d /~s TAB
>> 
>> results in this minibuffer display:
>> 
>> Dired (directory): ~/Downloads//~s█[No match]
>
> The original recipe was different:
>
>   0. emacs -Q
>   1. M-x cd RET ~/Downloads/ RET
>   2. C-x d / ~ TAB s TAB

I did not give, nor have I seen, this recipe in this bug thread.  But I
see now that the recipe of my OP (which lacked the above step 1) could
be understood as consistent with the above.  There is indeed a
difference between

  Dired (directory): ~/~ TAB

or

  Dired (directory): ~/Downloads/~ TAB

on the one hand, and

  Dired (directory): ~//~ TAB

or

  Dired (directory): ~/Downloads//~ TAB

on the other.  But the bug I meant to report is about this:

  Dired (directory): ~//~s TAB

or

  Dired (directory): ~/Downloads//~s TAB

which both get '[No match]', whereas

  Dired (directory): ~//~steve TAB

or

  Dired (directory): ~/Downloads//~steve TAB

both complete, to '~//steve/' and '~/Downloads//steve/', respectively.  

One thing I just noticed: in the latter two case, when I type '/', that
changes the face on '~/' or '~/Downloads/' to shadow, and when I then
type '~', the changes the face of the just typed '/' to shadow, but when
I continue and type 's', then the face of the last '/' returns to
default (but the face of the preceding characters remains shadow), and
stays like that when I add 't', 'e', 'v'; but as soon as I add 'e'
(which make TAB complete successfully), the face of the last '/' changes
back to shadow (and '~steve' keeps default face).

Steve Berman