From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel Subject: Re: Shift selection using interactive spec Date: Fri, 14 Mar 2008 04:36:48 -0700 Message-ID: <47DA6350.9040303@emf.net> References: <87k5k69p92.fsf@stupidchicken.com> <47D9CA73.40501@emf.net> <85wso66u7s.fsf@lola.goethe.zz> <47D9D366.4060000@emf.net> <858x0l7i50.fsf@lola.goethe.zz> <47DA5D4A.9050202@emf.net> <857ig560zh.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------070604060305010600050708" X-Trace: ger.gmane.org 1205492379 2585 80.91.229.12 (14 Mar 2008 10:59:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Mar 2008 10:59:39 +0000 (UTC) Cc: Chong Yidong , emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 14 12:00:07 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 1Ja7dp-0005mo-OT for ged-emacs-devel@m.gmane.org; Fri, 14 Mar 2008 12:00:02 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ja7dG-0002GB-Lj for ged-emacs-devel@m.gmane.org; Fri, 14 Mar 2008 06:59:26 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ja7cR-0001cR-RY for emacs-devel@gnu.org; Fri, 14 Mar 2008 06:58:36 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ja7cK-0001Rj-8Y for emacs-devel@gnu.org; Fri, 14 Mar 2008 06:58:28 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ja7cI-0001QF-Tk for emacs-devel@gnu.org; Fri, 14 Mar 2008 06:58:27 -0400 Original-Received: from mail.42inc.com ([205.149.0.25]) by monty-python.gnu.org with esmtps (SSL 3.0:RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1Ja7cD-0003lW-Ag; Fri, 14 Mar 2008 06:58:21 -0400 X-TFF-CGPSA-Version: 1.5 X-TFF-CGPSA-Filter-42inc: Scanned X-42-Virus-Scanned: by 42 Antivirus -- Found to be clean. Original-Received: from [69.236.65.4] (account lord@emf.net HELO [192.168.1.64]) by mail.42inc.com (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 25444508; Fri, 14 Mar 2008 03:58:06 -0700 User-Agent: Thunderbird 1.5.0.5 (X11/20060808) In-Reply-To: <857ig560zh.fsf@lola.goethe.zz> X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:92523 Archived-At: This is a multi-part message in MIME format. --------------070604060305010600050708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David Kastrup wrote: > >> Um. Ok, take a buffer of text. M-x transient-mark-mode. Set a mark. >> Move a bit with C-n. Now hit G-g. >> >> The region is now "deactivated," sure. But type C-xC-x: >> the mark you set is still there. A *tentative* mark would >> be completely wiped out by the C-g. >> > > That is basically just a matter of semantics. "Basically?" Yes, the semantics of the command set is the topic. I think you are trying to brush aside the real differences between two approaches by saying it's "*just* semantics" (emphasis added). But that's circular. The two approaches are *defined* in terms of their differing semantics. > The command "C-x C-x" can > be thought of as setting the mark at point, and moving point where a > mark had been last. > > And that means that the user's model of emacs is that emacs remembers that that mark existed. The user's model of Emacs' state is pretty tricky: there's "selected frame" and "current window" and "current minor modes" and etc. But the state model that user's have to (one way or another) have a mental map of -- at least the state model is orderly. Tentative marks modify the base-line state-model of emacs only a tiny bit. User's get a new "pronoun" (the tentative mark) to assign bindings to or to refer to. It's a very "context specific" pronoun in that it tends to become unbound by default. Transient marks modify the base-line state-model of emacs by a large amount. Commands that used to unconditionally work on "the region" now have to work on the region only if the "activated" flag is set. The user is not just temporarily naming some point -- as with a tentative mark -- but is instead having to keep track of a new, buffer-local boolean variable. So, tentative marks are cleaner. It's just icing on the cake that, aside from being cleaner from an Emacs perspective, they *also* happen to be a more perfect emulation of what those "other GUIs" do. -t >> I've described why about 3 times already. Tentative marks always go >> away unless the user uses a key-sequence that preserves them or the >> command the user invokes is a rare variety that explicitly preserves >> it. >> > > So the "advantage" of your "tentative mark" would be that "C-x C-x" now > beeps and does nothing. What does that buy the user? > > >> (I think if you look back at history you'll discover that >> transient-mark-mode was actually a mistake. It was >> in effect a crude attempt to hack around the lack of >> "tentative marks". People were confused but were happy >> that transient-mark-mode seemed to mostly highlight regions >> and mostly work like other GUIs, at least in simple cases). >> Tentative marks capture the familiar semantics much more >> precisely than transient ones. >> > > By making it impossible to recreate a mark where one had been last time? > What's the advantage in providing strictly less functionality? > > >> Having looked at it more closely now, I would even suggest that >> transient-mark-mode be deprecated (as in dis-recommended for use and >> of low priority for compatibility, going forward).) >> > > I don't get your point. You basically want to remove functionality and > sell this as an advantage under a different name. > > --------------070604060305010600050708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David Kastrup wrote: 

