Yes it does. Pretty much anything in emacs that uses a PTY for the subprocess is improved by this (process-connection-type does default to true, which makes it the default type for a process unless the developers explicitly opt in to it being a regular pipe.) It might have some benefits when the process-connection-type is nil, but I haven’t tested that extensively.
I’m planning on trying to upstream it once I extend it to work with the rest of the subprocess types for emacs. Currently, I’m not handling network and pipe subprocesses with the background thread.
I assume yes but I didn’t see this mentioned: is there still backpressure? I assume you don’t want the background thread to buffer data forever and make emacs OOM if the command runs too much faster than eshell can consume its output for too long.
Yes, this is still back pressure at the background output thread level. The nice thing about this though is it’s back pressure at a larger size instead of 1024 byte back pressure.
Eshell was always frustrating so I tend to always use ansi-term when inside Emacs, but even that one has issues because of how wonky the terminal is with evil-mode for me (difficulties escaping insert mode, or difficulties coming back into focus with insert mode).
Very cool patch and I hope others get use out of it.
Tried giving it a build, basically git clone ... && cd ... && guix shell --development emacs -- {./autogen.sh, ./configure, make}, but get this error here: https://pastebin.com/raw/7x1Q0AdF
Probably the first build that isn’t on a Mac ¯_(ツ)_/¯
And with that said, this is awesome! I haven’t the faintest idea how this part of the stack works and wouldn’t have known where to start, or even been able to recognize the fundamentals of what the issue was and how to approach it– there’s a kot of background and work in that commit! Are the benefits limited to MacOS, or generalizable to other Unix’s?
Promising! Knowing that works on 18.04 helos a bunch. I’ll take a another look when I have a second, and should probably roll back to upstream and make sure I can build that anyways :p
Very interesting! Process output latency has bothered me numerous times in Emacs.
Does your change also make M-x compile output faster?
Are you going to upstream your change?
Yes it does. Pretty much anything in emacs that uses a PTY for the subprocess is improved by this (process-connection-type does default to true, which makes it the default type for a process unless the developers explicitly opt in to it being a regular pipe.) It might have some benefits when the process-connection-type is nil, but I haven’t tested that extensively.
I’m planning on trying to upstream it once I extend it to work with the rest of the subprocess types for emacs. Currently, I’m not handling network and pipe subprocesses with the background thread.
I assume yes but I didn’t see this mentioned: is there still backpressure? I assume you don’t want the background thread to buffer data forever and make emacs OOM if the command runs too much faster than eshell can consume its output for too long.
Yes, this is still back pressure at the background output thread level. The nice thing about this though is it’s back pressure at a larger size instead of 1024 byte back pressure.
Eshell was always frustrating so I tend to always use
ansi-termwhen inside Emacs, but even that one has issues because of how wonky the terminal is withevil-modefor me (difficulties escaping insert mode, or difficulties coming back into focus with insert mode).Very cool patch and I hope others get use out of it.
Try https://github.com/akermu/emacs-libvterm, it’s much better than ansi-term.
Makes sense, the interop with evil mode is one of the reasons I use eshell over a different terminal emulator.
This change also speeds up ansi-term because that also uses a PTY to communicate with emacs.
I probably should’ve emphasized that more in the blog post originally, since it’s really improving subprocess output handling across all of emacs.
Tried giving it a build, basically
git clone ... && cd ... && guix shell --development emacs -- {./autogen.sh, ./configure, make}, but get this error here: https://pastebin.com/raw/7x1Q0AdF Probably the first build that isn’t on a Mac ¯_(ツ)_/¯And with that said, this is awesome! I haven’t the faintest idea how this part of the stack works and wouldn’t have known where to start, or even been able to recognize the fundamentals of what the issue was and how to approach it– there’s a kot of background and work in that commit! Are the benefits limited to MacOS, or generalizable to other Unix’s?
hmm, i just tried it on a ubuntu (18.04/bionic) machine, and seems to compile and work just fine.
Promising! Knowing that works on 18.04 helos a bunch. I’ll take a another look when I have a second, and should probably roll back to upstream and make sure I can build that anyways :p
Definitly is that commit, but it looks like they’re on the case c:
oh, i am really sorry there were minor modifications that i had to make, for that to work, specifically:
lemme know if you care about the diffs etc.
Oh, no problem! C just ain’t something I’m familiar with yet, and those diff’s will be upstream soon enough c:
I was wondering if this patch would make vterm output faster as well?
see https://lobste.rs/s/zd8jh7/living_eshell_dream_reduction_latency#c_q9xkt7