[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: On improving Bookmarks
Re: On improving Bookmarks
Wed, 16 Nov 2022 11:37:52 -0600
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:
On 16 Nov 2022, Gabriel wrote:
3) Add Type to bookmark-sort-flag
A simple suggestion to add Type to the choices of
+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
other than regular "Files" and "Directories". It causes the
bookmark-relocate: Wrong type argument: stringp, nil
Would be nice to make it work for all types. I am not sure what
be the best way to implement it and the required effort. Perhaps
similar to how VC handles different backends or similar to how
bookmarks handles 'bookmark-handler-type. See also comment from
bookmark-location. As a simple remediation in case this change
added to Bookmarks, Emacs could report a better error message for
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
with xdg-open rather than DocView or open an URL with Firefox
than EWW). Not sure what would be the best way to implement it,
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
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
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.
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
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
have the choice of a bookmark scope: global or current project.
When jumping to a bookmark from a buffer attached to a project,
expect to have choice from bookmarks with global scope and
with scoped to current project.
A project-bookmark-bmenu-list command could be created that
bookmarks with global scope and scoped to current project.
I don't know whether one should extend bookmarks with a scope
or store bookmarks in projects (using .dir-locals.el or a
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
in each project. Unfortunately when you press the s key from
BMenu, the default bookmark file is overwritten with bookmarks
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?