From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: Type Ahead Find Date: Sat, 19 Mar 2005 14:29:29 +0200 Organization: JURTA Message-ID: <87psxvq11d.fsf@jurta.org> References: <87k6o4eo2u.fsf@jurta.org> <874qf83a5i.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1111235479 10814 80.91.229.2 (19 Mar 2005 12:31:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 19 Mar 2005 12:31:19 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 19 13:31:18 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DCd6X-0006j1-Fb for ged-emacs-devel@m.gmane.org; Sat, 19 Mar 2005 13:30:57 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DCdND-0004t3-Vn for ged-emacs-devel@m.gmane.org; Sat, 19 Mar 2005 07:48:12 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DCdLj-0004SE-Sq for emacs-devel@gnu.org; Sat, 19 Mar 2005 07:46:40 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DCdLc-0004N2-Md for emacs-devel@gnu.org; Sat, 19 Mar 2005 07:46:33 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DCdLb-0004Lf-S9 for emacs-devel@gnu.org; Sat, 19 Mar 2005 07:46:32 -0500 Original-Received: from [194.126.101.98] (helo=MXR-5.estpak.ee) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DCd6I-0002qk-2c for emacs-devel@gnu.org; Sat, 19 Mar 2005 07:30:42 -0500 Original-Received: from mail.neti.ee (80-235-34-167-dsl.mus.estpak.ee [80.235.34.167]) by MXR-5.estpak.ee (Postfix) with ESMTP id A20DD12C96A; Sat, 19 Mar 2005 14:30:39 +0200 (EET) Original-To: Stefan Monnier In-Reply-To: <874qf83a5i.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Fri, 18 Mar 2005 16:53:45 -0500") User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/22.0.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: news.gmane.org gmane.emacs.devel:34769 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:34769 Stefan Monnier 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 The GNU Project 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/