Unlike TerminalView it also supports Windows and its various shells (cmd.exe, powershell.exe, wsl.exe).

Why?

There's no excuse for the file sizes to be this dramatic, apart from outright laziness

https://www.imagemagick.org/Usage/anim_opt/#removedups

And right above this paragraph is a dope technique to use overlays and a non-dispose of frames to make the gif only change which pixels are being updated (like a video format I guess).

This might sound pretty complex, and sure, That's fair, we are coming up on 30 years since an update to the format. People just generally use videos these days for desktop recording since they're more suited for the job, at a even lower filesize

Out of curiosity, any idea what formats you'd choose to embed in a Github readme? Videos or otherwise, I'm not sure which play well when embedded, and are GitHub allowed, etc.

[1] https://github.com/nbedos/termtosvg

I also exclusively do SQL in Emacs, and dataframes and plots in R, and tailing log files, and no end of other stuff, and if there's ever anything, no matter how little, that bothers me about interacting with these things, I can write code to make it behave exactly how I want it to.

The only thing I _don't_ do with terminals inside Emacs is SSH into a screen on a server that's already running Emacs, but even then, little jobs are generally easier with tramp, which makes it transparent when you're editing stuff and issuing commands remotely.

Unfortunately, some programs treat the teminal emulator as a screen with fixed positions to put coloured characters in. And this breaks down when your terminal is a text buffer.

It's quite useful and convenient.

That said, I agred that alt-tabbing isn’t hard, and a tiling window manager makes it even easier (less window administration).

Its annoying with a bunch of programs open. I prefer to have a keybind to get the terminal with dropdown, akin to Guake [1]. This is possible with iTerm2 as well. Also, Expose-like or tiling window feature of a desktop comes in handy. For that, I can recommend Amethyst.

[1] http://guake-project.org/

It will never replace my "main terminal" but makes my life a little bit easier.

This is documented here to be copying the Linux kernel's built-in terminal emulator and so compatible with the "linux" terminfo record. The Linux kernel's built-in terminal emulator, however, supports the 16 CGA colours, and nowadays also recognizes the SGR sequences for both ISO 8613-6 Indexed and Direct colour.

The underlying terminal emulator is, in its own documentation, moreover, documented as emulating a VT100, which is a rather different beast to the Linux kernel's built-in terminal emulator in several ways. But this is the usual mis-use of that designation, that Thomas Dickey points out, because VT100s had no notion of multiple colours at all.

So it's not supporting everything that I would expect, and it's not equivalent to either of the terminal types that its doco says that it is.

I haven't found what it does for DECFNK and whether it even generates it, let alone supports modifiers. That's another very common expectation nowadays.

I used to need to hop between many tools and windows and I found that, similar to the doorway effect, this switching had the chance to distract me from what I was doing. That split second of switching contexts was enough to let my mind drop the balls it was juggling and think about something else.

So in my chosen tool I now have the terminal, editor, debugger and database as tabs or tool panes. It has helped my concentration immensely as I am not switching contexts to a new window and my focus remains on the task.

I go to great lengths to stuff tools into the platform I use in order to reduce switching, even down to making tool buttons for things like enabling ssh tunnels needed for remote debugging, compiling assets from a button and so on. For everything I can't stuff into a button, shortcut or tool pane, there is the terminal pane. Learning my tool thoroughly has been a real boon for my working efficacy.

Launch a terminal.

Start Emacs.

M-x term

Run vim.

That got me.

[1]: https://github.com/magit/magit

Run ed.

This would give you the ability to use any REPL as (something close to) a Jupyter-style notebook. Sure, curses apps wouldn’t work very well... but why are you running curses apps inside an IDE?

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.)

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.

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. :)

Plugins are written in Lua.

Appreciate the tip, though!

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.

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.

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.

One thing though - whats up with key repeat? It doesn't seem to be working at all .. (macOS, ST3 Build 3176) .. this kind of makes the whole thing unusable for me, personally.

Also its not processing any of my ~/.bash* scripts .. I guess this is by design since its not guaranteed to be a full-featured Term yet?

This can be Awesome, i3, bspwm, or anything out there.

You can also try using tmux or even gnu screen.

  $ size /usr/local/plan9/bin/acme
      text    data     bss      dec       hex   filename
    356886   14680   52332   423898   0x677da   /usr/local/plan9/bin/acme