[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Type Ahead Find

From: Juri Linkov
Subject: Re: Type Ahead Find
Date: Sat, 19 Mar 2005 14:29:29 +0200
User-agent: Gnus/5.110002 (No Gnus v0.2) Emacs/22.0.50 (gnu/linux)

Stefan Monnier <address@hidden> writes:
>> I-search: gnu [GNU Free Documentation License]
> I'm not particularly happy about this reuse of the [...] message.
> It's meant to hold an error message.

Reusing an error message variable is not a clean solution, indeed.
Perhaps, it's better to add a new similar variable with the purpose
of displaying an additional data during isearch.

> Maybe it's not too serious as such, but given that the text displayed
> there is (at least in your example) nothing more than the text
> under point, I don't find it to be worthwhile.

There is the text under point only in my first example.  It would be
very useful to display hidden text like when Info-hide-note-references
hides the reference node names, so for example, when isearch reaches
the reference `*Note Local Variables in Files: (emacs)File variables',
it would display the hidden node name in square brackets:

I-search: local variables [(emacs)File variables]

It is also useful to display a data associated with the text
under point (from text properties, or other associated sources).
So in w3m buffers (where only a link text is displayed) it would
display an URL (not present in the buffer) in square brackets.
For example, for a link <a href="http://www.gnu.org/";>The GNU Project</a>
when isearch finds the link text `The GNU Project', the message will be:

I-search: project [http://www.gnu.org/]

> Actually, the first implementation of isearch-search-fun-function
> (a good bit before I installed it in the CVS) was triggered by
> a question on gnu.emacs.help of how to do an "incremental imenu" and
> I implemented it with isearch-search-fun-function where I simply
> mixed the "current search string" with the imenu-generic-expression
> in order to constrain the search space, pretty much in the way
> you suggest.

IMO, it would be much simpler to implement this with
`isearch-success-function', with a small piece of code:

(set (make-local-variable 'isearch-success-function)
     ;; isearch only in function names
     (lambda ()
         (let* ((re (cdr (assoc nil imenu-generic-expression))))
           (and (save-excursion (beginning-of-line) (looking-at (car re)))
                (>= (point) (match-beginning (cadr re)))
                (<= (point) (match-end (cadr re))))))))

> It seems that what you're suggesting is basically implementable as:
>    (setq isearch-search-fun-function
>          `(lambda (string &optional bound noerror)
>            (if (funcall isearch-success-function)
>                (,(isearch-search-fun) string bound noerror))))

This won't work.  There should be a while-loop to call the
default search function in loop until the predicate function
`isearch-success-function' reports the success.  But there is
already such a loop in `isearch-search'.  It's better to reuse it.

`isearch-success-function' has another useful property: it overrides
the test with `(isearch-range-invisible)'.  This will allow searching
in invisible texts in a function defined in `isearch-success-function'.

The new `isearch-success-function' will also simplify implementing of
search in modes where both "widening" and constraining the search space
is simultaneously needed, like in Info to search text only in references
and menu items through multiple nodes.

Juri Linkov

reply via email to

[Prev in Thread] Current Thread [Next in Thread]