unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Karl Fogel <kfogel@red-bean.com>
To: Gabriel <gabriel376@hotmail.com>
Cc: 59212@debbugs.gnu.org, emacs-devel@gnu.org
Subject: bug#59212: On improving Bookmarks
Date: Wed, 16 Nov 2022 11:28:30 -0600	[thread overview]
Message-ID: <87k03u7qrl.fsf@red-bean.com> (raw)
In-Reply-To: <SJ0PR06MB860930928FB323D442DDC26C8B079@SJ0PR06MB8609.namprd06.prod.outlook.com> (Gabriel's message of "Wed, 16 Nov 2022 02:25:20 -0300")

[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





  parent reply	other threads:[~2022-11-16 17:28 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
2022-11-16  8:05 ` Stefan Kangas
2022-11-16 17:28 ` Karl Fogel [this message]
2022-11-16 19:33   ` bug#59212: " 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=87k03u7qrl.fsf@red-bean.com \
    --to=kfogel@red-bean.com \
    --cc=59212@debbugs.gnu.org \
    --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).