From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?Vincent_Bela=EFche?= Newsgroups: gmane.emacs.devel Subject: Re: Transient Region Highlighting - an improvement over Transient Mark Mode. Date: Tue, 01 Apr 2008 19:16:54 +0200 Message-ID: <47F26E06.9040407@gmail.com> References: <20080401151931.GA6533@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1207075064 28779 80.91.229.12 (1 Apr 2008 18:37:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Apr 2008 18:37:44 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 01 20:38:14 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 1JglMj-0005Zz-Oe for ged-emacs-devel@m.gmane.org; Tue, 01 Apr 2008 20:37:50 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JglM7-0002DO-GK for ged-emacs-devel@m.gmane.org; Tue, 01 Apr 2008 14:37:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jgk66-0007a2-VI for emacs-devel@gnu.org; Tue, 01 Apr 2008 13:16:35 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jgk63-0007ZG-Vc for emacs-devel@gnu.org; Tue, 01 Apr 2008 13:16:34 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jgk63-0007ZA-T4 for emacs-devel@gnu.org; Tue, 01 Apr 2008 13:16:31 -0400 Original-Received: from nf-out-0910.google.com ([64.233.182.186]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jgk63-0004Z5-FX for emacs-devel@gnu.org; Tue, 01 Apr 2008 13:16:31 -0400 Original-Received: by nf-out-0910.google.com with SMTP id f5so986681nfh.26 for ; Tue, 01 Apr 2008 10:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=0MCKGqcfxAtvKNFAbzV54l7Z17lkkZ948U9tap973zs=; b=kZK+NmBciWeZf36hR6lIF2swGmMkrx/nAG1ZYCeODUAcAafv22SOAnfxQX9YsUX+wukT4eQDPUtj8gCcWbzH0zfq0KhyF8ZR4iOYn9A0ctiHkyx5YQbQZqJ9Om3BwQCo2SfXoYgVTs+/cG9FgLkCxkQakFFHvYYZ+A5DeFJzcIo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=iuJNZY8SHZW1LiAtdGG6BVz2eu7KmnPj0hFhwS/uMtlyix5ngtP6Fl7sfssf/XaAk2Th8fYPTsH0EVXHNi8iBoBDhzlxh9O6jZNQHaERpQIcow+Me4BrXlxs4b3oyrePkETPF52op4GCypTOeZv44EK9Tp/1RgU4AmFOgdmolKU= Original-Received: by 10.78.178.5 with SMTP id a5mr26915861huf.5.1207070184293; Tue, 01 Apr 2008 10:16:24 -0700 (PDT) Original-Received: from ?192.168.1.11? ( [90.32.1.137]) by mx.google.com with ESMTPS id u26sm328432mug.17.2008.04.01.10.16.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 01 Apr 2008 10:16:22 -0700 (PDT) User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) In-Reply-To: <20080401151931.GA6533@muc.de> X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) X-Mailman-Approved-At: Tue, 01 Apr 2008 14:35:00 -0400 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:94139 Archived-At: Dear all, Sorry to step into a discussion connected to a development I am not involved in. Just a few suggestions, hoping that that they can be useful : 1) There are already commands to narrow commands' scope to the region and to widen it to the whole buffer (C-x n n, C-x n w, etc... see *info* node Narrowing) , but they are not transient. I think that narrowing whether it is permanent or transient (one-shot) should be accessible independently from indicating it. So there should be 1.1) three narrowing states = permanent, one-shot, inactive 1.2) a number of command scope narrowing targets (e.g. region, page, paragraph, Lisp defun, C-function, sentence, whole buffer) one of which is used when the narrowing state is not inactive (ie is permanent or one-shot), and that may be accessible depending on buffer mode (e.g. Lisp defun has no meaning in text mode) 1.3) one default command scope to be used when the narrowing state is inactive (default command scope should be whole-buffer by default) 1.4) after each command operating on a narrowed portion of buffer, the narrowing state should transit as follows: +----------+ V ! +----------+ ! |permanent |----+ +----------+ +---------+ |one-shot | +---------+ ! ! ! +----------+ V V ! +--------+ ! |inactive|------+ +--------+ 2) Highlighting the region as such is not the relevant thing to the user. What the user is really interested in is to have an indication of what the narrowed portion is for commands, and what is the narrowing state (permanent, one-shot, or inactive). This indication may be done with reverse video like for TMM, or it may be done otherwise, notably by displaying only the narrowed portion as with command C-x n n. Note for instance that with this approach "C-x n n" would set: - the narrowing state to "permanent", - the narrowing target to region - and the method of indication to "displaying narrowed portion only" Method of indication should be configurable independently from narrowing command scope, and it should be configurable in a way that indication is dependent on the narrowing target (whole buffer, page, region, etc...) and on the narrowing state (permanent, one-shot, or inactive). The state is important because for instance reverse video could be a good idea for one-shot state, but it would be painful for permanent. This independence between the mode of operation itself, and indications to the user of what is the mode of operation is crucial for futureproofnew / flexibility w.r.t. different platforms. For instance some people may think in the future that this indication would be better by some letters in the Mode Line, or by some prompt in the Minibuffer. Best regards, Vincent. Alan Mackenzie a écrit : > Hi, Emacs! > > 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: > > 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. > > 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, anymore than a milepost on a country road between two villages, > or the road itself, do. So I suggest we purge these terms from the code > and manual. > > > 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). > > > 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. > > 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. > > "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. > > > 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. > > > 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. > > What do others think? > >