From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Augusto Stoffel Newsgroups: gmane.emacs.devel Subject: Re: [WIP PATCH] Controlling Isearch from the minibuffer Date: Mon, 10 May 2021 22:24:13 +0200 Message-ID: <87eeeenxqq.fsf@gmail.com> References: <87zgx5cz33.fsf@gmail.com> <87o8djohqf.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36649"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cc: emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 10 22:25:17 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 1lgCSr-0009R8-36 for ged-emacs-devel@m.gmane-mx.org; Mon, 10 May 2021 22:25:17 +0200 Original-Received: from localhost ([::1]:59948 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lgCSq-00011L-4z for ged-emacs-devel@m.gmane-mx.org; Mon, 10 May 2021 16:25:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51916) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lgCRv-0000Gg-9R for emacs-devel@gnu.org; Mon, 10 May 2021 16:24:19 -0400 Original-Received: from mail-ej1-x62f.google.com ([2a00:1450:4864:20::62f]:37868) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lgCRt-0007iR-JA for emacs-devel@gnu.org; Mon, 10 May 2021 16:24:18 -0400 Original-Received: by mail-ej1-x62f.google.com with SMTP id w3so26472818ejc.4 for ; Mon, 10 May 2021 13:24:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:message-id:user-agent :mime-version; bh=HzvPRWG0jwrNzIGyjVf5NzyjvB7QP4Pws9j7uK7714Q=; b=mSqzUjGTXEGDtkXHXaFLuIk9+I/LMOtXd0zPgNibco5LnEfUo7SK3OD63Ln2YveuCy 91vir5JLf/oFC9qLqX899eOzq5bTCppTNhKIoB9ig8KdBgHNmvWDQHMYktsprYzmGa7m heJkBjTb/tMI6cGjszhDeTvuYLx8cXq29K+twxGzmaMmhXvwQPAe9d70hiWYvp8hHf1c yMZv27BEcwg9J/44QCQM89W+qtUg1drtBF+0Y4kDIKnx/6ZMgmXcTfezvf+JMmpRBi5F ZKBTyyJ8i0l7+pk/Hj/Ext0eiedzYMnhVEa0whuFBpCt2M30rANHJdDmy44FdcoJWTRa wK2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:message-id :user-agent:mime-version; bh=HzvPRWG0jwrNzIGyjVf5NzyjvB7QP4Pws9j7uK7714Q=; b=GuJ0zoWwX18hi09dkK9sNtui8zkd0hnsq5tVu9HMh0smWzZE6eD8Ov1OiMB/lSQ4FJ Gj6Kw8fwWF4H6rxfuDMmAlmRMKVMHbOvulgvqq0WuBt9zdyGhCLIKx+jAQK30XHhp5VT ODzkcl4cLJ+eVRodZpt+bTSs1EzuPEqsAX4sUvLYdhYv4Jxpbp0tFypUf9F3Aub+ppQr 16NrKba8fNzs+9Giz+EUzVbYFAlfUurqFuPF6JmRUdNOU8Wx5xh/Ft+6BnZAG0ypeyir TqtzogClwmyVEs1uCAEEXynROJFpn1F9xOf9Pbnx/2M/Hn5kQAghpwCU2Z6K5YCgByJp Fm/A== X-Gm-Message-State: AOAM531no0tCYv+uc/UBkgqD2PP3HU9X+J8UGKUHaUqfcDRIFgAeo77N txwXVa73hYk1RufAPFiKqL3ThNX1ebQ= X-Google-Smtp-Source: ABdhPJw6N+JWu4YrRZuOV7VXDDSezWcbu6K6uI6xMQbvF2ayhoi/oetSN4GNUMOXpRB6gU6Qc6puXA== X-Received: by 2002:a17:906:c14c:: with SMTP id dp12mr27690557ejc.312.1620678255130; Mon, 10 May 2021 13:24:15 -0700 (PDT) Original-Received: from ars3 ([2a02:908:2211:8540::68a]) by smtp.gmail.com with ESMTPSA id x21sm9975537ejc.93.2021.05.10.13.24.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 May 2021 13:24:14 -0700 (PDT) Received-SPF: pass client-ip=2a00:1450:4864:20::62f; envelope-from=arstoffel@gmail.com; helo=mail-ej1-x62f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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:269131 Archived-At: On Sun, 9 May 2021 at 22:05, Juri Linkov wrote: >> - Does the approach taken here seem sufficiently robust? Note in >> particular the `with-isearch-window' macro, which is now needed around >> several functions, > > You can avoid the with-isearch-window macro by checking > in isearch-pre-command-hook if the current buffer is the minibuffer, > then switch to the original buffer, and let the isearch command to > do what it normally does, then switch back to the minibuffer > in isearch-post-command-hook. That's an interesting idea, thanks. This indeed makes the changes more localized, which seems desirable. (On the other hand, it spreads the logic currently contained in `with-isearch-window' across various hooks.) > >> as well as the somewhat hacky `run-with-idle-timer' >> call inside the `isearch-mode' function. > > You can avoid the timer hack by adding a guard to > isearch-post-command-hook: when at the end of the isearch command, > point is not in the minibuffer, activate the minibuffer > (assuming that isearch-from-minibuffer is t). That didn't work well, because when canceling a command called from the post-command hook one gets an ugly error message. > >> - Are the slightly backwards incompatible keybinding changes in >> `isearch-edit-string' acceptable? > > Only when isearch-from-minibuffer is t. I hope this is a guideline rather than an axiom, so let me describe what the *slight* incompatible changes are: 1. The user is forced to see lazy highlight and lazy count while editing the search string via M-e, as long as these options are already enabled globally. 2. A M-s prefix is added to minibuffer-local-isearch-map, as well as a few extra commands (M->, M-<, etc.) 3. and C-f are unbound. > >> - I don't like the `with-isearch-window-quitting-edit' macro, but I >> don't see a different way of achieving the necessary effect. > > The with-isearch-window-quitting-edit macro can be avoided the same way > as the with-isearch-window macro. I'm not sure this is possible. Is there a way to get rid of the minibuffer without returning control to the caller of `read-from-minibuffer'? I couldn't find a way to do this, hence the throw/catch of a continuation function in the current version of the patch.