[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: |
Wed, 09 Sep 2020 14:26:43 +0800 |
User-agent: |
mu4e 1.4.13; emacs 27.1 |
Richard Stallman <rms@gnu.org> writes:
> That describes how it felt, subjectively, to you.
> That's a consequence of some concrete things about DOOM,
> I am sure -- but I have no idea what those concrete things _are_.
I appreciate the difficulty.
Unfortunately, as you point out this is a single subjective impression
of qualitative factors that are generally hard to pin down.
I welcome any attempt to corral my jumbled thoughts into something
actually useful, and will try my best to communicate which factors had
the most impact on my experience :)
> Can you describe even a few of the concrete differences of DOOM that
> made it so easy for you? I suggest not aiming for completeness,
> but rather mentioning the ones that are most important.
>
> That would be the information we might perhaps draw concrete lessons
> from.
>
> > IMO the most significant factor is that Doom allowed me to "just get
> > started" with the tasks
>
> Could you describe a few of those tasks, and what would have been
> hard about them, which DOOM made easier?
So, the task that got me started was using R, notebook style
--- i.e. R + Org.
This is what the process was like with Doom:
- run the one-line install script
- opening the config dir is prominently listed (with the associated
keybinding) on the 'home'/init/welcome buffer
- I find three files, well commented, describing what they are and what
to do with them
- I see ESS listed in init.el as a 'statistics' module under :lang
C-c c k pulls up the documentation on it (as I am told by comments at
the start of the file) and I see that it does indeed add support for
R. I uncomment the line and run 'doom refresh'
- Excluding install time, I think this took me ~5 minutes
At this point I have:
- Support for R
- Completion via Company
- Linting via Flycheck
- A fuzzy searcher for commands I don't know with Ivy
- When I pause on keybindings (what was that next part?)
which-key pops up.
- An editor that appeals to my 'flashy modern' sensibles
+ A UI/theme more inline with Atom/VS Code/etc.
+ Git status gutters
+ A modeline that tells me nice stuff like
To get here all I needed to know is that I wanted to use R,
notebook-style with Org, hoping to see the 'editor features' that I
missed in JupyterLab.
In order to get to this same point with Vanilla emacs I'd need to:
- Identify ESS as the package for R (quick search online)
- Work out how to install packages
+ come across conflicting answers on the web. use-package? straight?
package-install?
- I'd try an R block in org, and get told:
"No org-babel-execute function for R!"
+ what's this? how do I fix it?
- Once I get that working - where's the completion I was hoping for?
+ another internet trip...
- Etc.
Unfortunately I can't imagine this taking a comparable length of time,
or being nearly as easy.
I'm not sure that Emacs can embrace the behaviours that people who have
primarily experienced the likes of VS Code/Atom/JetBrains/Sublime/etc.
will be looking for, without compromising the experience that long-time
users have come to expect. Perhaps the way forward may be to treat
standard Emacs as a core and prominently offer 'distributions' of Emacs?
Possibly the best thing about Emacs IMO is its versatility. I suspect
that trying to be all things to all people could be a futile task,
but maybe Emacs can lean into this and say to a new user:
- if you're looking to use Emacs like X, here you go
- looking for Y instead? Then just use/do this
- actually want Z? Here's that option...
This seems like something where some selection of:
- modules
- profiles
- embracing distributions
could improve the situation.
Anyway, that's just my thoughts. Hopefully they're of some interest.
> I'm also curious about how why you decided to change from DOOM
> to standard Emacs?
Erm. I haven't switched from Doom to standard Emacs. Apologies if I
incorrectly implied that somewhere.
My journey was (excluding pre-emacs):
Spacemacs (for a brief period) → Vanilla (for mere hours) → Doom
[aside: why I'm still on doom, http://ix.io/2wUw]
I feel that for the purposes of this discussion, it would have been nice
if I'd spent longer trying to get vanilla/standard Emacs working --- but
I didn't. However I'll still offer what I can in the hope that it may be
useful.
All the best,
Timothy.
- Re: "modern" colors Re: Changes for emacs 28, (continued)
- Re: "modern" colors Re: Changes for emacs 28, Ergus, 2020/09/12
- RE: "modern" colors Re: Changes for emacs 28, Drew Adams, 2020/09/12
- Re: "modern" colors Re: Changes for emacs 28, Arthur Miller, 2020/09/12
- Re: "modern" colors Re: Changes for emacs 28, Ricardo Wurmus, 2020/09/12
- Re: "modern" colors Re: Changes for emacs 28, Arthur Miller, 2020/09/12
- Re: "modern" colors Re: Changes for emacs 28, Dmitry Gutov, 2020/09/12
- Re: "modern" colors Re: Changes for emacs 28, Alfred M. Szmidt, 2020/09/12
- Re: "modern" colors Re: Changes for emacs 28, Dmitry Gutov, 2020/09/12
- Re: Changes for emacs 28, TEC, 2020/09/08
Re: Changes for emacs 28, Richard Stallman, 2020/09/08
Fwd: Re: Changes for emacs 28, Göktuğ Kayaalp, 2020/09/08
Fwd: Changes for emacs 28, Göktuğ Kayaalp, 2020/09/08
Re: Changes for emacs 28, Ergus, 2020/09/10
- Re: Changes for emacs 28, Caio Henrique, 2020/09/10
- Re: Changes for emacs 28, Eli Zaretskii, 2020/09/11
- Re: Changes for emacs 28, Robert Pluim, 2020/09/11
- Re: Changes for emacs 28, Eli Zaretskii, 2020/09/11
- Re: Changes for emacs 28, Robert Pluim, 2020/09/11
- Re: Changes for emacs 28, Eli Zaretskii, 2020/09/11