|
From: | Thomas Lord |
Subject: | Re: Shift-movement selection |
Date: | Wed, 12 Mar 2008 10:39:16 -0700 |
User-agent: | Thunderbird 1.5.0.5 (X11/20060808) |
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 <address@hidden> 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. |
[Prev in Thread] | Current Thread | [Next in Thread] |