Re: On improving Bookmarks

[Karl Fogel]

[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
> error:
>
> 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
> navigation.

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
> file?).

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,
-Karl