From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Mendler Newsgroups: gmane.emacs.devel Subject: Re: [External] : Re: Indicate better the current use of the echo area / minibuffer [was: Controlling Isearch from minibuffer] Date: Thu, 13 May 2021 18:33:03 +0200 Message-ID: References: <83y2cj171z.fsf@gnu.org> <61c85b87-98f2-1fa2-4e0a-aba40b080049@mendler.net> 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="24193"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "emacs-devel@gnu.org" , "monnier@iro.umontreal.ca" , "kevin.legouguec@gmail.com" , "acm@muc.de" , Eli Zaretskii , "arstoffel@gmail.com" , Drew Adams To: =?UTF-8?Q?Daniel_Mart=c3=adn?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 13 18:54:30 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 1lhEbU-0006Ab-Rp for ged-emacs-devel@m.gmane-mx.org; Thu, 13 May 2021 18:54:28 +0200 Original-Received: from localhost ([::1]:46834 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lhEbT-0006DO-Sh for ged-emacs-devel@m.gmane-mx.org; Thu, 13 May 2021 12:54:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41210) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lhEGv-00008i-EF for emacs-devel@gnu.org; Thu, 13 May 2021 12:33:13 -0400 Original-Received: from server.qxqx.de ([2a01:4f8:121:346::180]:33461 helo=mail.qxqx.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lhEGr-0005Yf-1D; Thu, 13 May 2021 12:33:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=OkXYuQI0EHl58UE5K6xALg+zN6MJp3uCzympYl3mOYE=; b=yLkAWyTmtdHAngss9KMGga8jtR ck3WIuLs4NSw8Yp3Xl0pjw8557f4uWXhgk3Tz+/3XgYnvywmaBPD+Je0I60pWOJeJ/xdSaLtDJoOO 8dvngG7ZC2ZlWVuPncS+/Gp8Rr1uXkacPaVRXGM+mUNA4l3kRj5F0egaWe8pqvkzBZBg=; In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=2a01:4f8:121:346::180; envelope-from=daniel@mendler.net; helo=mail.qxqx.de X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-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:269250 Archived-At: On 5/13/21 6:16 PM, Daniel Martín wrote: > It's unexpected if you come from other applications, but I don't think > it's a bad UX. Once you get used to how Isearch works, in my opinion > it's much more efficient than using the minibuffer. For example, it's > very common to use incremental search to navigate to a particular place > in a buffer, and, once you are in the desired position, do something > like C-n, C-v, or C-p to move the point further and end the search at > the same time. This use case wouldn't be as convenient if incremental > search used the minibuffer. Try it in the CtrlF package, for example. Yes, of course. But this is where the preferences may differ. Some people prefer to navigate the search string, others may prefer to navigate the buffer and quit the transient Isearch keymap in that case. The patch by Augusto does not remove the current Isearch mode. The default would stay as is. >> There exists the ctrlf package on MELPA which also uses the minibuffer, >> but it feels hardly justified to install an extra package only to get a >> minibuffer-controlled search mode. I also don't want to replace such a >> tightly integrated component like Isearch with an external package. If a >> minibuffer mode can be added to Isearch with small effort and in a >> reasonably clean way, why not do that? > > That's the problem. Given the amount of subtle use cases currently > supported by Isearch, I think that even adding a separate option to use > the minibuffer would not be a simple implementation (for example, you > can perform an incremental search in the minibuffer itself, etc.). The incremental search in the minibuffer is a feature I use rarely. It is okay if this feature is not available if the minibuffer is used itself to control the search. This is not up to me to tell, it seemed the patch by Augusto providing the minibuffer-controlled search is "full featured", such that it works as one would except from Isearch, as long as one accepts that the minibuffer is used for controlling the search. What other subtle edge cases do you have in mind? > To be fair, I see some good things about using the minibuffer (for > example, it'd be simpler to perform certain actions, like scrolling the > window, without exiting the search), but all the things that we'll lose > or will change don't quite justify the new feature, IMHO. Nothing will be lost, except some simplicity. The current Isearch will stay as is. Only the command `isearch-edit-string` will be made more incremental with live updating results. From what I've seen the question is if the "loss in simplicity/purity" is justified since Isearch will get an additional interaction mode, which deviates from the currently existing interaction mode. Daniel Mendler