Re: transient-mark-mode in 22.0

[Richard Stallman <rms@gnu.org>]

    It *could* be that this is a bug introduced when mouse-show-mark was
    rearranged, and what was intended was really:

	(if transient-mark-mode
	    (delete-overlay mouse-drag-overlay)
	  (move-overlay mouse-drag-overlay (point) (mark t))

I recall making that change intentionally, and the change log entry
confirms it.

I did this to fix a bug.  I don't remember what bug, but It may have
had to do with the new features that temporarily enable
transient-mark-mode.

So I guess you're out of luck on this one.

Stefan wrote:

    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.

      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?

    - 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.

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.

							   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.