GNU bug report logs -
#37700
27.0.50; undo mouse-drag-and-drop-region ineffective
Previous Next
Reported by: Mattias Engdegård <mattiase <at> acm.org>
Date: Fri, 11 Oct 2019 11:52:02 UTC
Severity: normal
Found in version 27.0.50
Done: Mattias Engdegård <mattiase <at> acm.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 37700 in the body.
You can then email your comments to 37700 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37700
; Package
emacs
.
(Fri, 11 Oct 2019 11:52:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Mattias Engdegård <mattiase <at> acm.org>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 11 Oct 2019 11:52:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Undoing mouse-drag-and-drop-region doesn't work:
1. (setq mouse-drag-and-drop-region t)
2. mark a region
3. use the mouse to drag the region elsewhere
4. Undo (twice)
Result: the dragged text disappears from its destination, but does not reappear where it was dragged from.
Instead, we get the "No further undo information for region" error.
The action can be undone by moving point and backing up a different undo branch a few steps, but that is hardly ideal.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37700
; Package
emacs
.
(Fri, 11 Oct 2019 12:20:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 37700 <at> debbugs.gnu.org (full text, mbox):
> Undoing mouse-drag-and-drop-region doesn't work:
>
> 1. (setq mouse-drag-and-drop-region t)
> 2. mark a region
> 3. use the mouse to drag the region elsewhere
> 4. Undo (twice)
>
> Result: the dragged text disappears from its destination, but does not reappear where it was dragged from.
> Instead, we get the "No further undo information for region" error.
>
> The action can be undone by moving point and backing up a different undo branch a few steps, but that is hardly ideal.
I suppose this the effect of undo working on the active region only.
A very nasty invention. Try deactivating the region right after 3.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37700
; Package
emacs
.
(Fri, 11 Oct 2019 12:27:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 37700 <at> debbugs.gnu.org (full text, mbox):
> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Fri, 11 Oct 2019 13:51:38 +0200
>
> Undoing mouse-drag-and-drop-region doesn't work:
>
> 1. (setq mouse-drag-and-drop-region t)
> 2. mark a region
> 3. use the mouse to drag the region elsewhere
> 4. Undo (twice)
>
> Result: the dragged text disappears from its destination, but does not reappear where it was dragged from.
> Instead, we get the "No further undo information for region" error.
Why is that a problem? Emacs cannot possibly "un-dnd" text, it can
only remove the copy, which AFAIU it does.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37700
; Package
emacs
.
(Fri, 11 Oct 2019 12:52:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 37700 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
11 okt. 2019 kl. 14.19 skrev martin rudalics <rudalics <at> gmx.at>:
>
> I suppose this the effect of undo working on the active region only.
> A very nasty invention. Try deactivating the region right after 3.
Right, thank you. I wonder if anything would break if that were changed.
Proof-of-concept patch attached. (Manual and NEWS changes not included.) It does solve this particular problem.
Do you know of any drawbacks for someone whose editing habits are not dependent on the region confinement of undo?
[0001-Make-undo-confinement-to-active-region-user-settable.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37700
; Package
emacs
.
(Fri, 11 Oct 2019 12:54:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 37700 <at> debbugs.gnu.org (full text, mbox):
11 okt. 2019 kl. 14.26 skrev Eli Zaretskii <eliz <at> gnu.org>:
>
> Why is that a problem? Emacs cannot possibly "un-dnd" text, it can
> only remove the copy, which AFAIU it does.
It does not undo the deletion of the text at its original position, which is what I believe a user would have expected (at least this user).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37700
; Package
emacs
.
(Fri, 11 Oct 2019 14:45:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 37700 <at> debbugs.gnu.org (full text, mbox):
> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Fri, 11 Oct 2019 14:51:01 +0200
> Cc: 37700 <at> debbugs.gnu.org
>
> 11 okt. 2019 kl. 14.19 skrev martin rudalics <rudalics <at> gmx.at>:
> >
> > I suppose this the effect of undo working on the active region only.
> > A very nasty invention. Try deactivating the region right after 3.
>
> Right, thank you. I wonder if anything would break if that were changed.
>
> Proof-of-concept patch attached. (Manual and NEWS changes not included.) It does solve this particular problem.
Given that the region can be easily deactivated, I'm not sure I see
the sense in introducing options that selectively disable
region-sensitive behavior of specific commands.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37700
; Package
emacs
.
(Fri, 11 Oct 2019 17:19:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 37700 <at> debbugs.gnu.org (full text, mbox):
11 okt. 2019 kl. 16.43 skrev Eli Zaretskii <eliz <at> gnu.org>:
>
> Given that the region can be easily deactivated, I'm not sure I see
> the sense in introducing options that selectively disable
> region-sensitive behavior of specific commands.
When the user doesn't like the result of an operation, be it a change of mind or a mistake, the first logical reaction is to undo. Many users if not most are unaware that undo in Emacs is restricted to an active region, and even if they know, they are not likely to think of it before instinctively pressing the well-learned undo key.
One reason is that no other editor works like this; another is that almost all other operations that can be undone either deactivate the region or take place wholly inside it, so there is no reason for the user to care about that quirk.
Moreover, users are often aware from experience with other software that the time to undo an action is immediately afterwards, with no other potentially inhibiting action in-between. Requiring a specific undo-enabling action is therefore doubly hostile.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37700
; Package
emacs
.
(Fri, 11 Oct 2019 18:27:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 37700 <at> debbugs.gnu.org (full text, mbox):
> Do you know of any drawbacks for someone whose editing habits are
> not dependent on the region confinement of undo?
Here I once had my own 'undo' function since I disliked the one in
simple.el. Eventually I gave up because it was too tedious to keep up
with the changes of the original. Nowadays I'm just using
(defun my-undo (&optional arg)
(interactive)
(if mark-active
;; No `undo-in-region'.
(let (mark-active)
(undo arg)
(setq mark-active t)
;; The following might be harmful, let's see.
(setq deactivate-mark nil))
(undo arg)))
But I also faintly remember a discussion with the author of
'mouse-drag-and-drop-region' on whether it is a good idea to activate
the mark after dropping - IIRC he did have some argument in favor of
it. Maybe it would be easier to add an option for not activating the
region when dropping than adding one for 'undo'.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37700
; Package
emacs
.
(Fri, 11 Oct 2019 18:37:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 37700 <at> debbugs.gnu.org (full text, mbox):
> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Fri, 11 Oct 2019 19:18:51 +0200
> Cc: martin rudalics <rudalics <at> gmx.at>, 37700 <at> debbugs.gnu.org
>
> 11 okt. 2019 kl. 16.43 skrev Eli Zaretskii <eliz <at> gnu.org>:
> >
> > Given that the region can be easily deactivated, I'm not sure I see
> > the sense in introducing options that selectively disable
> > region-sensitive behavior of specific commands.
>
> When the user doesn't like the result of an operation, be it a change of mind or a mistake, the first logical reaction is to undo. Many users if not most are unaware that undo in Emacs is restricted to an active region, and even if they know, they are not likely to think of it before instinctively pressing the well-learned undo key.
>
> One reason is that no other editor works like this; another is that almost all other operations that can be undone either deactivate the region or take place wholly inside it, so there is no reason for the user to care about that quirk.
>
> Moreover, users are often aware from experience with other software that the time to undo an action is immediately afterwards, with no other potentially inhibiting action in-between. Requiring a specific undo-enabling action is therefore doubly hostile.
You are arguing that 'undo' should never be sensitive to the active
region. If that was so, we'd have gobs of bug reports, because this
behavior is quite old, since 2007 AFAICT.
So evidently this feature is not as hostile as you seem to imply.
Moreover, the situation is not irrecoverable, even if the user does
make mistakes you describe: one can undo the undo, then disable the
region, and undo again.
Your change, however, was for an option that would disable this
behavior only optionally, not altogether. And my response was to the
idea that we should have knobs that selectively disable
region-sensitive behavior of specific commands one by one. I still
maintain that doing that for individual commands makes little sense to
me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37700
; Package
emacs
.
(Fri, 11 Oct 2019 18:52:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 37700 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 11 Oct 2019 21:36:05 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 37700 <at> debbugs.gnu.org
>
> You are arguing that 'undo' should never be sensitive to the active
> region. If that was so, we'd have gobs of bug reports, because this
> behavior is quite old, since 2007 AFAICT.
Actually, more like since 1998: it was introduced in Emacs 20.3.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37700
; Package
emacs
.
(Fri, 11 Oct 2019 18:59:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 37700 <at> debbugs.gnu.org (full text, mbox):
> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Fri, 11 Oct 2019 19:18:51 +0200
> Cc: martin rudalics <rudalics <at> gmx.at>, 37700 <at> debbugs.gnu.org
>
> another [reason] is that almost all other operations that can be undone either deactivate the region or take place wholly inside it, so there is no reason for the user to care about that quirk.
So perhaps a better way to resolve this situation is to teach 'undo'
about drag-and-drop, so that it doesn't undo selectively immediately
after drag-and-drop?
IOW, the selective undo feature AFAIU assumes that the region is set
up by the user before invoking 'undo', and that is not so in this
case.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37700
; Package
emacs
.
(Fri, 11 Oct 2019 19:14:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 37700 <at> debbugs.gnu.org (full text, mbox):
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Fri, 11 Oct 2019 20:26:23 +0200
> Cc: 37700 <at> debbugs.gnu.org
>
> But I also faintly remember a discussion with the author of
> 'mouse-drag-and-drop-region' on whether it is a good idea to activate
> the mark after dropping - IIRC he did have some argument in favor of
> it. Maybe it would be easier to add an option for not activating the
> region when dropping than adding one for 'undo'.
Yes, that would be a possible solution, I think, since that command is
quite new.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37700
; Package
emacs
.
(Sat, 12 Oct 2019 01:56:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 37700 <at> debbugs.gnu.org (full text, mbox):
> But I also faintly remember a discussion with the author of
> 'mouse-drag-and-drop-region' on whether it is a good idea to activate
> the mark after dropping - IIRC he did have some argument in favor of
> it. Maybe it would be easier to add an option for not activating the
> region when dropping than adding one for 'undo'.
On revision of writing, I often want to move a sentence around to fit
into right place, without loosing the sentence from sight. Most of the
time I cannot relocate the sentence to the best place by single
drag-and-drop operation thus I want to maintain region active.
I found that I did not notice problem pointed by Mattias because I
assign `undo' by `redo+.el' to C-/. I agree that undo behavior by C-/
with Emacs -Q is inconvenient!
https://www.emacswiki.org/emacs/redo+.el
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37700
; Package
emacs
.
(Sat, 12 Oct 2019 08:25:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 37700 <at> debbugs.gnu.org (full text, mbox):
> And my response was to the
> idea that we should have knobs that selectively disable
> region-sensitive behavior of specific commands one by one. I still
> maintain that doing that for individual commands makes little sense to
> me.
Full agreement here.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37700
; Package
emacs
.
(Sat, 12 Oct 2019 08:25:05 GMT)
Full text and
rfc822 format available.
Message #47 received at 37700 <at> debbugs.gnu.org (full text, mbox):
> On revision of writing, I often want to move a sentence around to fit
> into right place, without loosing the sentence from sight. Most of the
> time I cannot relocate the sentence to the best place by single
> drag-and-drop operation thus I want to maintain region active.
>
> I found that I did not notice problem pointed by Mattias because I
> assign `undo' by `redo+.el' to C-/. I agree that undo behavior by C-/
> with Emacs -Q is inconvenient!
I think that we should provide an option to not enable the region
after dropping and maybe even make it the default.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37700
; Package
emacs
.
(Sat, 12 Oct 2019 16:43:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 37700 <at> debbugs.gnu.org (full text, mbox):
Tak Kunihiro wrote:
> On revision of writing, I often want to move a sentence around to fit
> into right place, without loosing the sentence from sight. Most of the
> time I cannot relocate the sentence to the best place by single
> drag-and-drop operation thus I want to maintain region active.
Thank you, very much my experience.
> I found that I did not notice problem pointed by Mattias because I
> assign `undo' by `redo+.el' to C-/.
Ah yes; apparently, region handling is mentioned in a TODO comment in redo+.el but nobody has bothered to implement it. Looks like the demand isn't there.
Martin Rudalics wrote:
> I think that we should provide an option to not enable the region
> after dropping and maybe even make it the default.
That would seriously degrade usability of the drag-and-drop feature. Selecting the text at its final position both highlights it, and allows the user to drag it again or do other region-related operations. (Other editors work the same way.)
This behaviour is definitely more important to the drag-and-drop user than the region-confinement of undo.
Eli Zaretskii wrote:
> So perhaps a better way to resolve this situation is to teach 'undo'
> about drag-and-drop, so that it doesn't undo selectively immediately
> after drag-and-drop?
Maybe --- can it be done within the current 'undo' framework, or would drag-and-drop need to be special-cased? Did you have a particular approach in mind?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37700
; Package
emacs
.
(Sat, 12 Oct 2019 17:18:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 37700 <at> debbugs.gnu.org (full text, mbox):
> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Sat, 12 Oct 2019 18:42:30 +0200
> Cc: Tak Kunihiro <homeros.misasa <at> gmail.com>, tkk <at> misasa.okayama-u.ac.jp,
> Eli Zaretskii <eliz <at> gnu.org>, martin rudalics <rudalics <at> gmx.at>
>
> > So perhaps a better way to resolve this situation is to teach 'undo'
> > about drag-and-drop, so that it doesn't undo selectively immediately
> > after drag-and-drop?
>
> Maybe --- can it be done within the current 'undo' framework, or would drag-and-drop need to be special-cased? Did you have a particular approach in mind?
I didn't figure out the details, I only had a general idea. I thought
about doing that inside 'undo', perhaps have a list of commands for
which an immediate 'undo' will disregard an active region.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37700
; Package
emacs
.
(Sat, 12 Oct 2019 17:54:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 37700 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 12 Oct 2019 20:17:02 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 37700 <at> debbugs.gnu.org, tkk <at> misasa.okayama-u.ac.jp, homeros.misasa <at> gmail.com
>
> perhaps have a list of commands for which an immediate 'undo' will
> disregard an active region.
Or maybe have those commands have an 'undo' property which would tell
'undo' to treat them specially. Like we do with delete-selection.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37700
; Package
emacs
.
(Wed, 16 Oct 2019 15:28:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 37700 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
12 okt. 2019 kl. 19.53 skrev Eli Zaretskii <eliz <at> gnu.org>:
>
> Or maybe have those commands have an 'undo' property which would tell
> 'undo' to treat them specially. Like we do with delete-selection.
After trying various approaches, the attached patch looks somewhat promising. It adds a new element type to buffer-undo-list, `unconfined', which disables selective undo for one record. Consider it a proof-of-concept.
While it has the advantage of not requiring the user to change any settings, I still prefer the first approach (an option to disable undo confinement), as it's less intrusive and more generally useful. However, this should work as well.
[0001-Don-t-confine-undo-of-mouse-drag-and-drop-to-the-reg.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37700
; Package
emacs
.
(Sat, 26 Oct 2019 10:17:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 37700 <at> debbugs.gnu.org (full text, mbox):
> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Wed, 16 Oct 2019 17:27:05 +0200
> Cc: 37700 <at> debbugs.gnu.org, tkk <at> misasa.okayama-u.ac.jp,
> homeros.misasa <at> gmail.com
>
> After trying various approaches, the attached patch looks somewhat promising. It adds a new element type to buffer-undo-list, `unconfined', which disables selective undo for one record. Consider it a proof-of-concept.
>
> While it has the advantage of not requiring the user to change any settings, I still prefer the first approach (an option to disable undo confinement), as it's less intrusive and more generally useful. However, this should work as well.
Thanks. I don't consider myself an expert on undo, but the patch
looks reasonable to me. I think we should describe this new element
in the ELisp manual, but other than that, I think it can go in.
Stefan, any comments?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37700
; Package
emacs
.
(Mon, 28 Oct 2019 20:03:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 37700 <at> debbugs.gnu.org (full text, mbox):
> > On revision of writing, I often want to move a sentence around to fit
> > into right place, without loosing the sentence from sight. Most of the
> > time I cannot relocate the sentence to the best place by single
> > drag-and-drop operation thus I want to maintain region active.
> Thank you, very much my experience.
Indeed, that's also my experience [ and as a result I stay away from
text's drag-and-drop since I find C-w ... C-y to be easier since it
avoids this trial-and-error problem ;-) ]
> - (overlay-end overlay)))))
> + (overlay-end overlay))))
> + ;; Since we will leave the destination text selected,
> + ;; make sure an undo operation disregards the region
> + ;; or the operation will only be partially undone.
> + (when (consp buffer-undo-list)
> + (push 'unconfined buffer-undo-list)))
Rather than add a special new kind of entry you can use some version of
(apply DELTA BEG END FUN-NAME . ARGS), presumably with DELTA=0 and
BEG=END, so you don't need to modify the docstring of `buffer-undo-list`
nor the implementation of primitive-undo.
> @@ -2862,7 +2864,10 @@ undo-make-selective-list
> ((null undo-elt)
> ;; Don't put two nils together in the list
> (when (car selective-list)
> - (push nil selective-list)))
> + (push nil selective-list))
> + (setq unconfined nil))
> + ((eq undo-elt 'unconfined)
> + (setq unconfined t))
> ((and (consp undo-elt) (eq (car undo-elt) t))
> ;; This is a "was unmodified" element. Keep it
> ;; if we have kept everything thus far.
> @@ -2875,7 +2880,7 @@ undo-make-selective-list
> (t
> (let ((adjusted-undo-elt (undo-adjust-elt undo-elt
> undo-deltas)))
> - (if (undo-elt-in-region adjusted-undo-elt start end)
> + (if (or (undo-elt-in-region adjusted-undo-elt start end) unconfined)
> (progn
> (setq end (+ end (cdr (undo-delta adjusted-undo-elt))))
> (push adjusted-undo-elt selective-list)
As a user of undo-in-region, I think I'd be surprised if my undo started
to modify parts of the buffer outside the region, so I think a better
approach would be to only pay attention to the `unconfined' marker when
it appears at the top of the `buffer-undo-list` (i.e. only if the
drag-and-drop was the very last operation). Also I think it would
deserve a message in the minibuffer explaining that the undo is not
confined to the region.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37700
; Package
emacs
.
(Wed, 30 Oct 2019 19:10:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 37700 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
28 okt. 2019 kl. 21.01 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:
> Indeed, that's also my experience [ and as a result I stay away from
> text's drag-and-drop since I find C-w ... C-y to be easier since it
> avoids this trial-and-error problem ;-) ]
Thanks for taking a look. It seems that the only happy users are those that use redo+.el or similar packages that do not restrict undo to region.
Unfortunately, even with the patch, undoing a drag-and-drop does not leave the region active the way it was before the undo, so the user has to reselect the text in order to try again. Reactivating the region automatically on undo is tempting but incompatible with undo-in-region (the same problem but in the other direction). Partly because of this, I believe that providing an option to disable undo-in-region altogether is a better solution.
> Rather than add a special new kind of entry you can use some version of
> (apply DELTA BEG END FUN-NAME . ARGS), presumably with DELTA=0 and
> BEG=END, so you don't need to modify the docstring of `buffer-undo-list`
> nor the implementation of primitive-undo.
I'm not sure how that would be done in practice since 'undo-elt-in-region' is nil for any (apply ...) element. This could be remedied, of course, but that would entail undo machinery changes which we wanted to avoid in the first place. In addition, it is unclear how the 'apply' mechanism could be used in a way that is sensitive to whether it's the first record to be undone.
> As a user of undo-in-region, I think I'd be surprised if my undo started
> to modify parts of the buffer outside the region, so I think a better
> approach would be to only pay attention to the `unconfined' marker when
> it appears at the top of the `buffer-undo-list` (i.e. only if the
> drag-and-drop was the very last operation).
The patch has now been modified to that effect. (I'm still not sure it's the right solution.)
> Also I think it would
> deserve a message in the minibuffer explaining that the undo is not
> confined to the region.
It was tricky to do that cleanly, given the structure of the undo code, so it went into a separate patch.
[0001-Don-t-confine-undo-of-mouse-drag-and-drop-to-the-reg.patch (application/octet-stream, attachment)]
[0002-Adapt-undo-message-when-undoing-unconfined-actions-i.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37700
; Package
emacs
.
(Wed, 30 Oct 2019 19:57:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 37700 <at> debbugs.gnu.org (full text, mbox):
> Unfortunately, even with the patch, undoing a drag-and-drop does not leave
> the region active the way it was before the undo, so the user has to
> reselect the text in order to try again.
If the undo-list is built right, reselecting the text should be just
`C-x C-x`, which isn't that bad.
> Partly because of this, I believe that providing an option to disable
> undo-in-region altogether is a better solution.
I agree that disabling it right after a drag-and-drop is a better choice.
> I'm not sure how that would be done in practice since 'undo-elt-in-region'
> is nil for any (apply ...) element. This could be remedied, of course, but
> that would entail undo machinery changes which we wanted to avoid in the
> first place.
Yes, that's a long-standing missing feature, but I think it's orthogonal
to the current problem.
> In addition, it is unclear how the 'apply' mechanism could be used in
> a way that is sensitive to whether it's the first record to be undone.
With ad-hoc code looking for it at the beginning of `undo`.
But now that I think about it, maybe a better option would be to check
(when (symbolp last-command)
(get last-command 'undo-inhibit-region))
and then put the `undo-inhibit-region` property on
`mouse-drag-and-drop-region`.
Of course, I wouldn't oppose adding
(defcustom undo-use-region-when-active t ...)
so users can turn it off, but I think it's more important to make sure
that users never need to set such a var to nil.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37700
; Package
emacs
.
(Thu, 31 Oct 2019 11:01:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 37700 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
30 okt. 2019 kl. 20.56 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:
>
>> Unfortunately, even with the patch, undoing a drag-and-drop does not leave
>> the region active the way it was before the undo, so the user has to
>> reselect the text in order to try again.
>
> If the undo-list is built right, reselecting the text should be just
> `C-x C-x`, which isn't that bad.
Right, second nature to the Emacs user, but it would still be nice not having to go through that step. kill-region and delete-selection-mode are similarly affected.
> But now that I think about it, maybe a better option would be to check
>
> (when (symbolp last-command)
> (get last-command 'undo-inhibit-region))
>
> and then put the `undo-inhibit-region` property on
> `mouse-drag-and-drop-region`.
Thank you, this looks like the best idea so far. A very simple change, yet effective in practice. Not perfect --- last-command is not buffer-local, and even switching to a different frame and back will change it --- but good enough.
Patch attached.
[0001-Inhibit-undo-in-region-for-mouse-drag-region-bug-377.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37700
; Package
emacs
.
(Thu, 31 Oct 2019 14:46:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 37700 <at> debbugs.gnu.org (full text, mbox):
> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Thu, 31 Oct 2019 12:00:08 +0100
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 37700 <at> debbugs.gnu.org,
> tkk <at> misasa.okayama-u.ac.jp, homeros.misasa <at> gmail.com
>
> > But now that I think about it, maybe a better option would be to check
> >
> > (when (symbolp last-command)
> > (get last-command 'undo-inhibit-region))
> >
> > and then put the `undo-inhibit-region` property on
> > `mouse-drag-and-drop-region`.
>
> Thank you, this looks like the best idea so far. A very simple change, yet effective in practice. Not perfect --- last-command is not buffer-local, and even switching to a different frame and back will change it --- but good enough.
>
> Patch attached.
Fine with me (I proposed something like this during the original
discussion), but please document this property in the ELisp manual.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37700
; Package
emacs
.
(Thu, 31 Oct 2019 16:05:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 37700 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
31 okt. 2019 kl. 15.45 skrev Eli Zaretskii <eliz <at> gnu.org>:
> Fine with me (I proposed something like this during the original
> discussion), but please document this property in the ELisp manual.
Then I apologise for misunderstanding you!
Attached patch amended with changes to the manual and NEWS.
[0001-Inhibit-undo-in-region-for-mouse-drag-region-bug-377.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37700
; Package
emacs
.
(Thu, 31 Oct 2019 16:11:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 37700 <at> debbugs.gnu.org (full text, mbox):
> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Thu, 31 Oct 2019 17:04:41 +0100
> Cc: monnier <at> iro.umontreal.ca, 37700 <at> debbugs.gnu.org,
> tkk <at> misasa.okayama-u.ac.jp, homeros.misasa <at> gmail.com
>
> > Fine with me (I proposed something like this during the original
> > discussion), but please document this property in the ELisp manual.
>
> Then I apologise for misunderstanding you!
No need to apologize; I was just explaining why I like this patch ;-)
> Attached patch amended with changes to the manual and NEWS.
Thanks.
> --- a/doc/lispref/text.texi
> +++ b/doc/lispref/text.texi
> @@ -1451,6 +1451,12 @@ Undo
> This function does not bind @code{undo-in-progress}.
> @end defun
>
> +Some commands leave the region active after execution in such a way that
> +it interferes with selective undo of that command. To make @code{undo}
> +ignore the active region when invoked immediately after such a command,
> +set the property @code{undo-inhibit-region} of the command's function
> +symbol to a non-nil value.
Please add here a cross-reference to the other place, where this
property is described.
> +** 'undo' can be made to ignore the active region for a command
> +by setting its 'undo-inhibit-region' symbol property to non-nil.
Instead of "its" I'd use "that command's", because "its" is a bit
ambiguous in this context.
Reply sent
to
Mattias Engdegård <mattiase <at> acm.org>
:
You have taken responsibility.
(Thu, 31 Oct 2019 16:49:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Mattias Engdegård <mattiase <at> acm.org>
:
bug acknowledged by developer.
(Thu, 31 Oct 2019 16:49:03 GMT)
Full text and
rfc822 format available.
Message #88 received at 37700-done <at> debbugs.gnu.org (full text, mbox):
31 okt. 2019 kl. 17.10 skrev Eli Zaretskii <eliz <at> gnu.org>:
>
> Please add here a cross-reference to the other place, where this
> property is described.
Done.
>> +** 'undo' can be made to ignore the active region for a command
>> +by setting its 'undo-inhibit-region' symbol property to non-nil.
>
> Instead of "its" I'd use "that command's", because "its" is a bit
> ambiguous in this context.
Done.
Pushed with those patches (and moved the property description so that the list follows alphabetical order).
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 29 Nov 2019 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 266 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.