> 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
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
