
Emacs 26 Brings Generators and Threads - ingve
http://nullprogram.com/blog/2018/05/31/
======
Diobo1000
In all honesty, the main selling point of Emacs for me isn't just how
configurable it is but also how performant it is in different environments.
Since VSCode uses Electron editing feels sluggish, high ram and cpu usage is
expected, and there's a noticable latency between keypresses. While these may
seem like trivial issues, they actually negatively impact my typing experience
to a high degree.

I'm currently using the Doom-Emacs distribution for Emacs and everything is
working very well. I can use vim keybindings in addition to many other
customizations and improvements with very little time invested in actually
writing elisp. This is mostly because the developer of the distribution is
passionate and optimizes his configuration for modern languages so there is
very little needed to change.

If VSCode or any other text editor managed to provide a fast yet highly
configurable editing experience without draining my laptop battery instantly,
I would immediately switch. So far, none have been able to meet this
specification even though I have tried almost all of the common text editors.

I'm hoping a project like the Xi text editor might one day actualize my
desire.

~~~
Pimpus
> While these may seem like trivial issues, they actually negatively impact my
> typing experience to a high degree.

I don't think these are trivial issues at all. I do the majority of my
computing work in a text editor so it's important to me that it's as
performant as possible. Imagine if, in real life, there was a slight lag every
time you sent a "command" (e.g. pick up coffee). It would drive you crazy. And
yet a lot of developers think that lag is acceptable in software. (I say
"developers" because a lot of non-developers I meet complain about software
being frustrating to use, even if they may not consciously notice it is
laggy.)

People think I'm joking when I say this, but I'm so attuned to Emacs,
especially when I'm in a flow state, that I can actually feel when the garbage
collector kicks in. It totally throws me off. I have a bunch of optimizations
set up, like running GC whenever I tab out of Emacs or am idle for 5 seconds,
but sometimes I can still feel it. I hope Emacs makes some progress in this
area -- I hear there's a Rust rewrite in the works :)

> If VSCode or any other text editor managed to provide a fast yet highly
> configurable editing experience without draining my laptop battery instantly

This is huge for me. I basically work by grabbing my laptop and sitting,
standing, or laying wherever I feel like. I can't stand the idea of having an
"office". So I'm acutely aware of when an application is running down my
battery. Emacs is awesome in this regard because it has no noticeable energy
usage, which boggles the mind when I think about how powerful it is as
software. I honestly see no reason whatsoever to use anything else.

~~~
jackewiehose
>> While these may seem like trivial issues, they actually negatively impact
my typing experience to a high degree.

> I don't think these are trivial issues at all

I'm stunned that anyone would actually be OK with "a noticable latency between
keypresses" in text-editors. This might be still a thing if the whole desktop
is streamed on a slow network but it shuld be completely unacceptable for
normal text-editing.

