Re: transient-mark-mode in 22.0

[JD Smith]

On Thu, 2005-06-09 at 10:41 -0400, Richard Stallman wrote: 
> The change you've observed is probably due to a change in the code of
> mouse-drag-region.  I suggest you look at the code and see what's
> going on.

OK, I've had a look, and think I've figured it out.  Aside from the
superficial difference of having split mouse-drag-region into two
functions in 22.0, the real difference actually occurs in `mouse-show-
mark' which is called after all mouse movement events have been
processed, in the code handling the final up-event of the drag.

In 21.3, mouse-show-mark immediately returns if transient-mark-mode is
set:

(defun mouse-show-mark ()
  (if transient-mark-mode
      (delete-overlay mouse-drag-overlay)
    (let ((inhibit-quit t)
      ....

This allows mouse-drag-region to run to completion.  In 22.0, mouse-
show-mark does *not* return immediately:

(defun mouse-show-mark ()
  (let ((inhibit-quit t)
        (echo-keystrokes 0)
        event events key ignore
        (x-lost-selection-functions
         (when (boundp 'x-lost-selection-functions)
           (copy-sequence x-lost-selection-functions))))
    (add-hook 'x-lost-selection-functions
              (lambda (seltype)
                (when (eq seltype 'PRIMARY)
                  (setq ignore t)
                  (throw 'mouse-show-mark t))))
    (if transient-mark-mode
        (delete-overlay mouse-drag-overlay)
      (move-overlay mouse-drag-overlay (point) (mark t)))
    (catch 'mouse-show-mark
      ;; In this loop, execute scroll bar and switch-frame events.
      ;; Should we similarly handle `select-window' events?  --Stef
      ;; Also ignore down-events that are undefined.
      (while (progn (setq event (read-event))
        ....

Instead, it waits for that final read-event, apparently relating to
scrollbar/frame events.  So it essentially requires one last non-drag
event (arrow movement, anything), to permit mouse-drag-region to run to
completion.

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))
      (catch 'mouse-show-mark
        ;; In this loop, execute scroll bar and switch-frame events.
        ;; Should we similarly handle `select-window' events?  --Stef
        ;; Also ignore down-events that are undefined.
        ....

i.e. the loop is never entered and read-event is never called, if
transient-mark-mode is set.  This trivial fix gives me the behavior I
want, but since I don't know enough about these functions to understand
if this was intended behavior or not, I'd appreciate your feedback.

Here is the relevant change log comment:

revision 1.252
date: 2004/10/27 17:44:59;  author: rms;  state: Exp;  lines: +49 -48
(mouse-show-mark): Do most processing the same
regardless of transient-mark-mode.

>From the comment it does seem intended.  

JD