emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Package "luwak"


From: Alfred M. Szmidt
Subject: Re: Package "luwak"
Date: Fri, 16 Dec 2022 10:33:54 -0500

Isn't this sorta tackling the wrong problem?

The main issue that I think Richard wants to tackle is
discoverability.  So while luwak as a name is is meaningless, doesn't
mean that it in itself is a bad name -- it is unique, and easy to
remeber.

In most Emacs files there is the Keywords: field, which lists some
"things that this does".  This would be a better way to make things
discoverable.  If we take a simple example of what I would consider
bad discoverability, it would be eww and shr.

eww.el has:
  Keywords: html

shr.el has:
  Keywords: html

They do do "html" -- but are totally different in what they _actually_
do.  I was looking if there was a command, say package-list-keywords,
package-apropos or apropos-package, but didn't find anything.


Even for rmail, gnus, and mule which are all mail clients and the
names mostly meaningless we have:

rmail.el:
;; Keywords: mail

gnus.el:
;; Keywords: news, mail

mh-eh.el
;; Keywords: mail

While slightly better, but as a user slightly meaningless (what does
"mail" mean? is it a MTA? MUA? does it parse SMTP? mbox files?)
mail-utils.el also has `mail' as a keyword.  A crude grep for `mail'
as a keyword results in 108 files, and I don't think we have 108 mail
readers. :-)


Instead of trying to find "perfect" names (that both explain what a
program does (by "program" i mean something a user directly interactes
with, e.g., rmail, org-mode, gnus, or eww), but are also easy to
remeber and unique); wouldn't it make more sense to have another
field, or extend the Keywords field?  In the case of eww and luwak, or
even a links or lynx mode, the Keywords: (or whatever) could
explicitly say "web-browser".

A command like apropos-package could then list those, or some other
solution.  We have variables like browse-url-browser-function which
could take use of this as well in some form, where "things" could be
marked as "suitable" for use in this variable.

That gets rid of all discussion of "that isn't a very good name of a
package", and instead makes it easier to discover things that might be
useful.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]