[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [PATCH] Add user option to disable location in bookmarks

From: Drew Adams
Subject: RE: [PATCH] Add user option to disable location in bookmarks
Date: Sun, 21 Jun 2020 18:44:29 +0000 (UTC)

> > If this is about save-place then save-place should
> > do the right thing.  See above.  If there's an option
> > to be added in that regard, it's a save-place option:
> > `save-place-ignore-bookmark-position'.  The hook
> > function (see above) can move to the save-place place
> > if the option is non-nil, and just do nothing if it's
> > nil.
> I think you are too quick in punting the change to ‘save-place’.
> I think it’s a matter of user expectations.

Of course it is.  User expectations, common use
cases, and individual preferences.

The _general_ expectation is realized in the default
make-record function.  And in the default jump-to
behavior.  That's why they are defaults.  But they're
only defaults.

> You expect that a bookmark targets a particular location in the file.

No.  I don't expect anything particular from a given
bookmark, other than what it advertises.

Emacs users, in general, expect, by default, what
the default behavior provides.  That's why it's the

> (There are bookmarks that do not target a file;
> let’s ignore them for now.)

First, not targeting a file is not the same thing
as not targeting a particular location in a file.

But if you really mean not targeting a position
in a file, why ignore the case of bookmarks that
don't target such locations, if that's just what
this user's looking for?

If you as a particular user, or a particular mode
or library author, want all bookmarks used in some
context - or even all bookmarks - to not go to a
specific file position then why create bookmarks
that do that?  Why use the _default_ make-record
function to create bookmarks for that use case?

That's the first point.  There's no requirement to
use the default make-record function, if you want
a custom behavior.

> Activating the bookmark visits that file (if not already
> visited), displays that file’s buffer, and jumps to the bookmarked
> location (adjusting it by searching for context if necessary).

By default, yes.  That's the default behavior for
jumping to a bookmark, including a file-visiting

> Jamie expects that a bookmark targets the file in its entirety.
> Activating the bookmark then should visit the file (if not already
> visited) and display the file’s buffer.

I understand that.  (Visiting a file does put the
cursor at _some_ position - bob by default.)

> If the file had to be
> re-visited, save-place kicks in and restores the point and scroll
> position to the values saved when the file’s buffer was killed. If
> save-place is not active, the point and scroll position should remain
> whatever they end up by default (top of buffer?).

Yes, bob, by default, when first visiting a file.

> I dare say both expectations are valid for files.

All kinds of expectations are valid.  Whatever a
user wants and is realizable is valid.  No one's
suggested that Jamie's preferred behavior is invalid.

> Therefore, the fix should allow the user to avoid
> saving a location in bookmarks targeting files,

That doesn't follow.  A user should be able to jump
to a file bookmark and end up at the last save-place
location in that file.  That says nothing about what
gets saved in a bookmark record.

Is the need to avoid saving a location in bookmarks?
Or is the need to always visit a file bookmark at
bob (position 1)?  Or is the need to always (or only
sometimes perhaps) let a hook function adjust the
position upon visiting?

I think the need described is just to have jumping
to a file bookmark go to save-place's recorded
location within the file.

> perhaps by introducing a setting like
> ‘bookmark-set-save-location’, boolean, default t.

saveplace.el affects only file (and Dired) visits,
right?  So only file (and possibly Dired) bookmarks
present the user with this need.

> Other bookmark types would then decide if it makes
> sense to honor that setting, and how.

You mean they would _have_ to do that - decide.  Or
else they would just get their `location' settings
ignored whenever someone wanted save-place to ignore
`location' for file bookmarks.

So _every_ kind of bookmark would now need to add
logic to deal with this blanket, all-bookmarks option.

Unless, that is, for some reason some particular kind
of bookmark really wanted to make its `location' be
ignored whenever the option is enabled.  In which case,
it probably would have just not included a `location'
setting, or it too would have already felt the need for
such an option.

> E.g. an Info buffer technically contains a whole Info manual but,
> through narrowing, makes an appearance of displaying only a single
> Info page; it would make sense to bookmark the page but not the exact
> line and context.

Would it?  If necessarily so, then Info bookmarks
wouldn't have a `location' setting, would they?

Now, you can say that we could add such a blanket
user option, which makes all bookmarks, of all
kinds, have their `location' setting ignored.

And we could compensate for that blanket treatment
by providing a separate option that lists bookmark
types (or buffers or files or whatever) to exclude
from the option behavior.

Or we could incorporate that into the same option,
by making it (1) a list of type, buffer, files, or
whatever to exclude; (2) t or `all', meaning include
all; or (3) nil, meaning always respect `location'.

Or we can just satisfy the need, which is for
save-place, by having save-place do what it does
for visiting files generally: invoke its hook,
already defined, for visiting a file,
`save-place-find-file-hook'.  That hook function
(which shouldn't be named `*-hook', BTW) does just
what's wanted.

(And perhaps Jamie will want to do similarly for
Dired bookmarks, using `save-place-dired-hook'.)

And the place to use such a save-place hook
function for bookmark jumping, is
`bookmark-after-jump-hook', just as the place to
use the same function for `find-file' visiting is

Completely comparable, IMO.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]