From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: visual-region-mode? Date: Thu, 13 Sep 2018 17:22:10 +0000 Message-ID: <20180913172210.GA4019@ACM> References: <874lf0oul4.fsf@toy.adminart.net> <877ejuabdt.fsf_-_@toy.adminart.net> <878t473dhg.fsf@toy.adminart.net> <87pnxii2b7.fsf@toy.adminart.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1536859405 4341 195.159.176.226 (13 Sep 2018 17:23:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 13 Sep 2018 17:23:25 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: lokedhs@gmail.com, cpitclaudel@gmail.com, "Charles A. Roelli" , rms@gnu.org, emacs-devel@gnu.org To: hw Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 13 19:23:20 2018 Return-path: Envelope-to: ged-emacs-devel@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 1g0VKq-00011Q-3o for ged-emacs-devel@m.gmane.org; Thu, 13 Sep 2018 19:23:20 +0200 Original-Received: from localhost ([::1]:43647 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g0VMw-0001pU-Em for ged-emacs-devel@m.gmane.org; Thu, 13 Sep 2018 13:25:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42600) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g0VMk-0001mC-7q for emacs-devel@gnu.org; Thu, 13 Sep 2018 13:25:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g0VMZ-000106-3m for emacs-devel@gnu.org; Thu, 13 Sep 2018 13:25:14 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:59900 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1g0VMV-0000tP-2b for emacs-devel@gnu.org; Thu, 13 Sep 2018 13:25:03 -0400 Original-Received: (qmail 51306 invoked by uid 3782); 13 Sep 2018 17:24:58 -0000 Original-Received: from acm.muc.de (p5B14757B.dip0.t-ipconnect.de [91.20.117.123]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 13 Sep 2018 19:24:57 +0200 Original-Received: (qmail 4881 invoked by uid 1000); 13 Sep 2018 17:22:10 -0000 Content-Disposition: inline In-Reply-To: <87pnxii2b7.fsf@toy.adminart.net> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:229743 Archived-At: Hello, hw. On Thu, Sep 13, 2018 at 06:00:32 +0200, hw wrote: > charles@aurox.ch (Charles A. Roelli) writes: > >> From: hw > >> Date: Tue, 11 Sep 2018 23:56:11 +0200 > >> [...] > > This is where Emacs differs from other programs, I suppose. It's > > optimized for efficient use, even when the result can be a surprise to > > the user. Otherwise, in this case, C-w and M-w would do nothing with > > no "active region". > What is efficient about hidden regions the way they are? They don't get in your way. A lot of the time, you won't be conceptualising the buffer portion between mark and point as "the region" - it's just point, and there's mark hanging around somewhere, possibly at somewhere significant. I think at some stage somebody tried having the region constantly highlighted, and it proved annoying, with the highlighting continually moving as you type stuff in, or even just move point. > If killing or copying a region didn't happen to be bound to keys that > are rather unlikely to get pressed by mistake, the design flaw of being > able to do something with a non-highlighted region while > transient-mark-mode is enabled might be more obvious. What seems like a design flaw to you is a feature to somebody else. That's why Emacs is so customisable. As Juri has already pointed out, there's an option you can set so that this "design flaw" won't affect you. I suggest you spending a couple of hours reading through the chapter "The Mark and the Region" (also known simply as "Mark") in the Emacs manual to see if there're any other options which would be useful to you at a non-default setting. > Disabling transient-mark-mode removes the possibility of highlighting > regions. What is the purpose of that? For users who find this highlighting unhelpful. As stated above, it was found in the distant past that constantly highlighting the region was counter-productive. If you disagree with that, then implement an option to have such highlighting. If you genuinely find it useful, then ask for your new option to be incorporated into the Emacs master. You might be surprised just how open the project leadership is to such innovations. > >> > C-SPC (without a prefix argument) always pushes a mark, so it always > >> > alters the region (unless point is already at the mark). C-u C-SPC > >> > sets point where the mark is, and pops the mark ring, effectively > >> > restoring the previous region. We should keep this behavior. > >> How am I supposed to know where a mark was? Why would I try to confuse > >> myself with C-u C-spc? In which way is the position of the mark > >> adjusted so that it sticks with the same contents of the buffer, which > >> it would need to do to be of any use? Mark does get adjusted so that it stays at the "same" position in the buffer, even if you insert or delete text before it. Try it! > > Various commands set the mark, as documented in the manual. When you > > use them, normally a message appears in the echo area saying "Mark > > set". > Yes, and they never told me anything because I don't use the mark for > navigation. An interesting question: why not? The mark is one of the concepts which distinguish Emacs from lesser editors, and with it you can do things like: (i) You search for something, and find it. You want to go back to your starting point. No problem in Emacs! C-u C-. (ii) You're editing something, and you want to read the massive comment that often appears near the beginning of source files. You do M-<, read that comment, then C-u C- to get back to where you were editing. Personally, I use the mark all the time for navigation, and would not want to go back to an editor without one. > When I want a region, i. e. a selection, I go where I want it and > select what I want. The mark is irrelevant with this kind of usage, > and so are these messages. You can ignore both of them, surely, for this kind of usage. [ .... ] > And there is no way to show the mark? Not really, no. Highlighting the region when transient-mark-mode is enabled is sort of a way, but that's not really what you meant. When I use the mark, my subconsciousness retains a map of where the mark is for an appreciable time. I don't need the mark to be visible. I don't think most users do, either. If you want the mark to be visible, implement it. Others might find it useful, too. > >> >> What would the advantage of hidden regions be? When something is within > >> >> a region, it should be highlighted, and when it is no longer > >> >> highlighted, it should no longer be within a region. > >> > Again, in Emacs, as long there is a mark in the current buffer, there > >> > is always a "region". > >> How would that make sense? I expect the mark to be gone once I used the > >> region. > > That's what transient-mark-mode tries to implement, I think. > It doesn't remove the mark after a highlighted region has been used. > The idea was apparently to limit functions to a selection by > highlighting a region and then calling it particularly "active". > Highlighting and calling a region "active" would not be necessary if > functions could otherwise be limited to the region. Combining these > three things and not allowing another way to limit functions to the > region make a mess. There is another way: narrow to the region (e.g. with C-x n n). Standard editing function are then restricted to this portion of the buffer. Useful here is, for example, C-x n d, which narrows to the current source-code function. [ .... ] > Emacs would have to have all key bindings re-defined to work well with > keyboards for different languages, leading to a definition for each > language. That's a bit of an exaggeration. [ .... ] > The only purpose of the mark is to make a selection. No. That's how _your_ use of it is currently restricted. I earnestly recommend you to spend time learning other uses of the mark. It will ease your editing. > After the selection has been used, editing moves on, and the location > has become irrelevant. Places of interest are those where navigational > aids are being placed, like bookmarks and registers. > If it was possible to make a selection without using the mark, I might > never use the mark. However, I might get used to using the mark for > navigation if it was like a default register that can be easily set and > moved back to. The way it currently is is merely dangerous because it > may influence hidden and highlighted regions without that being my > intention. Repeat: in an Emacs buffer there is exactly one region at any time. I can't suppress the feeling that sometime soon, something in your brain is going to click, you're going to shout "Eureka!", and suddenly the Emacs mark will be obvious and natural to you (as it is to so many users). [ .... ] > A feature request for the possibility of having multiple regions that > can be highlighted, first decoupling making selections from navigation, > might be an option. I'm not sure if further discussion before making > such a request is better because there might be pretty strong resistance > against this from everyone used to and using things the way they have > been for a long time --- and maybe we're missing something. There would indeed be resistance. Somehow, you've got to set up a multiple region. That will need key sequences (of which there are very few spare). Then you've got to modify lots of commands to work on a multiple region. Indeed you've got to decide what they will do. This is not a task for the faint-hearted. [ .... ] > Why not let the mark be mark and find a way of making selections > independently from it? Because that would lead to a general loss of convenience in the use of the mark. Still, if you have a solid idea of how this could work (and it would have to be optional), implement it and ask for it to be incorporated into Emacs. [ .... ] > That would overload the mark even more than it already is. I don't agree the mark is overloaded. Using it's several features together is one of the delights of Emacs. -- Alan Mackenzie (Nuremberg, Germany).