From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Simple isearch concerns Date: Thu, 3 Mar 2022 17:50:00 +0000 Message-ID: References: <878s5tc0rn.fsf@mail.linkov.net> <87v8wvc7sc.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20801"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gregory@heytings.org, emacs-devel@gnu.org, spacibba@aol.com, juri@linkov.net To: Augusto Stoffel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Mar 03 18:51:47 2022 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 1nPpc9-00059r-30 for ged-emacs-devel@m.gmane-mx.org; Thu, 03 Mar 2022 18:51:45 +0100 Original-Received: from localhost ([::1]:38684 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nPpc7-00087l-Ub for ged-emacs-devel@m.gmane-mx.org; Thu, 03 Mar 2022 12:51:43 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:58358) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nPpam-0006sW-Kg for emacs-devel@gnu.org; Thu, 03 Mar 2022 12:50:20 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:14184 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1nPpaj-0005KV-D4 for emacs-devel@gnu.org; Thu, 03 Mar 2022 12:50:19 -0500 Original-Received: (qmail 36603 invoked by uid 3782); 3 Mar 2022 17:50:01 -0000 Original-Received: from acm.muc.de (p4fe15875.dip0.t-ipconnect.de [79.225.88.117]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 03 Mar 2022 18:50:00 +0100 Original-Received: (qmail 8312 invoked by uid 1000); 3 Mar 2022 17:50:00 -0000 Content-Disposition: inline In-Reply-To: <87v8wvc7sc.fsf@gmail.com> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:286793 Archived-At: Hello, Augusto. On Thu, Mar 03, 2022 at 17:36:35 +0100, Augusto Stoffel wrote: > The non-quitting scroll commands in isearch are an extremely useful > addition. But I looked at the implementation now and I'm finding it > problematic. > At some point it was decided that instead of just defining > 'isearch-scroll-up' and 'isearch-scroll-down commands', some > pre-command-hook trickery would be used. Presumably this is so that an > user option, 'isearch-allow-scroll', could be provided (that's what I > gather from the parent message of this email). This is not quite how the history of this facility was. (I wrote the original version back in 2003.) isearch-allow-scroll was at the centre of the mechanism right from the beginning. The idea was that users could use the same keys for scrolling whilst inside an isearch as in ordinary editing. Commands like isearch-scroll-up never came into consideration. Originally, the pre-command- and post-command- hooks weren't used. They were implemented as a code clean-up some while later (I think, by Juri Linkov). > But this has several disadvantages: you can't assign different keys for > the quitting and non-quitting versions of the scroll commands; How is that a disadvantage? To quit and scroll requires RET plus a scrolling key sequence. Were we to find new key sequences just for a quitting version of lots of commands, they would be longer than for the two distinct commands together. > you can't put the (nonexistent) isearch-scroll-up/down commands in a > repeat map; you can't activate the feature selectively, e.g. so that > scrolling doesn't quit isearch but beginning/end of buffer does; For this, you can just set the isearch-allow-scroll property to nil for the commands you want to quit isearch. > you can't advice or redefine isearch-scroll-up/down, because they > don't exist; You can advise the scrolling commands directly, testing for being inside an isearch if needed. > it's harder for external package to integrate (I had to copy a piece > of the isearch-pre-command-hook into isearch-mb.el). I'm not sure what you mean by "integrate", here: integrate with what, to what purpose? > The obvious and natural way to implement this feature would be to define > isearch-scroll-up/down commands, bind them in the M-s prefix, and let > whoever wants it by default to rebind the keys. I think there are around 20 commands which have the isearch-allow-scroll (or scroll-command) property set. I have a few more personal commands, bringing my total to around 30. > Perhaps it's not too late to fix this. Sorry I didn't bring this up at > the time of the discussion. What is to happen to my 30 scrolling commands? Would I have to find 30 new key sequences to bind them to? I wouldn't like that, and I don't think most users of isearch scrolling would, either. Could you perhaps be more explicit on what you're trying to do, and why the current implementation of isearch scrolling makes this difficult? Maybe there's a way forward which doesn't involve wholesale rewriting. -- Alan Mackenzie (Nuremberg, Germany).