From: Drew Adams <drew.adams@oracle.com>
To: Stefan Kangas <stefan@marxist.se>,
Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 20845@debbugs.gnu.org
Subject: bug#20845: 25.0.50; bookmark.el, handling of fictitious `buffer' property
Date: Fri, 5 Jul 2019 10:16:18 -0700 (PDT) [thread overview]
Message-ID: <bc9398b8-6eb0-4edb-8e2f-0062386ef0ad@default> (raw)
In-Reply-To: <CADwFkmnBSAAFWwm64L+TphPLkwWFDN-6B5zJv-kjLWOnR==6Gw@mail.gmail.com>
> > > I'm looking into Emacs Bug#20845 which asks about the purpose of the
> > > "bookmark" property in bookmark.el.
> >
> > I don't see any `bookmark` property, sorry.
>
> That should be "buffer", sorry about that.
That typo at the beginning of the report was my fault.
I meant `buffer' property, not `bookmark' property.
> > Oh, I see how/where it's used and it's definitely still used:
> > Info-bookmark-jump uses it (i.e. not in the stored bookmark object, but
> > in a transient object passed to bookmark-default-handler).
Yes, thanks for pointing that out.
> > So maybe it should be documented in the docstring of
> > `bookmark-default-handler` for the benefit of other handlers.
>
> I agree with this conclusion. So not only do we keep it, but we document
> it.
>
> Thanks for helping out Stefan, it seems we now have a way forward.
I agree, provided the doc of `bookmark-default-handler'
makes clear (1) that the value is assumed to be a
buffer, not a buffer name, and (2) that this is not a
"normal" bookmark property, that is, one whose value
can be saved.
It's OK for a jump function to pass a buffer object as
the property value to the default handler. But it's
generally not OK for code to try to store a buffer
value for property `buffer'. Such a bookmark works OK
in a live `bookmark-alist', but it isn't persistable.
That the default handler recognizes this property,
which cannot be persisted, is a bit aberrant.
It's normal for mode-setting, narrowing, etc. to be
coded in a jump function. What's not so normal is
to communicate the buffer to the default bookmark
handler as a bookmark property.
It should be sufficient to communicate the buffer
_name_ as the property value. And that's something
savable and retrievable - it's useful generally.
IOW, it's OK to have `buffer' bookmark property,
but I think its value should be a buffer name.
Something like this might be better than what we
have now (tested only mildly, using vanilla Emacs
26.2):
(defun Info-bookmark-make-record ()
""
(let* ((file (and (stringp Info-current-file)
(file-name-sans-extension
(file-name-nondirectory Info-current-file))))
(bookmark-name (if file
(concat "(" file ") " Info-current-node)
Info-current-node))
(defaults (delq nil (list bookmark-name file Info-current-node))))
`(,bookmark-name
,@(bookmark-make-record-default 'no-file)
(filename . ,Info-current-file)
(info-node . ,Info-current-node)
(buffer . ,(buffer-name)) ; <=======================
(handler . Info-bookmark-jump)
(defaults . ,defaults))))
(defun Info-bookmark-jump (bmk)
""
(let* ((file (bookmark-prop-get bmk 'filename))
(node (bookmark-prop-get bmk 'info-node)))
(Info-find-node file node)
;; Use `bookmark-default-handler' to move to location in node.
(bookmark-default-handler
(cons "" (bookmark-get-bookmark-record bmk))))) <===== no BUF
(defun bookmark-default-handler (bmk-record)
""
(let ((file (bookmark-get-filename bmk-record))
;; Get buffer from recorded buffer name. <================
(buf (get-buffer (bookmark-prop-get bmk-record 'buffer)))
(forward-str (bookmark-get-front-context-string bmk-record))
(behind-str (bookmark-get-rear-context-string bmk-record))
(place (bookmark-get-position bmk-record)))
(set-buffer
(cond
((and file (file-readable-p file) (not (buffer-live-p buf)))
(find-file-noselect file))
(buf)
(t (signal 'bookmark-error-no-filename (list 'stringp file)))))
(if place (goto-char place))
(when (and forward-str (search-forward forward-str (point-max) t))
(goto-char (match-beginning 0)))
(when (and behind-str (search-backward behind-str (point-min) t))
(goto-char (match-end 0)))
nil))
next prev parent reply other threads:[~2019-07-05 17:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-18 15:26 bug#20845: 25.0.50; bookmark.el, handling of fictitious `buffer' property Drew Adams
2019-07-05 12:45 ` Stefan Kangas
2019-07-05 13:46 ` Stefan Monnier
2019-07-05 14:04 ` Stefan Kangas
2019-07-05 17:16 ` Drew Adams [this message]
2019-07-05 20:39 ` Noam Postavsky
2019-07-05 21:35 ` Drew Adams
2019-07-05 20:51 ` Stefan Monnier
2019-07-05 21:33 ` Drew Adams
2022-02-03 21:16 ` Lars Ingebrigtsen
2022-02-03 22:03 ` bug#20845: [External] : " Drew Adams
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=bc9398b8-6eb0-4edb-8e2f-0062386ef0ad@default \
--to=drew.adams@oracle.com \
--cc=20845@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=stefan@marxist.se \
/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).