unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Federico Tedin <federicotedin@gmail.com>
To: rudalics@gmx.at
Cc: 31240@debbugs.gnu.org, homeros.misasa@gmail.com,
	tkk@misasa.okayama-u.ac.jp, charles@aurox.ch
Subject: bug#31240: 26.1; mouse-save-then-kill does not kill rectangles
Date: Fri, 12 Oct 2018 19:08:50 -0300	[thread overview]
Message-ID: <CAA8GjPkkiLV5i54WAJzz87NgP5_XGvK99A8nX0kx1zKU8NOmHg@mail.gmail.com> (raw)
In-Reply-To: <5BC05F09.40007@gmx.at>

> If I now drag it up by one line and four columns to the right (so that
> it just does not intersect with itself) I get
>
> ;;;;;;;;;;RECT;;;;;;;;;
> ;;;;;;RECT;;;;;;;;;
> ;;;;;;RECT;;;;;;;;;
> ;;;;;;RECT;;;;;;;;;
> ;;;;;;RECT;;;;;;;;;
> ;;;;;;;;;;;;;;;
> ;;;;;;;;;;;;;;;;;;;
>
> which is somehow counterintuitive.  Any ideas?

This is because after inserting the rectangle, the original rectangle
(which is to the left of the inserted one) is deleted. When it is
deleted, then the last 4 lines of the inserted rectangle are shifted
to the left:

1) Inserted new rectangle:

;;;;;;;;;;RECT;;;;;;;;;
;;;;;;RECTRECT;;;;;;;;;
;;;;;;RECTRECT;;;;;;;;;
;;;;;;RECTRECT;;;;;;;;;
;;;;;;RECTRECT;;;;;;;;;
;;;;;;RECT;;;;;;;;;
;;;;;;;;;;;;;;;;;;;

2) Deleted the original one:

;;;;;;;;;;RECT;;;;;;;;;  <--- this line isn't shifted
;;;;;;RECT;;;;;;;;;
;;;;;;RECT;;;;;;;;;
;;;;;;RECT;;;;;;;;;
;;;;;;RECT;;;;;;;;;
;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;

I've thought up two ways of dealing with this problem:

A) Forbid the user from dragging the rectangle to the right when the
new rectangle is *not* completly above or completly below the original
one. As an exception, allow the user to drag the rectangle purely to
the right (same line). In this option, the drag operation in your
example would not be permitted.  I think this option would be a bit
confusing for users (and too restrictive).

B) Add a variable mouse-drag-and-drop-rectangle-fill, initially set to
nil. When the variable's value is nil, the behaviour of dragging and
dropping rectangles is exactly the same as it is now. When it is set
to a non-nil value (for example, " "), then replace all characters of
the original rectangle with the variable's value. In this case, your
example would look like this:

1) M-: (setq mouse-drag-and-drop-rectangle-fill " ")

2) Inserted new rectangle:

;;;;;;;;;;RECT;;;;;;;;;
;;;;;;RECTRECT;;;;;;;;;
;;;;;;RECTRECT;;;;;;;;;
;;;;;;RECTRECT;;;;;;;;;
;;;;;;RECTRECT;;;;;;;;;
;;;;;;RECT;;;;;;;;;
;;;;;;;;;;;;;;;;;;;

3) Deleted the original one:

;;;;;;;;;;RECT;;;;;;;;;
;;;;;;    RECT;;;;;;;;;
;;;;;;    RECT;;;;;;;;;
;;;;;;    RECT;;;;;;;;;
;;;;;;    RECT;;;;;;;;;
;;;;;;    ;;;;;;;;;
;;;;;;;;;;;;;;;;;;;

I can't think of any other way of ensuring the inserted rectangle
retains its shape after being inserted, if there are pending delete
operations to its left.





  reply	other threads:[~2018-10-12 22:08 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
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 [this message]
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=CAA8GjPkkiLV5i54WAJzz87NgP5_XGvK99A8nX0kx1zKU8NOmHg@mail.gmail.com \
    --to=federicotedin@gmail.com \
    --cc=31240@debbugs.gnu.org \
    --cc=charles@aurox.ch \
    --cc=homeros.misasa@gmail.com \
    --cc=rudalics@gmx.at \
    --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).