On improving Bookmarks

On improving Bookmarks

[Gabriel]

Hi,

I think there are some opportunities for improvements in Bookmarks (in
general and in how it support Types) and would like to collect general
feedback and directions before reporting bugs or proposing patches,
especially considering if such changes would be useful, the effort to
implement them and how to handle compatibility.

Bookmarks has support for Types besides regular "Files" or "Directories"
(opened with Dired).  A quick xref in current Emacs master branch shows
the following Types:

- "DocView"
- "Eshell"
- "Gnus"
- "Help"
- "Image-Dired"
- "Info"
- "Man"
- "EWW"
- "VC"
- "WoMan"

1) The empty "Type" column on C-x r l (bookmark-bmenu-list)

Bookmarks shows a proper value in the Type column of bookmark-bmenu-list
for all Types, except for regular "Files" and "Directories", in which
shows an empty string.  I believe that displaying the actual Type rather
an empty string for these cases would make the interface more consistent
and easier for navigation.  See bug#59212 for the open discussion.
Besides the question regarding the real value of this change, I
currently don't know how to easily distinguish between "Files" and
"Directories" without relying on IO calls (e.g. file-directory-p), which
could degrade performance in case of long Bookmarks lists.  We could
display the string "File" for both "Files" and "Directories", but it
would be a worse experience for users to not provide such distinction.

2) The usage of "File" and "Filename" in docs and interface

In docs (e.g. (info "(emacs)Bookmarks")) and interface (e.g. the "File"
column in bookmark-bmenu-list), we can find several occurrences of the
terms "File" and "Filename" (and related terms), which I think is
inconsistent since Bookmarks supports Types that do not really have
these concepts (e.g. "Help", "Man", "EWW", "Gnus").  A better term would
be "Location", which is already used in some places
(e.g. bookmark-location, bookmark-relocate, the 'location property).
Thus, I propose to make "Location" the official term in docs, interface
and code, and to obsolete "File", "Filename" and related ones.

3) Add Type to bookmark-sort-flag

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

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".

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.

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.

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.

---
Gabriel

Re: On improving Bookmarks

[Matthias Meulien]

Gabriel <gabriel376@hotmail.com> writes:

> (...) I think there are some opportunities for improvements in
> Bookmarks (in general and in how it support Types) and would like to
> collect general feedback and directions before reporting bugs or
> proposing patches, especially considering if such changes would be
> useful, the effort to implement them and how to handle compatibility.

Thank you!

> 1) The empty "Type" column on C-x r l (bookmark-bmenu-list)
>
> Bookmarks shows a proper value in the Type column of
> bookmark-bmenu-list for all Types, except for regular "Files" and
> "Directories", in which shows an empty string.  I believe that
> displaying the actual Type rather an empty string for these cases
> would make the interface more consistent and easier for navigation.

+1

> See bug#59212 for the open discussion.  Besides the question regarding
> the real value of this change, I currently don't know how to easily
> distinguish between "Files" and "Directories" without relying on IO
> calls (e.g. file-directory-p), which could degrade performance in case
> of long Bookmarks lists.  We could display the string "File" for both
> "Files" and "Directories", but it would be a worse experience for
> users to not provide such distinction.

Yes you're right.

If I remember correctly, when serialized, those "Files and Directories"
bookmarks aren't associated to a handler.  Introducing distinct handlers
for both would help to have a meaningful "type" value.

> 2) The usage of "File" and "Filename" in docs and interface (...)
> 3) Add Type to bookmark-sort-flag
>
> A simple suggestion to add Type to the choices of bookmark-sort-flag.

I am no against, but I'm not sure I'll use it.  Extending the / key
(bookmark-bmenu-search) to mimic what is done por packages would be more
interesting from my pov (ie make it a prefix key and for example have /
n filter by name, / t filter by type, and / l filter by location).

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

+1

> 5) Ability to open Bookmarks with external applications (...)
> 6) Add minibuffer completion details to C-x r b (bookmark-jump)

+1

> 7) Add Tags

+1

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

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...
-- 
Matthias

Re: On improving Bookmarks

[Stefan Kangas]

Gabriel <gabriel376@hotmail.com> writes:

> I think there are some opportunities for improvements in Bookmarks (in
> general and in how it support Types) and would like to collect general
> feedback and directions before reporting bugs or proposing patches,
> especially considering if such changes would be useful, the effort to
> implement them and how to handle compatibility.

Some good ideas here, indeed.  I think the best way forward is to submit
bug reports (put "Severity: wishlist" on the first line of your email)
for all of these.

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

