Re: Fast completion with visible cue?

From:

Juri Linkov

Subject:

Re: Fast completion with visible cue?

Date:

Sun, 29 Aug 2004 23:29:15 +0300

User-agent:

Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux)

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/