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 10:39:16 -0700 Message-ID: <47D81544.9050408@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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------020303030201000908090300" X-Trace: ger.gmane.org 1205341690 16036 80.91.229.12 (12 Mar 2008 17:08:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 12 Mar 2008 17:08:10 +0000 (UTC) Cc: rms@gnu.org, cyd@stupidchicken.com, emacs-devel@gnu.org, juri@jurta.org, monnier@iro.umontreal.ca, Alan Mackenzie , miles@gnu.org To: "Kim F. Storm" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 12 18:08:27 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 1JZUR6-0001QJ-H4 for ged-emacs-devel@m.gmane.org; Wed, 12 Mar 2008 18:08:16 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JZUQX-0005RQ-Tc for ged-emacs-devel@m.gmane.org; Wed, 12 Mar 2008 13:07:41 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JZUKX-0000Ql-8W for emacs-devel@gnu.org; Wed, 12 Mar 2008 13:01:29 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JZUKT-0000Q0-Qm for emacs-devel@gnu.org; Wed, 12 Mar 2008 13:01:28 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JZUKT-0000Pj-HG for emacs-devel@gnu.org; Wed, 12 Mar 2008 13:01:25 -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 1JZUKL-0002NL-8d; Wed, 12 Mar 2008 13:01:17 -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 25227346; Wed, 12 Mar 2008 10:00:46 -0700 User-Agent: Thunderbird 1.5.0.5 (X11/20060808) In-Reply-To: <87fxuwos3s.fsf@kfs-lx.rd.rdm> 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:92298 Archived-At: This is a multi-part message in MIME format. --------------020303030201000908090300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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. So, use a mechanism pretty close to recursive edits to implement shift-select. Two variations on the idea are given here. One that does in fact have a recursive command loop; a second that fakes having a recursive command loop using minor modes: In the default key-maps, bind all shifted keys to a single command we can call enter-implicit-select-mode That command essentially begins a recursive edit: enter-implicit-select-mode should first remember where the point is starting from, then recursively call the command that would have been invoked without the shift (this may require reading more keys from the user). enter-implicit-select-mode should then read key-sequences, mapping them the usual way in key maps, but examining the function to be invoked before invoking it. If the mapped function is, again, enter-implicit-select-mode then don't recurse but do look up the unshifted binding and call that interactively. If the mapped function is some other function, then directly call that function interactively, but immediately return from enter-implicit-select-mode's recursive edit afterwards (terminating "shift select"). Commands for cutting, copying, wiping, yanking etc. would still need to be handled specially and might benefit from some separate mechanism for telling enter-implicit-select-mode to not exit its loop, yet. In other words, a small number of commands can be modified to continue shift-selection even if they are not invoked by a shifted key-sequence. Some modes might already have shift-bindings that conflict with this. Oh well, those need individual attention anyway. Recursive edits, as described, might not be quite right. A similar effect could be achieved with minor-modes, I think. A "ghostly" minor mode could have no extended key-sequences and map *all* keys to a function saves up the list of keys pressed so far until they map to a binding in the underlying keymaps of the buffer (then call the right commands interactively, adjust whether shift-select is going on, possibly de-install the ghostly minor mode, etc.) Either way, one advantage might be that nothing is particular "shift specific". A user who prefered "hyper-select-mode" (or whatever) could have that and the same mechanisms would still work. Another advantage is that most commands would not need to change. Another advantage is that, while this approach does *slightly* change the way input key-sequences invoke commands, it's really a very slight change and mostly transparent to users. A practical advantage is that it would probably "mostly work" and almost never fail or surprise in horrible ways. It does (I *think*) 80% of the job "for free" and then makes it easy to go and patch up the remaining annoyances "by hand" as they come to attention. -t Kim F. Storm wrote: > Richard Stallman writes: > > >> Why not introduce an after-move-hook, somewhat akin to after-change-hook? >> >> If the idea is that Fgoto-char and other point-setting primitives >> would call this, that would be hard to implement safely and it slow >> down Lisp programs terribly. >> > > Maybe the idea is to simply call the hook if point after executing the command > is different from the value before the command. It may be useful, but > I'm not sure it will do the trick... for the shift-move function. > > --------------020303030201000908090300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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.
So, use a mechanism pretty close to recursive edits
to implement shift-select.   Two variations on the
idea are given here.   One that does in fact have a
recursive command loop;  a second that fakes having
a recursive command loop using minor modes:

In the default key-maps, bind all shifted keys to a single
command we can call enter-implicit-select-mode

That command essentially begins a recursive edit:

enter-implicit-select-mode should first remember where
the point is starting from, then recursively call the
command that would have been invoked without
the shift (this may require reading more keys from the
user).

enter-implicit-select-mode should then read
key-sequences, mapping them the usual way
in key maps, but examining the function to be
invoked before invoking it.   If the mapped
function is, again, enter-implicit-select-mode
then don't recurse but do look up the unshifted
binding and call that interactively.   If the
mapped function is some other function,
then directly call that function interactively,
but immediately return from enter-implicit-select-mode's
recursive edit afterwards (terminating "shift select").

Commands for cutting, copying, wiping, yanking
etc. would still need to be handled specially and
might benefit from some separate mechanism for
telling enter-implicit-select-mode to not exit its
loop, yet.    In other words, a small number of commands
can be modified to continue shift-selection even if they
are not invoked by a shifted key-sequence.

Some modes might already have shift-bindings that
conflict with this.    Oh well, those need individual
attention anyway.

Recursive edits, as described, might not be quite
right.   A similar effect could be achieved with
minor-modes, I think.   A "ghostly" minor mode
could have no extended key-sequences and map
*all* keys to a function saves up the list of keys
pressed so far until they map to a binding in the
underlying keymaps of the buffer (then call the
right commands interactively, adjust whether shift-select
is going on, possibly de-install the ghostly minor mode,
etc.)

Either way, one advantage might be that nothing
is particular "shift specific".   A user who prefered
"hyper-select-mode" (or whatever) could have that
and the same mechanisms would still work.

Another advantage is that most commands would
not need to change.   

Another advantage is that, while this approach does
*slightly* change the way input key-sequences
invoke commands, it's really a very slight change
and mostly transparent to users.

A practical advantage is that it would probably
"mostly work" and almost never fail or surprise
in horrible ways.    It does (I *think*) 80% of the
job "for free" and then makes it easy to go and
patch up the remaining annoyances "by hand" as
they come to attention.

-t


Kim F. Storm wrote: 
Richard Stallman <rms@gnu.org> writes:

  
    Why not introduce an after-move-hook, somewhat akin to after-change-hook?

If the idea is that Fgoto-char and other point-setting primitives
would call this, that would be hard to implement safely and it slow
down Lisp programs terribly.
    

Maybe the idea is to simply call the hook if point after executing the command
is different from the value before the command.  It may be useful, but
I'm not sure it will do the trick... for the shift-move function.

--------------020303030201000908090300--