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:12:27 +0200 Message-ID: <502924ee-aaeb-c35b-8f75-4fbbf009dfb4@mendler.net> 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="17905"; 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: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 13 18:15:01 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 1lhDzI-0004V4-Vq for ged-emacs-devel@m.gmane-mx.org; Thu, 13 May 2021 18:15:01 +0200 Original-Received: from localhost ([::1]:58394 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lhDzH-0005zf-Th for ged-emacs-devel@m.gmane-mx.org; Thu, 13 May 2021 12:14:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36796) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lhDwx-0002ow-N2 for emacs-devel@gnu.org; Thu, 13 May 2021 12:12:35 -0400 Original-Received: from server.qxqx.de ([2a01:4f8:121:346::180]:43675 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 1lhDwv-0001r1-1s; Thu, 13 May 2021 12:12:35 -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=ual+4GF33GEKwimmLNnEv24R1pV/iAMOE34ZRf8mv+4=; b=RZ3qZmHfnUrUCEljf90iqHJIOA 5hgSWQmCmiuq1mjEveFlP9b3ro0xfYVPjMAV07URze1O3Ur40ljBkH2kSRO2OmhDQ0JJAkmeNueAF 2Nsj5TSvvmbxM8TV0H4Y5AT3/A6HizOGnB1A30G973QPgc2kHVmq+6VplzRUYyRKvyQU=; 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:269246 Archived-At: On 5/13/21 5:24 PM, Alan Mackenzie wrote: >> 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". I deliberately took the perspective of a new user here and I am convinced that the current behavior is problematic. Incremental search is also present in other programs, where you enter something and "the buffer" updates accordingly. The only difference here is that the cursor stays in the buffer where the search happens. But the location of the actual cursor is not that relevant, it is a technical detail. There are also packages emulating and showing multiple cursors using overlays, e.g., multiple-cursor.el. > 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 think it is justified to lose this functionality in the minibuffer-controlled Isearch mode. I never use the Isearch to search or jump in the minibuffer. On the other hand I would like to edit the search string using the normal editing commands which are available in the `fundamental-mode`. >> 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. I am not familiar with the details of the Isearch implementation, but I don't see why it has to be a kludge in principle. If I would start a new search package, I would certainly use the minibuffer in combination with a `post-command-hook` (or an `after-change-function`) to update the buffer incrementally with the search results. It is not difficult to do that as one can see in the ctrlf.el package. Stefan Monnier also stated something along these lines: "I don't know what impacts it might have on the UI, but I've often wished (from an implementation point of view) that Isearch used an actual plain old minibuffer rather than mimicking one..." Therefore I think the characterization of a minibuffer-controlled search as a "kudge" is not balanced. One could as well criticize the Isearch since it does not use the minibuffer and deviates from the behavior of other Emacs commands. >> 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". I agree that 500 lines is long but the current version only adds ~160 lines. I am not sure at which point you consider this a clean patch. > 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 want to use the `fundamental-mode` to edit the search string with all its features. This cannot be achieved by adjusting something in the current Isearch implementation. The only way to achieve this is by using a separate buffer in a recursive editing session. There is already -edit-string` which gives a minibuffer. But then one loses all the incremental search functionality, which makes this uncomfortable to use. >From what I've seen, Augusto's patch mostly adjusts this command, which limits the impact of the patch. > 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. I did not try the current version of the patch but the last time I tried it, I quite liked the result. It didn't feel sluggish and felt natural as long as one accepts that one is typing in the minibuffer. Overall, I understand the resistance against the proposed changes. If one wants to stay in any case within the paradigm of using the echo area, there is no place for a minibuffer controlled Isearch. Nevertheless I found it quite astonishing that Augusto managed to create this relatively small patch (up to debate ;) which substitutes this central part of the Isearch interaction. Daniel