Re: Shift selection using interactive spec

[Alan Mackenzie <acm@muc.de>]

Hi, Thomas!

On Sat, Mar 15, 2008 at 01:59:25PM -0700, Thomas Lord wrote:

[ .... ]

> The region between tenative-mark and point is called the
> tentative-region.

> save-excursion should save and restore the value of tentative-mark,
> setting it to nil when running its body.

Maybe.

> Low level functions (in C) that insert text into a buffer should
> unconditionally delete the tentative region first, if there is one, and
> set tentative-mark to nil.

No, I disagree.  Philosophically, this is a mixup of levels.  A low-level
function which is inserting text should NOT be messing around with
tentative regions.  This will surely cause pain, in some as yet unclear
way.  Surely higher level defuns should be built which call the C
primitives, allowing these primitives to remain primitive.

Also, can't we make Emacs a bit better?  A tentative region should be
_killed_, not deleted - i.e., there should be an easy way of recovering
it when it's accidentally de-regioned.

> Conceptually, this is a generalization of the notion of a "point".  A
> point is an index naming a theoretical "space between" two adjacent
> characters in a buffer, or the space at the beginning or end of buffer.
> A "tentative region" is like having a pseudo-point which indicates a
> conceptual "space between" in a hypothetical buffer that results from
> deleting the contents of the tentative region.

> That is the essential functionality that delete-selection-mode is
> aiming for but, by adding the concept of a tentative-mark, that
> essential functionality is simplified enough that it can reasonably be
> built-in as unconditional behavior of a few insertion commands.

That unconditionality would make the concept of a "tentative region" less
flexible and less useful, wouldn't it?  The user should be able to
customize when his tentative regions are killed by insertion commands;
for example, by major mode.

> There should be a a second and third variable:
> maybe-preserved-tentative-mark and preserved-tentative-mark.  These
> are, again, either nil or a mark.   These are used to control which
> commands preserve the tentative mark vs. which set it back to nil (the
> default behavior):

You've completely lost me, here.  I can't see how the first two sentences
connect with the last one.

I'm also getting lost in the sheer complexity of the proposal, and feel
that three "tentative-mark" variables is a bad idea - there will be too
much confusion between them.

> When a command returns to a command loop, the value of
> preserved-tentative-mark should be copied to tentative-mark,
> unconditionally.  Both maybe-preserved-... and preserved-... should be
> set to nil.    So, by default, commands implicitly "clear" the
> tentative mark.

Presumbaly, there would be customization commands to tailor this default.
For example, C-l is the sort of thing you'd want to do _without_ losing a
tentative region.

> Before a command loop invokes a command, it should first copy
> tenative-mark to maybe-preserved-...  That way, if a command wants to
> preserve the tentative mark if it is already present (the default
> interpretation of "shifted keysequences") then it can simply copy
> maybe-preserved-...  to preserved-tentative-mark.  When the command
> returns, that saved mark will be copied back to tentative-mark.

This sounds like the tail waggging the dog.  If a command wants to
preserve a tentative mark, it merely needs to do nothing.  Why should the
command loop be complicated for this purpose?

I really don't think we should be messing with the command loop for this
facility; that's a horrible kludge.  The mechanics of executing one
command after another should be kept separate from what these commands
do; conceptually, the "tentative region" mechanism has no connection with
the command loop, any more than scrolling, fontification or indentation
has.

[ .... ]

> So:

> three new variables
> one new display feature (clone of an existing feature)
> a couple unconditional variable copies in the command loop
> a few new functions
> unconditionally delete the transient region in some C code
> modify some core functions like yank and replace-string
> fix obscure commands that work similarly to yank or replace-string on-demand
> lots and lots of code that doesn't have to be modified at all
> a very simple "state machine" model of the behavior
> a behavior that highly agrees with "all those other GUIs"

and how about a name for this new editor?  ;-)

> For extra special featurefulness, you could build on that
> by adding a "transient region ring" -- a circular buffer that
> remembers the last N transient regions whenever some
> command nillifies the transient region at the top level.
> A "remembered" transient region is a pair of marks:
> the transient-mark and a marker at what was then the
> point.

Something like this is utterly required.

> N should probably be small but the idea is that recent
> transient regions are cached so that if the region is
> accidentally cleared by some command then a user
> can likely restore it, easily.

YES!!!

> So, in terms of "pronouns" again -- "addressing modes" for users -- the
> mark stack gives you a set of pronouns for recursing while the
> transient region ring gives you augmented short-term memory about "fat
> cursors".

> I'm really surprised, as I've been led to think about these features by
> the recent discussion, just exactly how complementary "GUI-style
> shift-select" and Emacs' user model and command interaction loop turn
> out to be.   They fit together like hand and glove, if only Emacs will
> actually implement it that way.

Hmm...  Do they really?  One good reason I've stayed with Emacs is that
it doesn't impose this (to me) ghastlily inefficient and nerve-wrackingly
fragile shift-select mechanism on me.  Please make sure that ALL the
features you're talking about are optional, even if they do become the
default.

> I'm one of those users who is both an Emacs power user *and* make
> pretty heavy use of GUI-style apps.   I constantly have the low-level
> frustration of how selection, cut, paste, etc. work differently between
> these environments:  often typing or mousing into some app as if it
> were Emacs or into Emacs as if it were some other app.   So, I feel
> pretty viscerally the pain that work on shift selection is trying to
> address.  

> I'm pretty convinced the little state machine model I've been
> developing here is a really good model for the desired functionality.
> So, I'm skeptical that all the hair of trying to use
> transient-mark-mode for this stuff is a good idea.

I rather think that these things are more flavour of the decade rather
than permanent; in ten or twenty years time, shift-select may well have
gone the way of autoexec.bat.  So lets not embed it too firmly inside
Emacs, below the level of individual commands.

> -t

-- 
Alan Mackenzie (Nuremberg, Germany).