Re: transient-mark-mode in 22.0

[Stefan Monnier <monnier@iro.umontreal.ca>]

>     To fix this problem, I maybe mouse-show-mark should be rewritten to
>     not use (read-event), but instead to use something like
>     pre-command-hook.

> I think that is too risky.  The reason this code has some bugs
> is that there is no obvious simple rule for what it should do.
> I could only patch it case by case, as various cases showed up
> that did not work.

> If you rewrite it to work differently, you'll have to start this
> process from scratch, which means it will be more unstable than
> it is now.

No, the current code and the change-log-trail make it pretty clear what the
function is meant to do:
1 - preserve the mouse-drag-overlay highlighting until the "next" command,
    where things like scrolls and switch-frames aren't considered
    real commands.
2 - implement the mouse-region-delete-keys functionality.

The problem is that the loop that does
read-event/key-binding/call-interactively basically can't be reliably
re-implemented in elisp.  That's why a solution using pre-command-hook would
probably be more reliable.

>       if the event is `switch-frame', we'll do a key lookup for
>       [vertical-scroll-bar switch-frame] which of course will fail.
> Does that lead to the wrong results?

It don't know of any bug it introduces but since it fails to call
handle-switch-frame at the proper time, I guess reading the code of
handle-switch-frame should make it reasonably easy to come up with
a scenario where it doesn't do the right thing.

>     - the overlay management has apparently been rendered completely
>     useless by the use of the temporary transient-mark-mode.  So all that
>     this code really does is implement the mouse-region-delete-keys.
>     This variable was introduced in 1996, but is not documented anywhere.

> We must have forgotten to document the feature.  However, the feature
> is not just this variable.  The feature is that typing DELETE deletes
> the selected region.

That's what I meant by the "mouse-region-delete-keys" feature, of course.

> It isn't documented, but I would expect that many people have simply
> tried it, expecting it to work, and found that it did, so they use it.

Could be.

> 							   Does anybody use
>       this?  (I expect that people who want such a functionality probably use
>       delete-selection-mode instead anyway).

> They might; but it isn't exactly the same, and it would not surprise
> me if many users use this feature and don't use delete-selection-mode.
> Perhaps they would be happy switching to delete-selection-mode, but it
> is not obvious.

> However, if the only function of that code is to implement this
> feature, it might easy to reimplement the feature in a simpler way.

Indeed.


        Stefan