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: Wed, 03 Oct 2018 17:43:46 +0200 Organization: my virtual residence Message-ID: <87woqz2fyl.fsf@toy.adminart.net> References: <878t403dn5.fsf@toy.adminart.net> <878t3yv0p0.fsf@toy.adminart.net> <87d0t9ckzl.fsf@toy.adminart.net> <87a7oa1toa.fsf@toy.adminart.net> <20180924202401.GB9502@ACM> <87d0szx4go.fsf@toy.adminart.net> <20180927172601.GA4015@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1538581476 7344 195.159.176.226 (3 Oct 2018 15:44:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 3 Oct 2018 15:44:36 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: lokedhs@gmail.com, cpitclaudel@gmail.com, "Charles A. Roelli" , rms@gnu.org, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 03 17:44:32 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 1g7jKA-0001mQ-Td for ged-emacs-devel@m.gmane.org; Wed, 03 Oct 2018 17:44:31 +0200 Original-Received: from localhost ([::1]:49413 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g7jMH-0003ZW-Ak for ged-emacs-devel@m.gmane.org; Wed, 03 Oct 2018 11:46:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56920) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g7jLs-0003Rs-Uh for emacs-devel@gnu.org; Wed, 03 Oct 2018 11:46:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g7jLr-0007B5-9L for emacs-devel@gnu.org; Wed, 03 Oct 2018 11:46:16 -0400 Original-Received: from mo6-p01-ob.smtp.rzone.de ([2a01:238:20a:202:5301::7]:33518) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1g7jLq-00078Y-JL; Wed, 03 Oct 2018 11:46:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1538581571; 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=hm1np4VgFJSFdN5NkZAamiZuFqhdmgI4qJ8ZuXQkD1s=; b=Uy35Hiil9XI9y14yIeMS1wpIBfQCX80qhQf4IUntBKL3hqC3Tg5CHNQ+k9l6vmsB0u KF1QFhMJlgJni7qmiN5kkP6Vnr1FUL7xmwPDanmHV66g+jG7qdMsGBnmwyb3d3AK/HNt m+1DY9SfzJdL6F9SuLe0jWs0+fkZNaBkGuROczP00NQ3CT6MrOynIfHTq+gWV1K6pGof za6V9E66M7Jm8xR9fwXXay43M6hRql4ntF7zJeWCAd3z9lB2DyB/LRgJ2foD01Xz+97m zJhoUPmDlHk5lBO5fFaFmD0R1Wo9JwOqrz3Y7eLs6Wbck7NiYZcrUQL0VAOO6J0oIjtG 9LHQ== X-RZG-AUTH: ":O2kGeEG7b/pS1FS4THaxjVF9w0vVgfQ9xGcjwO5WMRo5c+h5ceMqQWZ3yrBp+AVdI4USjneHd9k=" X-RZG-CLASS-ID: mo00 Original-Received: from himinbjorg.adminart.net by smtp.strato.de (RZmta 44.2 DYNA|AUTH) with ESMTPSA id 907ec3u93Fk25BX (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); Wed, 3 Oct 2018 17:46:02 +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 1g7jLd-0001i6-So; Wed, 03 Oct 2018 17:46:01 +0200 In-Reply-To: <20180927172601.GA4015@ACM> (Alan Mackenzie's message of "Thu, 27 Sep 2018 17:26:01 +0000") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:238:20a:202:5301::7 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:230202 Archived-At: Alan Mackenzie writes: > Hello, hw. > > On Thu, Sep 27, 2018 at 00:45:59 +0200, hw wrote: >> Alan Mackenzie writes: > >> > Hello, hw. > >> > On Fri, Sep 21, 2018 at 22:28:53 +0200, hw wrote: >> >> charles@aurox.ch (Charles A. Roelli) writes: > >> >> >> From: hw >> >> >> Date: Wed, 19 Sep 2018 22:04:14 +0200 > >> >> >> With t-m-m disabled, there is no way to fortify the region, and there is >> >> >> no highlighting. Why would I disable it? > >> > [ .... ] > >> >> Disabling t-m-m doesn't make any sense at all. Why would anyone disable >> >> it? > >> > For the avoidance of the complexities that dealing with >> > transient-mark-mode involves. > >> Which complexities do you mean? > > The ones I've outlined in previous posts to you. You've shown no sign in > the past of having understood what I've said. So I'll say it one last > time. This time please pay attention. > > The complexity I'm referring to is having "modes" (like vi's insert and > command mode) in Emacs where a single command does different things > according to the mode. This happens with transient-mark-mode enabled, > the two modes being mark "active" and mark not "active". This complexity > is avoided by disabling transient-mark-mode. I must be blind? Where did you say this before? I'm saying all this complexity is avoided by removing the possibility of having transient-mark-mode disabled, and that there is no need for two different sets of commands when t-m-m is enabled. There is also only advantages of having t-m-m enabled and only disadvantages having it disabled, so why disable it? If you never disable it, you don't need to deal with the complexity, though it remains in the sources until removed. > [ .... ] > >> > Your last suggestion borders on the offensive, since it suggests that >> > any user whose needs and understanding are different from yours >> > should not be taken into account in plotting the future of Emacs. > >> It doesn't suggest that; it only suggests to remove functionality that >> is pointless and unnecessary and, along with it, a great deal of >> complexity and inconsistency which accompany it. > > You _are_ becoming offensive. Your personal preferences are NOT > objective goodness. You have your way of using Emacs, and you should not > try to force it onto me. Thankfully, the maintainers of Emacs are not > about to remove the choice. I didn't say that my preferences are good for everyone and am not trying to force them upon anyone. I'm merely suggesting that something unnecessary could be removed. >> Do you have an example of something that could not be accomplished with >> transient-mark-mode enabled and only with it disabled? > > No, of course not. Any editing result can be achieved with t-m-m either > enabled or disabled. If you really were interested in simplicity, you > would be advocating abolishing transient-mark-mode completely. Emacs is > simpler without it, and still a full-featured editor (as it was in the > decades before transient-mark-mode was written). It would make lots of > users unhappy, though. See above, you don't like the complexity, and you'd rather remove transient-mark-mode than you'd remove the possibility of disabling it. I don't find that offensive, though it seems to me that you have some hate for t-m-m for unknown reasons, and I still don't understand why you would disable and remove it and still don't see any advantages of having it disabled. Nobody has yet shown any advantages of having t-m-m disabled. > [...] >> > I also agree with you that these distinct features should be capable of >> > being en/disabled independently. These distinct features are (i) the >> > highlighting of the region; (ii) the disablement of commands which need >> > the mark to function; > >> Do you mean it should be possible to disable commands that want the >> region to be active to do something? > > No, I meant precisely what I wrote. I did not mention the region. The mark implies region, and why would you want to disable commands that need the mark to function? >> That would at least need clarification of the intention, i. e. was the >> intention to limit them to the region, to extend them to the region, or >> both? > > With transient-mark-mode disabled, you avoid this complexity. ;-) Not really: you would need to narrow or to widen the buffer depending on the intention, and that is way more complicated than making a selection and doing something with it. You could much better avoid this complexity by clarifying the intention of having a selection --- reasonably to the understanding that, for functions, it means to do their thing with the selection, regardless of whether it means to limit or to extend their doing to it. For this, it doesn't matter what t-m-m originally meant. There goes all the complexity out the window. >> --- Commands are already disabled when t-m-m is enabled and >> mark-even-if-inactive is nil, so why do there need to be more ways to >> disable them? > > Please read again what I wrote, and concentrate. see above >> Not that I, in theory, wouldn't appreciate a way to fortify the region >> .... > > To WHAT the region? "Fortify" is not Emacs terminology. Yet Emacs can already fortify the region. If you want to stick with Emacs terminology, how would you ever make any progress? >> .... when t-m-m is disabled, but since there is no point in disabling >> it, ... > > You are simply wrong on this point. I wish you would stop incessantly > repeating it. What would be the point of disabling t-m-m? I wish you could show one. >> .... I don't see a need for one (But you could disable the mark, see >> below.) > >> Instead of voting for more ways to disable commands, .... > > Nobody is advocating this. You want an independent way to disable commands that need the mark to function. Isn't that voting for more ways to disable commands? >> .... I might argue to remove the functions that imply "region" because >> implying to do stuff with a region is unnecessary when t-m-m is enabled >> because t-m-m means to do anything either with a region or not, >> depending on whether the region is active or not. > > You would be better not so to argue. Why not? Does having two sets of functions that do the same thing, once with the selection, once with random parts of the buffer unless you kinda make a selection by narrowing it, reduce complexity? Or does it have some advantages? >> What's the point and the advantage of duplicating all commands that can >> do stuff with the contents of a buffer only because a fundamental design >> flaw makes it so inefficient to determine whether commands should do >> their things with the whole buffer or with a part of it by requiring the >> user to narrow and to widen the buffer in order to make that >> determination? > > Would you please stop insinuating that a feature of Emacs which you > happen not to like is a "fundamental design flaw". It is insulting to > generations of Emacs developers, and is not true. Your thinking it is > based on your lack of a deeper understanding of Emacs' design, purpose > and history. Maybe you can explain to me how it is not a design flaw that navigating and making and having a selection --- or having random parts of a buffer always threatened by mistakes --- are inseparable from each other and how this design flaw is not a fundamental one while Emacs is built upon this. Imagine a hundred years ago a bridge was built from wood which now can not withstand the traffic it would need to carry because the wood simply can't handle the load. It was a design flaw to build it from wood rather than steel, and it's a fundamental design flaw because changing that would mean to build a new bridge. Now I call it a fundamental design flaw --- and you would expect the people who built and maintained the bridge to be insulted? They would probably laugh about it. If they don't, they should. It's still a fundamental design flaw that can not be changed, so what. Duplicating all commands for Emacs that can do something with contents of a buffer still doesn't seem advantageous. >> I don't understand why this wasn't simply overcome by setting the mark >> to nil. You could have *one* set of commands instead of several, and if >> you wanted them to do their things with the region, do not have the mark >> set to nil, and if you want them to work on the whole buffer, just set >> the mark to nil. You wouldn't need t-m-m then, would you (except for >> the highlighting)? > > Setting the mark to nil at any time would reduce its effectiveness for > navigation. There you see the design flaw. >> > (iii) the "narrowing" of the buffer for certain >> > commands (such as M-%). > >> Is narrowing the buffer sometimes disabled? > > No. Why do you need to independently disable it? >> How do you determine to which parts you want to narrow buffers to >> without selecting either the relevant parts or the irrelevant parts? > > C-x n n narrow-to-region (after setting mark and moving point); or > C-x n d narrow-to-defun; or > C-x n p narrow-to-page. > And when you're finishied, > C-x n w widen. That's either: + make a selection and then narrow to it, or + determine whether you are within something that would count as a defun, then determine if all the brackets (or whatever is used) are balanced, then narrow to it, using yet another key binding, or + Who is using pages?, or + do something with the narrowed buffer, then widen it, using yet another key binding This doesn't account for that the units you would narrow to would have to happen the part of the buffer you want to do something with, which is the most unlikely case. You also need to remember four different key bindings. Though it's a valid example, I wouldn't say it's something practical. Instead of all this, you can just make a selection and do something with it, all without any further ado, without having to remember lots of key bindings and without needing to determine first if any of them is currently applicable. You can't do that when t-m-m is disabled, and still you insist on having it disabled. Can't you see how t-m-m reduces complexity, which is what you wanted? And where is the point in disabling it? >> >> Without highlighting, a different indicator could be useful to show >> >> whether the region is active or not, like a hint in the mode line. > >> > Yes. I suggest this should be a single character, or at most two >> > characters. Space in the mode line is precious. Maybe "+" could fulfil >> > this role somewhere. > >> Right, though '+' would make me think that there is more to display >> while there isn't, like because there isn't enough room for it. >> Changing the colour of the mode line might work, too. > > I suppose so. Though I'd be more in favour of changing the colour of > just a small part of the mode line, to minimise the reduction in > readability. That could be optional.