See the package `marginalia' for this.  Maybe we should even consider
including that package by default.

bug#59212: On improving Bookmarks

[Karl Fogel]

[I'm combining the original bug-59212 thread with an emacs-devel 
thread here.]

On 12 Nov 2022, Eli Zaretskii wrote in Bug #59212: 
>> From: Gabriel <gabriel376@hotmail.com>
>> Date: Sat, 12 Nov 2022 05:56:22 -0300
>> 
>> Description:
>> Not a bug per se, but a suggestion for improvement in how 
>> Bookmark
>> displays the Type (added by commit 
>> 7c995264359824cc1aca40ca37201db5ed44e659).
>> 
>> Currently, bookmark-bmenu-list (C-x r l) displays a column 
>> named Type,
>> which has a proper value for all handlers (e.g.: Eshell, VC, 
>> EWW etc)
>> except for regular files, in which an empty string is 
>> displayed. I
>> believe the current behavior could be improved by displaying a 
>> default
>> value ("Files") to make the interface more uniform, explicit 
>> and to
>> avoid confusion.
>> 
>> Steps:
>> 1) emacs -Q
>> 2) M-x eshell
>> 3) C-x r m <RET>
>> 4) C-x C-f ~/foo.bar
>> 5) C-x r m <RET>
>> 6) C-x r b
>> 
>> These steps will add two bookmarks (eshell and foo.bar) and 
>> will open
>> the Bookmarks list. The Type column will have values "" and
>> "Eshell". After the patch below is applied, the Type column 
>> will have
>> values "File" and "Eshell".
>
>Thanks.
>
>Karl, any comments?

I don't have a strong opinion on this UI suggestion.

For users who set mostly file-or-directory bookmarks, and don't 
set very many bookmarks of other types, then it probably makes 
sense to treat files/directories as the default and not show a 
type for them.  That way, the unusual bookmarks stand out (which 
is useful because they might have different response-time 
characteristics, or other interactive idiosyncracies, than that 
user's typical bookmark does).

On the other hand, for users for whom file/directory bookmarks are 
not more common than other kinds of bookmarks, showing "File" or 
"Directory" like any other type would probably be better.  Those 
users are already accustomed to a variety of interactivity 
characteristics from their bookmarks anyway, so it makes less 
sense to trade away consistency of display in favor of stand-out 
visibility of certain cases.

But these are really minor differences; they're not terribly 
persuasive either way.  I think I'm still at "no strong opinion". 
I wouldn't stand in the way of the change.

Continuing on to the later conversation on emacs-devel about this:

On 16 Nov 2022, Gabriel wrote:
>Hi,
>
>I think there are some opportunities for improvements in 
>Bookmarks (in
>general and in how it support Types) and would like to collect 
>general
>feedback and directions before reporting bugs or proposing 
>patches,
>especially considering if such changes would be useful, the 
>effort to
>implement them and how to handle compatibility.
>
>Bookmarks has support for Types besides regular "Files" or 
>"Directories"
>(opened with Dired).  A quick xref in current Emacs master branch 
>shows
>the following Types:
>
>- "DocView"
>- "Eshell"
>- "Gnus"
>- "Help"
>- "Image-Dired"
>- "Info"
>- "Man"
>- "EWW"
>- "VC"
>- "WoMan"
>
>1) The empty "Type" column on C-x r l (bookmark-bmenu-list)
>
>Bookmarks shows a proper value in the Type column of 
>bookmark-bmenu-list
>for all Types, except for regular "Files" and "Directories", in 
>which
>shows an empty string.  I believe that displaying the actual Type 
>rather
>an empty string for these cases would make the interface more 
>consistent
>and easier for navigation.  See bug#59212 for the open 
>discussion.
>Besides the question regarding the real value of this change, I
>currently don't know how to easily distinguish between "Files" 
>and
>"Directories" without relying on IO calls 
>(e.g. file-directory-p), which
>could degrade performance in case of long Bookmarks lists.  We 
>could
>display the string "File" for both "Files" and "Directories", but 
>it
>would be a worse experience for users to not provide such 
>distinction.

Could we just use a combined term like "File/Dir" or "File/Path" 
or just "Path" or something?  Not the perfect user experience, but 
an 80% solution.  Obviously, we'd want to keep the width small.

>2) The usage of "File" and "Filename" in docs and interface
>
>In docs (e.g. (info "(emacs)Bookmarks")) and interface (e.g. the 
>"File"
>column in bookmark-bmenu-list), we can find several occurrences 
>of the
>terms "File" and "Filename" (and related terms), which I think is
>inconsistent since Bookmarks supports Types that do not really 
>have
>these concepts (e.g. "Help", "Man", "EWW", "Gnus").  A better 
>term would
>be "Location", which is already used in some places
>(e.g. bookmark-location, bookmark-relocate, the 'location 
>property).
>Thus, I propose to make "Location" the official term in docs, 
>interface
>and code, and to obsolete "File", "Filename" and related ones.

+1.  This makes a lot of sense, independently of whatever we do in 
the Type column of the Bookmark Menu.

The rest of your post on emacs-devel isn't really related to bug 
#59212, so I'll follow up separately to it in a moment.

Best regards,
-Karl

Re: bug#59212: On improving Bookmarks

[Eli Zaretskii]

> Cc: 59212@debbugs.gnu.org, emacs-devel@gnu.org
> From: Karl Fogel <kfogel@red-bean.com>
> Date: Wed, 16 Nov 2022 11:28:30 -0600
> 
> Could we just use a combined term like "File/Dir" or "File/Path" 
> or just "Path" or something?

Not "Path", please.  The GNU Coding Standards frown on using "path"
for anything except PATH-style directory lists.

Re: bug#59212: On improving Bookmarks

[Karl Fogel]

On 16 Nov 2022, Eli Zaretskii wrote:
>> Cc: 59212@debbugs.gnu.org, emacs-devel@gnu.org
>> From: Karl Fogel <kfogel@red-bean.com>
>> Date: Wed, 16 Nov 2022 11:28:30 -0600
>> 
>> Could we just use a combined term like "File/Dir" or 
>> "File/Path" 
>> or just "Path" or something?
>
>Not "Path", please.  The GNU Coding Standards frown on using 
>"path"
>for anything except PATH-style directory lists.

Thanks -- "Path" is out, then.

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

Re: On improving Bookmarks

[Jean Louis]

* Karl Fogel <kfogel@red-bean.com> [2022-11-16 20:40]:
> 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.

I use this variable to open files in Dired, this could be also used
for bookmarks.

dired-guess-shell-alist-user is a variable defined in ‘dired.el’.

Value:
(("\\.gif\\'" "sxiv -a")
 ("\\.mts\\'" "mpv")
 ("\\.pdf\\'" "zathura")
 ("\\.epub\\'" "mupdf")
 ("\\.djvu\\'" "evince")

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: On improving Bookmarks

[Karl Fogel]

On 17 Nov 2022, Jean Louis wrote:
> * Karl Fogel <kfogel@red-bean.com> [2022-11-16 20:40]:
>> 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.
>
> I use this variable to open files in Dired, this could be also 
> used
> for bookmarks.
>
> dired-guess-shell-alist-user is a variable defined in 
> ‘dired.el’.
>
> Value:
> (("\\.gif\\'" "sxiv -a")
>  ("\\.mts\\'" "mpv")
>  ("\\.pdf\\'" "zathura")
>  ("\\.epub\\'" "mupdf")
>  ("\\.djvu\\'" "evince")

That's a start -- it covers files at least.  But it wouldn't know 
what to do if handed (say) a URL, right?

We need something like a generalized MIME-type handler list.  And 
maybe Emacs has such a thing already?  Emacs is so big that I pack 
canned goods before I go looking for things in it...

Best regards,
-Karl

Re: On improving Bookmarks

[Stefan Kangas]

Karl Fogel <kfogel@red-bean.com> writes:

> We need something like a generalized MIME-type handler list.  And
> maybe Emacs has such a thing already?  Emacs is so big that I pack
> canned goods before I go looking for things in it...

See also the discussion in Bug#18132.

Re: On improving Bookmarks

[Jean Louis]

* Stefan Kangas <stefankangas@gmail.com> [2022-11-18 06:15]:
> Karl Fogel <kfogel@red-bean.com> writes:
> 
> > We need something like a generalized MIME-type handler list.  And
> > maybe Emacs has such a thing already?  Emacs is so big that I pack
> > canned goods before I go looking for things in it...
> 
> See also the discussion in Bug#18132.

That one opens files on local system. 

I would like EWW to open content type by predefined applications.

If Emacs would be using ~/.mailcap file that would be already good enough.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: On improving Bookmarks

[Jean Louis]

* Karl Fogel <kfogel@red-bean.com> [2022-11-18 00:19]:
> We need something like a generalized MIME-type handler list.  And maybe
> Emacs has such a thing already?  Emacs is so big that I pack canned goods
> before I go looking for things in it...

When I have mentioned on the Org mailing list that eww shall be able
to recognize content type, basically MIME type, and that Emacs shall
have possibility to define how to open different content types, people
started speaking of insecurity, how it is not good for Emacs users,
etc.

But I can easily use Iceweasel, fork of Firefox, and setup Emacs to
open text/x-org files.

See:
https://lists.gnu.org/archive/html/emacs-orgmode/2022-10/threads.html#00889

It came out in discussion that Emacs shall not open Org files coming
from WWW servers, while in the same time every other browser can open
Org files by using Emacs. 

Makes no sense to me.

Opening MIME types is not related to security. I can have Perl files
to be opened directly with Perl interpreter, that is my user choice.

In my opinion there shall be mechanism in Emacs to open any MIME type.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/