unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: "Alfred M. Szmidt" <ams@gnu.org>, "rms@gnu.org" <rms@gnu.org>
Cc: "philipk@posteo.net" <philipk@posteo.net>,
	"emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: RE: [External] : Re: Package "luwak"
Date: Fri, 16 Dec 2022 17:31:57 +0000	[thread overview]
Message-ID: <SJ0PR10MB5488D7A0731662C7BDAD9E9AF3E69@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <E1p6Cig-0004RG-Ij@fencepost.gnu.org>

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

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

___

[ 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*'.

  https://www.emacswiki.org/emacs/download/finder%2b.el
]



  reply	other threads:[~2022-12-16 17:31 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-30 23:51 Package "luwak" Richard Stallman
2022-12-01  0:52 ` Stefan Monnier
2022-12-02 22:51   ` Richard Stallman
2022-12-03  2:49     ` T.V Raman
2022-12-11  4:04       ` Yuchen Pei
2022-12-04 23:18   ` Will Mengarini
2022-12-05  4:25     ` Jean Louis
2022-12-05 22:30     ` Richard Stallman
2022-12-06  9:05       ` Philip Kaludercic
2022-12-06 22:37         ` Richard Stallman
2022-12-07  3:33           ` Eli Zaretskii
2022-12-07  7:11             ` Philip Kaludercic
2022-12-07  8:44               ` Andreas Schwab
2022-12-01  3:54 ` North Year
2022-12-11  3:54 ` Yuchen Pei
2022-12-11 23:34   ` Richard Stallman
2022-12-11 13:07 ` Yuchen Pei
2022-12-12 22:19   ` Richard Stallman
2022-12-11 14:29 ` Stefan Monnier
2022-12-11 18:03   ` Tim Cross
2022-12-12 22:19   ` Richard Stallman
2022-12-12 22:42     ` Philip Kaludercic
2022-12-13 23:58       ` Richard Stallman
2022-12-14 21:34         ` Philip Kaludercic
2022-12-14 21:41           ` [External] : " Drew Adams
2022-12-16  3:35           ` Richard Stallman
2022-12-16 15:33             ` Alfred M. Szmidt
2022-12-16 17:31               ` Drew Adams [this message]
2022-12-16 18:52                 ` [External] : " Alfred M. Szmidt
2022-12-18  3:21               ` Richard Stallman
2022-12-16 11:05           ` 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=SJ0PR10MB5488D7A0731662C7BDAD9E9AF3E69@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=ams@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=philipk@posteo.net \
    --cc=rms@gnu.org \
    /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).