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, 27 Sep 2018 17:26:01 +0000 Message-ID: <20180927172601.GA4015@ACM> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1538069422 4756 195.159.176.226 (27 Sep 2018 17:30:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 27 Sep 2018 17:30:22 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: "Charles A. Roelli" , cpitclaudel@gmail.com, lokedhs@gmail.com, 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 27 19:30:17 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 1g5a7E-00016Y-5d for ged-emacs-devel@m.gmane.org; Thu, 27 Sep 2018 19:30:16 +0200 Original-Received: from localhost ([::1]:38532 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g5a9K-0004eU-OE for ged-emacs-devel@m.gmane.org; Thu, 27 Sep 2018 13:32:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53726) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g5a8M-0004dE-5B for emacs-devel@gnu.org; Thu, 27 Sep 2018 13:31:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g5a8H-0005V4-4V for emacs-devel@gnu.org; Thu, 27 Sep 2018 13:31:24 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:23533 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1g5a8G-0005Tl-Aq for emacs-devel@gnu.org; Thu, 27 Sep 2018 13:31:20 -0400 Original-Received: (qmail 67204 invoked by uid 3782); 27 Sep 2018 17:31:18 -0000 Original-Received: from acm.muc.de (p5B147350.dip0.t-ipconnect.de [91.20.115.80]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 27 Sep 2018 19:31:16 +0200 Original-Received: (qmail 4636 invoked by uid 1000); 27 Sep 2018 17:26:01 -0000 Content-Disposition: inline In-Reply-To: <87d0szx4go.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:230094 Archived-At: 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. [ .... ] > > 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. > 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. > > I do agree with you that transient-mark-mode is a hodge-podge of vaguely > > related distinct features, mostly badly named, and that was why I argued > > against it becoming a default setting some years ago. > I didn't say that t-m-m is a hodge-podge. Sorry, those were my words, not yours. > > 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. > 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. ;-) > --- 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. > Not that I, in theory, wouldn't appreciate a way to fortify the region > .... To WHAT the region? "Fortify" is not Emacs terminology. > .... 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. > .... 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. > .... 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. > 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. > 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. > > (iii) the "narrowing" of the buffer for certain > > commands (such as M-%). > Is narrowing the buffer sometimes disabled? No. > 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. > >> 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. -- Alan Mackenzie (Nuremberg, Germany).