unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#59212: On improving Bookmarks
       [not found] <SJ0PR06MB860930928FB323D442DDC26C8B079@SJ0PR06MB8609.namprd06.prod.outlook.com>
@ 2022-11-16 17:28 ` Karl Fogel
  2022-11-16 19:33   ` Eli Zaretskii
       [not found]   ` <83edu2g0dl.fsf@gnu.org>
  0 siblings, 2 replies; 3+ messages in thread
From: Karl Fogel @ 2022-11-16 17:28 UTC (permalink / raw)
  To: Gabriel; +Cc: 59212, emacs-devel

[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





^ permalink raw reply	[flat|nested] 3+ messages in thread

* bug#59212: On improving Bookmarks
  2022-11-16 17:28 ` bug#59212: On improving Bookmarks Karl Fogel
@ 2022-11-16 19:33   ` Eli Zaretskii
       [not found]   ` <83edu2g0dl.fsf@gnu.org>
  1 sibling, 0 replies; 3+ messages in thread
From: Eli Zaretskii @ 2022-11-16 19:33 UTC (permalink / raw)
  To: Karl Fogel; +Cc: gabriel376, 59212, emacs-devel

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





^ permalink raw reply	[flat|nested] 3+ messages in thread

* bug#59212: On improving Bookmarks
       [not found]   ` <83edu2g0dl.fsf@gnu.org>
@ 2022-11-16 19:47     ` Karl Fogel
  0 siblings, 0 replies; 3+ messages in thread
From: Karl Fogel @ 2022-11-16 19:47 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: gabriel376, 59212, emacs-devel

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.





^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-11-16 19:47 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <SJ0PR06MB860930928FB323D442DDC26C8B079@SJ0PR06MB8609.namprd06.prod.outlook.com>
2022-11-16 17:28 ` bug#59212: On improving Bookmarks Karl Fogel
2022-11-16 19:33   ` Eli Zaretskii
     [not found]   ` <83edu2g0dl.fsf@gnu.org>
2022-11-16 19:47     ` Karl Fogel

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