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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 32215 <at> debbugs.gnu.org, npostavs <at> gmail.com
Subject: Re: bug#32215: 27.0.50;
 Minibuffer completion fails with /~<partial-name>
Date: Fri, 20 Jul 2018 17:56:12 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  32215 <at> 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?

Previous Next

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