unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: ken manheimer <ken.manheimer@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel <emacs-devel@gnu.org>
Subject: Re: reenabling icomplete operation during read-buffer
Date: Wed, 11 Feb 2009 19:08:17 -0500	[thread overview]
Message-ID: <2cd46e7f0902111608s3c41cba2tc1ed14f861b6f2d4@mail.gmail.com> (raw)
In-Reply-To: <jwv63jjgi0s.fsf-monnier+emacs@gnu.org>

On Mon, Feb 9, 2009 at 9:11 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > i noticed that icomplete stopped operating during, eg,
> > switch-to-buffer, in my CVS checkouts a good while back.  i'm finally
> > getting around to investigating, and see that read-buffer &c fail this
> > condition in icomplete-simple-completing-p:
>
> >        (or t (not (functionp minibuffer-completion-table))
> >            (eq icomplete-with-completion-tables t)
> >            (member minibuffer-completion-table
> >                          icomplete-with-completion-tables))))
>
> > i believe i (or someone) put that in to weed out complicated
> > situations where casual use of completion may be prohibitive, for
> > instance, during file-name read operations where the filesystem could
> > be remote or otherwise mediated.  the thing is, this inhibition is not
> > necessary for buffer-name-reading situations, but i haven't figured
> > out a good way to recognize that situation, in order to reframe the
> > above condition to allow for it.  can anyone suggest a good way to do
> > so?  or am i heading in the wrong direction?
>
> The best fix AFAIK is to set icomplete-with-completion-tables to
> t (i.e. to just drop this whole condition).  After all, icomplete's code
> is now run within a while-no-input, so even access to remote filesystems
> shouldn't be problematic (this was new in Emacs-22, IIRC).

i'd love to simplify that to default icomplete-with-completion-tables
to t, but it misbehaves dramatically for special tramp file visits,
like /sudo:root@localhost:/etc/hosts or /ftp:...

unfortunately, it looks like read-buffer-to-switch (files.el) was
changed to use a manufactured lambda as the completion table, which
means that icomplete can't statically match it to recognize being
within that completion context.  i can add a condition like:

           (and (boundp 'rbts-completion-table)
                (equal minibuffer-completion-table rbts-completion-table))

to get the behavior i want, but that is much too brittle - it depends
on an internal detail of read-buffer-to-switch.

offhand, i would like to have a reliable and simple way to detect that
buffer name reading is happening, so icomplete can be safely enabled
in that situation.  i'm not sure about the more general question,
which is classifying minibuffer reads as candidates for incremental
completion or not..  (in the remote-file reads, there are intermediate
strings which are invalid, and even many valid intermediate strings
would be expensive to complete.)
--
ken
http://myriadicity.net




  reply	other threads:[~2009-02-12  0:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-09 23:27 reenabling icomplete operation during read-buffer ken manheimer
2009-02-10  1:01 ` Drew Adams
2009-02-10  2:11 ` Stefan Monnier
2009-02-12  0:08   ` ken manheimer [this message]
2009-02-12  2:21     ` Stefan Monnier
2009-02-12 23:28       ` ken manheimer
2009-02-13  0:00         ` Drew Adams

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=2cd46e7f0902111608s3c41cba2tc1ed14f861b6f2d4@mail.gmail.com \
    --to=ken.manheimer@gmail.com \
    --cc=emacs-devel@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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).