From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: Simple isearch concerns Date: Wed, 07 Apr 2021 23:12:12 +0300 Organization: LINKOV.NET Message-ID: <878s5tc0rn.fsf@mail.linkov.net> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33727"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) Cc: Ergus , emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 07 22:18:56 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 1lUEdW-0008Ts-1l for ged-emacs-devel@m.gmane-mx.org; Wed, 07 Apr 2021 22:18:50 +0200 Original-Received: from localhost ([::1]:56964 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lUEdV-0000CU-36 for ged-emacs-devel@m.gmane-mx.org; Wed, 07 Apr 2021 16:18:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57218) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUEbO-0006Q4-Gb for emacs-devel@gnu.org; Wed, 07 Apr 2021 16:16:38 -0400 Original-Received: from relay5-d.mail.gandi.net ([217.70.183.197]:55183) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUEbM-0000FU-AZ for emacs-devel@gnu.org; Wed, 07 Apr 2021 16:16:38 -0400 X-Originating-IP: 91.129.107.223 Original-Received: from mail.gandi.net (m91-129-107-223.cust.tele2.ee [91.129.107.223]) (Authenticated sender: juri@linkov.net) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 94F4D1C0003; Wed, 7 Apr 2021 20:16:32 +0000 (UTC) In-Reply-To: <3ec7e2e58a3733a48ae9@heytings.org> (Gregory Heytings's message of "Wed, 07 Apr 2021 17:21:16 +0000") Received-SPF: pass client-ip=217.70.183.197; envelope-from=juri@linkov.net; helo=relay5-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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:267572 Archived-At: >>> +(put 'beginning-of-buffer 'isearch-match-scroll 'isearch-beginning-of-buffer) >>> +(put 'end-of-buffer 'isearch-match-scroll 'isearch-end-of-buffer) >>> +(put 'scroll-up-command 'isearch-match-scroll 'isearch-scroll-up) >>> +(put 'scroll-down-command 'isearch-match-scroll 'isearch-scroll-down) >>> ... >>> + ((and isearch-allow-match-scroll >>> + (symbolp this-command) >>> + (get this-command 'isearch-match-scroll)) >>> + (setq this-command (get this-command 'isearch-match-scroll))) >> >> As noted in another message, this is basically the same as: >> >> (define-key isearch-mode-map [remap beginning-of-buffer] 'isearch-beginning-of-buffer) >> (define-key isearch-mode-map [remap end-of-buffer] 'isearch-end-of-buffer) >> (define-key isearch-mode-map [remap scroll-up-command] 'isearch-scroll-up) >> (define-key isearch-mode-map [remap scroll-down-command] 'isearch-scroll-down) > > I'm not sure I understand what you mean by this. Indeed this can be done > that way, too, but in that case it isn't a user option anymore, which can > be easily set and toggled. If you want a separate option, this is fine. But then there is no need to duplicate the key remapping feature. To make the new feature more powerful, you could attach to command symbol properties a function that defines where to move point before searching the next match. This is similar to how isearch-yank-internal funcalls its arg 'jumpform', and how its callers like isearch-yank-char uses (lambda () (forward-char arg) (point)) or isearch-yank-word uses (lambda () (forward-word arg) (point)) to define where to move point before using it as the buffer position. So command symbol properties could be defined using the same logic: (put 'beginning-of-buffer 'isearch-match-scroll 'beginning-of-buffer) (put 'end-of-buffer 'isearch-match-scroll 'end-of-buffer) (put 'scroll-up-command 'isearch-match-scroll (lambda () (goto-char (window-end)))) (put 'scroll-down-command 'isearch-match-scroll (lambda () (goto-char (window-start)))) where the symbol property is called like (funcall 'beginning-of-buffer) before repeating the search. Then there is no need to add such ad-hoc commands as isearch-scroll-up and isearch-scroll-down. And instead of (setq this-command (get this-command 'isearch-match-scroll)) isearch-pre-command-hook could contain the same code that is currently duplicated in several commands: (setq isearch-just-started t) (goto-char (window-end)) ;; only this line needs to be ;; replaced with (funcall jumpform) (isearch-repeat 'forward) Whereas it would be easy to handle more commands like below: >>>>> Should then forward-char be remapped to isearch-repeat to go to the >>>>> next match? Then also remap next-line to go to the next line with >>>>> matches, etc. >>>> >>>> Please don't, these commands should exit the search. >>> >>> Yes, I also think these commands should exit the search by >>> default. Users who would like to have that behavior can do so easily >>> with my patch: >>> >>> (put 'next-line 'isearch-match-scroll 'isearch-repeat-forward) >> >> Then 'isearch-match-scroll' has nothing to do with scrolling. > > It was you who suggested that change, you asked: "Should then forward-char > be remapped to isearch-repeat to go to the next match?" Or am > I misunderstanding something? Actually, the 'isearch-match-scroll' above doesn't do what is needed. It just goes to the next match, whereas the need was to go to the next line before searching for a new match. With the logic above, this is easy to define like: (put 'next-line 'isearch-match-scroll (lambda () (forward-line 1)))