GNU bug report logs - #66313
29.1.50; process-mark sometimes does not yield the expected value

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: 66313 <at> debbugs.gnu.org
Subject: bug#66313: Acknowledgement (29.1.50; process-mark sometimes does not yield the expected value)
Date: Sat, 07 Oct 2023 18:56:21 +0300

> From: Markus Triska <triska <at> metalevel.at>
> Cc: 66313-done <at> debbugs.gnu.org
> Date: Sat, 07 Oct 2023 17:28:32 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > I fixed this on the emacs-29 branch
> 
> Thank you! I now found the related issue #43573, where Lars states:
> 
>    "If this breaks anything (and that is possible -- somebody could be
>    using `process-mark' as a weird way to keep track of what the
>    previous buffer was -- it should be reverted."
> 
> Also, I found commit 7b3e94b6648ed00c6948c09267894b548b2868e7, where the
> following (then) new piece of documentation was added to processes.texi:
> 
>    if non-@code{nil}, the process mark will be
>    set to point to the end of @var{buffer}.
> 
> When I wrote ediprolog.el, this was not documented as such.
> 
> Is the behaviour now consistent with the documentation, or must the
> documentation or behaviour be changed? Should the change introduced in
> #43573 be reverted as indicated above, because it broke something?

I see no need to revert the patch nor update the documentation.  You
have just bumped into a gray area, where the process mark was not
associated with a buffer, but set-marker (which is unrelated to
processes) just happened to associate the mark with the same buffer
which you later used in set-process-buffer.  This is
borderline-invalid code, but since it was easy to avoid moving the
marker if the marker's buffer is already the same as the one set by
set-process-buffer, I preferred to do that, rather than making any
disruptive changes so much time after that bug#43573 fix was
installed.

Previous Next

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