emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mouse.el patch for region tracking


From: JD Smith
Subject: Re: mouse.el patch for region tracking
Date: Mon, 02 Jan 2006 14:20:58 -0700

On Mon, 2006-01-02 at 10:38 +0100, Kim F. Storm wrote:
> Stefan Monnier <address@hidden> writes:
> 
> > There is another reason to wait for the next event: the selected region is
> > highlighted until the next event.  Now this is not necessary if
> > transient-mark-mode is activated, so your suggestion is that code that wants
> > to do something like XEmacs's mouse-track should do
> 
> In any case, JD's patch is good, but there should be some more
> commentary to explain the meaning of the HANDLE-TERMINATING-EVENT arg
> to mouse-drag-track.  Also, we may want to announce this function
> somewhere.

I've reworked the patch a bit, because I found that the mark was not
being set in my previous version.  Now I skip only the copy-region and
mouse-show-mark stuff, unless the optional argument is passed.  This
leaves the mark set (which of course is preferred for operating on the
region).  I also expanded the documentation to mouse-drag-track.

The one question remaining is whether it is appropriate to delete the
overlay (as I currently do) when transient-mark-mode is nil, and
terminating events aren't being processed.  This means the highlighted
region vanishes just after the drag completes.

I checked XEmacs mouse-track, and it works differently: with zmacs-
regions on, the overlay disappears only when a new region is started,
just like transient-mark-mode.  However, with it nil, the overlay still
remains until some other event (any event) arrives, yet somehow it's
able to allow the drag to complete anyway.  I.e., it doesn't block
operation on the region, as mouse-drag-region does.

I'm not sure how this is achieved, but I think it's the best behavior
(most consistent with regular mouse selection).  Unfortunately, the way
"regular mouse selection" seems to work in Emacs is by using that
blocking call to 'mouse-show-mark' to delete the overlay when the next
event arrives, which is the behavior this patch is attempting to
address.  

Unless someone can think of a clever way to implement this, I think I
can live with the overlay disappearing (or can just (let ((transient-
mark-mode t)) and delete it myself as appropriate).

Let me know if this looks acceptable and I'll check it in.

JD

Attachment: mouse_patch_jds2.diff
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]