From: Matthias Meulien <orontee@gmail.com>
To: Gabriel <gabriel376@hotmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: On improving Bookmarks
Date: Wed, 16 Nov 2022 08:23:59 +0100 [thread overview]
Message-ID: <87wn7vbbw0.fsf@gmail.com> (raw)
In-Reply-To: <SJ0PR06MB860930928FB323D442DDC26C8B079@SJ0PR06MB8609.namprd06.prod.outlook.com> (Gabriel's message of "Wed, 16 Nov 2022 02:25:20 -0300")
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
next prev parent reply other threads:[~2022-11-16 7:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-16 5:25 On improving Bookmarks Gabriel
2022-11-16 7:23 ` Matthias Meulien [this message]
2022-11-16 8:05 ` Stefan Kangas
2022-11-16 17:28 ` bug#59212: " Karl Fogel
2022-11-16 19:33 ` Eli Zaretskii
2022-11-16 19:47 ` Karl Fogel
2022-11-16 17:37 ` Karl Fogel
2022-11-17 10:20 ` Jean Louis
2022-11-17 21:17 ` Karl Fogel
2022-11-18 3:13 ` Stefan Kangas
2022-11-18 7:58 ` Jean Louis
2022-11-18 7:53 ` Jean Louis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wn7vbbw0.fsf@gmail.com \
--to=orontee@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=gabriel376@hotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).