reenabling icomplete operation during read-buffer

reenabling icomplete operation during read-buffer

[ken manheimer]

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?

thanks!
--
ken
http://myriadicity.net

RE: reenabling icomplete operation during read-buffer

[Drew Adams]

> 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))

Typo - (or (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?

1. Please consider doing this for `icomplete-with-completion-tables':

* Make it a defcustom.
* Document `t' as a possible value.

The doc of `icomplete-with-completion-tables' does not mention what it means for
the value to be `t', and the above code is the only place where the variable is
used.

I was not aware of this variable, which has apparently existed since Emacs 22. I
might even try using `t' as the value - at least for a while. ;-)


2. FWIW, this code seems a bit weird, to me:

(defvar icomplete-prospects-length 80)
(make-obsolete-variable
 'icomplete-prospects-length 'icomplete-prospects-height "23.1")

(defcustom icomplete-prospects-height
  (+ 1 (/ (+ icomplete-prospects-length 20) (window-width)))
  "Maximum number of lines to use in the minibuffer."
  :type 'integer :group 'icomplete :version "23.1")

The CURRENT-NAME for the OBSOLETE-NAME `icomplete-prospects-length' is said to
be `icomplete-prospects-height' (using the terminology of the doc string of
`make-obsolete-variable'). I recognize that this really means only that the
compiler warning will advise you to use the latter instead of the former, but at
least some users might (mis)understand this as saying that they are just
different names that represent the same thing (have the same value). Better to
have an explicit message that describes the relation (see below).

The default value of the option seems problematic anyway, since it is based on
the width of the window that happens to be current at the time the defcustom is
evaluated. Does that make sense? I guess this assumes that that window is the
minibuffer window, and it assumes that that particular minibuffer window is
representative of other possible minibuffer windows.

If something really smart and foolsafe can't be done here, perhaps just (a) have
a fixed default value for the option of, say, 1 or 2, and (b) tell users at
byte-compile time that `icomplete-prospects-length' can no longer be used. IOW,
something like this:

(defvar icomplete-prospects-length nil
  "Obsolete internal variable - do not use this.
You can no longer control the icomplete display length
directly.  You can instead control the height of the
displayed prospects, using option `icomplete-prospects-height'.")

(make-obsolete-variable 'icomplete-prospects-length
  "You can no longer control the icomplete display length.
You can instead control the height of the displayed
prospects, using option `icomplete-prospects-height'." "23.1")

(defcustom icomplete-prospects-height 2
  "Maximum number of lines for icomplete to use in the minibuffer."
  :type 'integer :group 'icomplete :version "23.1")

Or is it "not done" to just cut off an obsolete variable completely and
immediately like that?

Re: reenabling icomplete operation during read-buffer

[Stefan Monnier]

> 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).


        Stefan

Re: reenabling icomplete operation during read-buffer

[ken manheimer]

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

Re: reenabling icomplete operation during read-buffer

[Stefan Monnier]

> 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:...

These need to be fixed.  At some point, they worked OK.

> 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.

I've installed a different fix.


        Stefan

Re: reenabling icomplete operation during read-buffer

[ken manheimer]

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

> > 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:...
>
> These need to be fixed.  At some point, they worked OK.
>
> > 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.
>
> I've installed a different fix.

thanks!

people wanting to use icomplete but turn it off for buffer name
reading (so they can use something like iswitchb or icycles) won't be
able to do so, but providing for that seems beyond the point of
diminishing returns, to me.

>        Stefan

--
ken
http://myriadicity.net

RE: reenabling icomplete operation during read-buffer

[Drew Adams]

> people wanting to use icomplete but turn it off for buffer name
> reading (so they can use something like iswitchb or icycles) won't be
> able to do so, but providing for that seems beyond the point of
> diminishing returns, to me.

FWIW, there is no problem using Icomplete with Icicles (for buffer names, file
names or whatever).