[Top][All Lists]

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

RE: [External] : Re: Package "luwak"

From: Drew Adams
Subject: RE: [External] : Re: Package "luwak"
Date: Fri, 16 Dec 2022 17:31:57 +0000

> 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....
> I was looking if there was a command, say package-list-keywords,
> package-apropos or apropos-package, but didn't find anything...
> 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.

Good initiative.  The point truly is _discoverability_.

A file/library name can sometimes help discovery a little bit,
but that effect and possibility is quite limited (doesn't
scale).  Nothing wrong with trying to have better library
names, but that isn't much of a solution for the problem of
finding libraries.

Discoverability can no doubt be improved.  And a file's
`Commentary' field `Keywords' is, yes, one thing that could
be leveraged better.  (That would of course depend on library
maintainers actually adding and maintaining that field.)

There's library `finder.el'.  It's all about leveraging field
`Keywords' in library Commentary.  It has commands
`finder-by-keyword' and `finder-list-keywords'. (For some
reason those seem to be exactly the same, without aliasing -
the first just calls the second.  Why?).

There could/should be a `finder-apropos', which lets you use
multiple keywords.  (You mention the need for a command such
as `apropos-package', which would be essentially the same

`finder.el' is quite old.  It could be beefed up and perhaps
extended to do some more (?) for "packages".  IOW, it, - and
field `Keywords' - could use some more love.

We might imagine some semi-automatic way (suggestions for a
maintainer) of coming up with relevant keywords, to help make
the job of adding and maintaining `Keywords' easier and more


[ My library `finder+.el' enhances `finder.el' in a few minor
  ways, such as using its own syntax table, adding font-lock,
  and naming the `*Finder*' buffer after the library instead
  (so you can have multiple such buffers) - e.g., for library
  `cl-lib' the buffer is named `*Commentary, cl-lib*'.


reply via email to

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