From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie 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 15:24:23 +0000 Message-ID: References: <83y2cj171z.fsf@gnu.org> <61c85b87-98f2-1fa2-4e0a-aba40b080049@mendler.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6505"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "emacs-devel@gnu.org" , "monnier@iro.umontreal.ca" , "kevin.legouguec@gmail.com" , Eli Zaretskii , "arstoffel@gmail.com" , Drew Adams To: Daniel Mendler Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 13 17:25:36 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 1lhDDT-0001Xe-Pr for ged-emacs-devel@m.gmane-mx.org; Thu, 13 May 2021 17:25:35 +0200 Original-Received: from localhost ([::1]:37408 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lhDDS-0002yS-Nb for ged-emacs-devel@m.gmane-mx.org; Thu, 13 May 2021 11:25:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51378) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lhDCO-0002FA-LP for emacs-devel@gnu.org; Thu, 13 May 2021 11:24:28 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:62181 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1lhDCM-0006Tt-6z for emacs-devel@gnu.org; Thu, 13 May 2021 11:24:28 -0400 Original-Received: (qmail 32299 invoked by uid 3782); 13 May 2021 15:24:23 -0000 Original-Received: from acm.muc.de (p4fe15ecf.dip0.t-ipconnect.de [79.225.94.207]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 13 May 2021 17:24:23 +0200 Original-Received: (qmail 11219 invoked by uid 1000); 13 May 2021 15:24:23 -0000 Content-Disposition: inline In-Reply-To: <61c85b87-98f2-1fa2-4e0a-aba40b080049@mendler.net> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de 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, 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:269245 Archived-At: Hello, Daniel. On Thu, May 13, 2021 at 16:41:10 +0200, Daniel Mendler wrote: > On 5/13/21 4:11 PM, Drew Adams wrote: > >>> As I've said, I, for one, think it's good that Isearch > >>> doesn't use the minibuffer. But I think it might help > >>> if there were a visual indication of some kind, to > >>> distinguish Isearching from use of the minibuffer, and > >>> Isearching from (other) use of the echo area. > >> There is such an indication: the cursor is not in the mini-window. > > Yes, there is indeed an "indication of some kind". > > ABut as the Subject says, this is about _better_ > > indicating such things - being _more_ helpful. > Personally, I would not like to use such a colorful "subtle" indication > in the echo area. To me this seems more like an implementation detail, > which should not be visible to the user. > 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. That's a rather misleading way of portraying it. Users used to other programs tend not to be familiar with incremental search, where point is not in "a separate input form" but in the buffer they're searching through. There is no "separate input form". Besides, currently isearch can be used in the mini-window, searching through a minibuffer. If we are not to lose this feature, things will get complicated and messy. > 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évin Le Gouguec. But it's a gross kludge. The principle behind the minibuffer is that the current edit is suspended, and the current window is switched to a minibuffer window, and (more or less) normal editing happens in that mini-window until the user terminates it. This clashes with the concept of incremental searching, where point stays in the target window at all times, guided by a sequence of commands, there being no recursive edit. > 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? See above. It would be anything but clean, given the clash between the way the minibuffer works and the way incremental search works. Augusto's original patch was ~500 lines long, which scarcely suggests "reasonably clean". You seem to be asking for an Emacs internal mechanism (the minnibuffer) to be used rather than for particular user visible effects to be seen. Why not concentrate on the latter, so that we can evaluate such suggestions and incorporate them into the current way isearch is implemented? I am worried that these suggestions for using the minibuffer will get implemented, and searching in Emacs will move from the delightfully lightweight feature we have at the moment to something awkward and sluggish, like most other programs' searching is. > Daniel -- Alan Mackenzie (Nuremberg, Germany).