Re: Fast completion with visible cue?

[Juri Linkov]

Miles Bader <address@hidden> writes:
> For cases where you want to recall something "by (non-prefix) name" just
> using minibuffer history search (M-r) is also very useful.

Using M-r and M-s for minibuffer history search is not too convenient:
switching keys `M-r RET M-r RET M-r RET ...' is not as fast as using
only one key to repeat the search for the same string.

What I'm thinking about as a better alternative is using isearch
for minibuffer history search.  By redefining `isearch-search-fun-function'
and `isearch-wrap-function' and using C-M-s and C-M-r to search the
minibuffer history this is quite easy to implement.

But there are some problems:

1. isearch used to search text in the minibuffer overwrites the minibuffer
   contents with its own text "I-search: ...".  This problem could be
   solved by not displaying this message when the minibuffer is active,
   because isearch has other visible indication for the search string
   which is displayed in the (mini-)buffer in the `isearch' face.
   What is needed to be displayed in the isearch minibuffer are
   isearch messages about the failed isearch (perhaps, 1 sec is a
   sufficient delay for displaying it), and the value of an incomplete
   regexp (to help the user to finish writing it).  So instead of the
   current code in the `isearch-message' function:

    (if c-q-hack
        m
      (let ((message-log-max nil))
        (message "%s" m)))

   to use the following conditions:

    (if (or (and (minibuffer-window-active-p (selected-window))
                 isearch-success
                 (not isearch-invalid-regexp))
            c-q-hack)
        m
      (let ((message-log-max nil))
        (message "%s" m)
        (when (and (minibuffer-window-active-p (selected-window))
                   (not isearch-invalid-regexp))
          (sit-for 1)
          (message ""))))

2. Another question is what function to use as `isearch-search-fun-function'
   to search the minibuffer history.  Most natural candidates are
   `next-matching-history-element' and `previous-matching-history-element',
   but they can't be used without changes.  I see three possibilities:

   1. to improve them to allow finding multiple occurrences of the
   search string in the same minibuffer history item before going
   to the next history item (currently, M-n and M-p search only for
   the first occurrence of the search string within one history item,
   but isearch should visit all occurences), and some other changes
   not affecting the current behavior of M-n and M-p, but needed for
   isearch.

   2. to implement new functions similar to `previous-matching-history-element'
   suitable for using in isearch.

   3. to set `isearch-wrap-function' to a function calling either
   `next-history-element' or `previous-history-element'.  This is the most
   easiest solution, but this is not quite right, since it requires an
   additional keystroke C-s before wrapping, and moreover, wrapping
   should mean going to the first item of the minibuffer history ring,
   instead of going to the next history element.

I'm most inclined to the second solution (implementing new functions).

-- 
Juri Linkov
http://www.jurta.org/emacs/