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

Drew Adams <drew.adams@oracle.com> writes:

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

I disagree. Redundancy leads to misuse and under-use. And it's a pain to
parse. Using `Keywords:' for tagging sections is good because most files
need not be touched: they're already fine.

On the other hand, if we introduce something like:

    ;; Section: python

with a tight list of exclusive sections (a file can belong to only one
section), I'd be fine with that. The key here that it needs to be small,
with little room for misinterpretation. As I mentioned before, there are
more than 1000 unique keywords for 2000 packages. Having so many unique
keywords hampers their functionality.

But then again, being too restrictive with `Section:' would probably
lead to 800 packages filed under "convenience". That's why I think that
`Keywords:' are still better. We just need to select a group of keywords
that are deemed "important" and make it easy to see all "important"
keywords at once and browse them.


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

I don't see how defining a subset of "important" ~50 keywords among the
current ~1000 keywords in use is doing anything against the "more
flexible" use cases.

Basically, I want something like `finder-list-keywords' to work for all
packages managed by package.el as well. I think it would be a great
interface to complement `package-list-packages'. Maybe call it
`package-list-categories'. It currently has 36 sections and looks great.
I wouldn't mind changing my ace-window.el from:

    ;; Keywords: window, location

to

    ;; Keywords: frames, window, location

or even just

    ;; Keywords: frames

to conform to `finder-list-keywords' convention.



  reply	other threads:[~2015-06-09 14:47 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
2015-06-09 14:47         ` Oleh Krehel [this message]
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=87zj49kkff.fsf@gmail.com \
    --to=ohwoeowho@gmail.com \
    --cc=bruce.connor.am@gmail.com \
    --cc=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    --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).