From: Juri Linkov <juri@jurta.org>
Cc: emacs-devel@gnu.org
Subject: Re: Type Ahead Find
Date: Sat, 19 Mar 2005 14:29:29 +0200 [thread overview]
Message-ID: <87psxvq11d.fsf@jurta.org> (raw)
In-Reply-To: <874qf83a5i.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Fri, 18 Mar 2005 16:53:45 -0500")
Stefan Monnier <monnier@iro.umontreal.ca> 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 ()
(save-match-data
(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
http://www.jurta.org/emacs/
next prev parent reply other threads:[~2005-03-19 12:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-18 19:45 Type Ahead Find Juri Linkov
2005-03-18 20:21 ` Drew Adams
2005-03-18 21:53 ` Stefan Monnier
2005-03-19 12:29 ` Juri Linkov [this message]
2005-03-19 21:19 ` Miles Bader
2005-03-19 22:09 ` David Kastrup
2005-03-19 23:33 ` Miles Bader
2005-03-20 20:17 ` Juri Linkov
2005-03-20 21:46 ` David Kastrup
2005-03-20 22:04 ` Miles Bader
2005-03-21 19:28 ` Juri Linkov
2005-03-20 20:14 ` Juri Linkov
2005-03-20 20:22 ` Juri Linkov
2005-03-20 0:22 ` Richard Stallman
2005-03-20 20:19 ` Juri Linkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87psxvq11d.fsf@jurta.org \
--to=juri@jurta.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.