unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Sean McAfee <eefacm@gmail.com>
To: 74438@debbugs.gnu.org
Subject: bug#74438: 29.1; global-mark-ring does not work as described
Date: Thu, 21 Nov 2024 11:49:53 -0800	[thread overview]
Message-ID: <CANan03auzErUpQTptt6j2Sh8=MXU=n4T8aqoO5J7Qi21vw2Usg@mail.gmail.com> (raw)
In-Reply-To: <37667f67-9c28-4543-a28a-c5d42878dbce@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2216 bytes --]

On Thu, Nov 21, 2024 at 12:09 AM Nikolay Kudryavtsev <
nikolay.kudryavtsev@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.

[-- Attachment #2: Type: text/html, Size: 3173 bytes --]

  reply	other threads:[~2024-11-21 19:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-19 20:24 bug#74438: 29.1; global-mark-ring does not work as described Sean McAfee
2024-11-20 10:18 ` Nikolay Kudryavtsev
2024-11-20 14:35   ` Eli Zaretskii
2024-11-21  7:51     ` Nikolay Kudryavtsev
2024-11-21  9:49       ` Eli Zaretskii
2024-11-20 19:16   ` Sean McAfee
2024-11-21  8:09     ` Nikolay Kudryavtsev
2024-11-21 19:49       ` Sean McAfee [this message]
2024-11-21 20:32         ` Nikolay Kudryavtsev
2024-11-21 21:03           ` Sean McAfee

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='CANan03auzErUpQTptt6j2Sh8=MXU=n4T8aqoO5J7Qi21vw2Usg@mail.gmail.com' \
    --to=eefacm@gmail.com \
    --cc=74438@debbugs.gnu.org \
    /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).