[Conkeror] Bug: minibuffer history and completion

[Jeremy Maitin-Shepard]

marting at gmx.ch writes:

> Hi all,
> I've just reported the following bug on conkeror.org:

> 1. In conkeror, type 'M-x conkeror-version' ((almost) any other
> interactive command will do as well) and hit ENTER.

> 2. Type 'M-x' and then hit TAB (minibuffer-complete) to see possible
> completions.

> 3. Type 'M-p' (minibuffer-history-previous) to access the previous
> command 'conkeror-version'.

> At this point it seems like the completion tree "has precedence over
> the minibuffer"; to see what I mean do any of the following:

> * Hit ENTER and notice the "No match" error.

> * Hit TAB to see possible completions. Notice that the completion tree
>   hasn't shrunk at all (as if the minibuffer was empty).

> * Hit ENTER on one of the possible completions and notice that the
>   completion is executed, not 'conkeror-version'.

I agree the behavior in these cases could improve.  Would you care to
send a patch? (I don't think it would be very difficult to fix.)

> Notice also that the value of 'minibuffer_auto_complete_default'
> doesn't significantly influence conkeror's behaviour in the above
> situation. I would expect the completion tree to be automatically
> recomputed after 3. if 'minibuffer_auto_complete_default' is true.


The minibuffer_auto_complete_default variable specifies whether to
auto-complete only if minibuffer_auto_complete_preferences does not
override it for a particular setting of the $auto_complete argument to
minibuffer.read.

> Finally, conkeror's behaviour in other minibuffer states is also
> contrary to what I would expect but different from the above; e.g. do
> the analogous steps with 'M-x' replaced by 'g'.


-- 
Jeremy Maitin-Shepard