unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Federico Tedin <federicotedin@gmail.com>, tkk@misasa.okayama-u.ac.jp
Cc: 31240@debbugs.gnu.org, homeros.misasa@gmail.com, charles@aurox.ch
Subject: bug#31240: 26.1; mouse-save-then-kill does not kill rectangles
Date: Tue, 09 Oct 2018 09:43:33 +0200	[thread overview]
Message-ID: <5BBC5C25.8080002@gmx.at> (raw)
In-Reply-To: <CAA8GjP=k4_k=zpR=MCZD78gxne1qsgbkSSszip=W3j8mtLH-cQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2943 bytes --]

 > Martin, I didn't manage to understand the condition you are testing:
 >
 > (and (>= start point-to-paste)
 >       (<= point-to-paste (+ start (car size))))))))

Obviously so.  It should be

(and (<= start point-to-paste)
      (<= point-to-paste (+ start (car size))))))))

I attach a diff of this very chunk against the original trunk version
I have here.  Sorry for my sloppiness.

The idea is to not set drag-but-negligible when point-to-paste is (1)
on the first line of the original region and (2) before its start or
after its end.  To elaborate:

If point-to-paste is on the first line of the original region in
between its start and end, we would try to replace the text by itself
on this and all subsequent lines which is just as silly as replacing a
contiguous region with itself.  So set drag-but-negligible in such a
case.

If point-to-paste is not on the first line of the original region but
the region to insert intersects with the original region, then killing
the original region after inserting the copy might get me some pretty
unintelligible result.  So set drag-but-negligible in that case as
well.

But moving the rectangle strictly to the left or the right on the same
lines it originally occupied seems to work here.  So I would not set
drag-but-negligible in that case.

 > If the first condition is true, the second will also be true (if
 > point-to-paste is smaller than start, point-to-paste will also be
 > smaller than start plus a positive integer).

Indeed.

 >>From what I understand, these two explanations refer to the same
 > thing: it is better to have at all times the dragged region somewhere
 > in the buffer (even when undoing the drag operation). It would be best
 > to keep this behaviour in future versions of
 > mouse-drag-and-drop-region.

This looks like an invariant we could try to preserve.  But I only
tried to guess the rationale of the original design for moving a
contiguous region.

Note that I have never written or used rectangle code.  AFAICT
'insert-rectangle' inserts spaces (via 'move-to-column') when the
target line is too short.  And these insertions can make the result of
a rectangle move look bad when the deletion is done after the copying.
Is that interpretation correct?  Does it always look intelligible when
the deletion is done before the copying?

 > I'll check if I can come up with a better solution that best fits the
 > points that have been discussed above. If I can't, I'll check how
 > complex it would be to implement this special case at the end.

IIUC the code of rect.el nowhere provides an operation that kills a
rectangle and reinserts it in one and the same step not to mention the
possibility that these operations take place in an overlapping area of
one and the same buffer.  So I think that you are in uncharted waters
here and hardly anyone will tell you what to do.

If worse comes to worst, we can always leave your patch as it is now.

martin

