GNU bug report logs - #19412
24.3; ido-write-file sometimes writes to a different directory than it says it will

Previous Next

Full log

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

From: "Ryan C. Thompson" <rct <at> thompsonclan.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 19412 <at> debbugs.gnu.org, Stefan Kangas <stefan <at> marxist.se>
Subject: Re: bug#19412: 24.3; ido-write-file sometimes writes to a different
 directory than, it says it will
Date: Mon, 11 Jan 2021 09:28:06 -0500

On 1/11/21 9:14 AM, Lars Ingebrigtsen wrote:
> "Ryan C. Thompson" <rct <at> thompsonclan.org> writes:
>
>> It's been a while, but I've fixed up my patch and given it some
>> testing, and it seems to work on for me. However, in the meantime,
>> this issue has recently been "fixed" by special-casing write-file in
>> ido.el, as seen in #28513. So if you want to install my patch now,
>> you'll need to install the version attached to that thread. That
>> version reverts the other fix, since of course they are not
>> compatible, and would be redundant even if they were.
> It looks like a more thorough fix.  However:
>
> +          (minibuffer-with-setup-hook
> +              (:append
> +               (lambda ()
> +                 ;; Clear out whatever started in the minibuffer and
> +                 ;; replace it with what the user had already entered
> +                 ;; into ido.
> +                 (delete-minibuffer-contents)
> +                 (insert (abbreviate-file-name ido-current-directory))))
> +            (call-interactively this-command))))
>
> I'd be worried that this would step on other modifications the user may
> be doing from the minibuffer setup.

The only case where this would step on other minibuffer setup code is 
when that code makes modifications to the initial input in the 
minibuffer, since those modifications would be deleted and replaced. 
However, in this case I'd argue that is the correct behavior. The point 
of this code is to fall back from ido completion to standard emacs 
completion while preserving the current input. That means that any setup 
hook that modifies the initial contents of the minibuffer has *already* 
run at the start of ido completion and should not run *again* here. 
Effectively, we want to pretend that we are continuing the same 
completion session with a different completion system, even though we 
are actually starting a new completion session. And to do that, we need 
to preserve the user's current input verbatim when falling back.

Previous Next

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