Re: Shift selection using interactive spec

[Thomas Lord <lord@emf.net>]

Chong Yidong wrote:
>  I think it might not be necessary to change the default
> for transient mark mode if we do this.
>   

The problem with trying to force-fit transient mark mode for
this purpose is that it tries to equivocate the traditional Emacs
current mark with the beginning of a "shift-selected" region.

That's a problem because the current mark in Emacs doesn't
traditionally behave anything like the beginning of a "shift-selected"
region.  It's a force fit, at best.   The addition (by transient-mark-mode)
of an "activated/de-activated" flag is a crude *approximation*
of what users expect, in a situation where no approximating is
necessary.   For example, a "right arrow" key-press should simply
*forget*, more or less entirely, the marker at the start of the
highlighted region.    That's the default behavior if tentative mark
functionality is added but it's functionality that would require
yet more elisp code if transient-mark-mode were to catch up with
it.

What users expect, in the traditional GUI paradigm, is a kind of
mark that doesn't toggle between "activated" and "deactivated" but,
rather, is always active when present but which commands tend to
cause to go away entirely.   Let's dub that "the mistake".  The
mistake is adding an "active" flag instead of a separate tentative
mark.

It's *because* of the mistake that, for example, Stefan is now
positing the existence of a formal category of "motion commands"
that have to be modified to call a function that dynamically
asserts that they are motion commands.    That hair is not necessary
if you add the simple mechanism of a tentative mark instead of
trying to force fit the hairy mechanisms of transient mark mode.

The "fat cursor" concept (a region, rather than a simple point)
is what those other applications actually do.   It's what user's
expect.   It's what "tentative mark" implements.   It's perfectly
harmonious with traditional Emacs.   It simply *is* TRT.

Transient-mark-mode is *similar* to TRT for many command
sequences but hairier to implement,
hairier to extend, and doesn't correspond to any user expectation but
only to what seemed easy enough to do to its implementor.

T-m-m was a *mistake* and now you guys seem to want
to double down on that bad bet.

-t


>
>
>