From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Tomas Nordin Newsgroups: gmane.emacs.help Subject: Re: killing the result of isearch Date: Thu, 09 Nov 2017 22:38:01 +0100 Message-ID: <87h8u32kw6.fsf@fliptop> References: <433bd3d0-a506-4d89-9d10-dcbfb0e23be0@default> <852BAA28-2A50-4AD9-B8D6-9F06905A4395@gmail.com> <87r2tava5x.fsf@hornfels.zedat.fu-berlin.de> <87y3nigy86.fsf@hornfels.zedat.fu-berlin.de> <87wp32f7os.fsf@hornfels.zedat.fu-berlin.de> <29AEE45F-D0CA-442F-8F46-E290C40782B4@gmail.com> <87k1z02yth.fsf@fliptop> <4EA90B44-DF92-43C3-B8D0-6C42D1D6F1DA@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1510263517 10284 195.159.176.226 (9 Nov 2017 21:38:37 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 9 Nov 2017 21:38:37 +0000 (UTC) To: Jean-Christophe Helary , Help Gnu Emacs mailing list Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Nov 09 22:38:31 2017 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eCuWr-0002LZ-0s for geh-help-gnu-emacs@m.gmane.org; Thu, 09 Nov 2017 22:38:29 +0100 Original-Received: from localhost ([::1]:38880 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eCuWy-000404-Az for geh-help-gnu-emacs@m.gmane.org; Thu, 09 Nov 2017 16:38:36 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54318) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eCuWY-0003zx-J7 for help-gnu-emacs@gnu.org; Thu, 09 Nov 2017 16:38:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eCuWV-0002ST-EK for help-gnu-emacs@gnu.org; Thu, 09 Nov 2017 16:38:10 -0500 Original-Received: from mout02.posteo.de ([185.67.36.66]:55774) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eCuWV-0002QJ-46 for help-gnu-emacs@gnu.org; Thu, 09 Nov 2017 16:38:07 -0500 Original-Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 6AB88209D3 for ; Thu, 9 Nov 2017 22:38:03 +0100 (CET) Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 3yXxNV0vZHzyxY; Thu, 9 Nov 2017 22:38:02 +0100 (CET) In-Reply-To: <4EA90B44-DF92-43C3-B8D0-6C42D1D6F1DA@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 185.67.36.66 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:114827 Archived-At: Jean-Christophe Helary writes: >> On Nov 9, 2017, at 7:24, Tomas Nordin wrote: >> >> Jean-Christophe Helary writes: >> >>> No, I am actually talking about expectations from using emacs where regions are highlighted, like what isearch seems like doing. What I am seeing is what looks like a region (and except for the active match, all the others are highlighted exactly as a region would be), but it doesn't act like a region. So there is a UI promise that's broken. >> >> Does this imply that in a read-only buffer, there must be no highlighting of the match for you not to say the UI is broken? > > Read my text again, and read your question one more time. You probably have the answer you need by now. > >> You cannot act on the text there. > > I can certainly M-w on any region I like. A region is a region, regardless of the buffer state, afaiu. Ok, in a couple of posts it looked like the lack of possibility to just delete the thing highlighted was the main distraction. I also got the impression it is the subject of the thread. > >> Or, in a read-only buffer, is it good that the match(es) are highlighted? Why? > > I may be thick, but it does look like you're trying to make me look like a fool, when it is you who do not seem to properly understand the issue I'm talking about. I don't want to upset anyone, and I didn't have that intention. My wording was maybe unnecessarily short. I was trying to suggest that a highlight might have other meanings than that it will be altered by next insertion or deletion. Anyway, I think I was reacting on the UI promise wording. I don't know there is such promise. There are expectations of course, based on peoples habits and prior experience. I agree that in most other applications, a highlighted region will get replaced by the next character you insert, or deleted if that is the action. When I started out with Emacs, I already knew that almost everything is different from what I was used to. So, for example, visit a file is not done by "ctrl-O" or a search is not started with "ctrl-f". Things like that. So many things are different so I never even reflected over that the region is not replaced just by hitting a character. About the incremental search thing. I agree that it *could* be useful maybe to add an in-search command like Type C-l to toggle isearch-lock-string. The current search string is frozen and next self-insert-command or DEL will operate in the current buffer. C-l again from this state will revert to normal isearch. In this mode you can hit C-s again to get at the next mach. But then again, I don't know it would save so many key-strokes. If I want to search and delete, I find it rather fast anyway to just hit C-s again two times to get to the next match. I was curious on the expectations based on other editors, so I tried this at work with notepad++. The first thing tried was a ctrl-f for the search. That brings up a dialog for the search and it was not possible to just delete the thing found. I checked a little and it turned out that pressing (after a search and dialog closed) would "select" next match (the first was already consumed by the dialog search) and move point to the end of it. And then, yes, possible to act directly on that selection, like delete for example. However, this required that one first do a regular search (ctrl-f), escape that dialog and then start to press . Its one of the many things that is different in Emacs to other editors but then I think that other editors differ to each-other as well, and each promise their own things. But I don't agree that Emacs is braking a UI promise. But for sure it will have a different method for doing things compared to some other editor. I think one exciting thing with Emacs has been the practice that you never have to use the mouse for anything (if you don't want to). I could guess that many commands are not even possible to do via the mouse. Then one could maybe claim that since Emacs often is used a a GUI, its braking a promise because the mouse cannot be used for this or that command. But then I wouldn't agree. As you say, editing in Emacs is done by the lisp interpreter, so almost any wish for a behavior can be satisfied by some snippets of code, often provided by the very kind and helpful Emacs help list. Or, if enough developers agree on a new feature it will even be added into stock Emacs. To that note by the way, I evaled the code snippets posted by Stefan and said `M-x delete-selection-mode`, and after that I got a behavior exactly as I understand you are looking for. Just don't forget to hit RET before acting on that region. That post also give some reasons for the current behavior. I am reading my mail in Emacs so that behavior slided smoothly into my Emacs just as if it would have been a feature available through an item in a menu. -- Tomas