unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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



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