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 15:00:19 -0700 Message-ID: <47D85273.6010500@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> 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 1205356937 10649 80.91.229.12 (12 Mar 2008 21:22:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 12 Mar 2008 21:22:17 +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 Wed Mar 12 22:22:40 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 1JZYPG-0002u9-Gu for ged-emacs-devel@m.gmane.org; Wed, 12 Mar 2008 22:22:38 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JZYOh-0007TY-Rh for ged-emacs-devel@m.gmane.org; Wed, 12 Mar 2008 17:22:03 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JZYOc-0007SW-RK for emacs-devel@gnu.org; Wed, 12 Mar 2008 17:21:58 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JZYOa-0007Ri-V7 for emacs-devel@gnu.org; Wed, 12 Mar 2008 17:21:58 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JZYOa-0007Rc-QC for emacs-devel@gnu.org; Wed, 12 Mar 2008 17:21:56 -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 1JZYOU-00010B-07; Wed, 12 Mar 2008 17:21:50 -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 25253001; Wed, 12 Mar 2008 14:21:45 -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:92320 Archived-At: Richard Stallman wrote: > An idea: Shift-select has pretty close to the same > "semantics" as recursive edits, when viewed from > the point of view of an emacs interaction loop. > > I have to say they don't seem very similar to me > in their behavior. > > Maybe a better way to say it: "Shift-select" strikes me as a single command. There should be an interactive "shift-select" command. That command takes the sequence that invoked it and, if it is shifted, removes the shift modifier and looks up the binding, then runs that command. After the command completes, shift-select updates the "shift-selected region". The shift-select command then enters a loop, reading key-sequences against the current key-maps. If a key-sequence is read that maps to the shift-select command itself, then again, the shift is removed, the binding checked again, the new command recursively invoked, and the shift-select loop continues. Otherwise, normally, the shift-select loop exits. As an exception, functions can set a flag that will cause shift-select to keep looping (after clearing the flag). Finally, add a higher-order command generator: (shift-select-variant 'some-command) which returns a function that, when invoked, sets the flag that keeps select-mode going (or enters select mode) and then interactively invokes "some-command". Default bindings to shift-select itself do most of the work. Further customization can be done by binding sequences to either shift-select or to some (shift-select-variant 'X). No? A nice feature would be an "interactive" declaration (as someone mentioned) that, in this model, would set the shift-mode-continue flag. That way, commands could be easily written that would only continue shift mode if they are called interactively. I'm sorry if I'm misunderstanding the problem but would appreciate knowing *how* I'm misunderstanding it. -t