From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Tentative diagnosis of TMM's problem. [Re: Enabling TransientMark Mode by default] Date: Wed, 20 Feb 2008 14:16:14 -0800 Message-ID: <006e01c8740e$366ebbd0$c2b22382@us.oracle.com> References: <200802151711.m1FHB3Y3008798@sallyv1.ics.uci.edu><200802171658.m1HGwQ4h011067@sallyv1.ics.uci.edu><20080219085231.GA1032@muc.de><200802190938.m1J9ccVg016565@sallyv1.ics.uci.edu><20080219190127.GA1106@muc.de> <877ih0o9dx.fsf@catnip.gol.com> <20080220200142.GA1979@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1203552117 24789 80.91.229.12 (21 Feb 2008 00:01:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Feb 2008 00:01:57 +0000 (UTC) Cc: rms@gnu.org, 'Sascha Wilde' , lennart.borgman@gmail.com, emacs-devel@gnu.org, juri@jurta.org, dann@ics.uci.edu, storm@cua.dk, 'Miles Bader' To: "'Stefan Monnier'" , "'Alan Mackenzie'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 21 01:02:11 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 1JRysa-0001au-Ep for ged-emacs-devel@m.gmane.org; Thu, 21 Feb 2008 01:02:10 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JRyrc-000590-Ve for ged-emacs-devel@m.gmane.org; Wed, 20 Feb 2008 19:00:37 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JRxGP-0006KK-Bf for emacs-devel@gnu.org; Wed, 20 Feb 2008 17:18:05 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JRxGN-0006Je-NF for emacs-devel@gnu.org; Wed, 20 Feb 2008 17:18:05 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JRxGN-0006JZ-In for emacs-devel@gnu.org; Wed, 20 Feb 2008 17:18:03 -0500 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JRxGE-0002hg-6q; Wed, 20 Feb 2008 17:17:55 -0500 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m1KMHaT0007756; Wed, 20 Feb 2008 15:17:36 -0700 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m1KAWWl7016411; Wed, 20 Feb 2008 15:17:34 -0700 Original-Received: from inet-141-146-46-1.oracle.com by acsmt351.oracle.com with ESMTP id 3583647441203545787; Wed, 20 Feb 2008 14:16:27 -0800 Original-Received: from dradamslap1 (/130.35.178.194) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 20 Feb 2008 14:16:27 -0800 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ach0ArenJMvD7iMQRuuG96HwkGGatwABGh5Q In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 X-Mailman-Approved-At: Wed, 20 Feb 2008 18:54:49 -0500 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:89751 Archived-At: > The main issue is with the conflation of 2 concepts on > the set/push-mark commands: one is to push a buffer > location on a ring for navigational purposes, the other > is to set the boundary of the region. > > TMM is great for the second use, and is a drag for the first. Perhaps there is another way to look at this. Just throwing out an idea. I imagine that people from all directions will fire upon it, but what the heck: Do C-SPC to set the mark. Then click mouse-1 somewhere else. Point has moved away from the mark, but the region is not active, so no highlighting. In t-m mode, you can still use the region, if you have `mark-even-if-inactive' = t. I don't think anyone has complained about this use case. If, instead of clicking mouse-1, you use C-f (or C-M-f or...), then the region stays active. It is this highlighting that people find annoying, apparently. You cannot move point without the region being active (and thus highlighted), unless you use the mouse. Question: Is it important that the region stay active when you move point? If not, then perhaps (in t-m mode) we should always have point movement deactivate the region. The behavior would then be that you would use C-SPC to set mark and C-x C-x (or C-x C-x C-x C-x) to activate the region. The region would not be active otherwise. But with non-nil `mark-even-if-inactive', you could still use the region - you would get the same behavior as now, but without the annoying highlighting. The basic choices would then be: (a) t-m mode off, same behavior as now (the region is always active, and no highlighting), (b) t-m mode on, `mark-even-if-inactive' = nil: you must activate the region explicitly (C-x C-x), to use it, (c) t-m mode on, `mark-even-if-inactive' = t: same behavior as now, but no highlighting unless you activate the region explicitly. FWIW, I have `mark-even-if-inactive' = t, which means I can always use the region, but I can see when it is active (highlighting). Some contexts use the region only when it is active. Those are typically either contexts where it is helpful to see the region before acting on it or commands that can act either on the region or on the whole buffer. The behavior for such contexts should not change if we implemented this idea. Just an idea. Personally, I don't have a problem with the current t-m mode behavior.