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-movement selection Date: Wed, 12 Mar 2008 19:00:45 -0700 Message-ID: <47D88ACD.5080700@emf.net> References: <871w6ounk0.fsf@kfs-lx.rd.rdm> <87ablacdxt.fsf@catnip.gol.com> <87skyzzeng.fsf@catnip.gol.com> <87fxuyobxt.fsf@kfs-lx.rd.rdm> <20080311224232.GB4420@muc.de> <87fxuwos3s.fsf@kfs-lx.rd.rdm> <47D81544.9050408@emf.net> <47D85273.6010500@emf.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1205371599 22516 80.91.229.12 (13 Mar 2008 01:26:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Mar 2008 01:26:39 +0000 (UTC) Cc: cyd@stupidchicken.com, emacs-devel@gnu.org, juri@jurta.org, monnier@iro.umontreal.ca, storm@cua.dk, acm@muc.de, miles@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 13 02:27:06 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 1JZcDk-0002Fs-Ds for ged-emacs-devel@m.gmane.org; Thu, 13 Mar 2008 02:27:00 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JZcDB-0002tD-FA for ged-emacs-devel@m.gmane.org; Wed, 12 Mar 2008 21:26:25 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JZc9U-0001aM-1S for emacs-devel@gnu.org; Wed, 12 Mar 2008 21:22:36 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JZc9S-0001Z4-01 for emacs-devel@gnu.org; Wed, 12 Mar 2008 21:22:35 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JZc9R-0001Yt-Fm for emacs-devel@gnu.org; Wed, 12 Mar 2008 21:22:33 -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 1JZc9J-0007Rr-Qp; Wed, 12 Mar 2008 21:22:26 -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 25271574; Wed, 12 Mar 2008 18:22:10 -0700 User-Agent: Thunderbird 1.5.0.5 (X11/20060808) In-Reply-To: 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:92347 Archived-At: Richard Stallman wrote: > Now I understand your proposal. I don't see how it would handle the > issue of making non-shift movement commands deactivate the mark, but > maybe it can be made to do that. > I have accidentally confused things by making, now, three proposals. Of the three, I particularly like the last. One proposal is coded almost like i-search as a sorta-kinda recursive edit. Non-shift movement commands de-activate that because deactivation is the default for all commands which either (a) do not explicitly set a flag otherwise or (b) are *not* invoked via a shifted keysequence whose binding is found by defaulting to the unshifted sequence. That works but the third one is simpler. Proposal #2 is similar to #1 but hairier, using minor mode foo to .... nevermind... the third one is simpler. Proposal #3 could be re-expressed as: Function: enter-shift-mark-mode Install the shift-mark-mode-post-command-hook and record the point as the tentative mark. Function: abandon-shift-mark-mode Toss the tentative mark and remove the post command hook Function: seal-the-deal-from-shift-mark-mode Turn the tentative mark into a normal mark. Function: shift-mark-mode-post-command-hook If the last command set the right flag, keep the tentative mark. Otherwise, if the last command was invoked by defaulting a shifted key-sequence to non-shifted, then again keep the tentative mark. Otherwise, abandon-shift-mark-mode. Function: unbound-shift-key-treat-as-enter-shift-mark-mode Remove the shift from the keysequence that invoked this command, enter-shift-mark-mode, and process the simplified keysequence. and various convenience functions related to that basis. Make the default binding of various shift keys be "unbound-shift-key-treat-as-...." I think #3 could be the best of the lot. > However, I tend to think that the use of the special character in > `interactive' to indicate these commands is a cleaner method overall. > > Works both ways, here. The underlying enter-shift-mark-mode could be bound all by itself to a key or, if some prefer, can be called via unbound-shift-key-treat-as-enter-shift-mark-mode. The key thing is getting the "semantics of the mark ring" right. The mistake we've all been making (and me with proposals #1 and #2) is to think that shift-mark state has to be in the command loop. Instead, it's a 1-bit flag for the top of the mark stack: the distinction between a normal and a "tentative" mark, where "tentative" marks only ever occur on the top of the mark stack. -t > >