From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andreas =?iso-8859-1?q?R=F6hler?= Newsgroups: gmane.emacs.devel Subject: Re: Transient Region Highlighting - an improvement over Transient Mark Mode. Date: Tue, 1 Apr 2008 19:08:46 +0200 Message-ID: <200804011908.48002.andreas.roehler@online.de> References: <20080401151931.GA6533@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1207069832 7752 80.91.229.12 (1 Apr 2008 17:10:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Apr 2008 17:10:32 +0000 (UTC) Cc: Alan Mackenzie , Stefan Monnier To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 01 19:10:55 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Jgk0a-0001km-VM for ged-emacs-devel@m.gmane.org; Tue, 01 Apr 2008 19:10:53 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jgjzy-0007pl-OK for ged-emacs-devel@m.gmane.org; Tue, 01 Apr 2008 13:10:14 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JgjxY-00062H-Qf for emacs-devel@gnu.org; Tue, 01 Apr 2008 13:07:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JgjxX-000614-PE for emacs-devel@gnu.org; Tue, 01 Apr 2008 13:07:44 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JgjxX-00060r-Gp for emacs-devel@gnu.org; Tue, 01 Apr 2008 13:07:43 -0400 Original-Received: from moutng.kundenserver.de ([212.227.126.188]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JgjxW-0002sO-TX for emacs-devel@gnu.org; Tue, 01 Apr 2008 13:07:43 -0400 Original-Received: from noname (p54BE890C.dip0.t-ipconnect.de [84.190.137.12]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis) id 0ML25U-1Jgjx30Ab2-0003gN; Tue, 01 Apr 2008 19:07:14 +0200 User-Agent: KMail/1.9.5 In-Reply-To: <20080401151931.GA6533@muc.de> Content-Disposition: inline X-Provags-ID: V01U2FsdGVkX1+TnJROw/n2aeMMJsjoh+HBUZYjd0iMoybvVk9 YMaB6BJhAgMZDm2QFTsnAeEYrhSwUrflD4f4j2WonaFxsrO0NP Hbb4/bpf/kt/b0RDax05A== X-detected-kernel: by monty-python.gnu.org: Linux 2.6? (barebone, rare!) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:94128 Archived-At: Am Dienstag, 1. April 2008 17:19 schrieb Alan Mackenzie: > Hi, Emacs! >=20 > I've criticised Transient Mark Mode somewhat in the last few days. I > therefore feel obliged to make a constructive suggestion as how to make > it better. Here is that suggestion: >=20 > Analysing T-M-M, it seems to consist of 3 vaguely related features: > (i) Disabling functions which operate on the region; > (ii) Highlighting the region; > (iii) Restricting the operation of some commands (e.g. M-x occur) to the > region when highlit, a sort of narrowing. Thanks being initiative in that matter, which is important IMO, even if my understanding differs somehow. Some weeks ago I suggested to take the XEmacs terminology, which I still think is more straightforward. (unless (featurep 'xemacs) (defun region-active-p () (and mark-active transient-mark-mode (not (eq (region-beginning) (region-end)))))) >=20 > Just as an aside, I think that terms like "active mark" and "activating > the region" are unhelpful, and have caused confused thinking over the > years. Neither the mark nor the region is an agent - they don't DO > anything,=20 Yes, but their state is important:=20 =2D if a mark exists at all =2D if it's at a different point from cursor =2D if the user will be aware of it The first and the second are meaningful for programms, the last for interactive mode. The second condition has no own terminus at the moment AFAIU, and probably don't need it.=20 The third (which includes the others) is expressed by=20 `region-active-p' in XEmacs, which IMO is more precise than `transient-mark-mode', which doesn't really reports the state. Because it might be t without any region... Andreas R=F6hler > anymore than a milepost on a country road between two villages,=20 > or the road itself, do. So I suggest we purge these terms from the code > and manual. >=20 >=20 > Feature (i) above, the one for which "Transient Mark Mode" is named, > doesn't seem to be useful, so let's just remove it - the mark, once set, > remains set, ditto for the region. The variable mark-even-if-inactive is > redundant, and can vanish (or be marked obsolete). >=20 >=20 > Feature (ii) seems to be what people really want. So let's rename the > entire feature "Region Highlighting Mode". The variable > `region-highlighting-mode' should take the values nil, t, and possibly > 'always, should there be anybody who wants the region always to be > highlit. >=20 > Region highlighting is switched on when the user types C-, (?C-u) > C-x C-x or M-@ or the like, or the "certain mouse commands". There > should be a command to switch it off (Keybinding C-u C-g, perhaps?). I > don't think a simple C-g should switch it off. Highlighting should also > be removed (via a before-change-function, possibly) when the buffer is > changed. I don't think it should be switched off on executing a random > command. For example, if you do M-: region-highlit, and see "t", the t > should remain meaningful. >=20 > "Momentary Transient Mark Mode" (there's tautology there ;-) should stay, > but be renamed to "Explicit Region Highlighting", to indicated that the > region gets highlit only when the user explicitly requests it via > C- C- or C-u C-x C-x. >=20 >=20 > Feature (iii) should be construed as "Wide area commands are restricted > to the region when it is highlit", and should be an option independent of > Region Highlighting Mode. How about calling it > `area-commands-on-highlit-region-flag'? To use this feature when Region > Highlighting is switched off, a user needs to set explicit region > highlighting first. >=20 >=20 > I think something like this design would be logically coherent, simple to > document, implement and use, would have the features that people want, > and be a vast improvement over the current Transient Mark Mode. >=20 > What do others think? >=20 > --=20 > Alan Mackenzie (Nuremberg, Germany). >=20 >=20 >=20