unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: "Stephen J. Turnbull" <stephen@xemacs.org>,
	Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: Oleh Krehel <ohwoeowho@gmail.com>,
	Artur Malabarba <bruce.connor.am@gmail.com>,
	emacs-devel <emacs-devel@gnu.org>
Subject: RE: Adding a few more finder keywords
Date: Tue, 9 Jun 2015 07:22:59 -0700 (PDT)	[thread overview]
Message-ID: <048d389e-cd09-468e-b93f-729505e56ab0@default> (raw)
In-Reply-To: <873821xzon.fsf@uwakimon.sk.tsukuba.ac.jp>

>  > We could decide that the specific keywords are unwanted, tho.
> 
> An "unwanted" keyword doesn't exist though.  Somebody wanted it or
> it wasn't in Keywords: in the first place.  And although every human
> is unique, very few humans are so unique that they'll choose a keyword
> that nobody else would use to look up packages.
> 
> So I think what you mean by "unwanted" is mostly "redundant (because
> a> synonym)". It seems to me that
> 
> 1.  There *should* be a list of "recommended keywords" which package
>     maintainers can easily access for reference...
> 2.  There *should* be a database of synonyms of recommended keywords
>     for use by maintainers...
> 3.  There should be a tool to walk the libraries...
>     Probably this tool only needs to be run at release time...
> 
>     There's no need to be fascist about keyword maintenance...

I pretty much agree with all of those points, as being good things
to have.  But possibilities that work only with a set of
"recommended", predefined keywords, e.g. for the package system,
should use a different file-header keyword from `Keywords:'.  You
want something different from what `Keywords:' has always been,
something that conflicts with its usage?  Fine, just add a new
file-header keyword for that.  Happiness all around.

However, just as we should not co-opt `Keywords:', so we should
not co-opt `finder'.  Finder works with `Keywords:' in a particular
way. It is fine to extend finder so that it does additional things,
for particular use cases or in particular environments (e.g., for
Emacs maintainers or for the package system), but what it does
with `Keywords:' should not be cannibalized for the new features.

Again, let it do those things with a new file-header keyword.
If some of the things finder will do are the same, then let it
do them with both `Keywords:' and the new file-header keyword.
IOW, to the extent that some part of the updated finder does not
conflict with the normal interpretation/use of `Keywords:', let
it be used for both.

Should be a no-brainer.  `Keywords:' ain't broke; don't "fix" it.
Feel free to add new features that do something different and
have a different motivation.  But don't bother `Keywords:' just
to implement what you need.  It's not hard for you to leave
`Keywords:' alone, for its original, more flexible, use cases.



  parent reply	other threads:[~2015-06-09 14:22 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-25 16:59 Adding a few more finder keywords Artur Malabarba
2015-04-25 18:51 ` Drew Adams
2015-04-25 19:23   ` Artur Malabarba
2015-06-08 14:56 ` Oleh Krehel
2015-06-08 15:37   ` Drew Adams
2015-06-08 15:43     ` Oleh Krehel
2015-06-08 16:20       ` Drew Adams
2015-06-08 16:15   ` Artur Malabarba
2015-06-08 16:19     ` Artur Malabarba
2015-06-08 16:27       ` Drew Adams
2015-06-08 20:59   ` Stefan Monnier
2015-06-09  4:39     ` Stephen J. Turnbull
2015-06-09  6:52       ` Oleh Krehel
2015-06-09  8:02         ` Artur Malabarba
2015-06-09  8:54           ` Oleh Krehel
2015-06-09 14:22       ` Drew Adams [this message]
2015-06-09 14:47         ` Oleh Krehel
2015-06-09 16:05           ` Drew Adams
2015-06-09 16:47             ` Oleh Krehel
2015-06-09 17:19               ` Drew Adams
2015-06-09 16:08           ` Stephen J. Turnbull

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=048d389e-cd09-468e-b93f-729505e56ab0@default \
    --to=drew.adams@oracle.com \
    --cc=bruce.connor.am@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    --cc=ohwoeowho@gmail.com \
    --cc=stephen@xemacs.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).