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.