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?