From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: hw Newsgroups: gmane.emacs.devel Subject: Re: visual-region-mode? Date: Thu, 13 Sep 2018 06:00:32 +0200 Organization: my virtual residence Message-ID: <87pnxii2b7.fsf@toy.adminart.net> References: <83k1nxvm5j.fsf@gnu.org> <877ejxsm18.fsf@toy.adminart.net> <874lf0oul4.fsf@toy.adminart.net> <877ejuabdt.fsf_-_@toy.adminart.net> <878t473dhg.fsf@toy.adminart.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1536812143 5466 195.159.176.226 (13 Sep 2018 04:15:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 13 Sep 2018 04:15:43 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: cpitclaudel@gmail.com, lokedhs@gmail.com, rms@gnu.org, emacs-devel@gnu.org To: charles@aurox.ch (Charles A. Roelli) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 13 06:15:38 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 1g0J2Y-0001KS-68 for ged-emacs-devel@m.gmane.org; Thu, 13 Sep 2018 06:15:38 +0200 Original-Received: from localhost ([::1]:40264 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g0J4d-0005lT-Sq for ged-emacs-devel@m.gmane.org; Thu, 13 Sep 2018 00:17:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43027) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g0J4H-0005l9-Hr for emacs-devel@gnu.org; Thu, 13 Sep 2018 00:17:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g0J4F-0005TT-OK for emacs-devel@gnu.org; Thu, 13 Sep 2018 00:17:25 -0400 Original-Received: from mo6-p01-ob.smtp.rzone.de ([2a01:238:20a:202:5301::1]:17737) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1g0J4F-0005SA-6W; Thu, 13 Sep 2018 00:17:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1536812240; s=strato-dkim-0002; d=adminart.net; h=References:Message-ID:Date:In-Reply-To:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=jhkJu3dlXL7ykxoIs6nim93weYwhrmU26jotxUiA7rk=; b=oGmBRBiecsj3C+3HT+t3Lf3cFkf1hdSdFzYZIUf08sz0n2iKBgigtELbxX49RA7EvN xpJz/bumk//AMANlkuT+NempS4SnPfAz5jF2iDXA+mSSNnZCAoSf+iA80Nx3TTREJs8j X3czC89+xhFws1tDmktdwt1hTojC0rrQtgpG3hYeIUaSRP75ZJkfe7wKzVTu4btreeZh 2pz1PN5EM9OaEXXILZgqWwhgf55LC0COKl66AOUsHbDeMKGelj1FmRNERVrPIjOgRmhq 5UONnP0TuvR9Phv6IcY9rMQw72D6LU8himQDAKc/VgO3ik/TNo3u7yKZ/T2nq3YujjdL rDcQ== X-RZG-AUTH: ":O2kGeEG7b/pS1FS4THaxjVF9w0vVgfQ9xGcjwO5WMRo5c+h5ceMqQWZ3yrBp+AVdIIwXjneEe9k=" X-RZG-CLASS-ID: mo00 Original-Received: from himinbjorg.adminart.net by smtp.strato.de (RZmta 44.0 DYNA|AUTH) with ESMTPSA id e03b99u8D4HASZR (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Thu, 13 Sep 2018 06:17:10 +0200 (CEST) Original-Received: from toy.adminart.net ([192.168.3.55]) by himinbjorg.adminart.net with esmtp (Exim 4.90_1) (envelope-from ) id 1g0J42-0001hC-8G; Thu, 13 Sep 2018 06:17:10 +0200 In-Reply-To: (Charles A. Roelli's message of "Wed, 12 Sep 2018 21:47:07 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:238:20a:202:5301::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:229730 Archived-At: charles@aurox.ch (Charles A. Roelli) writes: >> From: hw >> Date: Tue, 11 Sep 2018 23:56:11 +0200 >> >> [...] >> >> As to the definition of the region: I've never seen it that way. The >> region is what is currently highlighted. I don't use and don't like >> hidden regions. They are a design flaw because when I press C-w, >> something of unknown extend is being deleted, and when press M-w, >> something of unknown extend is being copied and replaces what I kept on >> the clipboard. >>=20 >> These hidden regions always make me feel uneasy. It's like you're being >> forced to walk around with a loaded gun, safety off, once you only even >> touched the trigger without firing a shot because that sets a mark. The >> only way to get rid of this gun is to kill the buffer --- or is there >> another way? > > 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? 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. Disabling transient-mark-mode removes the possibility of highlighting regions. What is the purpose of that? >> > 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. >>=20 >> 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? > > 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. 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. > The mark is a standard Emacs marker, as described in (info > "(elisp) Markers"): > > A =E2=80=9Cmarker=E2=80=9D is a Lisp object used to specify a positio= n in a buffer > relative to the surrounding text. A marker changes its offset from t= he > beginning of the buffer automatically whenever text is inserted or > deleted, so that it stays with the two characters on either side of i= t. And there is no way to show the mark? >> >> What would the advantage of hidden regions be? When something is wit= hin >> >> 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". >>=20 >> 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. >> > The user might want it highlighted for various reasons, possibly not >> > covered by the current implementation, where Emacs highlights the >> > region only when 'mark-active' is non-nil. >>=20 >> Yes, and that leads to misunderstandings, like d-s-m. It doesn't make >> any sense to claim that there is a region when there is none highlighted >> and only creates the inconsistency that an arbitrary part of a buffer >> can be deleted or copied, accidentally or intentionally, i. e. that >> something can be done with a region while the region is not active and >> nothing should possibly be done with it. > > Again, that seems like the intention behind transient-mark-mode. But > the implementation is, then, in a way incomplete: C-w still kills the > region, no matter whether it is active or not, in transient-mark-mode. Yes, it is an inconsistency. >> >> Are these hidden regions a remnant of technical limitations that made= it >> >> advisable not to highlight the selection? >> > >> > No, they stem from convenience. For example, typing C-M-a in a source >>=20 >> That key binding only works when you can use Alt instead of ESC. > > Does ESC C-a not work for you? Or C-[ C-a? ESC C-a works. [ is on AltGr+8. 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. > [...] >> > Highlighting the region at any of these steps might be helpful for the >> > user, but Emacs can't know exactly when -- which is one argument for >> > allowing to toggle the highlighting dynamically as necessary, >> > independently of whether the mark is ever "active". >>=20 >> This is a problem of navigating source code (or other files) and has >> nothing to do with regions or highlighting. >>=20 >> Or what has navigating between a current location and the beginning of a >> function to do with selecting and highlighting parts of the contents of >> a buffer in order to copy or to delete them, or to do something with >> them like query-replace? > > The places where the mark has been set are places of interest to the > user for some reason or another -- that's all. The only purpose of the mark is to make a selection. 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. >> > As seen above, use of C-u C-SPC effectively restores the region at >> > some previous point in editing. >>=20 >> That I move around in a file as I see fit while reading or editing it >> doesn't have anything to do with regions I might select to do something >> with. I might highlight a selection to make parts of source code stick >> out as a reminder because they need to be fixed or worked upon in some >> particular order. I could use registers and/or bookmarks instead, but >> it would be much more convenient to use highlighting and perhaps to be >> able to jump through the selections. > > This would be a good use case for registers storing regions, I think. > The mark ring is a useful tool, but it does not give easy, random > access to all previous selections. We need a bug report for this. 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. >> The mark is only for setting the begin of a selection, nothing else. I >> expect it to be gone once I did something with the selection. >>=20 >> It doesn't even matter to me if there is a mark. All I do is start >> selecting somewhere and when it's selected, I do something with it, and >> that's all there is to it. >>=20 >> Don't mix up a mark for navigational purposes with making and >> highlighting selections. > > It's probably feasible to add a "type" field to the mark, indicating > where it came from (i.e., if it was set explicitly by the user, by a > certain command, from a mouse selection, ...). Then we could offer > commands that jump between previous selections, or between previous > marks set by the user for navigation. Why not let the mark be mark and find a way of making selections independently from it? Some people like to make shift-selections. They could be independent from the mark stuff and simply allow to make selections something can be done with. >> > Working on a specific region can often be done conveniently from an >> > indirect buffer, as in the earlier example. >>=20 >> It's quite inconvenient because with that, the source tends to occupy >> both frames I have on screen because I'd narrow the indirect buffer to >> what I'm working on --- which is already another inconvenience --- and >> need the other frame to look up things I can't see in the indirect >> buffer because it's narrowed. I've given up on it, it's just too >> awkward. >>=20 >> As for doing other things, like replacing text in multiple parts of a >> buffer, is that something that could be usefully done with indirect >> buffers? With multiple regions, I'd highlight some parts of the buffer, >> do the replacement limited to these parts and would be done with it. >> I'd be able to see all of the buffer while doing this. > > Not possible yet, I think (at least, without making N indirect buffers > for the N regions and running the replacement command in all of them). Yes, that's what I thought, I'd have to make many indirect buffers. > But if we had some way to record the "type" of a previous mark (as > above), then we could offer a command to replace, for example, the > last N "active regions" in the buffer. I think that might fit the > bill. That would overload the mark even more than it already is. >> Indirect buffers still hold all of the text, so instead of marking what >> I want to work with, I'd have to narrow out what I'm not working with, >> and IIRC, it's not possible to narrow a buffer "the other way round" so >> that the parts I want to work with remain and all the rest of the buffer >> is narrowed away. > > I don't think that's possible yet. Having multiple regions active would make this unnecessary :)