From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Daniel_Mart=C3=ADn?= 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:16:23 +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: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36880"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (darwin) Cc: Drew Adams , Eli Zaretskii , "acm@muc.de" , "kevin.legouguec@gmail.com" , "arstoffel@gmail.com" , "monnier@iro.umontreal.ca" , "emacs-devel@gnu.org" To: Daniel Mendler Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 13 18:18:12 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 1lhE2L-0009HY-GQ for ged-emacs-devel@m.gmane-mx.org; Thu, 13 May 2021 18:18:09 +0200 Original-Received: from localhost ([::1]:36696 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lhE2K-000264-6N for ged-emacs-devel@m.gmane-mx.org; Thu, 13 May 2021 12:18:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38142) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lhE0q-0008NH-Pu for emacs-devel@gnu.org; Thu, 13 May 2021 12:16:36 -0400 Original-Received: from sonic306-20.consmr.mail.ir2.yahoo.com ([77.238.176.206]:39483) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lhE0n-0004Kd-Sc for emacs-devel@gnu.org; Thu, 13 May 2021 12:16:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.es; s=s2048; t=1620922589; bh=m0pwbtbtykxhQm6XVyyOPUa1PO59ykze1F52p+77Ubw=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=RuzD1OOUAGJWmDsUNxzBXh2rA61zCMf5Ccgeg3N4SIy3YpKFP0LZaB5aD14dI5vIhEcmOrMS9HyTr6y2qqQ8aZa+NgnxxtIkH+JkbvHv6Uxfp3QGdesAOBPMr5iejWjG9psiukRzaJbT9hbkEmWq5guhVErWmwqIwdZ67vZgHw/M0fdz49suqfCXYgNeM5daETbGCWI/IARD+fgCo10IZffzUoKnSydCHM+McNxy2SWhfJX+fgGnyQpDvOFJ0pXVB5Bg0biDpydomIkGKZVKYwF72bMfszasYkGyel+/8WzgSDYQm5QAodvjNmAfb11iJE+HmCSDgV2pcPAWiKHZWA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1620922589; bh=XOfrpo950EpT9eayG2fMY2Ur0PgVHdDzBn8jcP9lPXo=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=iXGaWeI0DVnt4S5WCSI5EJAvf18i0LYZ+k1wSScEE6N/aSXv0So4zyugdsondK8afCgeaoicfXhGOSfkk32+eorYokO8cf0AeBI7Fyd2iSNjaWUd4xAFwtRml06Lv8XeHZN+KlJIRuBlVnRrq/CkRB3k0wPPhetq3UhQXVAs7g4vVzlISSeUmHoSLlwg4OdN60mcm9e7j7iVIJYBWyiraibc8G95neYagJbGh9rQaVUcn8V+3qOnech9VpEnqukeVwZJeaGAFWnR27lr3cNHrR9Io1IlE7jk1e3jgg0QkY4wpLt0Qkrz2+k/wz1sLtGwmWDYR7HVh2QqJMIQeSreZg== X-YMail-OSG: pj5wNwIVM1mGIaJW9zv1G8K.eR9f_EmQfLzUfzmCTg2FeUVqOd_jQyINTk_PSGw YZfeuRtXzDbrbqVkuZa8zYjCNd3fE7l2uvdIs_ovawNMXDahHzEn4ZTjIw6JsEfOD3VdDKxlqPpi cUoLDV2TzPQavIcmc6dv5vVa9JKMTyYCP_jDHvpFHmy4_qJfQAo7cWJ4tFM2fo1y.Gc3WnlRu9E. 54VHLIlUOwYpNEvpBEErMEH8GKKBQDlNzcQDFxifuRdi7wdGOZfrCAcuaDNbFaAbehTwZxpx1qbx kDjPRSVP4lDgFIZs6tgWqulNp9dxcBaEzGkrpIEyMU0KUu.kBnKWkqwl89WuNHWmiab4DxMtPBde i5o1XhqUiAVK9_MTV0EWyuCTnYmupz1oCrcpy.gzyv3s.TWBugV7zcA.p7onNOt539PMSbm8zb0N IzEyAp6N3C6KPfFq6NLEHTlcdNQ_kFmmQmq8m5bWFk8hZqJONV0JG.YHqU8n6i5EcgflN4v8LWqH lT.2MQMyUZKikCJ.yECfJen5gk6HSsU0Htihnxhh3BnDT1XlaPKKVgXr_ZgOIAlS_rQKXlgWPHsU wD4u5X9FcOLhhz6dKEFTMYE06_rc74SX59yLHiyvaexvAtwxg1w6eK612FAOTeqjjcK3BKdewEz7 6Axj4dr7XMjC1VuzkyWKniPjMjxBa2vpO5NHU.K45iBVvA34bc5Rx3o3IY7E_8J9hD44v0Rkavzo AKiSXXrMOVWMn2roImwBKmdzL6nOHtLtQrdwoHBI56vquL6665DAli0VUePJDPbGnKSY9jhY8.v6 1BZE9k3vAf2KIk.ocRW2E1jj.WwQHBoaIJsD0d48gT X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ir2.yahoo.com with HTTP; Thu, 13 May 2021 16:16:29 +0000 Original-Received: by kubenode512.mail-prod1.omega.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f29514324cd8a8e85c6bd132166196a0; Thu, 13 May 2021 16:16:24 +0000 (UTC) In-Reply-To: <61c85b87-98f2-1fa2-4e0a-aba40b080049@mendler.net> (Daniel Mendler's message of "Thu, 13 May 2021 16:41:10 +0200") X-Mailer: WebService/1.1.18291 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Apache-HttpAsyncClient/4.1.4 (Java/16) Received-SPF: pass client-ip=77.238.176.206; envelope-from=mardani29@yahoo.es; helo=sonic306-20.consmr.mail.ir2.yahoo.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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:269247 Archived-At: Daniel Mendler writes: > > The echo area/minibuffer distinction comes up from time to time in > discussions with new users. I know that I had been confused for a while > with the Isearch behavior. The Isearch use of the echo area is > unexpected. Users expect to enter a search string into a separate input > form as is common in many other programs. In Emacs this input form is > the minibuffer. 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. > > I would welcome the changes by Augusto. The minibuffer-controlled > Isearch makes entering the search string more robust with regards to > various editing commands as mentioned before by K=C3=A9vin Le Gouguec. > I wouldn't like them. If you want to edit the search string, you can just 'M-e' or click on the echo area. You can also type 'C-M-d' to delete individual characters, instead of using 'backspace'. > 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.). 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.