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 11:41:09 -0700 Message-ID: <47DAC6C5.3020207@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> <47DA6672.3080807@emf.net> <85myp14jrh.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------000204010409020305060806" X-Trace: ger.gmane.org 1205520175 10910 80.91.229.12 (14 Mar 2008 18:42:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Mar 2008 18:42:55 +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 19:43:22 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 1JaEs6-00007A-7C for ged-emacs-devel@m.gmane.org; Fri, 14 Mar 2008 19:43:14 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JaErW-0001jh-Qo for ged-emacs-devel@m.gmane.org; Fri, 14 Mar 2008 14:42:38 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JaErR-0001iG-Mg for emacs-devel@gnu.org; Fri, 14 Mar 2008 14:42:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JaErP-0001dR-3a for emacs-devel@gnu.org; Fri, 14 Mar 2008 14:42:33 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JaErO-0001dJ-Sx for emacs-devel@gnu.org; Fri, 14 Mar 2008 14:42:31 -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 1JaErJ-0001aD-Tb; Fri, 14 Mar 2008 14:42:26 -0400 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 25478033; Fri, 14 Mar 2008 11:02:27 -0700 User-Agent: Thunderbird 1.5.0.5 (X11/20060808) In-Reply-To: <85myp14jrh.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:92600 Archived-At: This is a multi-part message in MIME format. --------------000204010409020305060806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David Kastrup wrote: >> strictly less functionality? >> >> Tentative marks do *not* make it impossible to recreate a >> mark where one had been last time. >> > > So what's your complaint about C-x C-x? > In t-m-m? For the purpose of shift-select? It's that the marker being "reactivated" by C-x C-x shouldn't be on the mark stack at all. > >> They do imply that "recreatable" tentative marks are stored >> someplace else besides the mark stack. >> > > C-x C-x does not push onto the mark stack. > > Right. By the time it is run, the mistake is already made -- the marker in question has already been pushed. Here is an interaction script that shows what shift-marking should do: a) start with a big buffer of text (e.g. COPYING). b) Set a mark somewhere in the file using C-@ -- this is "the mark" c) Navigate away. No highlighting should happen. C-x C-x should swap the point and mark, as usual. d) While navigated away, put the point at the start of some word and type M-C-S-f. The entire word should now be selected between the point and a *transient* mark. e) Kill-region (C-w). The selected word is now gone. So is the *transient* mark. f) C-x C-x C-y -- the word you killed should now be inserted at "the mark" from step b For a user, that means you can set marks and reliably return to them using C-@ and C-x C-x or C-u C-@ but you can *also* just use all of your familiar "shift-select" gestures for simple edits -- the two concepts work side by side rather than one trying to emulate the other. >> Tentative marks are by definition not precious so >> I don't know that you'd want to put much effort into saving >> them but you could always keep, maybe the most recent >> one or two if you have commands that would want to restore them. >> > > What's the advantage to what is already there? Can you present a > sequence of operations or keypresses where your scheme would provide an > advantage? What advantage? > > The above (a..f) is one such example. The key thing is that tentative marks give you one level of additional selection without perturbing the traditional mark stack. Another way to look at it is to think about what shift-marking means in most GUIs. Most GUIs support shift-marking. If you start marking some region it's highlighted but then if you do anything that cancels that selection, the selection is simply gone and the application is back to its original state -- no trace of the former region. That's a good default. -t --------------000204010409020305060806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David Kastrup wrote:
 strictly less functionality?

Tentative marks do *not* make it impossible to recreate a
mark where one had been last time.
    

So what's your complaint about C-x C-x?

In t-m-m?  For the purpose of shift-select?   It's that the
marker being "reactivated" by C-x C-x shouldn't be on
the mark stack at all.



  
They do imply that "recreatable" tentative marks are stored
someplace else besides the mark stack.
    

C-x C-x does not push onto the mark stack.

Right.   By the time it is run, the mistake is already made -- the marker
in question has already been pushed.

Here is an interaction script that shows what shift-marking should
do:

      a) start with a big buffer of text (e.g. COPYING).
      b) Set a mark somewhere in the file using C-@  -- this is "the mark"
      c) Navigate away.   No highlighting should happen.  C-x C-x
          should swap the point and mark, as usual.
      d) While navigated away, put the point at the start of some word
           and type M-C-S-f.    The entire word should now be selected
           between the point and a *transient* mark.
       e) Kill-region (C-w).   The selected word is now gone.  So is
           the *transient* mark.
       f) C-x C-x C-y   -- the word you killed should now be
           inserted at "the mark" from step b


For a user, that means you can set marks and reliably return to
them using C-@ and C-x C-x or C-u C-@ but you can *also*
just use all of your familiar "shift-select" gestures for simple
edits -- the two concepts work side by side rather than one trying
to emulate the other.




  

    
Tentative marks are by definition not precious so
I don't know that you'd want to put much effort into saving
them but you could always keep, maybe the most recent
one or two if you have commands that would want to restore them.
    

  

  

What's the advantage to what is already there?  Can you present a
sequence of operations or keypresses where your scheme would provide an
advantage?  What advantage?

  





The above (a..f) is one such example.  The key thing is that tentative
marks

give you one level of additional selection without perturbing the
traditional

mark stack.



Another way to look at it is to think about what shift-marking means

in most GUIs.   Most GUIs support shift-marking.    If you start marking

some region it's highlighted but then if you do anything that cancels

that selection, the selection is simply gone and the application is
back to 

its original state -- no trace of the former region.     That's a good
default.









-t






--------------000204010409020305060806--