Yeah, this is exactly how the emacs `shell` mode works, and it's fucking awesome + completely addictive.

The only bad thing about it is emacs is so shit-ass slow at rendering text that I have to drop back to a normal shell for commands that spew a bunch of shit (like maven, ugh).

It's one of the can't-live-without-it things that's keeping me on emacs.

(Also how dumb is it that a text editor is slow at rendering text? Emacs is amazingly flexible, but the implementation is just junk. I dream of an editor w/ the speed & implementation quality of Sublime, with the flexability of emacs, that'll still run in a terminal. And a pony. I want that too.)

* dream of an editor w/ the speed & implementation quality of Sublime, with the flexability of emacs, that'll still run in a terminal. And a pony. I want that too.)*

And configurable in language that can also be used outside the editor (unlike vimscript, elisp), it could be js, python, scheme, lua, I don't care ;)

JS or Python being the most appropriates IMO.

Not sure what you mean about elisp here. Provided you aren't doing anything super specific to emacs, most lisps can actually move around quite easily.

Though, I have a somewhat irrational dislike of python. JS I accept, but most of the ecosystem has caused me to greatly question our profession. :)

Try micro: https://github.com/zyedidia/micro

Plugins are written in Lua.

Do you know Kakoune? I've used a month and like it. Fast, lean, work with other unix tools well, extend by sh,

Never heard of it. Initial thoughts: Very vi-inspired. Snappy on small files at least. Terminal only? Is it easy to extend? Anything comparable to emacs "shell" mode?

Appreciate the tip, though!

> Terminal only?

Yes, but there's a GTK proof of concept: https://gitlab.com/Screwtapello/kakoune-gtk

> Anything comparable to emacs "shell" mode?

No, it's design goal is to be just an editor, things like shell mode are left to something like tmux or a tiling window manager.

> Is it easy to extend?

Yes, but not in the same way as emacs or vim, it's very much built around the unix as an IDE philosophy so it makes interacting with external tools easy through shell scripts.

As a sibling post points out, you are basically discovering what many people come to love about emacs. I've even taken to loving eshell because of its transparent integration with remote filesystems using TRAMP. Add in the ability to redirect output of a command to a new buffer that you can then treat like any other text file, and things can be a ton of fun.

Once you get even slightly addicted to this, take a peek at org-mode and find an environment that can already compete with jupyter in pretty much every way. All without a giant json blob backing it, so that reviewing your changes can stick within your current version control world.

Program like iPython doesn't work in serial-terminal. The simpliest reason is that it needs the ability to go back to the previous line to allow multi line editing.

Input in a text-buffer-backed system usually involves a "baked" line discipline where the text editor isn't submitting individual characters to the process as you type them, but rather holds onto your input as regular text, allowing you to edit it as you please, until you do something to "commit" it as input to the program—at which point it becomes available all at once on that program's stdin.

In some editors with shell support, this just happens when you type a newline; but in others, even newlines are treated as ordinary text, and you have to press Ctrl+Enter or somesuch to submit the (multi-line!) command.

In Plan9's Acme editor, for an interesting example, there is no shell mode as such; rather, in any buffer, you can make a text selection, and then middle-click that text selection, and it will feed that input to the stdin of whatever forked interpreter process is configured for the buffer (usually determined by the buffer's filetype); and then the output from the stdout of the program will be inserted in the same buffer, just below your text-selection; or, if you middle-click while holding shift (I think?), it'll replace your selection.

In other words: you don't rely on a REPL for multi line editing, because that's what text-editors are for! :) Your REPL can see your editor as a dumb serial terminal—most REPLs gracefully degrade in such situations.