[-- Attachment #2: mouse-drag-and-drop-region.diff --]
[-- Type: text/plain, Size: 1911 bytes --]

@@ -2500,12 +2520,24 @@ mouse-drag-and-drop-region
             ;; text will be inserted to inside of the original
             ;; region.
             (setq drag-but-negligible
-                  (and (eq (overlay-buffer mouse-drag-and-drop-overlay)
+                  (and (eq (overlay-buffer (car mouse-drag-and-drop-overlays))
                            buffer-to-paste)
-                       (<= (overlay-start mouse-drag-and-drop-overlay)
-                          point-to-paste)
-                       (<= point-to-paste
-                          (overlay-end mouse-drag-and-drop-overlay)))))
+                       (if region-noncontiguous
+                           ;; If the region is rectangular, check if the newly inserted
+                           ;; rectangular text would intersect the already selected
+                           ;; region. If it would, then set "drag-but-negligible" to t.
+                           (let ((size (cons region-width region-height)))
+                             (and (rectangle-intersect-p
+                                   (rectangle-position-as-coordinates start) size
+                                   (rectangle-position-as-coordinates point-to-paste) size)
+                                  (or (not (= (line-number-at-pos start)
+                                              (line-number-at-pos point-to-paste)))
+                                      (and (<= start point-to-paste)
+                                           (<= point-to-paste (+ start (car size)))))))
+                         (and (<= (overlay-start (car mouse-drag-and-drop-overlays))
+                                  point-to-paste)
+                              (<= point-to-paste
+                                  (overlay-end (car mouse-drag-and-drop-overlays))))))))
 
           ;; Show a tooltip.
           (if mouse-drag-and-drop-region-show-tooltip

  reply	other threads:[~2018-10-09  7:43 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-22 18:35 bug#31240: 26.1; mouse-save-then-kill does not kill rectangles Charles A. Roelli
2018-08-20  2:26 ` Federico Tedin
2018-08-30 20:06   ` Charles A. Roelli
2018-09-12  0:39   ` Federico Tedin
2018-09-12 18:14     ` Charles A. Roelli
2018-09-22 20:05       ` Federico Tedin
2018-09-23 10:16         ` Charles A. Roelli
2018-09-23 22:23           ` Federico Tedin
2018-09-24 20:04             ` Charles A. Roelli
2018-09-26  0:33               ` Federico Tedin
2018-09-27 20:34                 ` Charles A. Roelli
2018-09-27 23:45                   ` Federico Tedin
2018-09-28  7:47                     ` martin rudalics
2018-09-29 23:18                       ` Federico Tedin
2018-09-30  7:59                         ` martin rudalics
2018-09-30 15:45                         ` Charles A. Roelli
2018-09-30 16:20                           ` Federico Tedin
2018-09-30 17:18                             ` Eli Zaretskii
2018-09-30 17:50                             ` martin rudalics
2018-09-30 18:25                               ` Federico Tedin
2018-10-01  8:33                                 ` martin rudalics
2018-10-01 21:34                                   ` Federico Tedin
2018-10-02  7:39                                     ` martin rudalics
2018-10-02 12:37                                       ` Federico Tedin
2018-10-02 13:17                                         ` martin rudalics
2018-10-04  2:56                                           ` Homeros Misasa
2018-10-05  6:57                                             ` martin rudalics
2018-10-05  9:28                                               ` Tak Kunihiro
2018-10-05 12:15                                                 ` Federico Tedin
2018-10-06 17:08                                                   ` martin rudalics
2018-10-06 20:16                                                     ` Federico Tedin
2018-10-07  6:17                                                       ` martin rudalics
2018-10-08 10:25                                                         ` Tak Kunihiro
2018-10-08 23:18                                                           ` Federico Tedin
2018-10-09  7:43                                                             ` martin rudalics [this message]
2018-10-10  6:19                                                               ` martin rudalics
2018-10-12  0:42                                                                 ` Federico Tedin
2018-10-12  8:44                                                                   ` martin rudalics
2018-10-12 22:08                                                                     ` Federico Tedin
2018-10-13  8:18                                                                       ` martin rudalics
2018-10-13 14:01                                                                         ` Federico Tedin
2018-10-15  7:56                                                                           ` martin rudalics
2018-10-17  7:28                                                                             ` martin rudalics
2018-10-19  0:02                                                                               ` Federico Tedin
2018-10-19  7:40                                                                                 ` martin rudalics
2018-10-19 12:53                                                                                   ` Federico Tedin
2018-10-11  2:14                                                               ` Tak Kunihiro
2018-09-29 10:07                     ` Charles A. Roelli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5BBC5C25.8080002@gmx.at \
    --to=rudalics@gmx.at \
    --cc=31240@debbugs.gnu.org \
    --cc=charles@aurox.ch \
    --cc=federicotedin@gmail.com \
    --cc=homeros.misasa@gmail.com \
    --cc=tkk@misasa.okayama-u.ac.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).