Re: Shift selection using interactive spec

[Thomas Lord]

Chong Yidong wrote:
> After playing around with an implementation of this, I feel that it is
> very problematic.
>   


Have you looked at the other recent messages about
scrolling the selection outside of the visible region?

There's a related problem, too.   Not many GUIs
give you Emacs' ability to display the same "buffer"
in two windows *but* it is the case that the selections
in two windows are always independent of one another.

Yet in Emacs, because the buffer-local mark stack is
used instead of a window-local tentative mark, all
windows on the same buffer share one end point
of the selection in common.   I can't see any user benefit
to that restriction at all.   I think it is a symptom of
a design mistake in the first place.    (The mark stack
is a fine and powerful thing.   It just isn't suitable as
a tentative mark.)

That suggests a simple model where a window-local
tentative-mark, if not nil, makes the cursor fat.   In
turn, that leaves the question of how to arrange that most
commands turn it off by default yet commands can
treat it specially.  I don't know of any simpler way to
do that than with the two variables that relate to command
phases:  maybe-preserved-tentative-mark so that commands
know what tentative mark the user last saw.   preserved-tentative-mark
so that commands can assert what tentative mark the user should
next see.

The concept is probably useful in low-level elisp, too. 
Less need to write code like:

   (let ((start (point)))
     (forward-word)
     (delete-region start (point))
     (insert "bar"))

if there's an available short-hand, something like:

   (with-tentative-mark (point)
     (forward-word)
     (insert "bar"))

Programs can usefully "shift select" on their own,
behind the user's back, just as a handy way to express
the common pattern of having to operate on some region
that is being measured out on-the-fly.


-t