Re: New Context Menu and mouse-1

[Juri Linkov]

>> -         (deactivate-mark)
>> -         (pop-mark)))))
>
> Note that this changes conceptually what `mouse-drag-track` does.
> Instead of only giving visual feedback during a drag, it actually does
> select the region (whereas in the current code, the region selection is
> actually performed by the binding of `drag-mouse-1` to `mouse-set-region`).
>
> So the above will lead to `mouse-set-region` being called when the
> region has already been set (at least in terminals that provide
> `mouse-movement` events).
>
> I'm not sure if it can introduce problems, but it would deserve
> a comment about the fact that the region selection is performed
> "redundantly" here and in `mouse-set-region` and why it's done this way.

With more testing I noticed that after pushing the mark twice
it requires more C-u C-SPC to get back to the original mark.
Maybe push-mark could be optimized to not push the mark
to the same position that is already at the top of the mark-ring.
Hmm, interesting that it intentionally let-binds history-delete-duplicates
to nil.

> From what I remember about the last time I worked in this code, it's
> a somewhat messy area.

Indeed, this code looks overcomplicated.  I tried to implement
extending the existing region with S-mouse-1 based on existing code,
but this is not a simple task due to code complexity.

> BTW, maybe another way to look at the problem is to say that
> invoking the context-menu should not exit the transient map (but this
> may come with its own set of problems, of course).
>
> Related to this, I wonder if `down-mouse-1` .. move .. `down-mouse-3`,
> `up-mouse-3` ... `up-mouse-1` would and/or should generate
> a `drag-mouse-1` event.

Actually, the existing event sequence without the final `drag-mouse-1`
is exactly what is needed, because `drag-mouse-1` is intended to finalize
the region selection, but there may be nothing to select at this time
after `up-mouse-3` invoked "Cut" or "Clear" from the context menu.