From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Simple isearch concerns Date: Fri, 09 Apr 2021 13:46:27 +0300 Message-ID: <837dlb91mk.fsf@gnu.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> <940751cee5bc247768d3@heytings.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21492"; mail-complaints-to="usenet@ciao.gmane.io" Cc: spacibba@aol.com, emacs-devel@gnu.org, juri@linkov.net To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 09 12:47:53 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 1lUog4-0005Tb-Sq for ged-emacs-devel@m.gmane-mx.org; Fri, 09 Apr 2021 12:47:52 +0200 Original-Received: from localhost ([::1]:45896 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lUog3-0006ek-Ug for ged-emacs-devel@m.gmane-mx.org; Fri, 09 Apr 2021 06:47:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53038) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUof3-0006Bo-DR for emacs-devel@gnu.org; Fri, 09 Apr 2021 06:46:49 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:42119) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lUof0-0003sf-Lb; Fri, 09 Apr 2021 06:46:46 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1256 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lUof0-000442-1e; Fri, 09 Apr 2021 06:46:46 -0400 In-Reply-To: <940751cee5bc247768d3@heytings.org> (message from Gregory Heytings on Fri, 09 Apr 2021 07:20:14 +0000) 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:267700 Archived-At: > Date: Fri, 09 Apr 2021 07:20:14 +0000 > From: Gregory Heytings > cc: juri@linkov.net, spacibba@aol.com, emacs-devel@gnu.org > > > >> +@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. The "scroll" part is what I think needs to be amended: the commands you are affecting are not scroll commands, they are cursor motion commands. > >> ++++ > >> +** 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? I would say "the commands 'beginning-of-buffer', ..., when invoked during I-search, move respectively to ...". > >> +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"? No, just that they exit the search and are executed normally. > >> + (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. I don't understand: why are you wrapping the call with condition-case, in that case?