emacs-pretest-bug
[Top][All Lists]
Advanced

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

Re: double-clicking on closing paren - wrong region marked


From: Stefan Monnier
Subject: Re: double-clicking on closing paren - wrong region marked
Date: Thu, 08 Mar 2007 12:55:28 -0500
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.95 (gnu/linux)

>> Enter the below text into a vanilla buffer. It consists of a  rather
>> long expression (3415 characters, I believe), which is all in one
>> line (rather than nicely formatted). Add a few extra lines to the
>> expression.
>> 
>> That is not a precise specification.  I tried this, and it worked
>> fine, but I have no way of telling whether this is because it doesn't
>> fail for me, or because it depends on how you "add a few extra lines".
>> 
>> "Enter the below text into a vanilla buffer" is not precise either.
>> 
>> Please send a _precise_ bug report.

> Well, I'll try again. Copy the expression at the end of this e-mail  into
> the clipboard.

> /Applications/Emacs.app/Contents/MacOS/Emacs -Q

> Press C-y RET RET RET.

> Move mouse pointer over last closing paren in the buffer. Double-click.

> The result is exactly as in the screenshot attached. What happens  after the
> double-click is that the whole visible buffer contents are  visually marked
> as region, then the buffer scrolls up one line, and  then the region is
> changed to what is shown in the screenshot  attached. Note that at the end,
> the mouse pointer is over the  "." (period) at which the region begins.

> Note that the text being copied into the buffer is on one long line;  if
> your e-mail client breaks the lines, it might not work.

> I afraid can't any more precise than this.

The problem is as follows:

1 - the first down-mouse-1 is processed correctly.
2 - the first (up) mouse-1 is also processed correctly.
3 - the second down-mouse-1 correctly highlights the parenthesized
    expression.
4 - somehow this highlighting causes scrolling.
5 - the subsequent (up) mouse-1 is then treated as a drag because the start
    and end point in the buffer are different.

The problem can be fixed at 2 places:
1 - at step 4, there shouldn't be any scrolling.
2 - at step 5, since the mouse hasn't moved, and since the time between the
    down-mouse-1 and the (up) mouse-1 is short, this shouldn't be considered
    as a drag.

The way drag are detected is pretty messy right now.  Part of it is because
it needs to handle the case where we do not keep track of mouse-movement, so
we have to decide drag-ness solely based on the relation between the down
and the up events (e.g. whether they're at the same screen spot or the same
buffer position).  But in case we do get mouse-movements, it may very well
happen than a drag starts and ends at the exact same screen position
(because the mouse-movements in between have caused scrolling).

I think both steps 4 and 5 should be fixed (although fixing only one of the
two is enough to fix the OP's problem).


        Stefan




reply via email to

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