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, 27 Sep 2018 00:45:59 +0200 Organization: my virtual residence Message-ID: <87d0szx4go.fsf@toy.adminart.net> References: <87k1nm7eit.fsf@toy.adminart.net> <878t403dn5.fsf@toy.adminart.net> <878t3yv0p0.fsf@toy.adminart.net> <87d0t9ckzl.fsf@toy.adminart.net> <87a7oa1toa.fsf@toy.adminart.net> <20180924202401.GB9502@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1538001895 20514 195.159.176.226 (26 Sep 2018 22:44:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 26 Sep 2018 22:44:55 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: "Charles A. Roelli" , cpitclaudel@gmail.com, lokedhs@gmail.com, rms@gnu.org, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 27 00:44:50 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 1g5IY5-0005At-5t for ged-emacs-devel@m.gmane.org; Thu, 27 Sep 2018 00:44:49 +0200 Original-Received: from localhost ([::1]:32777 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g5IaB-0006s2-RC for ged-emacs-devel@m.gmane.org; Wed, 26 Sep 2018 18:46:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37004) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g5IZz-0006qg-O2 for emacs-devel@gnu.org; Wed, 26 Sep 2018 18:46:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g5IZy-0008NV-Nc for emacs-devel@gnu.org; Wed, 26 Sep 2018 18:46:47 -0400 Original-Received: from mo6-p01-ob.smtp.rzone.de ([2a01:238:20a:202:5301::5]:18171) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1g5IZy-0008ML-H3; Wed, 26 Sep 2018 18:46:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1538002005; 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=YhOKpGkSIp6NASd/5DuTQPQ5utR13co2Mki6ofCXCxQ=; b=q0VD3Stcnusv36K6aKm+B/6zb4f89FuckiIpqfawp+zpFzeDc69hu/Ya9NLe5aLAVk V4zkvgArypEMjdgIhSfY5aGbuLcfGSwF1iltePcwBSXODMtUS/OiWrFvjezgYgthqqoT yMUNBBHbptb0r0zeFC1kI0xNWxJ5YsVkwf3/I8oUH7DHH+V/3WIznQOl69FtDof4SOo4 Bjb6IOHbkoOeu9BBIoqW5lK7BoLIt8ZkoJTpbCEBjQRB93/cu+lR1z/5tOvLnKux1noq T9QXthLqtvYWF4g6CCAs9VT1WQ/Qmy8JUuwX5VYPTnmF3I4d5rAGEBBjJPLBDZEOowdK rlXA== X-RZG-AUTH: ":O2kGeEG7b/pS1FS4THaxjVF9w0vVgfQ9xGcjwO5WMRo5c+h5ceMqQWZ3yrBp+AVdIIwXjneEe9k=" X-RZG-CLASS-ID: mo00 Original-Received: from himinbjorg.adminart.net by smtp.strato.de (RZmta 44.2 DYNA|AUTH) with ESMTPSA id C07935u8QMkY1c8 (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, 27 Sep 2018 00:46:34 +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 1g5IZm-0000bO-2g; Thu, 27 Sep 2018 00:46:34 +0200 In-Reply-To: <20180924202401.GB9502@ACM> (Alan Mackenzie's message of "Mon, 24 Sep 2018 20:24: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::5 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:230092 Archived-At: 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? >> I can see it for someone who doesn't like the highlighting, so if it was >> configurable --- and it is amazing that is isn't --- whether to >> highlight the region when it's active or not, everyone who dislikes the >> highlighting could have t-m-m enabled. I would remove having it >> disabled entirely from Emacs because there is no point in that and only >> complication. > > There is a great deal of point. Which is? > 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. Do you have an example of something that could not be accomplished with transient-mark-mode enabled and only with it disabled? > 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. > 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? 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? --- 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? Not that I, in theory, wouldn't appreciate a way to fortify the region when t-m-m is disabled, but since there is no point in disabling 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, 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. 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? 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)? > (iii) the "narrowing" of the buffer for certain > commands (such as M-%). Is narrowing the buffer sometimes disabled? How do you determine to which parts you want to narrow buffers to without selecting either the relevant parts or the irrelevant parts? >> 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.