GNU bug report logs - #31240
mouse commands not aware of rectangle regions

Previous Next

Full log

View this message in rfc822 format

From: charles <at> aurox.ch (Charles A. Roelli)
To: Federico Tedin <federicotedin <at> gmail.com>
Cc: 31240 <at> debbugs.gnu.org
Subject: bug#31240: 26.1; mouse-save-then-kill does not kill rectangles
Date: Sat, 29 Sep 2018 12:07:58 +0200

> From: Federico Tedin <federicotedin <at> gmail.com>
> Date: Thu, 27 Sep 2018 20:45:42 -0300

> > For some reason, the region is not moved, and it gets re-activated as
> > a normal region instead of a rectangular region.  Maybe I'm missing
> > something obvious.  I was able to get the dragging of a rectangular
> > region working sometimes, but not consistently.
> 
> I've tried your test, and it does break my fix, as you mentioned.
> 
> The problem was in the criteria used to define the variable
> 'drag-but-negligible'. The drag action used in your test was being
> incorrectly marked as negligible. Because of this, the region was
> also re-activated, but not in Rectangle Mark mode (this was also a bug).
> 
> I have made a correction where the variable 'drag-but-negligible' is
> defined, so dragging a rectangle region outside of itself will no longer
> mark it as negligible; and when it _is_ negligible, the region is
> re-activated as a rectangle again.

Thanks, sounds good.
 
> I've also found some cases where the overlay list is not working well
> enough to track the selected rectangle. For example, if a buffer
> contains the following:
> 
> aaaa
> BBbb
> CCcc
> 
> Dragging a 2x2 square starting from the first 'B' (spaces added for
> clarity):
> 
>  a a a a
> [B B]b b
> [C C]c c
> 
> to the column where the second 'a' is, results in the following:
> 
> a B B a a a
> b b
> c c
> 
> In this case, two 'C's are missing in the second line (after the first
> 'b'). The reason this is happening is the following: when
> mouse-drag-and-drop-region is called, the initial overlays are the
> following (shown with braces):
> 
>  a a a a
> {B B}b b
> {C C}c c
> 
> After the 2x2 square is inserted on the second 'a', the first overlay
> is automatically expanded, because characters where inserted between
> its start/end:
> 
>  a B B a a a
> {b C C b}b b
> {c c}c c
> 
> When the original text is then deleted (by deleting all overlays), the
> result is:
> 
> a B B a a a
> b b
> c c
> 
> So I think I have two options now: either forbid the user from
> dragging a rectangle to a position where the inserted rectangle would
> intersect the original rectangle, or find another way to track the
> originally selected rectangle in a way it can be accurately deleted
> after inserting it in the new position. I guess I'll go with the
> second option, since it would make function more useful for users.

This second option sounds like it can be quite hard to define.  If you
decide in the end to prevent the user from dragging the region
somewhere that would intersect with the dragged region (which, as
Martin said, is in line with the original design of
mouse-drag-and-drop-region) that would be fine.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.