GNU bug report logs - #74438
29.1; global-mark-ring does not work as described

Previous Next

Full log

Message #26 received at 74438 <at> debbugs.gnu.org (full text, mbox):

From: Sean McAfee <eefacm <at> gmail.com>
To: 74438 <at> debbugs.gnu.org
Subject: Re: bug#74438: 29.1; global-mark-ring does not work as described
Date: Thu, 21 Nov 2024 11:49:53 -0800

[Message part 1 (text/plain, inline)]

On Thu, Nov 21, 2024 at 12:09 AM Nikolay Kudryavtsev <
nikolay.kudryavtsev <at> gmail.com> wrote:

> Using the mark ring for programming purposes is generally seen as a faux
> pas, see the docstrings for push-mark and set-mark, which explicitly
> warn against this.
>

I've read those warnings, which seem to be about using the mark to keep
track of positions within a single function execution.  Here I'm writing a
command that wants to use information recorded by a previous command, which
seems like a legitimate use to me.


> If you still insist, then nothing is really stopping you from short
> circuiting this behavior by say doing a forward-char, set-mark,
> backward-char, set-mark again.
>

I could do that, but conceptually I just want to set the mark, and I don't
want to have to perpetually keep in mind that when I set the mark in this
one specific context, I need to go through an extended routine like that.


> But I also don't understand why do you need buffer 1 mark to be at the
> front of the ring, because it's gonna reliably be as the second element
> in it anyway.
>

But it won't; it could be anywhere in the global mark ring.

- Go to a new buffer foo and press C-SPC; now buffer foo is first in the
global mark ring.
- Go to a new buffer bar and press C-SPC; now buffer foo is second in the
ring.
- Go to a new buffer baz and press C-SPC; now buffer foo is third in the
ring.
- Go back to buffer foo and press C-SPC; buffer foo is still third in the
ring.

And buffer foo won't be in the ring at all if more than
global-mark-ring-max buffers are visited in this way.

Anyway, it seems like a consensus is emerging that it's the documentation
and not the code that needs to be updated.  At least I've thought of a way
to get the info I need without changing my workflow.  Something like:

    (defvar last-global-mark (make-marker))

    (defun my-set-mark-command (arg)
      (interactive "P")
      (set-mark-command arg)
      (unless (equal arg '(4))
        (set-marker last-global-mark (point))))

    (global-set-key [remap set-mark-command] #'my-set-mark-command)

I wish it weren't necessary, but at least it's not very long.

[Message part 2 (text/html, inline)]

Previous Next

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