(Unfortunatly I do have that problem sometimes with emacs (on cygwin) with
c++-files that are too large. But I won't dismiss cygwin.)

------
nathell
I think this bit is a piece of wisdom:

"I’m a firm believer that we should understand how things work underneath the
hood so that we can make the most effective use of at them. No program should
rely on the particulars of the iterator object internals for correctness, but
a well-written program should employ them in a way that best exploits their
expected implementation."

------
rusk
Here's what grinds my gears: That the cursor follows the visible buffer. It
would be nice to be able to scroll to another part of a file and then just
start typing and be back where I was ...

I mean I could understand if this was an efficiency thing to do with scaling
to large files due to a kind of a tiling memory model or something, but emacs
doesn't even do that!

It's not a huge deal I've learned to get used to using Ctrl+U-Space to get
back to where I was.

I read somewhere that somebody tried to implement what I'm talking about but
never really got around to trying it cause it seems a little half-baked.

~~~
rudolfwinestock
The cursor stays in the viewport because, deep down, Emacs still thinks that
it's outputting to a 1970s-era ASCII terminal.

See this [https://www.facebook.com/notes/daniel-colascione/buttery-
smo...](https://www.facebook.com/notes/daniel-colascione/buttery-smooth-
emacs/10155313440066102/)

“Internally, Emacs still belives it’s a text program, and we pretend Xt is a
text terminal, and we pretend GTK is an Xt toolkit. It’s a fractal of
delusion.”

For years, James Gosling, author of the first version of Emacs that ran on
Unix (the ancestor of GNU Emacs), has been begging people to stop using Emacs.

Emacs is in a race, not against Vim, but against VS Code and Atom for which
editor can be more easily customized. In the long run, it doesn't look good
for Emacs.

~~~
jonathanstrange
For me as a daily Emacs user this sounds like another "editor war" rant. I
neither find Emacs hard to customize nor do I think it has any substantial
limitations other than the ones that are based on my own lack of knowledge.
It's always fair to compare it to Vim, but I don't think it makes much sense
to compare it _in general_ to VS Code or Atom.

One major reason for me to use Emacs and not newer software is that it is not
only cross-platform but also gives some confidence that I will be able to use
it in twenty years from now on a new platform. The same could be said about
Vim. In comparison to these two, newer editors sometimes appear too ephemeral
and fragile to me. (Then again, I used to use BBedit on the Mac and just found
out that it's still around! What a nice surprise!)

~~~
BooneJS
Emacs is compared to vim because both can be run in a terminal on a remote
machine, not because it’s the JS-editor-of-the-month. There’s a fairly decent
chance I’d switch away from vim if I ever had a job where I could edit code
locally.

~~~
krylon
Emacs has TRAMP, which allows transparent access to files on remote systems
using a variety of protocols (but mostly ssh/sftp).

~~~
kqr
...and if you haven't given TRAMP an honest shot, you definitely should. I
took the leap not too long ago, and it is absolutely amazing. Whenever I can't
access a host using TRAMP (does happen, but very rarely), I put off whatever
task I have to do on that host for a very long time.

The fact that TRAMP lets you open files on remote systems in and of itself is
fairly mundane. What makes it really cool is that it works seamlessly also
with dual-pane dired, and just about anything you do in Emacs. It turns remote
filesystems into local ones.

Being able to, in my regular file manager (I like Sunrise Commander), treat
any combination of remote and local filesystems as though they were local, is
a huge productivity boost.

~~~
technofiend
It's this sort of thing that when I first saw it on Apollo's Aegis and again
later on Plan 9 it was so obviously useful I figured it would just be
_everywhere_ in no time. At then Sun touted "The Network Is The Computer (TM)"
and I was like here it comes! But it hasn't quite panned out that way.
Considering the number of viruses and ransomware perhaps that's a good thing
but it would be cool as hell if I had shared name spaces with my wife, mother,
sister, etc rather than the artificial constraint of mapping into Facebook or
Google Photos (for example) to share a photo album.

~~~
samatman
Not that it's the /correct/ solution, but Keybase does a good job of providing
that shared-directory experience, and the free tier is pretty roomy.

Not affiliated, just getting good use out of it.

------
pilif
Seeing generators and threads being mentioned in the release announcement of a
text editor feels a bit... strange.

Then again, Emacs is closer to a LISP toolkit for building text editors than
it is a text editor, so I guess it's not so strange after all.

~~~
pjmlp
Emacs is an OS written in Lisp, with a text editor as sample application. :)

~~~
signal11
Also if you require good keybindings in the sample application, there's always
viper :)

~~~
zaphar
Evil mode is far far better than viper. Do yourself a favor and switch today.

~~~
FPGAhacker
To that end I like spacemacs. But it did incur enough of a startup penalty
that have have shifted back to vim.

I oscillate between them and vscode. I don’t use vim bindings in vscode
though.

~~~
xfer
Run it in daemon mode. startup time is not a thing for emacs.

~~~
FPGAhacker
It's not stable enough for me. Well, my plugins aren't. I need to be able to
reset state periodically.

Plus, I like to have separate instances of emacs with different groups of
files from separate but related projects. I end up with a zoo of buffers
commingled in daemon mode. It just doesn't fit how I work.

I wish it had an image based startup scheme... freeze an image of emacs after
init is done.

~~~
harrygeez
What if I tell you that you can? :) You can unexec Emacs at its current
working state and it will output a new executable. Startup is close to
instant!

~~~
FPGAhacker
Can't seem to figure out how to do it. I can only find passing references to
it.

------
KirinDave
This is cool, but it's too bad folks here don't seem to have kept up with the
evolution of iteratees/enumerators and free monadic computations
(conduit/pipes/streaming) that other languages have pushed forwards as
evolutions of the generator ideal.

The net result for common iteration ops is quite nice, and has options for
reasonable optimizations in the world of lisp where macros are real.

~~~
chriswarbo
I thought the natural "successor" to generators was delimited continuations,
rather than iteratees or free monads/algebraic effects. Do such streaming
concepts map well to eager, imperative code? I've only encountered them in
Haskell, where laziness makes stuff like co-induction/recursion trivial.

~~~
KirinDave
Certainly for conduit the laziness sort of goes away since you _must_ sink a
source and unless you do that to some observable effect the entire result
disappears and no work is done at all.

But certainly iteratees as an independent went out of fashion when conduit and
pipes came on scene.

------
Theizestooke
Anyone know when the Windows builds will be available for download?

