[Top][All Lists]

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

Re: On improving Bookmarks

From: Karl Fogel
Subject: Re: On improving Bookmarks
Date: Wed, 16 Nov 2022 11:37:52 -0600
User-agent: Gnus/5.13 (Gnus v5.13)

[This is the second part of my reply in this thread. The first part was posted as part of a parallel reply to Bug #59212 and can be seen here: https://mail.gnu.org/archive/html/emacs-devel/2022-11/msg01053.html .]

On 16 Nov 2022, Gabriel wrote:
3) Add Type to bookmark-sort-flag

A simple suggestion to add Type to the choices of bookmark-sort-flag.

+1. I'm not sure how often people would actually use it, but if a column is present, it should be sortable on.

4) Make R (bookmark-relocate) work for all Types

The R (bookmark-relocate) currently does not seem to work with Types other than regular "Files" and "Directories". It causes the following

bookmark-relocate: Wrong type argument: stringp, nil

Would be nice to make it work for all types. I am not sure what would
be the best way to implement it and the required effort.  Perhaps
similar to how VC handles different backends or similar to how currently bookmarks handles 'bookmark-handler-type. See also comment from 2010 in bookmark-location. As a simple remediation in case this change is not added to Bookmarks, Emacs could report a better error message for users,
e.g.: "bookmark-relocate is not supported for type EWW".

I think starting by just improving the error would be great. The larger effort can be tackled on a case-by-case basis -- it doesn't have to be all solved all at once.

5) Ability to open Bookmarks with external applications

Add choice to open bookmarks in Emacs using the default
bookmark-handler-type or using an external application (e.g. open a PDF with xdg-open rather than DocView or open an URL with Firefox rather than EWW). Not sure what would be the best way to implement it, though.

That's a very interesting idea.  +1 to the concept.

But does Emacs already have a generic mechanism for saying "open things of type X with program Y"? If so, Bookmark should just rely on that mechanism, rather than have some Bookmark-specific mechanism. And if there isn't such a generic mechanism in Emacs, perhaps it be better to create that than to do something special for Bookmark.

6) Add minibuffer completion details to C-x r b (bookmark-jump)

A simple suggestion to add minibuffer completion details to
bookmark-jump so users can know, for example, the Type and Location. It
could be controlled by defcustom completions-detailed.

Again, +1 to the concept.

7) Add Tags

A "simple" feature that would make Bookmarks much more powerful. In
simple terms, a list of tags would be saved with each bookmark in
bookmark-default-file, and could be used for better filtering and

Well... I hesitate on this one. Tagging mechanisms often turn out to be half-baked solutions to sets of only partially-related problems. And in the case of bookmarks, we already have a lot of information we could work with, even without tags:

* The bookmark's name Its path Its type Its creation date The * front and back context strings

I guess I would ask: have you personally encountered situations with your bookmarks where tags would have been the best solution? I.e., is this idea based on directly-experienced need, or is it speculative?

On 16 Nov 2022, Matthias Meulien replied to Gabriel:
Let me mention two things I have in my wishlist:

8) Hability to scope bookmarks to Projects.

When setting a bookmark from a buffer attached to a project, I'd like to
have the choice of a bookmark scope: global or current project.

When jumping to a bookmark from a buffer attached to a project, I'd then expect to have choice from bookmarks with global scope and bookmarks
with scoped to current project.

A project-bookmark-bmenu-list command could be created that displays bookmarks with global scope and scoped to current project. I don't know whether one should extend bookmarks with a scope property or store bookmarks in projects (using .dir-locals.el or a dedicated

Whew. This would complexify Bookmark considerably -- it starts to transform into a project management system.

You can already use different bookmark-files for this kind of scoping, with a little bit of UI overhead (which we could improve, without having to fundamentally change how Bookmark works).

Aha, you touch on that below!...

9) Improve support for multiple bookmark files

I first thought 8) wouldn't be a problem if I maintained a bookmark file in each project. Unfortunately when you press the s key from bookmark BMenu, the default bookmark file is overwritten with bookmarks coming
from multiple sources...

And when jumping there's no way to select the bookmark source...

Maybe just designing a fix for that -- a better UI flow -- is the solution to the scoping need?

Best regards,

reply via email to

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