unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: bruce.connor.am@gmail.com
Cc: emacs-devel <emacs-devel@gnu.org>
Subject: RE: Improving browsing and discoverability in the Packages Menu
Date: Mon, 20 Apr 2015 13:30:48 -0700 (PDT)	[thread overview]
Message-ID: <dd2e60ea-09f7-41ce-8f9c-44592323d460@default> (raw)
In-Reply-To: <CAAdUY-+DOUhF-118ZqNAgj8yGj09gJFBDqCPNaLjqBkQfqw3bw@mail.gmail.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 ;-). 

Thank you.  (And I'll bet I'm not the only one who appreciates it.)

> If it's any consolation, your pre-filled emails look terrible on
> my phone too. :-)

If it's any consolation, they're not even prefilled.  I do it myself.

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

I would say to concentrate on what package.el needs.  And in particular,
to consider having it do whatever it thinks helps it, but in its own
header keyword (field), not in `Keywords'.  IOW, start clean, from
scratch, and impose any rules and checking you want.

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

Yes, it's a bother.  But there is no way to know what is a typo or
negligence and what is intentional difference, e.g. required by some
particular code or context.

That's why I suggest that you start out with a new, fresh field,
which you announce as pretty much dedicated to package.el and which
will be controlled by it.

With that announcement, you are free to ignore or correct or raise
an error for anything that doesn't fit the mold.

And with a little encouragement from such checks (e.g. errors),
library authors will learn to DTRT.

My only point was that it is not wise to try to usurp `Keywords'
for this.  Too much history, too long.  Too much out there already,
at least potentially, in the form of various usages and expectations.

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

See above.  Hands off `Keywords' and you're free to do whatever
you think helps in this regard.



  reply	other threads:[~2015-04-20 20:30 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
2015-04-20 20:30                     ` Drew Adams [this message]
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=dd2e60ea-09f7-41ce-8f9c-44592323d460@default \
    --to=drew.adams@oracle.com \
    --cc=bruce.connor.am@gmail.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).