GNU bug report logs - #34070
27.0.50; icomplete-mode candidate cycling broken for C-x C-f

Previous Next

Full log

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

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34070 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, drew.adams <at> oracle.com
Subject: Re: bug#34070: 27.0.50;
 icomplete-mode candidate cycling broken for C-x C-f
Date: Mon, 14 Jan 2019 17:11:58 +0000

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

>> From: João Távora <joaotavora <at> gmail.com>
>> Cc: Drew Adams <drew.adams <at> oracle.com>,  34070 <at> debbugs.gnu.org,  monnier <at> iro.umontreal.ca
>> Date: Mon, 14 Jan 2019 16:25:41 +0000
>> 
>> > Please add a test for this, if possible, so that we don't screw this
>> > up again in the future.
>> 
>> I'd love to, but it's not exactly simple to write tests that observe
>> user interaction the minibuffer with ert.  At least for me.  How would I
>> go about doing that?  Any pointers/prior art?
>
> (A stab in the dark) invoke the function bound to TAB and examine what
> it produces?

:-)

Where do you mean TAB?  It's not even in the recipe.  Well I though
about it a bit and can probalby use minibuffer-setup-hook

(let ((minibuffer-setup-hook
       (append minibuffer-setup-hook
               (list (lambda ()
                       ;; commands and observations
                       ))))
      (default-directory source-directory))
  (find-file-read-args "Find file: " (confirm-nonexistent-file-or-buffer)))

Don't know how to observe the icomplete candidates though, but this
strategy is probably enough to make a test.  I'd like to push the fix
before that maybe, any objections?

João

Previous Next

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