From: Artur Malabarba <bruce.connor.am@gmail.com>
To: Drew Adams <drew.adams@oracle.com>
Cc: emacs-devel <emacs-devel@gnu.org>
Subject: Re: Improving browsing and discoverability in the Packages Menu
Date: Mon, 20 Apr 2015 20:49:01 +0100 [thread overview]
Message-ID: <CAAdUY-+DOUhF-118ZqNAgj8yGj09gJFBDqCPNaLjqBkQfqw3bw@mail.gmail.com> (raw)
In-Reply-To: <ff2f56fe-414e-43ad-be03-750a22abfd77@default>
2015-04-20 19:17 GMT+01:00 Drew Adams <drew.adams@oracle.com>:
> (Sure wish you would send your emails as plain text, BTW.)
Haven't figured out how to that on my phone yet (so I'm switching to
the laptop just for you ;-). If it's any consolation, your pre-filled
emails look terrible on my phone too. :-)
> I for one (perhaps the only one) would object to that. There is no
> reason to "warn" users about libraries that are not doing anything
> even potentially wrong - and that includes using `Keywords' in a
> file header that you might never have heard of.
> [...]
> The problem is that you are referring to "the keywords system".
> And you are trying to shove it into a particular use case.
>
> File-header fields (keywords) that have been around for quite
> some time should be left as is (and this should have included
> `Version'). You can add whatever other fields you like, and
> make their use as restrictive or helpful with as many warnings
> or preventions as you like. No problem.
Thanks. I do see your point in all of that.I just wish we had some way
to polish things out a little bit.f This not even for the sake of
package.el, but for the keywords as a whole.
For instance, there are 3 different mode-line keywords: mode-line,
modeline, and mode line. The last two contain a single package each,
both of which will not show up if the user looks for the "mode-line"
keword.
A similar thing happens with `package' vs `packages', application vs
applications, buffer vs buffers, bookmark vs bookmarks, etc.
Not to mention a number of keywords which are just plain senseless
like: "$", "$date:", "/", "09:41:07", "2015/01/12", and ":".
These don't just affect the package menu. These also pollute the
finder keywords menu, and pretty much anywhere else they show up.
I understand a warning may not be the way of doing that, but it would
be nice if we could help developers standardize these a little. And
I'll appreciate further suggestions.
It's clear that whoever used "modeline" as a keyword simply didn't
know that mode-line is the commonly used one (and why should they
know, it's not in `finder-list-keywords'). And if they do (for
whatever reason) have the intention of using modeline instead of
mode-line, that's fine. I just want to avoid the accidental duplicates
by making developers more aware of the already existing keywords. I'm
don't want to prohibit duplicates or anything.
next prev parent reply other threads:[~2015-04-20 19:49 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-15 22:38 Improving browsing and discoverability in the Packages Menu Artur Malabarba
2015-02-16 2:25 ` Stefan Monnier
2015-02-18 16:23 ` raman
2015-04-18 11:26 ` Ted Zlatanov
2015-04-18 13:25 ` Artur Malabarba
2015-04-18 13:25 ` Artur Malabarba
2015-04-18 21:11 ` raman
2015-04-18 23:05 ` Ted Zlatanov
2015-04-19 1:20 ` Alexis
2015-04-19 3:16 ` Stefan Monnier
2015-04-19 4:03 ` Alexis
2015-04-19 16:14 ` raman
2015-04-20 1:57 ` Stefan Monnier
2015-04-19 16:12 ` raman
2015-04-20 1:22 ` Ted Zlatanov
2015-04-20 9:02 ` Artur Malabarba
2015-04-20 15:18 ` raman
2015-04-20 15:23 ` Drew Adams
2015-04-21 0:20 ` raman
2015-04-21 1:07 ` Drew Adams
2015-04-19 2:59 ` Eric Abrahamsen
2015-04-19 14:58 ` Drew Adams
2015-04-20 8:38 ` Eric Abrahamsen
2015-04-20 9:26 ` Artur Malabarba
2015-04-20 10:17 ` Alexis
2015-04-20 11:30 ` Artur Malabarba
2015-04-20 14:32 ` Drew Adams
2015-04-20 17:32 ` Artur Malabarba
2015-04-20 18:17 ` Drew Adams
2015-04-20 19:49 ` Artur Malabarba [this message]
2015-04-20 20:30 ` Drew Adams
2015-04-21 4:05 ` Tassilo Horn
2015-04-21 5:25 ` Drew Adams
2015-04-21 6:52 ` Tassilo Horn
2015-04-21 9:04 ` Eric Abrahamsen
2015-04-21 15:44 ` Drew Adams
2015-04-20 14:03 ` Eric Abrahamsen
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=CAAdUY-+DOUhF-118ZqNAgj8yGj09gJFBDqCPNaLjqBkQfqw3bw@mail.gmail.com \
--to=bruce.connor.am@gmail.com \
--cc=drew.adams@oracle.com \
--cc=emacs-devel@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).