Re: On improving Bookmarks

[Karl Fogel <kfogel@red-bean.com>]

[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