~~~
rusk
I got it from here:
[http://alpha.gnu.org/gnu/emacs/pretest/windows/](http://alpha.gnu.org/gnu/emacs/pretest/windows/)

It works flawlessly. I just dropped it (26.1) in on top of my existing setup
and had to do nothing else and I'm working away on it right now.

When I was downloading at least, I had to download it and the dependencies
separately. The README says there should be a unified zip-file but it wasn't
there at the time.

Had some issues with Windows 10 refusing to merge the directories from the
deps package so had to drop to a cygwin shell but it actually worked quite
well even without the deps.

~~~
sympodius
Flyspell in Emacs 26.1 seems to require a version of Aspell that is not
officially available for Windows. I might need to put off the upgrade until I
can attempt to compile a newer Aspell for Windows myself.

"Error enabling Flyspell mode: (aspell release 0.60 or greater is required)"

~~~
sympodius
In case anyone else was facing this problem (and isn't too committed to Aspell
as a backend for Flyspell), the version of Hunspell from ezwinports[1]
(version 1.3.2 at time of posting) seems to be working with Emacs 26.1 on
Windows.

[1]
[https://sourceforge.net/projects/ezwinports/files/](https://sourceforge.net/projects/ezwinports/files/)

------
samatman
Does anyone happen to know why e-lisp iterators stop on a magic `iter-end-of-
sequence` instead of on `nil`? That doesn't seem Lispy.

~~~
dang
Probably because the sequence might contain nil as an element, and you don't
want to short-circuit the iteration when that's the case.

For the same reason, it's the usual thing in Lisps to break on a sentinel
value (defaulting to EOF or similar) when reading sexprs from a file. In cases
where nil isn't a valid element, you can always specify nil as the sentinel.

------
jbirer
When is it getting it's own thread scheduler and bootloader?

------
cies
Weird place to vent. But I find it so interesting that Emacs in all it's
wisdom does not have (to me) acceptable undo behavior. Sometimes when I want
to undo a bit, it undoes so much that I have to do a few seconds of copy-
pasting.

~~~
todd8
The undo system is confusing if you are accustomed to undo/redo in practically
every other piece of software, but it does make sense (in its own kind of
way). See the documentation for the undo commmand[1]. Emacs undo is powerful
albeit with more cognitive load to use.

I have occasionally had to take over the controls for new emacs users while
pair programming because the undo, while logical and consistent, doesn’t work
as it does in other software. Each consecutive sequence of undo commands, once
interrupted by any command that is not an undo is considered itself to be an
atomic undoable change. This means that there is no need for a redo command,
just stop undoing and the last undo sequence can be undone. Because emacs has
a large undo limit you can keep undoing even past sequences of undos back to
the original edit points of the file’s history.

That probably made no sense if you haven’t already mastered it, but another
way to think of it is that edits and undos produce a branching tree of all the
history of changes being made to the file. The entire tree of changes can be
navigated with one command (undo) because that command makes a traversal of
the tree, kind of like a post-order tree traversal. This is sufficiently
confusing in practice that seeing the nanigation through the tree via the
popular undo-tree emacs package helps a lot. I use the undo-tree command when
I want to get to a version of the file not on the current main line of edits.

[1]
[https://www.gnu.org/software/emacs/manual/html_node/emacs/Un...](https://www.gnu.org/software/emacs/manual/html_node/emacs/Undo.html#Undo)

~~~
nerdponx
Vim also has an undo tree, but still manages to retain a sane user experience.

Not that Vim is any paragon of UX design. The point is that you can have a
powerful undo system without breaking user expectations.

~~~
LukeShu
> Vim also has an undo tree

There is an undo-tree implementation for Emacs (based off of Vim), but the
default undo described above isn't an undo-tree.

------
VikingCoder
I love the Emacs OS, but I'm just not thrilled with the editor that comes
default with it. Has anyone ported Visual Studio Code to run on Emacs OS yet?

~~~
FPGAhacker
All jokes aside, is it the ui if vscode that you prefer? I have a hard time
nailing it down, but aside from configuration, I do like vscode.

I might use it more if we weren’t stuck in an old version of rhel at work.

~~~
harrygeez
The dream is to have an Emacs with a modern UI like VSCode

~~~
FPGAhacker
I think your best bet would be to start with vscode and work toward what you
like about emacs.

For me, the only thing emacs has going for it are the plugins. If I could get
the plugins I use in VSCode I'd never look back. Mainly this comes down to
CIDER. But a lot of people have put person-years of work into cider. And it's
hard to imagine them embracing vscode.

Rather than porting plugins or making an elisp interpreter, if I were
passionate enough about it, I would look for a path to being able to run a
bridge (as a vscode plugin) to a headless emacs.

I have no clue how that would be done, but If I chose to believe it was
possible, I would try to write an network based API to emacs as an elisp
plugin to start, enabling other front ends as neovim does.

