From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.devel Subject: Re: Simple isearch concerns Date: Fri, 09 Apr 2021 07:20:14 +0000 Message-ID: <940751cee5bc247768d3@heytings.org> References: <20210403001539.x4rb55dvh46rmhb3.ref@Ergus> <20210403001539.x4rb55dvh46rmhb3@Ergus> <878s5wmsjp.fsf@mail.linkov.net> <87mtubz4ls.fsf@mail.linkov.net> <8735w22s9b.fsf@mail.linkov.net> <3ec7e2e58a3733a48ae9@heytings.org> <878s5tc0rn.fsf@mail.linkov.net> <3ec7e2e58a49d4f0ec99@heytings.org> <878s5t9p1i.fsf@mail.linkov.net> <9ff81b52fad2911cc740@heytings.org> <87im4w1tgw.fsf@mail.linkov.net> <9ff81b52fa878cb35a86@heytings.org> <87pmz4zgn5.fsf@mail.linkov.net> <9ff81b52fa72c1233122@heytings.org> <83czv47z99.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26054"; mail-complaints-to="usenet@ciao.gmane.io" Cc: spacibba@aol.com, emacs-devel@gnu.org, juri@linkov.net To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 09 09:21:28 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lUlSK-0006h1-Ec for ged-emacs-devel@m.gmane-mx.org; Fri, 09 Apr 2021 09:21:28 +0200 Original-Received: from localhost ([::1]:42600 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lUlSJ-0002o1-Gl for ged-emacs-devel@m.gmane-mx.org; Fri, 09 Apr 2021 03:21:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60330) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUlRE-0002Hh-2v for emacs-devel@gnu.org; Fri, 09 Apr 2021 03:20:20 -0400 Original-Received: from heytings.org ([95.142.160.155]:35038) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUlRB-0002AJ-Pw; Fri, 09 Apr 2021 03:20:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1617952814; bh=tcITFRmzYtd1X/EhEqhfNuctce+2deLLQYfUW8nSupg=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=sjWrtdb2j+z83dgkyAFr+WbqyWbfoIYRegHmD7tj9c/ZMTto4oDK6bnSnj91OO7pu 7F9J9yit3CwCMA7sYTZkeWzJT+S9sXs3vt9JIdQRxgA0uIjgvBOY3Z+4rh9b+yItIq X8nVgSJHGEOCql8EBlDyiyOzRBXdZJj7UwwfYOj5Ld31VRS1A7O02S0+am+jPlRXxJ 4KKkjaN8Ffj6Fvy9E0a9ObK4RigqBmeJxKGZYiFhuhpdwYprJY6l6eZxrQapzg15Ba eFcyWQyE25WIFVal4SQm8lLlpSSqZ2RuJ7jzbxGIuHt+Wnjb+ZjySJ4s+Pb70WoOCD 0UcYtIIX1R+yg== In-Reply-To: <83czv47z99.fsf@gnu.org> Received-SPF: pass client-ip=95.142.160.155; envelope-from=gregory@heytings.org; helo=heytings.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:267693 Archived-At: Thanks for your detailed comments! >> +@vindex isearch-allow-match-scroll > > IMO, the name of this variable (and the corresponding property) is not > the best one. "Scroll" is the wrong term here, and "match-scroll" > doesn't help understanding what it does. How about > isearch-allow-motion-commands instead? > I tend to agree with you, but I'm not sure. There is already an 'isearch-allow-scroll' and its corresponding 'isearch-scroll' property, which changes the behavior of motion commands: it becomes possible to scroll (recenter, scroll-up, scroll-down, ...) but without changing the current match. This patch does something related, but different: it becomes possible to scroll among the matches. >> +@cindex motion commands, during incremental search, change >> + When @code{isearch-allow-match-scroll} is non-@code{nil}, it >> +is also possible to change the effect of motion commands during >> +incremental search, by modifying the @code{isearch-match-scroll} >> +property of their symbols. For example, to make @kbd{C-p} and >> +@kbd{C-n} move to the previous and next line and restart Isearch >> +forward and backward respectively, you can put the following >> +lines in your init file (@pxref{Init File}): >> + >> +@example >> +(put 'next-line 'isearch-match-scroll '(next-line . forward)) >> +(put 'previous-line 'isearch-match-scroll '(previous-line . backward)) >> +@end example >> @end table > > This is too "Lispy" IMO to be in the user manual. I suggest to move the > bulk of it into the ELisp manual, and leave only a reference to that in > the user manual. > Okay. I've put it there because just above the 'isearch-move' and 'isearch-scroll' properties are discussed, but indeed no example is given, and these properties are only t/nil ones. >> ++++ >> +** New user option 'isearch-allow-match-scroll'. >> +When this option is set, the commands 'beginning-of-buffer', >> +'end-of-buffer', 'scroll-up-command' and 'scroll-down-command' move >> +respectively to the first occurrence of the current search string >> +in the buffer, the last one, the first one after the current window, >> +and the last one before the current window. > > This sentence should make it clear that it talks about the named > commands that are invoked while in I-search. Otherwise the sentence is > misleading. > I'm not sure I understand what you mean. How would you make it clearer? >> +If non-nil, the four scrolling commands `beginning-of-buffer', >> +`end-of-buffer', `scroll-up-command' and `scroll-down-command' move >> +respectively to the first first occurrence of the current search string in >> +the buffer, the last one, the first one after the current window, and the >> +last one before the current window. > > Presumably if this option is nil, these commands exit I-search and are > executed? This should be in the doc string. > Indeed, if this option is nil, the meaning of these commands is unchanged, which means that they exit Isearch. Should I add something like "If this option is nil, the meaning of these commands is unchanged"? But that could be misleading, because that's not correct when isearch-allow-scroll is non-nil... >> + (condition-case nil >> + (funcall function) >> + (error nil)) > > Wouldn't it be better to at least display the error message (or some > message) in the case the function signals an error? > In this specific case, no: what happens is that Isearch indicates that the search will wrap.