unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 17893@debbugs.gnu.org, charles@aurox.ch
Subject: bug#17893: 24.4.50; (error "Marker does not point anywhere")
Date: Mon, 20 Nov 2017 19:55:23 +0200	[thread overview]
Message-ID: <837eukesxg.fsf@gnu.org> (raw)
In-Reply-To: <jwvpo8csxx5.fsf-monnier+emacsbugs@gnu.org> (message from Stefan Monnier on Mon, 20 Nov 2017 11:51:45 -0500)

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: charles@aurox.ch (Charles A. Roelli),  17893@debbugs.gnu.org
> Date: Mon, 20 Nov 2017 11:51:45 -0500
> 
> > E.g., info.el itself maintains a per-buffer marker in
> > Info-tag-table-marker; evaluate it after M-n and see what it
> > tells you.
> 
> And for that reason, clone-buffer runs `clone-buffer-hook`, which
> Info-mode uses to do:

If so, it doesn't work well enough:

 emacs -Q
 C-u C-h i elisp.info RET
 M-: Info-tag-table-marker RET
  => #<marker at 3901363 in *info*>
 M-n
 M-: Info-tag-table-marker RET
  => #<marker in no buffer>

> > but in general this is a ticking bomb, unless I'm missing something.
> > If I'm right, the only solution is to walk all the markers that point
> > to the parent buffer and clone them to point to the cloned buffer
> > (this has to be done in C).
> 
> This can't be done in C because after creating those new markers, where
> would we store them?  E.g. cloning all the markers that are in
> `mark-ring` would just create new markers but it would fail to create
> a new list holding those markers, stored in the new buffer-local value
> of `mark-ring` (walking the markers doesn't tell us that they're
> referred to from `mark-ring`).

I guess we will have to walk all the local variables and find markers
in them, like GC does.  Is there any other way?

> Hence clone-buffer-hook, which doesn't solve the problem in itself, but
> makes it possible to fix it manually where needed.

I think this kind of problems is impossible to solve from Lisp, as we
don't expose enough information about markers, and for a good reason.
For starters, that hook assumes that every mode knows exactly what
local variables could need special handling, but that's an illusion.
For example, the user could have set all kinds of local variables
behind the back of Emacs which hold markers.

As another data point, there are 6 users of clone-buffer in Emacs
core, and only one of them bothers to set up a clone-buffer-hook.





  reply	other threads:[~2017-11-20 17:55 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-01 21:10 bug#17893: 24.4.50; (error "Marker does not point anywhere") Drew Adams
2014-07-01 22:42 ` Stefan Monnier
2014-07-02  1:17   ` Drew Adams
2014-07-02  2:11     ` Stefan Monnier
2014-07-02  2:49       ` Drew Adams
2014-07-02 14:09         ` Stefan Monnier
2014-07-02 14:22           ` Drew Adams
2014-07-02 14:58             ` Stefan Monnier
2014-07-02 16:08               ` Drew Adams
2014-07-02 18:24                 ` Stefan Monnier
2014-07-02 18:39                   ` Drew Adams
2014-07-02 18:58                 ` Stephen Berman
2014-07-15 16:19   ` Drew Adams
2017-11-12 10:41     ` Charles A. Roelli
2017-11-12 21:03       ` Stefan Monnier
2017-11-14 19:56         ` Charles A. Roelli
2017-11-14 20:08           ` Stefan Monnier
2017-11-19 19:31             ` Charles A. Roelli
2017-11-20 15:45               ` Eli Zaretskii
2017-11-20 16:51                 ` Stefan Monnier
2017-11-20 17:55                   ` Eli Zaretskii [this message]
2017-11-20 18:59                     ` Stefan Monnier
2017-11-20 19:32                       ` Eli Zaretskii
2017-11-20 19:49                 ` Andreas Schwab
2017-11-20 20:01                 ` Charles A. Roelli
2017-11-20 20:29                   ` Eli Zaretskii
2017-11-24 20:18                     ` Charles A. Roelli
2017-11-24 20:39                       ` Eli Zaretskii
2017-11-25 14:13                         ` Charles A. Roelli
2017-11-25 16:06                           ` Eli Zaretskii
2017-11-25 16:48                             ` Stefan Monnier
2017-11-25 17:20                               ` Eli Zaretskii
2017-11-25 18:30                             ` Andreas Schwab
2017-11-25 19:23                               ` Eli Zaretskii
2017-11-25 20:47                                 ` Andreas Schwab
2017-11-26 10:26                             ` martin rudalics
2017-11-26 16:07                               ` Eli Zaretskii
2017-11-27  8:50                                 ` martin rudalics
2017-11-27  9:54                                   ` Andreas Schwab
2017-11-27 10:02                                     ` martin rudalics
2017-11-24 21:22                       ` Stefan Monnier

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=837eukesxg.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=17893@debbugs.gnu.org \
    --cc=charles@aurox.ch \
    --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).