Um.  Ok, take a buffer of text.  M-x transient-mark-mode.  Set a mark.
Move a bit with C-n.  Now hit G-g.

The region is now "deactivated," sure.   But type C-xC-x:
the mark you set is still there.  A *tentative* mark would
be completely wiped out by the C-g.
    

That is basically just a matter of semantics.


"Basically?"   Yes, the semantics of the command set is the topic.

I think you are trying to brush aside the real differences between
two approaches by saying it's "*just* semantics" (emphasis added).
But that's circular.   The two approaches are *defined* in terms of
their differing semantics.



  The command "C-x C-x" can
be thought of as setting the mark at point, and moving point where a
mark had been last.

And that means that the user's model of emacs is that emacs remembers
that that mark existed.   The user's model of Emacs' state is pretty tricky:  there's
"selected frame" and "current window" and "current minor modes" and etc.
But the state model that user's have to (one way or another) have a mental
map of -- at least the state model is orderly.

Tentative marks modify the base-line state-model of emacs only a tiny bit.
User's get a new "pronoun" (the tentative mark) to assign bindings to or to
refer to.   It's a very "context specific" pronoun in that it tends to become
unbound by default.

Transient marks modify the base-line state-model of emacs by a large
amount.   Commands that used to unconditionally work on "the region"
now have to work on the region only if the "activated" flag is set.  The
user is not just temporarily naming some point -- as with a tentative mark --
but is instead having to keep track of a new, buffer-local boolean variable.

So, tentative marks are cleaner.   It's just icing on the cake that,
aside from being cleaner from an Emacs perspective, they *also* happen
to be a more perfect emulation of what those "other GUIs" do.

-t





  

    
I've described why about 3 times already.  Tentative marks always go
away unless the user uses a key-sequence that preserves them or the
command the user invokes is a rare variety that explicitly preserves
it.
    

  

  

So the "advantage" of your "tentative mark" would be that "C-x C-x" now
beeps and does nothing.  What does that buy the user?

  

  

    
(I think if you look back at history you'll discover that
transient-mark-mode was actually a mistake.  It was
in effect a crude attempt to hack around the lack of
"tentative marks".   People were confused but were happy
that transient-mark-mode seemed to mostly highlight regions
and mostly work like other GUIs, at least in simple cases).
Tentative marks capture the familiar semantics much more
precisely than transient ones.
    

  

  

By making it impossible to recreate a mark where one had been last time?
What's the advantage in providing strictly less functionality?

  

  

    
Having looked at it more closely now, I would even suggest that
transient-mark-mode be deprecated (as in dis-recommended for use and
of low priority for compatibility, going forward).)
    

  

  

I don't get your point.  You basically want to remove functionality and
sell this as an advantage under a different name.

  








--------------070604060305010600050708--