Re: A proposal for a friendlier Emacs

[Alexander Adolf <alexander.adolf@condition-alpha.com>]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > As your config evolves, the next question everyone will be asking
>   > themselves is "custom.el or init file?"
>
> It is possible to use both -- so why do people believe they have
> to choose one or the other?

Apologies for not having been clear enough. The question is not either
or, but whether any arbitrary, usually small, set of (setq X) or
(face-spec-set Y) are better added to a hand-crafted init file, or done
via Custom (so they end up in custom.el). The typical advice users get
on Stackexchange and similar, is to choose either variant at will (or
randomly), and to version control their emacs.d directory with git.

What this shows is that (too much) freedom of choice early on in a new
user's adoption journey can be perceived as an obstacle (by new users).

>   > Here is what I observed: when I start adding a new class of use-cases
>   > (example: email), I start out with a single package, that does most of
>   > what I want/need.
>
> We use multiple definitions of "package" in connection with Emacs.
> Would you please say what definition you're using here?
>
> For instance, does "package" include Rmail?

Good point; 'package' is used in so many contexts, it's a fuzzy
term. Yes, I would refer to Rmail as a 'package', too.

>   > Within this config file, I keep the setting for each package in a
>   > different section (separated by comments).
>
> Could Configure do this automatically?

That was precisely my idea.

> Would that require additional data about relationships between various
> things?

I haven't done any experiments, but in my manually crafted configs, I
never had an issue with the ordering of sections. Sure, not everything
is autoloaded, and there's lazy loading. What about wrapping a package's
config in a with-eval-after-load, or making use-package a builtin?

>   > Again, in my ideal world, each package would be classified into exactly
>   > one main category (email, content completion, etc.). 
>
> In principle, I think this is a good idea.  However, think it should
> NOT be limited to ELPA packages.

Fully agree.

> Also, I have a feeling that users won't all agree how to classify
> packages.  I expect there will be overlapping categories that make sense.
> So I think we need to make provision for having one package
> that fits into multiple categories.  Perhaps by asking the user
> which category to think of this package in.
> [...]

Let the package author choose and, and only one category, and any number
of tags he/she wants to use to describe the package.

When a user installs a package from a package archive, the category
chosen by the author is presented as the default choice, and can be
overridden by the user.

Just my two cents anyway.


Looking forward to your thoughts,

  --alexander