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: Sun, 25 Apr 2021 20:24:50 +0300 Organization: LINKOV.NET Message-ID: <87pmyimiwd.fsf@mail.linkov.net> References: <20210403001539.x4rb55dvh46rmhb3.ref@Ergus> <20210403001539.x4rb55dvh46rmhb3@Ergus> <2599ffef-4f70-025c-5f9c-61b9ac94faf8@inventati.org> <87eefrbo9k.fsf@posteo.net> <7473b27b2b479f5686af@heytings.org> <87tuon9vf1.fsf@posteo.net> <20210403174508.xwr5uc36dzityitn@Ergus> <87wnsurdr7.fsf@gmail.com> <87fszij6to.fsf@mail.linkov.net> <87v98asulc.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2573"; 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 , Gregory Heytings , Manuel Uberti , Philip Kaludercic , emacs-devel@gnu.org To: Augusto Stoffel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Apr 25 19:49:23 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 1laisl-0000WL-HE for ged-emacs-devel@m.gmane-mx.org; Sun, 25 Apr 2021 19:49:23 +0200 Original-Received: from localhost ([::1]:43112 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1laisk-0006fJ-Gc for ged-emacs-devel@m.gmane-mx.org; Sun, 25 Apr 2021 13:49:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43208) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lairI-0005QG-5S for emacs-devel@gnu.org; Sun, 25 Apr 2021 13:47:52 -0400 Original-Received: from relay7-d.mail.gandi.net ([217.70.183.200]:49805) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lairE-0007wx-Bo for emacs-devel@gnu.org; Sun, 25 Apr 2021 13:47:51 -0400 X-Originating-IP: 91.129.102.166 Original-Received: from mail.gandi.net (m91-129-102-166.cust.tele2.ee [91.129.102.166]) (Authenticated sender: juri@linkov.net) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id 515A720002; Sun, 25 Apr 2021 17:47:42 +0000 (UTC) In-Reply-To: <87v98asulc.fsf@gmail.com> (Augusto Stoffel's message of "Sun, 25 Apr 2021 09:15:43 +0200") Received-SPF: pass client-ip=217.70.183.200; envelope-from=juri@linkov.net; helo=relay7-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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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:268400 Archived-At: >> Nice idea. Like TAB typed in the minibuffer updates the Completions buffer, >> C-s typed in the isearch-edit-string minibuffer could update the matches >> in the searched buffer. > > Do you think this feature could make it into isearch.el, or would make > more sense as an external package? You can take a look at the git repo > linked in my previous message to get a sense of how the implementation > would look like. If its implementation becomes more hackish, then it would make more sense as an external package. Otherwise, if we can find an elegant way to naturally integrate it with isearch.el, then this feature could make it into isearch.el. As the first step in this direction, we could try to get rid of the macro ‘with-isearch-suspended’. It was a hackish solution to temporarily exit isearch before reading a string from the minibuffer. To be able to do the same in a nicer way, we need to turn isearch-mode into buffer-local. Its current global status caused too much trouble in the past. For example, see our recent attempt to forcefully terminate isearch when it switched to another buffer. With buffer-local isearch-mode, there will be no need to exit isearch before switching to another buffer. You could even have simultaneously active isearch modes in different buffers, and freely switch to the minibuffer without exiting buffer-local isearch. Is such thing achievable? There is no problem to make hooks used by isearch buffer-local by adding the arg LOCAL to add-hook: (add-hook 'pre-command-hook 'isearch-pre-command-hook nil t) (add-hook 'post-command-hook 'isearch-post-command-hook nil t) (add-hook 'mouse-leave-buffer-hook 'isearch-mouse-leave-buffer nil t) (add-hook 'kbd-macro-termination-hook 'isearch-done nil t) But trying to make buffer-local overriding-terminal-local-map with: (setq-local overriding-terminal-local-map isearch-mode-map) fails with an error: Debugger entered--Lisp error: (error "Symbol overriding-terminal-local-map may not be buffer-local") make-local-variable(overriding-terminal-local-map) (set (make-local-variable 'overriding-terminal-local-map) isearch-mode-map) isearch-mode(t nil nil nil) isearch-forward(nil 1) > In isearch.el itself, one would have to introduce a new macro > `(with-current-search-buffer ...)' and wrap the body of every relevant > interactive command in it (similar to the `isearch-mb--with-buffer' > advice in my package sketch). Then there's also the case of commands > start or end a search, which need special treatment. This is similar to what currently does isearch-yank-char-in-minibuffer. It would be nice to replace it with a new macro that will redirect all normal isearch commands to the original buffer.