Re:Eshell as a main shell
by uluyol on Wednesday May 09, 2018 @12:51AM
(#17027475)
A lot of this seems similar to what plan 9's acme editor provides. You can run shell commands anywhere and their output is written to a new window. You can also run an interactive shell in a window and edit the text directly. I have been using this as my main dev environment for a while now and I just hate when I need an application that tries to use fancy terminal features with no fallback. Russ Cox has a good video showing how acme works: https://research.swtch.com/acme
[ Parent
| on HN ]
Those ACME features are based on Oberon.
On Oberon the whole OS works like that.
http://www.progtools.org/article.php?name=oberon§ion=com...
Plus it had the benefit of being implemented in a GC enabled systems programming language.
Maybe one day we could get ACME re-implemented in Go, running on something like "Goberon System 3", specially now that it finally has plugin's support, essential for how Oberon implemented UI commands.
I find that the regular `M-x shell` functionality gives you a reasonable approximation of the acme `win` workflow. The 'shell' buffer acts mostly like a regular text buffer, so you can easily move around, edit things, and cut-n-paste.
Pressing <enter> sends the current line of buffer text as command-line input.
I love and use acme too.
I hate when I hit some tool that still emits color ansi escapes even with TERM=dumb (phabricator arcanist, I'm looking at you).
Do you know if there is a simple wrapper that swallows ansi escapes but yet preserves the illusion the output is a tty (so that the wrapped command doesn't freak out?)
EDIT: I'm having some success with `unbuffer -p arc diff | perl -pe 's/\e\[?.*?[\@-~]//g'` (part of `expect`) but interactive prompts are not flushing the line correctly in acme's win
I managed to silence arc by aliasing my arc command to be = `arc --no-ansi COMMAND`
See http://no-color.org for more.
I'm happily not using arc for work anymore.