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: Mon, 12 Apr 2021 01:17:04 +0300 Organization: LINKOV.NET Message-ID: <87czv078zr.fsf@mail.linkov.net> References: <20210403001539.x4rb55dvh46rmhb3.ref@Ergus> <83eefk802u.fsf@gnu.org> <871rbjdea4.fsf@mail.linkov.net> <8335vz91en.fsf@gnu.org> <940751cee594ef1cf8a4@heytings.org> <83zgy77hep.fsf@gnu.org> <940751cee566285b8519@heytings.org> <83wntb7eli.fsf@gnu.org> <940751cee50d69f2231d@heytings.org> <83r1jj7bhg.fsf@gnu.org> <940751cee5acf0f913df@heytings.org> <83eefj705i.fsf@gnu.org> <940751cee53181aedd72@heytings.org> <83a6q67gme.fsf@gnu.org> <5cf18ab57c8becad2999@heytings.org> <83pmz25sdr.fsf@gnu.org> <5cf18ab57ca5d2cc99ad@heytings.org> <8735vxbwju.fsf@mail.linkov.net> <83wnt947v0.fsf@gnu.org> <3755fe92dcaebb639062@heytings.org> <3755fe92dc9cb5a6a591@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="2125"; 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: Eli Zaretskii , spacibba@aol.com, emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 12 00:37:21 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 1lVihl-0000TZ-5j for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Apr 2021 00:37:21 +0200 Original-Received: from localhost ([::1]:45314 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lVihk-00031D-84 for ged-emacs-devel@m.gmane-mx.org; Sun, 11 Apr 2021 18:37:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52648) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lVie7-0008CV-7L for emacs-devel@gnu.org; Sun, 11 Apr 2021 18:33:35 -0400 Original-Received: from relay9-d.mail.gandi.net ([217.70.183.199]:36695) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lVie5-00044e-6l; Sun, 11 Apr 2021 18:33:34 -0400 X-Originating-IP: 91.129.96.157 Original-Received: from mail.gandi.net (m91-129-96-157.cust.tele2.ee [91.129.96.157]) (Authenticated sender: juri@linkov.net) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id C0611FF805; Sun, 11 Apr 2021 22:33:28 +0000 (UTC) In-Reply-To: <3755fe92dc9cb5a6a591@heytings.org> (Gregory Heytings's message of "Sun, 11 Apr 2021 10:16:37 +0000") Received-SPF: pass client-ip=217.70.183.199; envelope-from=juri@linkov.net; helo=relay9-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:267927 Archived-At: >> (Note that you should wait to push it until my paperwork has been >> processed by the FSF, I wasn't aware of that subtlety.) While you are waiting for your paperwork to be processed, I'd like to point out that when I tried to debug a problem of the failed lazy-highlighting for non-nil lazy-highlight-buffer, I noticed that the current implementation is not the best one: > +(put 'beginning-of-buffer 'isearch-motion > + '((lambda () (goto-char (point-min))) . forward)) > > + (let* ((property (get this-command 'isearch-motion)) > + (function (car property)) > + (funcall function) > + (setq this-command 'ignore))) The problem is that it executes a function as a command, and resets the current command to 'ignore'. This causes more problems. Instead of emulating the command execution, it would be more natural to let the command to be completed as usual, then call 'isearch-repeat' in 'isearch-post-command-hook' after the command moved point. This is how other existing features work: isearch-allow-prefix, isearch-allow-scroll, isearch-yank-on-move. They prepare internal variables in isearch-pre-command-hook, let the command to move point, then do post-processing in isearch-post-command-hook to update the search string, etc. Then instead of such definition: (put 'beginning-of-buffer 'isearch-motion '((lambda () (goto-char (point-min))) . forward)) you can use a shorter definition (put 'beginning-of-buffer 'isearch-motion 'forward) that means: let the command 'beginning-of-buffer' move point to the beginning of the buffer, then call 'isearch-repeat' with the argument 'forward' in isearch-pre-command-hook. When there is no existing command with required functionality, then the command body could be defined in the property, e.g. (put 'scroll-up-command 'isearch-motion '((lambda () (interactive) (goto-char (window-end))) . forward)) Then in isearch-pre-command-hook you can setq 'this-command' to the command definition: (let* ((property (get this-command 'isearch-motion)) (function (car property)) (setq this-command function))) then the definition will be executed as a command.