From: phillip.lord@russet.org.uk (Phillip Lord)
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] fix/undo-point-in-wrong-place 6b3cfe4 4/4: Prepare for record now separate function.
Date: Mon, 23 Nov 2015 17:41:28 +0000 [thread overview]
Message-ID: <87k2p8aa0n.fsf@russet.org.uk> (raw)
In-Reply-To: <jwvtwoeiqsb.fsf-monnier+emacsdiffs@gnu.org> (Stefan Monnier's message of "Sun, 22 Nov 2015 00:21:27 -0500")
Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>> PT is the position of point that will naturally occur as a result of the
>> undo record that will be added just after this command terminates. */
>
> This comment is invalidated by your change.
>
>> + record_point (beg + SCHARS (string));
>
> Hmm I thought the sign on sbeg took care of this case already (i.e. the
> record_point should only record something when point was neither at the
> beginning nor at the end of the deleted string).
Yep, you are right.
Although, the strange thing is, this should be enough to solve the
problem with a "kill-region" command (which needs record_point to work).
Except that this doesn't work because, AFAICT, the value of point gets
changed *before* we get to the record_delete. delete-backward-char works
without using record_point, as does kill-word.
I think it is buffer-substring--filter that is to blame which resets
point to the start of the region immediately before deleting it.
> As for the source of the bug (i.e. what change caused the new
> behavior): in the old code, undo-boundary was called right before
> every command (whether there was a need to push a boundary or not), so
> contrary to the comment in the code, last_boundary_position was
> actually recording "position of point at beginning of the command"
> rather than "position of point last time we inserted a boundary".
Ah, yes.
>
> So the hunk below should recover the old behavior (well, more or less:
> it wouldn't compile as is, but I hope you get the idea). But to fix it
> right, we should rename these vars and adjust their comment to better
> reflect the way they're really used.
>
I've pushed an alternative solution (yes, I know I said I would just do
what you told me, but I could not resist). There is already
last_point_position and prev_buffer variables which do this, as far as I
can tell.
Phil
next prev parent reply other threads:[~2015-11-23 17:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20151120221320.21643.45342@vcs.savannah.gnu.org>
[not found] ` <E1Zztvo-0005ey-0X@vcs.savannah.gnu.org>
2015-11-22 5:21 ` [Emacs-diffs] fix/undo-point-in-wrong-place 6b3cfe4 4/4: Prepare for record now separate function Stefan Monnier
2015-11-23 17:41 ` Phillip Lord [this message]
2015-11-25 22:46 ` Phillip Lord
2015-11-26 4:00 ` Stefan Monnier
2015-11-26 10:32 ` Phillip Lord
2015-11-26 15:56 ` Eli Zaretskii
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=87k2p8aa0n.fsf@russet.org.uk \
--to=phillip.lord@russet.org.uk \
--cc=emacs-devel@gnu.org \
--cc=monnier@IRO.UMontreal.CA \
/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).