unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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.



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