Re: Changes for emacs 28

[Ergus]

Hi:

My point actually goes in the opposite direction. I don't want to add an
extra layer of abstraction, a fork, a new distribution (starter kit),
external dependencies to do things that vanilla emacs is totally capable
to do with probably less than 100 lines of configuration... but hidden
in our old syntax/names/bindings, unfamiliar lisp, and long and
sometimes too technical documentation.

The idea is to bring what we already have in vanilla but disabled, no
long starting times, extra hacks/functions or complex things to attract
new users coming from VSCode, Sublime or Atom.  



On Mon, Sep 07, 2020 at 05:31:48AM -0400, Boruch Baum wrote:
> On Mon, 7 Sep 2020 00:20:08 +0200, Ergus wrote:
>
> > There will be never an agreement about changing defaults with long
> > ...
> > So what if:
> > ...
> > Does this makes sense?
>
> Debian (and possibly other downstream projects) liberally change
> defaults and add packages to their default version of emacs, so your
> idea might meet a more enthusiastic reception somewhere in some
> downstream project that caters more specifically to the user-base to
> which your proposal is aimed.
I thing that we should a attract a little bit of everything; not only
lisp hacker. In my personal experience the Starter_Kits do too much and
increases the configuration complexity much more than the benefit they
bring. Specially because of the external dependencies and trick to group
them while supporting different emacs versions.

> In the case of Debian, that project may have already started moving in
> the *opposite* direction; they culled many small debian-specific tweaks,
> and removed packages from their 'vanilla' default version of emacs. On
> the other hand, they've increased and somewhat standardized native
> package-manager support for many third-party packages that most users
> get MELPA or other third-parties.
I actually never understood why Debian adds melpa-elpa packages to their
repos as their update sycle is veeeery slow... but this is another
discussion.

> Communicating with people at the following links might help advance your
> proposal:
>
>  https://github.com/bbatsov/prelude
>
>  http://wikemacs.org/wiki/Starter_Kits
Actually no, because they support (as I said) add too many complexities
layers, external dependencies and custom configuration sets with
personalized packages (like spacemacs layers) while modifying completely
the emacs bindings and sometimes breaking the integration with internal
emacs features like package-list. I want to bring the best we can with
what we have but with the simplest possible configuration and only with
internal features.

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.


> --
> hkp://keys.gnupg.net
> CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0