emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Changes for emacs 28


From: TEC
Subject: Re: Changes for emacs 28
Date: Fri, 11 Sep 2020 14:07:22 +0800
User-agent: mu4e 1.4.13; emacs 27.1

Hi Ricardo,

In your reply I found something that I think really sums up my experience well.

Ricardo Wurmus <rekado@elephly.net> writes:
> [Doom and Spacemacs are good] because
> people can dive right into the interesting stuff without getting bogged
> down at the worst time: while learning something that is completely
> foreign to them.

For me, and for others, I feel that this is the crux of the matter.
All my comments about Doom's modules allowing me to 'just get started'
are in this vein, as are completion, linting, etc.

I think Emacs is tremendous (no surprise to anyone reading this 😛,
I'm sure). However, I fear that there are many  people who /would/
discover how brilliant Emacs is ... were it not for this initial hurdle.

I think there are essentially three categories of changes we'd likely
want in trying to make Emacs less off-putting:
 1. Look - theme, splash screen, etc.
 2. Feel - completion, linting, etc.
 3. Defaults - changes to functionality already present, e.g. setting
    utf8 at the default text encoding

I hear those long-time users who have years to decades of configuration
built on Emacs' current behaviour, I appreciate your need for Emacs'
behaviour to stay consistent.

I can't see any simple solution which I imagine makes both long-time
users, and 'just seeing what this is' newcomers happy --- but that
doesn't mean there isn't a way forward.

* Some potential avenues to investigate:

The most promising idea I've heard is to come up with a clean, and
elegant way to allow for users to easily select from/combine different
Emacs experiences.

Profiles are a nice idea I think. They sound good for easily selecting
from a selection of 'presets', but perhaps aren't so good when it comes
when use cases blur (as they often do) and one wants to combine
functionality.

Modules are a nicer approach in this respect, in that you partition
common/related functionality into discrete bundles that can be used (or
not) as one wishes.

Another approach may be to essentially delegate this to 'downstream
distributions' like Doom or Spacemacs, by making them trivially easy for
the user to chose to use --- as opposed to having them be something that
the user has to independently discover/investigate/install.

The reason I suggest this is because:
 - a lot of commonly used packages which help shape Emacs into what I
   consider a more approachable UX are only in MELPA
 - these packages seem to generally be frequently updated, and I fear
   that baking them into Emacs will result in a bifurcation of
   versions/features/development. This also opens up the annoyance
   backporting bug fixes etc.

That said, I for some 'key' aspects of functionality like code
completion, I feel that it would make sense to have something like
Company baked into Emacs.

Hopefully this can provide some food for thought,

Timothy.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]