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: Wed, 12 May 2021 08:40:28 +0200 Message-ID: <87mtt0wj37.fsf@gmail.com> References: <87zgx5cz33.fsf@gmail.com> <87o8djohqf.fsf@mail.linkov.net> <87eeeenxqq.fsf@gmail.com> <87h7jath3m.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="30441"; 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 Wed May 12 08:43:50 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 1lgiaz-0007q1-PZ for ged-emacs-devel@m.gmane-mx.org; Wed, 12 May 2021 08:43:49 +0200 Original-Received: from localhost ([::1]:33020 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lgiay-0004mz-BY for ged-emacs-devel@m.gmane-mx.org; Wed, 12 May 2021 02:43:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45074) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lgiXt-0001ml-B4 for emacs-devel@gnu.org; Wed, 12 May 2021 02:40:37 -0400 Original-Received: from mail-ej1-x631.google.com ([2a00:1450:4864:20::631]:45804) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lgiXp-0004GD-Oc for emacs-devel@gnu.org; Wed, 12 May 2021 02:40:36 -0400 Original-Received: by mail-ej1-x631.google.com with SMTP id c22so5201281ejd.12 for ; Tue, 11 May 2021 23:40:31 -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=oqEX2prI0gIg+c3y0WaJxPH6XERgaJgllinMBCuVthw=; b=r0TiLGYUe5xbKJaAXGBXAMjauswmBjR5DS5JEyRyEhBTotyKhVbTRH0dTkmdegvvU8 x41Oqf7hscGtlgNkRr3bk0e7vWEmItAhGKYt1iZ3YsCmD/GysVKW0p2zmsUIkCB49Qz6 IgHlxRHC+Cfq5MX7KCMkRl0RWQkQLwiLoq809krYeda74sEMhGcjrVX+IVxxdsgplDAR S7lmzqRqGaw5qzsX8t7wxL8DZlY7MPTUIGJHCG5+5LbQSHjCt6Zi4YaqahMXueza5teU ZX1xQTDuBaNPk0fX7Q7bg8LdDp6Ymvfrx4dVNmPpuycjCDzueRVwUsPVvwuZO188l+Py O7Ew== 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=oqEX2prI0gIg+c3y0WaJxPH6XERgaJgllinMBCuVthw=; b=kBgHsqOCwqDSDHr55U4y+++Kr2VVUyfxyKZqpEQMMca+dJ26lDcWDScCgnZ4/w6bdm bttEYpIrZr3K21JE3y1JiNourQa5Zsa2fM7bEYO9iQEjGhgfCFqXCD+xwSKfE0hhU9// yKbL2AHzRlfEl+D1pCxdbSsMNtM6XsvqAIXkKCTkKxwJ2rEg98cnP1+WIvaX6ExrECOx 8UyRSHdeKVwllqGn+zhzZiM7kHyf7T9ZA0nzj4kXHbFSvt6PFX+JPOB7DNo2EmhWpX7V ESCoKZQQe2woWwTvOsftFHzEaDsaUo2QDUmM1p8ZIcc0C8+Wa+a+Xfomr6FkA5YdBqxH lN2Q== X-Gm-Message-State: AOAM533qc/mF72E+3UlUxs4F35LvbjMvtXOSMLfb39rrzMebYCvsJa1F NKDY09MBcecIEOOxoH5ARB32y9Z0vrJtEg== X-Google-Smtp-Source: ABdhPJx4LSgx4nRY0ypoYEUzQkdTZ8Zlzx5thwVDXWjJujTg13zLbowMcluuS9zdrcqEmefjUExySQ== X-Received: by 2002:a17:906:3bc6:: with SMTP id v6mr36530472ejf.165.1620801630376; Tue, 11 May 2021 23:40:30 -0700 (PDT) Original-Received: from ars3 ([2a02:908:2211:8540::68a]) by smtp.gmail.com with ESMTPSA id d5sm16684515edt.49.2021.05.11.23.40.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 May 2021 23:40:29 -0700 (PDT) Received-SPF: pass client-ip=2a00:1450:4864:20::631; envelope-from=arstoffel@gmail.com; helo=mail-ej1-x631.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:269191 Archived-At: On Tue, 11 May 2021 at 00:17, Juri Linkov wrote: >>> 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. > > How do yo cancel such a command? C-g > >> 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. > > Why not enable these incompatible changes only when > isearch-from-minibuffer is t? Without the improvements to the good old M-e, my patch would be totally independent of the rest of isearch.el, so it could just as well be an external package. That's OK too, but why would anyone keep lazy highlight/count on for normal Isearch, but wish to disable it after pressing M-e? To put it from another perspective: you said earlier that my patch could be boiled down to 10 lines. Well, adding lazy highlight/count to `isearch-edit-string' is certainly more work than that. But once this is in place, then yes, the minibuffer-controlled mode is a small addition. > >> 2. A M-s prefix is added to minibuffer-local-isearch-map, as well as a >> few extra commands (M->, M-<, etc.) > > The users might want to use M-< M-> to go to the beginning/end of the > minibuffer. This seems way less useful than going to the first/last match in the search buffer, since in the minibuffer C-a and C-e are usually sufficient. By the way, what's the idea behind `minibuffer-beginning-of-buffer'? It moves past the prompt, which is a useless point to go. > >> 3. and C-f are unbound. > > Removing and C-f is a very good thing, indeed. > >>> 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. > > Why not return control to the caller with `exit-minibuffer'? > When still necessary, you could try `exit-recursive-edit'. First of all, let me say that you suggestion to get rid of the `with-isearch-window' macro works fine. The remaining problem is with commands that create a minibuffer, and therefore require that we quit the `isearch-edit-string' minibuffer first. One example would be `isearch-query-replace'. So here's the the situation in more detail: - You are in an `isearch-edit-string' session - Then you press M-% - Now we are in the pre-command-hook. We check `this-command` and see that it will need the minibuffer. >From there, how can we get rid of the minibuffer and continue running this-command? Calling `exit-minibuffer' now would return control to whoever called `isearch-edit-string', so `this-command' would never run.