all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 16943@debbugs.gnu.org
Subject: bug#16943: 24.3.50; [PATCH] `icomplete-exhibit' needs `with-current-buffer' for minibuffer
Date: Fri, 7 Mar 2014 17:40:20 -0800 (PST)	[thread overview]
Message-ID: <740624be-841d-4560-81b8-367599f26c05@default> (raw)
In-Reply-To: <jwv4n39fswv.fsf-monnier+emacsbugs@gnu.org>

> >  (with-current-buffer (window-buffer (active-minibuffer-window))
> 
> I think this would only paper over an underlying problem: icomplete uses
> a buffer-local post-command-hook, so it makes no sense that it would be
> run in another buffer.

`icomplete-exhibit' should not use a buffer other than the minibuffer.
But it apparently does sometimes.  Hence the fix: confine it to the
minibuffer.

(FWIW, it is text like this that gets picked up from *Completions*:
  "Click <mouse-2> on a completion to select it.")

IIRC, Icomplete started out using the minibuffer, but (in the same
(or perhaps a recursive?) minibuffer activation) it later was using
*Completions*.  I've kind of forgotten just how I was reproducing this.

> A few possibilities:
>
> - the hook is placed in the wrong buffer, in which case it would
>   only be run in the wrong buffer.
    ^^^^

Clearly the minibuffer, not *Completions*, is the current buffer
for *most* invocations of `icomplete-exhibit'.  Otherwise, it would
not work in general.  It is not run *only* in the wrong buffer, for
sure.

> - an earlier post-command-hook function changed current-buffer.
> - an earlier minibuffer-setup-hook function changed current-buffer
>   (which would cause the hook to be placed in the wrong buffer).

Even if such were the case, for whatever reason, `icomplete-exhibit'
should act on the text in the minibuffer.  It should look to the
minibuffer to do its job, regardless of whether some other buffer
happens to be current when it is invoked.  If the minibuffer is
active then its input text is there for Icomplete to read and
complete.

You have said that `icomplete-exhibit' should not be invoked unless
the minibuffer is current.  Maybe so.  But maybe not.  In the case
of my fix it now does the right thing: even if invoked with
*Completions* current, it picks up text from the minibuffer.
Would you instead have it do nothing in that case (e.g., by 
preventing from being invoked)?

Icomplete should complete minibuffer text, and so should be confined
to the minibuffer.  That does not imply that it should be invoked
only from the minibuffer, i.e., only when the minibuffer is the
current buffer.  That would be a stronger constraint, whose
necessity is not demonstrated.

What is necessary and sufficient is that it be able to do its job
when the minibuffer is active.  That's not the same thing as it
being *invoked* only with the minibuffer as current buffer.

In any case, `icomplete-exhibit', and the Icomplete code more
generally, should not have a say in what other things might or
might not do wrt `post-command-hook', including while the minibuffer
is active.

`icomplete-exhibit' is meant to operate in the minibuffer.
Perhaps some other commands on `post-command-hook' do not have
that constraint, and make sense regardless of the buffer.  Enabling
`icomplete-mode' should not prevent such commands from being invoked
by `post-command-hook' just because the minibuffer might be active.

It seems to me that the proposed fix is entirely appropriate:
as long as the minibuffer is active, `icomplete-exhibit' can do
its thing.  It just needs to be limited to doing it in the
minibuffer; that's all.

Control of Icomplete should be limited to what it does.  It should
focus on the minibuffer.  But that does not say anything about
`post-command-hook' in general while the minibuffer is active.

Feel free to debug this and come up with a different fix.  But
a priori I don't think that should involve "fixing" what other
commands on `post-command-hook' might do wrt the current buffer.





  reply	other threads:[~2014-03-08  1:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-05 18:50 bug#16943: 24.3.50; [PATCH] `icomplete-exhibit' needs `with-current-buffer' for minibuffer Drew Adams
2014-03-08  0:17 ` Stefan Monnier
2014-03-08  1:40   ` Drew Adams [this message]
2014-03-08  4:12     ` Stefan Monnier
2016-04-29 17:59       ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=740624be-841d-4560-81b8-367599f26c05@default \
    --to=drew.adams@oracle.com \
    --cc=16943@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.