Ask HN: What do you love/hate about terminals? Would you change them? - terminal-survey I'm part of a small group that is working on a new set of protocols for terminals and shells, in order to move terminal handling out of the kernel as much as possible, and to replace the huge organically grown mess of ANSI escape sequences, terminfo databases, and so on.
I'm posting this from 34C3, where I'm asking people the same questions:
- What do you love about terminals?
- What do you hate about terminals?
- If you had to build one from scratch, how would you do it?
If you do not wish to answer in public, you can also write a mail to 34c3-terminal-survey at posteo dot de.
[I'm posting from a throwaway account because my Github links to the work that we have started on this, and I don't want to bias the survey by having you look at it before answering.] <comment><USER3> Fix scrollback. Sometimes I run a command and it has 50,000 lines of output. Either I don't care about the output — in which case I should be able to click to fold it up and be able to see my history before that one command — or I do care about it, in which case I want every scroll, search and export operation that a full-fledged document editor would have.

In either case, UI latency shouldn't suffer, scroll bars shouldn't become unusable, my scrollback history before that one command shouldn't be thrown away — Mathematica notebook style, as another commentator suggests, might work well here.

<comment><USER4> I'm not sure I understand; if you don't care about the output then send it to /dev/null. If you do care then pipe it to an editor. A terminal is not a text editor (I mean, I suppose it could be, but that seems like a rather large scope change.)

<comment> terminal-survey I think the problem is that you only know if you care about the output after the fact. For example, if "make" runs through, I usually don't care about the output. But if "make" fails, then I want to read the error messages.

As I said somewhere else, we have a concrete solution in mind for implementing folding as GP describes.

<comment><USER4> I don't know that make is a good example here. This is a tool you use constantly, so I imagine you'd know to pipe std err if you wanted its output. We seem to be talking about turning the terminal into a full blown editor (when we already have editors...) to satisfy a rather limited use case of 'oops, guess I have to run that again."

But hey; your time to spend :)

<comment><USER5> > We seem to be talking about turning the terminal into a full blown editor > (when we already have editors...) to satisfy a rather limited use case of > 'oops, guess I have to run that again."

That seems like an incredibly _common_ use case to me. It's common for a command to have a lot more output than I originally expected, and when it happens, I usually want to examine that output in detail. It would be great to retroactively be able to open captured output in a text editor, dump it to a file, pipe it to another tool, or collapse it.

I don't really want to _edit_ the output in the terminal, but it would be great to be able to say "oops, do X with stdout from that last command, and do Y with stderr".

<comment><USER6> FWIW, I also find myself wanting this.

</comment></comment></comment></comment></comment></comment><comment><USER7> I think that the autocomplete story is abysmal. Modern IDEs can tell me exactly what can follow after a certain piece of text, and even the best tab completion in terminals is limited, ugly, and text-mode for no good reason.

Some protocol for a _real_ dropdown rendered in the style of the OS, plus a standard data format that allows tool builders to specify options, their meanings and the kinds of allowed parameters in a structural way (much like doccomments in code), is direly needed.

If I type "git " I want to see "add" as an option, with docs in a tooltip as I navigate the options. When I "git add " I want to see a list of files that make sense to add, eg only files that can be staged right now.

I want this to be consistent across commands, I want any shell to be able to add support for this and I want any command line program to be able to add support for this.

<comment><USER8> > If I type "git " I want to see "add" as an option, with docs in a tooltip as > I navigate the options. When I "git add " I want to see a list of files that > make sense to add, eg only files that can be staged right now

With fish you can customize auto completion for individual commands with full color and tooltip support.

As a long time emacs user I want to believe that much of the required functionality for menus can be achieved via a text only format (either using standard escape codes or a markup language).

I completely agree that we need to be able to incorporate native UI elements in CLI programs.

Recently I stumbled upon Steve Jobs's presentation of Next computers and the initial UIkit. Jobs himself programmed without writing a single line of code, only using the built in interface builder. This was in the 80s, now the year is 2017 and we are still trying to remember the parameters for tar to extract files :)

I think the future should not rely on terminals where we extensively type and read. There should be drop-down menus for all applications, whether text based or GUI based. And these menus should be able to incorporate system-native dialogs e.g choose a file, choose a font etc.

And I'd want PostScript support to all terminals. Green on black mono fonts are cool but we have 4K displays now, come on! I want to be able to specify font, show images, draw charts etc. in a terminal window.

Frankly the future of terminals should look like Python Notebooks such as Jupyter. We need to be able to use cool fonts graphics UI elements and we need to be able to share our terminal "page" with others.

<comment><USER9> > Recently I stumbled upon Steve Jobs's presentation of Next computers and the > initial UIkit. Jobs himself programmed without writing a single line of > code, only using the built in interface builder. This was in the 80s, now > the year is 2017 and we are still trying to remember the parameters for tar > to extract files :)

I watch it regularly. Every time I see even seasoned developers takes weeks or even months for building even a simple application, whether it's frontend or backend, I wonder if we developers have a subconscious bias towards tougher way of building things instead of a much easier way. Visual basic comes into my mind. Visual basic is probably inspired by interface builder and had similar rapid development features. Where/when have we lost it?

> Frankly the future of terminals should look like Python Notebooks such as > Jupyter.

I second that. A terminal should ultimately do it's purpose. Not mimic a 1950's thin client terminal with 80x25 resolution and dark colors (Nothing against dark theme, just saying). A user whether a normal user or power user or even a developer shouldn't be bothered with remembering the exact parameter or it's structure. It should be completely scriptable, but it need not appear like existing terminals.

<comment><USER10> > I wonder if we developers have a subconscious bias towards tougher way of > building things instead of a much easier way.

That and the fact you we don't know everything that's possible and stick to what we know.

But, there is another side of the story: reusability is hard, plus similarity and equality are very different things. Generalizing a problem can be more or less productive depending of your situation. Also learning how to use something and bend it to your needs can be an mistake too on the long run.

Mix complexity, money, human factors in that and you get the average IT project.

Which is still awesome if you ask me. Current softwares have many warts, but they are so freaking amazing.

</comment></comment></comment></comment><comment><USER11> I love terminal because it is universal tool. I use urxvt in X-session, or emacs-shell sometimes. I can use it over ssh. I have kernel console for times when Xorg is broken. It is great. Great for user and for programmer too. As programmer I need not to fo any special tricks for my program was able to work with any terminal. It just works. All I need is printf, or something like. It is much simplier than any GUI toolkit use. Moreover, I can write programs for microcontrollers and communicate with them through serial line. Terminal is universal tool.

But this fun ends quickly if I need more than just output text sequentially. I would have nothing wrong with an idea of esc-sequences, if those sequences were standartized. But esc-sequences is not the full story -- line disciplines, complex states of terminal, heaps of historical garbage. There is ncurses, it can hide a lot of complexity but not all. And I do not like ncurses, maybe due to unhided complexity.

If I had to build terminal from scratch... At first I would state one curious fact: if decades ago terminal was extremly dumb device connected to a relatively powerful computer, now the reverse is the case: terminal runs on a relatively powerful hardware while a program working with a terminal can be run on a microcontroller with 2Kb RAM. So I see no reason to allow a terminal to be a dumb-terminal. A terminal could be pretty smart now. At least it can describe his capabilities in a universal format, for client doesn't have to consult with terminfo database, trying to guess what this terminal can do and what it cannot do.

And the second is to define clear APIs. Every time I try to do something with a terminal I need to spend a couple of days reading texts just to remind myself what the hell a terminal is.

<comment> terminal-survey > At first I would state one curious fact: [...]

That part is so nicely said I might just steal it for our manifesto. :)

</comment></comment><comment><USER12> Here are my comments and concerns.

1\. Minimal latency from keyboard to screen.

2\. As others have mentioned here, awareness of line wrap, so that cut and paste work correctly at all times. Not just for raw output from a command. Editors too should communicate with the terminal to indicate that it is wrapping lines.

3\. 24-bit color.

4\. Apps (shells, editors) can query and set the window icon as well as the window title.

5\. Integrated graphics display. So that I can just 'cat' a picture to display it in the terminal window, instead of using an external application.

<comment><USER13> "cat" could never work of course, or the general idea of a terminal that has only a pair of input/output streams must be given up. I don't think people are willing to do that.

A sensible protocol to draw raster graphics would be nice, though. (And it might exist, I don't even know). I don't care whether I need to type "cat" or the name of a terminal-based image viewer.

<comment> terminal-survey > "cat" could never work of course

We have an idea in that direction, where each program in a pipeline can optionally specify a file type, and the last file type hint in the pipeline determines how the stdout is rendered. So if you have "cat image.jpg", then "cat" can indicate a file type of image/jpg, causing stdout to be interpreted as an image. But if you have "cat image.jpg | grep foo" (just making something up here), then grep can indicate a file type of application/octet-stream because it cannot guarantee what the file type is.

The tricky part, from what I can see, is explaining the pipeline topology to the terminal, so that it knows that "grep" comes after "cat", even though command parsing happens in the shell only. That's still a big unknown. A previous project in this area (TermKit) mandated that applications specify a "Content-Type" header (like in HTTP) in their stdout, but that would break most existing programs, so it's not an option for us.

<comment><USER13> I would not recommend that. That would be the source for endless bikeshedding and could never satisfy all people. (See the mess that HTTP / REST are).

It's not a problem to have this handled in the shell such that the output is rendered in such a way as to please the terminal. You can do this manually (e.g. append a "| display-jpeg-in-terminal" command to the pipeline), or use a magic bytes based file viewer.

Look at "run-mailcap" or its shortcuts like "see". It does basically that, and can also be fed through standard input (which covers the piping situation).

<comment><USER14> if shells had some more types than a stream of bytes, it'd make sense for 'image' type data to be displayed as images. the pipes you mention are then simply type casts or conversion functions.

<comment><USER13> I don't know what you think is missing. "Displaying 'image' type data as images" totally works. Are you aware of magic bytes (which I mentioned above)?

<comment><USER14> never used them, but i'm thinking more in terms of powershell (pretty sure displaing images isn't something it does though). if images in particular work ok then that's one thing that i can scratch off my list of annoyances with ssh.

<comment><USER13> If you want a few tips how to type less, feel free to write me an email describing your problem.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> > \- What do you love about terminals?

The cursor is (generally) an absolute source of truth: Terminals usually behave very predictably. A good terminal does not get in my way or have any bells and whistles. Text goes in, output goes out, there's support for whatever the application needs wrt graphical capabilities and cursor manipulation. That's it. I don't want to have to deal with "oh god I accidentally clicked on a link, let's wait for the firefox tab I didn't need to open".

They're text-based and thus it's very difficult to introduce distraction or overly busy interfaces. Scripting being part of the terminal culture is great. Automation is often at least somewhat thought about.

> \- What do you hate about terminals?

There used to be an issue with terminals not being encoding-aware and having big issues with UTF-8. Fortunately, it seems these days are long gone. One thing I loathe is when terminals try to look or behave fancy. Get out of my way, please. If you have that much dev time to spare, please make sure that bitmap fonts actually work.

Not about terminals themselves, but about the ecosystem around it: people assume bash is present and always in /bin/bash. That's an unreasonable assumption. Tab completion is a crapshoot since it's not context aware and _extending_ tab completion for the major shells (bash, zsh, fish) is still an unsolved task.

> \- If you had to build one from scratch, how would you do it?

Assuming I can look at prior work, I'd first look at prior work. Ideally _simple_ prior work, like st. I'd also read as much documentation on the VT100 and ANSI escape sequences as I possibly could, since I think that's (still?) kind of the gold standard.

Anything related to mouse support, "integration" with a desktop, trying to outsmart the shell at tab completion are anti-features.

<comment><USER16> >Anything related to mouse support, . . . are anti-features

How does mouse support harm you?

The change I'd most like to see to Apple's Terminal.app is that when I want make an edit to the middle of a command line that has not been sent to the shell yet, I can use the pointing device to move the cursor to the location of the intended edit. How would that change harm you?

Why isn't it enough that you are able to work the way you want to work?

Why are you in addition advocating preventing a different way of working that is preferred by many people?

(Most of the time, I use an emacs mode written by myself to issue command lines to a shell, and that mode allow me to use the pointing device to move the cursor, but when I've introduced a bug into the emacs-lisp code that I maintain, I have to use Terminal.app to recover from the bug. I also have to use Terminal.app when setting up a new Mac.)

<comment><USER17> >The change I'd most like to see to Apple's Terminal.app is that when I want make an edit to the middle of a command line that has not been sent to the shell yet, I can use the pointing device to move the cursor to the location of the intended edit.

I recall being able to do this by holding down the alt key as I left clicked where I wanted the cursor to be relocated.

There's nothing wrong with mouse support in itself. Being able to move the cursor, select text, and in general interface with the OS or an application using a mouse is great. However being _forced_ to use the mouse for any kind of general OS or application interfacing feels like an injustice. A macOS specific example would be moving a window between desktops. The last time I used macOS there was no native way to do this without using the mouse. I had to drag the window to the desired desktop (either by dragging it towards the edge of the current desktop or by going to the desktop overview mode and dragging it onto the desired desktop).

<comment><USER16> >I recall being able to do this by holding down the [option] key as I left clicked

Thanks!

</comment></comment></comment></comment><comment><USER18> Well it is obvious to me that terminal handling and indeed the shell itself should be absorbed into systemd....

On a more serious note, the terminal has to "just work", its role is to host shells, ncurses apps, and so on. It doesn't need to have any clever features, it just needs to be a blank canvas, one that is tolerant of its guests doing weird stuff and able to recover gracefully. All the "cleverness" should be in the shell, so it can be swapped out for another one easily.

<comment><USER19> > Well it is obvious to me that terminal handling and indeed the shell itself > should be absorbed into systemd....

systemd is like that emacs of process supervisors.

<comment><USER20> Except that emacs is less bloated and doesn't crash as often, and not being and important program for the system, one can easily replace it with more simple software.

<comment><USER21> This is simply not true about Emacs. I have to restart my Emacs every couple of months because it gets too slow. I am not quite sure how to debug this.

</comment></comment></comment></comment><comment><USER19> First, if I want to come up with a setup that includes a modern terminal emulator with lots of features, a decent number of extensions and plugins for things like zsh, etc..., I will INEVITABLY end up with a something that:

1) has way more input latency that it should have (iterm2, Ive had to just fall back to Terminal.app)

2) takes WAY too long to launch a new bash/zsh/whatever session if I split a window (cause parsing thousands of lines of autocomplete code written in bash, profiles, etc... is SLOW). Shit, just installing nvm and sourcing all its crap adds an easy 400ms to session start time.

3) works on one, maybe two platforms at best.

Second: I understand that using a terminal for everything is inevitably going to be less efficient that a UI in very specific scenarios, but this ends up being true way too often, and a large part of it is due to the CONSTANT need to parse/marshal/unmarshal output format of one program to get it right for input somewhere else. Some of that is the terminal's fault (along with the whole CLI ecosystem), but a lot of it is just cause there are 9000 different competing formats for human readable structured data. Powershell really tried to get this right, and I salute them for it.

Third: terminals have been around for a long time, and they've come up with their own conventions for keyboard shortcuts/etc... over the decades; I get it. But its time to just dump that baggage and default to whatever the standards for a particular OS are.

<comment><USER22> At the risk of starting a quasi-religious argument, the object-orientation of Powershell is one of the things I really like about it.

<comment><USER23> It is nice although quite difficult if you are just an occasional user.

<comment><USER19> I've forgotten how to write powershell more times than I can remember.

</comment></comment></comment></comment><comment><USER24> Here's a recent pet annoyance of mine: if you have a lot of output from a command, so you pipe it through less, and then use X cut-and-paste to copy a multiline chunk of it to another terminal, it seems to be arbitrary whether it pastes as a single line, or multiple separate lines split by newlines. (For instance, resizing the xterm can change which you get.) I think this is because cut-n-paste is handled by the terminal, but the pager is just drawing characters at cursor positions so the terminal can only make a best guess about multiline selections.

<comment><USER25> Along with this, it'd be so nice to have line numbers for certain outputs along with a simple way of outputting a specific line to the clipboard or a file.

<comment><USER26> iirc, there is a program called 'nl' that should do the trick

<comment><USER27> I find "nl" pretty useless, because it only numbers non-empty lines, which is never what I want.

There's "cat -n" which numbers all lines. (-n is not POSIX, but it's available on at least on BSDs and Linux.)

<comment><USER26> > ... because it only numbers non-empty lines...

oh, that's just a man page lookup away. use 'nl -ba' which numbers all the lines. default style is '-bt' which numbers only non-empty ones, as you have experienced...

<comment><USER27> Even with -ba (which I could never remember), nl does too much magic:

      $ printf 'foo\n\:\nbar\n' | cat -n
           1	foo
           2	\:
           3	bar

      $ printf 'foo\n\:\nbar\n' | nl -ba
           1	foo

             bar

</comment></comment></comment></comment></comment></comment><comment><USER28> My ideal modern terminal would be pretty much a reimplementation of Symbolics' Listener: [https://youtu.be/o4-YnLpLgtk?t=1m46s](https://youtu.be/o4-YnLpLgtk?t=1m46s)

\- A presentation-based UI, where every on-screen element is always linked to the data it represents: [https://dspace.mit.edu/handle/1721.1/6946](https://dspace.mit.edu/handle/1721.1/6946)

\- A powerful autocomplete that knows about possible keywords and arguments, and can list them in a graphical fashion (e.g. a drop-down menu).

\- An ability to use any previously displayed data as input to a new command just by clicking on it, with the UI highlighting only the things than can be used as valid input to the current command.

\- Embedding of images and arbitrary UI widgets.

\- Sensible names for commands and their arguments, i.e. "Delete File" instead of "rm", and ":Output Destination File /home/erikj/log" instead of "> /home/erikj/log". This makes a lot more sense with the enhanced autocompletion facility than the current 70s style cryptic Unix two-letter commands that were employed because of the hardware limitations. It would be easier to learn and less prone to errors.

<comment><USER13> You are not going to get more than 10% of shell users to type ":Output Destination File /home/erikj/log" instead of just "> home/erikj/log". Learn it once, save typing a lot of characters, many times a day.

The idea that you should type so much more just to be "not cryptic" is as old as COBOL. Which, as most people would agree, was not a good idea.

<comment><USER28> Why do you think I mentioned the autocompletion facility? Shell users won't have to type any more characters than they do now. Please give Genera a try in the emulator to see how it would work with your own eyes, it's nothing like COBOL.

</comment></comment></comment><comment><USER29> I like Plan 9 terminal somewhat, even though it's infuriatingly simplistic and non-ergonomic:

\- the idea of the terminal as a document which can be navigated is pretty interesting (tmux fixes this to some degree).

\- the possibility to display other types of content directly inside the terminal window (e.g. man-pages rendered as pdf inside the terminal window), although it was not a terminal feature, but the feature of rio.

</comment><comment><USER30> I'm a big fan of the Mathematica-style console that mixes commands with media. Being able to embed surfaces that each command could communicate with would be fantastic. I believe Genera and Dr. Racket have similar features.

For short-lived processes, another stdio pipe pair may be sufficient (i.e. imgin/imgout). By image, not necessarily a raster. A byte buffer with a mime type would be more flexible (audio processing, etc.).

For long-lived processes, interactivity would be nice. Could have a communication protocol for keystrokes/mouse while the process is active. Or perhaps X or Wayland could be retrofitted into it some way where developers can kill two birds with one stone.

Keeping the alignment is worthwhile, so may want to round the surface size to some whole multiple of the character width/height.

</comment><comment><USER31>
      What do you hate about terminals?

Escape sequences. The current system is basically a giant bag of baggage we inherited from ye olden days. If implemented today I'd guess it would make much more sense to let a terminal application determine the actual key combination pressed (such as C-Tab, for example). I'm pretty sure that wouldn't be very easy to change, though (at least while keeping compatibility).

Edit: To clarify: I'm referring mainly to the fact that certain key combinations are not mapped at all, while other ones are synonyms for special keys, i.e.: ^[ is Escape,^I is Tab etc.

cf.: [http://wiki.bash-hackers.org/scripting/terminalcodes](http://wiki.bash- hackers.org/scripting/terminalcodes)

<comment> terminal-survey Oh yes. We want to have an API where clients (i.e. programs running in the terminal) can receive actual key/pointer/touch events if they choose to. The terminal may retain control over a few crucial keysequences (similar to how Ctrl-Alt-Del is always handled by the OS on Windows), but it has to inform the client about that.

<comment><USER31> Very good to hear! That alone makes me root for you guys.

Edit: BTW: If you really get a project going, make sure to inform us how to chip in (at least in monetary way, if nothing else. I'd like to be able to pay anyone who tackles this a beverage of their choice ;-) ).

<comment> terminal-survey As soon as the project is at a point where we feel comfortable showing it to a wider audience, we'll make a proper announcement and post it to HN (among other places).

</comment></comment></comment></comment><comment><USER32> The simplicity is great.

All the dark art and knowledge spread around is a pain, tty controls, escape codes, etc.. I've used terminals for decades but where the lines are draw between terminal, shell, tty and terminal emulator might be worth readdressing; it's 2017 and I will semi regularly see broken escape codes, Eshell in Emacs doesn't deal with the color prompt correctly as an example.

This isn't a terminal thing exactly but I've got 4K displays and greater then 1080p on laptops and there is still a strong 80 column legacy. Ideally terminal-ng would not ntroduce some future version of 80columns, I can't think what that would be. Perhaps somehow bridging between fixed width and non fixed width fonts or something like that, somehow.

</comment><comment><USER33> On the lines of "just working", it'd be cool to have a shell which if I could accidentally cat a binary file and not have the shell be completely in- operable or have to run this long archaic command to get it working again.

Maybe have something like "when I run the cat command, ignore all commands to the terminal until cat finishes".

<comment><USER34> What long archaic command are you running? 'clear; reset' usually does it for me.

<comment><USER33> Sometimes clear; reset works but other times I can't see what I'm typing, and so when I type it and hit enter it might clear the screen, sometimes it runs the command but the bash prompt is completely messed up. I use tmux a lot, so I usually use the reset code from this answer: [https://unix.stackexchange.com/questions/49886/tmux- status-b...](https://unix.stackexchange.com/questions/49886/tmux-status-bar- corrupted-after-catting-a-binary-file-how-to-reset)

stty sane; printf '\033k%s\033\\\\\033]2;%s\007' "`basename "$SHELL"`" "`uname -n`"; tput reset; tmux refresh

</comment></comment></comment><comment><USER35> I'm excited about notty [1], but I'm bummed the repo hasn't seen much action in awhile. I think the maintainer is on the Rust core team now. Some of its goals from the readme:

\- Full support for rich text formatting, including 24-bits of color.

\- Full and correct support for all of Unicode.

\- Lossless keyboard input.

\- Inline media content, including raster graphics and structured data.

\- Dropdown menus, tooltips, and other features which do not strictly reside in the character grid.

\- Local echo and retained off-screen character grid state to reduce the need for the tty to transmit data back to the terminal.

\- Subdividing the character grid to enable more complex interface layouts without repeatedly reimplementing that logic in the controlling process.

It cites Gary Bernhardt's talk A Whole New World [2] as a major influence. There's an open issue in the tracker for the Alacritty terminal emulator to implement notty [3].

[1] [https://github.com/withoutboats/notty](https://github.com/withoutboats/notty)

[2] [https://www.destroyallsoftware.com/talks/a-whole-new- world](https://www.destroyallsoftware.com/talks/a-whole-new-world)

[3] [https://github.com/jwilm/alacritty/issues/51](https://github.com/jwilm/alacritty/issues/51)

</comment><comment><USER36> It would be nice if the terminal and/or shell exposed some metadata. For example which machine and folder it is currently at.

This would allow one to have two terminals connected to two different machines ( via ssh for example ) and drag and drop files from one terminal to the other, even if there is no route between the two hosts

It would also be nice if words or sentences in the terminal had metadata. So one could type `ls`, see a lot files and click on obe of them to open it

<comment><USER37> Terminology does allow you to click a file after ls

</comment></comment><comment><USER29> > If you had to build one from scratch, how would you do it?

I consider Jupyter notebooks to be a fascinating evolution of the terminal paradigm: their basic behavior is close enough to a terminal, but then you are free to rearrange, rerun, delete cells, you can have rich visualization and any type of browser content, you can save and restore sessions (notebooks), share them easily, access them over the network, detach from them, etc.

</comment><comment><USER38> I often lose my place in a sea of similar outputs. It's infuriating that distinguishing which command belongs to which output at which time requires me to rely on my eyeballs.

So for example it'd be nice if my output folded up after the following command is run. If `time` was run automatically. If I could switch on autodiffing between runs of the same command. There are probably other such ideas.

<comment> terminal-survey We already have a solution for this sketched out on paper (not in writing or code yet, though). The idea is that the shell can split the terminal into "frames", where each frame acts as its own terminal. The shell would then use one frame per command prompt, and one frame per command (for its input and output). The stdin/stdout that is given to the command is restricted to that particular frame. It can then write text into that frame and move the cursor around inside it, but cannot break out of the frame, so e.g. it cannot overwrite the output of the previous command.

And once you have these frames, you can give them some useful properties: For example, the shell can fold them, or apply styling hints to them (e.g. so that a command with non-zero exit code can be highlighted with a red border or similar).

With frames, you can also have multiple commands running in parallel. For example, wget could signal to the shell that it will run for a while longer, but does not require user interaction, so the shell can allocate the next frame below the frame where wget is still running, and offer the next command prompt.

It also means that fullscreen programs do not need to block everything: vim may be running inside a frame that is set to the full window size, but you can just move the keyboard focus out of this frame and scroll upwards to review the output of a previous command while vim continues to run down below.

<comment><USER39> I think this would be pretty easy to do in eshell. Emacs gives you frames already and supports interacting with output buffers (like compilations errors)

Its been on my to-do list for a while. I wrote a rough outline and its similar to what you've said as well: [https://reddit.com/comments/6y3q4k/comment/dml16vq](https://reddit.com/comments/6y3q4k/comment/dml16vq)

</comment></comment></comment><comment><USER40> > What do you love about terminals?

The lack of distraction, the information density, the ability to integrate command line tools into my workflow (yes, I have "selected text is copied to the clipboard" enabled).

> What do you hate about terminals?

How slow the modern terminal is to transfer inputs and paint responses. I like a lot about how iTerm2 works (its integration with tmux and sensible keybinds), but dislike the latency even after all the recent improvements to latency.

A much more minor gripe, but I spend a lot of time working on laptops; acknowledging the lack of a middle mouse button (yes, I hate it too) as a reality for most people's interactions with the terminal would be nice.

> If you had to build one from scratch, how would you do it?

First, I would "borrow" heavily from iTerm2 - its customizability and easy defaults.

Second, I would "borrow" from the web browser rendering engines out there. Make it simple for programs to either not care about their output at all and let it look and and act sensibly (paragraph breaks, reflowing around spaces, easy tables, etc), or to define a minimum amount of "styling" to create reasonable outputs (right justifying text, centering, maximum/minimum width, etc), or have absolute control over the positioning of every item with low level feedback about the terminal.

This would have to be done in addition to a backwards-compatible escape- sequence method of placing characters, of course, and couldn't be the default, but simply making it available for new programs would be a great start. Creating libraries for such interactions would be even better.

There is a lot of history in the terminal; it's time to learn from it and plan for a future beyond ASCII.

</comment><comment><USER41> What I love: speed. Responsiveness. The focus on text, which is what I read most unambiguously. Resizability and reflowing on a line-by-line basis. vim, slrn and mutt: they all understand that a "page" is just the viewable area, and is both important as a unit of scrolling and unimportant because it can change at any time.

</comment><comment><USER42> Learn from history.

Anyone who is working on improving terminals now, in the second decade of the 21st century, needs to learn from all of the work that went on in the 1970s and 1980s addressing much the same needs and wants, let alone what has happened since then.

Terminals got graphics capabilities. Operating systems vendors enhanced their operating systems with abstractions with far better programmatic interfaces like the KBD/VIO/MOU subsystems in OS/2 and the console subsystem in Windows NT, providing mouse and keyboard input _messages_ that did not have to be parsed and directly addressable video buffers that could be written to _and read from_.

Real terminals and terminal emulators converged on the ECMA-48 and DEC VT control sequences. For terminal emulators people invented remote terminal protocols more geared towards common IBM PC compatible hardware such as AVATAR (see FSC-0025 from 1988), and even protocols for encapsulating higher-level things like TUI widgets.

* [https://jdebp.eu/FGA/tui-console-and-terminal-paradigms.html](https://jdebp.eu/FGA/tui-console-and-terminal-paradigms.html)

* [http://ftsc.org/docs/fsc-0025.001](http://ftsc.org/docs/fsc-0025.001)

* [http://ftsc.org/docs/fsc-0037.001](http://ftsc.org/docs/fsc-0037.001)

As for moving terminal handling out of the various operating system kernels, people were doing that years ago too. I wrote a white paper on it for Linux in 2006, and the ideas were not new then, they having already existed in systems like GNU Hurd and Windows NT. David Herrman, one of the systemd people, wrote KMSCON; which, ironically given the comments about systemd on this page, was actually included in systemd (as systemd-consoled) for about nine months until he (with much less fanfare than accompanied the inclusion and no comment from Lennart Poettering when asked about it) removed it again. Many people wrote framebuffer terminal emulators, including me.

* [http://jdebp.eu./Proposals/linux-console-daemon.html](http://jdebp.eu./Proposals/linux-console-daemon.html)

* [https://cgit.freedesktop.org/systemd/systemd/commit/?id=ce7b...](https://cgit.freedesktop.org/systemd/systemd/commit/?id=ce7b9f50c3fadbad22feeb28e4429ad9bee02bcc)

* [https://plus.google.com/+LennartPoetteringTheOneAndOnly/post...](https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/8fQ9t9pmUuT)

* [https://github.com/systemd/systemd/pull/747](https://github.com/systemd/systemd/pull/747)

* [https://unix.stackexchange.com/a/177209/5132](https://unix.stackexchange.com/a/177209/5132)

* [http://jdebp.eu./Softwares/nosh/user-vt-screenshots.html](http://jdebp.eu./Softwares/nosh/user-vt-screenshots.html)

<comment><USER30> Your stack exchange post is _epic_. Thank you!

I have some reading to do...

<comment><USER42> I probably should not point to any more, then. (-:

* [https://unix.stackexchange.com/a/289871/5132](https://unix.stackexchange.com/a/289871/5132)

</comment></comment></comment><comment><USER43> I love terminals because they have a perfect memory of all the things I've typed. Many IDEs lack this feature. They don't keep a history of every menu command that I've used. Shortcut keys works for simple queries, but you can compare that to the power of repeating complex Vim commands.

I also like terminals because it feels like I'm talking to the computer more directly, we're not going through a 3rd party.

What I don't like about terminals is that it feels like I'm in a dark tunnel when moving around the file hierarchy, I can only see the directories directly ahead and behind me. I guess things like FZF help to do quick searches, but you get a much more visual picture when using window file explorers.

<comment><USER42> If you have never encountered an Orthodox File Manager, you should try one. One _can_ have a hierarchical display of the file system without necessarily using a GUI.

</comment></comment><comment><USER14> i've got ~20 bashes open in various tmux configurations. the amount of times i lost command history is infuriating (e.g. due to reboot or whatever).

context-sensitive completion (not necesarrily tab completion, mind you) is very basic compared to IDEs.

mouse support would be good if it was actually useful. copy and paste is useful.

zoom in/out (think c--/c-+/c-0 in browsers) would be nice sometimes, especially when i want to copy large amounts of stuff. the fact that copy/paste is the easiest way to transfer files over ssh is also mildly irritating.

option to display an image or render a webpage or pdf in the terminal directly (ala jupyter) would be nice.

<comment> terminal-survey > i've got ~20 bashes open in various tmux configurations. the amount of times > i lost command history is infuriating (e.g. due to reboot or whatever).

zsh does (has an option to) commit commands to the history file immediately when you execute the command. Makes me hate bash even more when I have to use it occasionally on a server.

<comment><USER44> You can do something similar with bash. If you set PROMPT_COMMAND='history -a', it'll append to the history file right after the command completes (because the prompt command is run as the prompt is printed).

<comment><USER14> thanks, i'm sure you've just saved a couple hours for a future me :)

</comment></comment></comment></comment><comment><USER45> I love that everything is doable without lifting my hand from the home row keys, the programmability, the lack of advertisements, the consistent emacs/vi keybindings and the low performance costs.

</comment><comment><USER46> Better integration with multiplexers like tmux and screen. Thus I get native window boundaries for easy copy&paste with a mouse. I think iTerm2 can do this on macOS but no Linux/BSD-one. There is terminator which has this functionality but it does its own thing and doesn't use a multiplexer in the background. Essentially terminator but with tmux and Screen (both for choice of the user…even though I think tmux is superior) in the background, so that I can let sessions run in the background and have them available when I connect via ssh or have them survive when the WM should crash. In addition I am a sucker for theming. Thus easy themability and an easy way to import and export themes. With 256 colors of course and not only 16. Otherwise I am pretty uninagimative because most of the stuff is handled by the shell anyways and I need to ssh into servers all the time, so for stuff like auto-completion the terminal would need to have knowledge about the remote server as well which would be problematic probably. Easy ways to resize - not only drag and drop but give me a way to enter dimensions when I am on a legacy machine which has only screen and I have to share a session with someone. And it would be neat to save session layouts. So that the terminal opens up my last session with 10 terminals placed on the right positions on my screen (but tmux-integration might solve that already) and maybe even remembers which servers I connected to last in which terminal. So when I restarted my computer I open the terminal and it starts to connect already my ssh-sessions. It is really annoying when I restart my machine and have to reconnect to a dozen servers and arrange all the terminals.

</comment><comment><USER10> # Portability

Having a terminal that works the same in Windows, Mac and Linux.

# Browsing UI

I have autojump and I know all the cd shenanigans, but really I want my terminal to make it easier for me.

I want an url bar where I can see my file path and click on part of it like in a file browser (eg: nautilusà or put an ssh address in it.

I want a back and forward button.

I want an history.

I want bookmarks.

I want to be able to right click on a path and "open url in the browser", "unzip/untar file", "open in libre office/vlc". And I want to be able to ctrl + left-clik path and cd to it or xdg-open it.

This should be customizable. E.G: tilix let you enter regex that makes things clickable. Very useful to debug tracebacks.

# Split and tabs

Most good terminals (ex: tilix, cmder) have a good split screen, quake mode, and tab story. You can save profiles, restore them, auto run commands, etc.

It should have those, and it should be well integrated with the browsing UI.

Also changing the aspect a tab according to events. E.g: red if command return and error code. With a special icon if you are running as root, if you ssh on a remote computer.

# Graphical display

I want to be able to request the display of an media inside the terminal, like an embeded image or video.

# Take control

I get that we wanted the terminal to be separated from the shell. But this createe such an integration mismatch.

Code completion, helps, prompts... Everything is slow, hard to configure, incomplete, unsatisfying, and not cross plateform.

Just hijack the shell and do the right thing. People that don't like it can always use another terminal.

We don't lack configurability. We have freedom all the way with current solutions. Keyboard only people with no windows decoration have everything they need.

What we do lack, is a terminal for mouse lovers.

Careful with this though. Some project tried it and added a lot of graphical things that looked cool, but were totally useless in practice.

</comment><comment><USER47> I'm a Mac User, and honestly I think the Mac terminal is fine and there's very little room for improvement. But if I were to improve here's a few of the things that I would do:

\- Make it easier to know what the current process is and kill it if it goes haywire. An out-of-control process can trap control C and ignore it. I really hate digging into activity monitor to kill a process when I just want to keep the same terminal window open.

\- A better display of my current working directory, and my current git branch. These items should be displayed at the edge of the window, not inside the terminal itself.

\- Better view and management of my previous commands in the shell.

\- Do away with psuedo-gui terminal applications. My terminal already has a large scroll back buffer, so we don't need applications within the terminal to also implement scrolling and paging. I have plenty of graphical text editors on hand. We have protocols like VNC for remote desktop control.

\- Try and see if there is a way to lower the learning curve of various terminal applications that I may use infrequently. Often I learn how to use terminal applications by Googling around for examples of what I am trying to do. Perhaps something like autocomplete that we have in our modern IDEs?

\- Allow me to collapse the output of programs, just like we can collapse comments in hacker news.

<comment><USER48> > An out-of-control process can trap control C and ignore it.

Many programs that trap SIGINT won't trap SIGQUIT so ^\ will still kill the process. Even if they do, if ^Z works then kill -9 %1 will be good.

> A better display of my current working directory, and my current git branch. > These items should be displayed at the edge of the window, not inside the > terminal itself.

MY prompt has been \$ for ages, and I've many names complained about my failing memory, but since I don't change directories often this causes me little grief (and being in one directory means my ^R search is very useful). Have you considered just storing this information in the title? Many virtual terminals have an escape sequence that sets the title.

> Allow me to collapse the output of programs, just like we can collapse > comments in hacker news.

This sounds very useful. Perhaps it would be implemented as an escape sequence that would be marked in the prompt.

<comment><USER47> What you suggest requires a significant amount of learning and relies on hidden commands. What I'm suggesting is narrowing the use case of the terminal and making it more user-friendly without relying on non obvious hidden tricks.

<comment><USER48> "Significant" is relative.

What I suggest is available today: and for the cost in time of reading my message will resolve a third of your issues.

I don't know what you mean by "non obvious hidden tricks". People learn what control-C does because they read the manual; because someone shows them. Likewise with other keys and job control. Or the tab key. Or google. Very few things are obvious, and you can find what they are by putting them in a room with a potato and watching: If the potato can figure it out, then it was obvious.

</comment></comment></comment></comment><comment><USER49> Probably the most frustrating thing for me is when I'm connected to another terminal via ssh and am typing in a command (without using autocomplete). When I am on a poor internet connection the latency between rendering each keystroke makes me want to throw my computer out the window.

It would be cool if the local terminal could render text at the speed of typing and while lazily sending that back to the other machine.

<comment><USER50> mosh[1] provides the buffering you're looking for and some other useful features, at the cost of extra complexity that could lead to other issues (e.g. no scrollback unless you use tmux as well).

[1] [https://mosh.org/](https://mosh.org/)

</comment></comment><comment><USER51> I spent yesterday rewriting my ZSH config. A lot of the time I spent on figuring out how to map random key combos to unused control characters. So if I could implement both the terminal and the shell from scratch (or make a significant addition), I would implement a scenario like this:

      1. Program informs the terminal that it supports "extended keyboard input". This would be done with an escape code, much like bracketed paste.
      2. Terminal informs the program that it is now enabled.
      3. Terminal informs the program of the initial modifier key state.
      4. When the user presses a key (including modifiers), it is sent in a format that standardizes over all the commonly used key codes. Also, if the key represents a Unicode codepoint, that is sent as well. E.g. (mod-status-at-key-press)(key-code)(utf8-char-or-null)(null-terminator).
      5. When the user releases a key, a similar message would be sent.
      6. When the program exits (or a shell runs another program), it asks the terminal to disable "extended keyboard input"

</comment><comment><USER52> I love tab completion.

I hate that the terminal and the browser are two different applications.

<comment><USER53> They don't have to be! See: w3m and vimperator / Tridactyl

<comment><USER54> While amazing in their own right, those aren't examples of a web browser and terminal becoming one application. Those are more like the interface of one being used to manipulate the other.

I think something like hyper will get us close: [https://hyper.is](https://hyper.is)

</comment></comment></comment><comment><USER55> Hate the fact that you can cannot revert the termtitle to it's previous value. A mechanisme like push/pop titles would be more convenient. Anchoring metadata to some text (like  links in HTML) for terminal emulator to understand instead of regex.

I would suggest asking authors of libraries like python_prompt_toolkit who likely have ideas.

<comment><USER26> changing terminal-titles is just a google search away. or perhaps i am missing something fundamental. may you please elaborate? thanks!

<comment><USER55> Yes I'm aware of the ansinescape sequence to _set_ the termtitle. But you can't _restore_ previous termtitle without knowing them (or existing current program). In my case with IPython I want a termtitle that say "busy" when computation is in progress otherwise get back to it's initial value of before starting IPython. I can't do that, because I would have to exit my IPython shell for bash to set the previous value. So I want termtitle to technically be a stack, on which I can push a title or pop-it without having to know what the previous one was. See for example [https://github.com/ipython/ipython/issues/9722](https://github.com/ipython/ipython/issues/9722), which is recurrent. Without a getter (which is a security issue) or introducing global state or passing the values all around you can't set a temporary value for the title. Is that clearer ?

<comment><USER26> > Without a getter (which is a security issue) or introducing global state or > passing the values all around you can't set a temporary value for the title. > Is that clearer ?

yes, it is. thank you ! one simple solution might be to wrap this thingy within an 'xprop(1)' invokation. for example, i can do the following:

        signal11@fatcat networking % xprop -id 0x2c00022 | grep WM_NAME
        WM_NAME(STRING) = "fatcat:~/source-code/c/networking"
        signal11@fatcat networking % cd ~/source-code/c/quick-hacks
        signal11@fatcat quick-hacks % xprop -id 0x2c00022 | grep WM_NAME
        WM_NAME(STRING) = "fatcat:~/source-code/c/quick-hacks"
        signal11@fatcat quick-hacks %

WM_NAME(STRING) points to the current title. and when i change the directory, i can query the new name. fitting this mechanism for aforementioned usecase is left as an exercise for the reader :) fwiw, the value for '-id' argument comes from 'xwininfo(1)'

<comment><USER55> That is a nice hack thanks! Though it is not really portable to all OS, and AFAIU not working if you ssh to a remote host ! It may give a potential way to work partially around that limitation. I feel like an actual push/pop solution would be better.

<comment><USER26> > ... and AFAIU not working if you ssh to a remote host !

X being a network protocol at heart, it positively is weird. i tried that thingy on both local machine, and ssh'ed xterm to remote-machine (with X sessions correctly forwarded locally), and it all seems to work just fine for me.

edit-001 : these are linux machines at both ends, so, i dunno...

<comment><USER55> Yes, I'm on Mac OS so that's likely it, and the server I was trying had no X anyway. Thanks for investigating.

</comment></comment></comment></comment></comment></comment></comment><comment><USER56> I love how terminals are a universal tool that can do a lot with just the default GNU toolset.

I hate how I can't choose the caret position with my mouse when using a terminal emulator. Nothing seems designed to allow this. Sometimes there's too much input and using the arrow keys or HOME/END gets tedious.

<comment><USER21> M-x shell in Emacs lets you use your mouse.

</comment></comment><comment><USER57> Love: That any terminal anywhere that speaks VT100 -- including real DEC hardware from the 70s and 80s, "communications programs" for DOS or Windows, and modern ssh clients -- can interact with a program that also speaks VT100, and that program thereby can produce a clean, usable, if not elaborate UI on 8-bit hardware with KiB of RAM through to 64-bit hardware with GiB of RAM and beyond.

Hate: Mainly kids who've never seen or interacted with a dialup or other serial connection, let alone a real hardware terminal, who think that "the terminal" is some software construct which can (and therefore should) be thrown out and replaced with something based on the ergonomics of a 2017 Macintosh.

</comment><comment><USER58> I want a terminal that writes from the top down instead of from the bottom up.

<comment> terminal-survey You mean that it should scroll in the opposite direction?

</comment></comment><comment><USER59> I'd want to be able to split it horizontally and vertically, and sub-split those similarly, ad infinitum (see eMacs C-x 2 and C-x 3), cycling through them with convenient copy/paste across them, with them also aware of each other and able to pipe information to each other.

There are some that split to various degrees already; I don;t know how aware the panes are of each other or if they'll happily pipe into each other. I'd like to be able to run a script in one pane and have the outputs go into different panes as directed by the script.

</comment><comment><USER60> I hate terminals because they're completely undiscoverable and they depend on you typing each character exactly right or things could blow up.

Give me a good discoverable, safe UI over a terminal any day.

The only good thing about a terminal is that flexibility you get by piping programs together. GUIs can (and do) have the same kind of flexibility but it's not as standardized so I guess another good thing about terminals is that there are some simple standards.

Other than that though, I'd throw away terminals forever if I could.

</comment><comment><USER61> I rarely use terminals so please don't take my answer into account. Just for the fun: I hate terminals because of the lack of discoverability. I know, it is probably the antithesis of a terminal, something that can not be fixed without breaking the concept of a CLI. But I really hate the lack of visual feedback. What is the state of the system? What are my options right now? How was my command interpreted (sometimes I have to scroll many pages up to maybe find an error message.) Etc.

</comment><comment><USER62> I would love for someone to produce a modern dumb terminal - akin to the Hazeltine/VT100 systems of the past, but using modern components. It'd have multiple serial ports, and do _nothing_ but act as a dumb terminal for a Unix system - but it'd use modern display tech, maybe something from the elite mechanicalkeyboards world, and so on. I'd buy one for my desktop in a heartbeat - I'm truly sick of all the bloat required just to fire up iTerm.app and so on.

<comment><USER42> Many people have already done this, such as the people who emulate DEC VTs with arduinos and suchlike for starters.

* [https://github.com/mkschreder/avr-vt100](https://github.com/mkschreder/avr-vt100)

* [https://hackaday.io/project/13273-diy-vt100-a-miniature-hard...](https://hackaday.io/project/13273-diy-vt100-a-miniature-hardware-terminal)

* [https://hackaday.com/2010/02/24/oscilloscope-doubles-as-a-se...](https://hackaday.com/2010/02/24/oscilloscope-doubles-as-a-serial-terminal/)

* [https://tech.scargill.net/vt100-terminal-for-hc2016/](https://tech.scargill.net/vt100-terminal-for-hc2016/)

<comment><USER62> Quite nice .. I wonder if there'd be demand for an upscale version of these, sort of more turnkey and less hack.

</comment></comment></comment><comment><USER63> I'd like to see terminals start to mirror sort of how those interactive programming language environments work, like where data scientists have a notebook or workbook. Output should be collapsible, there should be snippets on the side, and most importantly, the history should be easily manageable and obvious to use/re-use.

It's possible a lot of terminals have the features I want already, in which case I have a discoverable-feature problem also. Haha.

</comment><comment><USER17> > \- What do you hate about terminals?

Having to use the mouse to select/highlight/copy output I didn't know I was interested in until after it'd been outputted. Being able to export/open the currently visible history/output to an editor would be great.

> \- What do you love about terminals?

Unless I'm suddenly interested in the output of a previously run command that can't be reproduced, I can interface with them without using the mouse at all.

</comment><comment><USER64> guiding principles is that a terminal is still part of the computing ecosystem and needs to be a well integrated companion to GUI and desktop apps running concurrently.

so here are some suggestions off the top of my head

* padding on the left of the terminal. mouse selection from the start of the line needlessly requires precision mousing. more often than essential when attempting to select some text with the mouse, one resizes the terminal or selects a window behind the terminal frame. probably best in the gui client but perhaps some escape modes where whitespace can be hinted as not copyable

* perhaps a modes to suggest arbitrary text should not be copied to the clipboard ? say lots of banner text with a supprt url among it. selectingthe whole block only selects the useful url. ignorable by the end user of course

* mouse double-click-to-select should grow the selection. terminal output often needs to be cutnpasted into other apps

* snapshot the offscreen buffer somehow ? less somefile.txt... exit... rm somefile.txt... oops gone for all time including scrollback

* sane modern defaults. Ctrl-S freezes terminal ?!? I know this a bash thing setopt -w checkwinsize. why is this not on by default ?

</comment><comment><USER65> Call me crazy, but why does every terminal output text from the bottom and have the cursor slowly go _up_ the screen? Why do my eyes constantly have to track the cursor on a vertical plane? What I would like is the option for the cursor to be at the top (the most "level" for eyes) and for all text to waterfall down, never changing the cursor position.

</comment><comment><USER66> Love: I think it's the best way to do things without GUI Hate: I cant use mouse for copy command or edit a line

<comment><USER67> Yes, changing the cursor position with the mouse while typing a command would be handy in some situations!

<comment><USER68> I wanted to say this as well. Maybe it's blasphemy to want better mouse support in a keyboard-driven environment, but dammit if it wouldn't be handy to just click to a position in the line you're typing instead of slowly crawling your way there with arrow keys.

<comment><USER67> > Maybe it's blasphemy

No, it is not blasphemy! I often find myself copying text from some non- keyboard driven program into the command line and having the ability to change the position of the text cursor in the command line with the mouse would be nicer and faster because my hand is already on the mouse.

Pointing with the mouse to a specific location in the middle of a string is always faster than doing the same thing with the keyboard (if your hand is already on the mouse)

My favorite example is htop: Clicking on a random column header with the mouse feels easier and faster than doing the same thing with pure keyboard navigation.

> slowly crawling your way there with arrow keys.

In case you did not know yet: Try using ctrl + arrow keys (or ctrl + b/f) to jump over whole words. It's still not ideal but at least it is faster than just arrow keys.

</comment></comment></comment></comment><comment><USER67> I use stock bash / Konsole and I am really missing a good text reflow when changing the size of the window.

If some command prints a line which gets wrapped because it is too long then I wish I could un-wrap it by making the terminal window wider and forcing some sort of re-layout.

<comment> terminal-survey Yes, it would be nice if reflowing became more common. We are not sure if our spec requires the terminal to support reflowing (because of the resource usage implications), but the terminal must at least be able to announce whether it does reflowing (and/or word wrapping).

</comment></comment><comment><USER69> I would like to be able to use modifier/control keys over terminal similarly to GUIs, e.g. use Shift+arrows to mark text, impossible on current terminals. I guess transmitting the state of all modifier keys with every keystroke would be a simple fix.

<comment><USER42> It has been possible on terminals for about three decades -- since the DEC VT220 at least.

Applications know when shift+arrow is pressed because they receive a different control sequence. Modifier keys are reported as an extra parameter in the control sequence for function keys and extended keys. Dickey xterm has been doing the same since 1999. The PuTTY changelog does not indicate when it gained this, but it has had it for years, too.

* [http://invisible-island.net/xterm/xterm.log.html#xterm_94](http://invisible-island.net/xterm/xterm.log.html#xterm_94)

And indeed you will find that TUI applications such as VIM and NeoVIM recognize these control sequences and can distinguish arrow from shift+arrow. See :help cursor-up and (on VIM) :help xterm-modifier-keys . (NeoVIM handles the TUI differently, is terminfo-only, and has modifier recognition always on.)

If some other application does not, then it is _not_ the terminals that need fixing.

</comment></comment><comment> terminal-survey Hi everyone, thanks a lot for the responses. Keep them coming!

As mentioned in some of my replies, we have already considered some of the things that you mentioned (and incorporated them in our design), but your responses show that there is still a lot more to consider.

</comment><comment><USER70> Finalterm was really a promising modern terminal and had a huge potential. It is a shame the project has been abandoned.

[https://github.com/p-e-w/finalterm](https://github.com/p-e-w/finalterm)

</comment><comment><USER71> I want more interactivity with printed terminal output. Similar to copy mode in tmux but with tools of my choice. I can type c-x e to edit input with my $EDITOR. I want at least the same power over the output, like what I have using acme.

</comment><comment><USER72> Love:

1 speed (of typing/screen updates/just doing things)

2 simplicity (in general)

3 basic highlighting

Hate:

When layout gets into a terrible jumble that's hard to distinguish one thing from another (kind of rare and is usually when using suboptimal tools/solutions, so isn't usually a show stopper)

</comment><comment><USER73> I like that they're easy to automate actions with.

I hate that commands are difficult to discover.

<comment><USER37> Exactly what I think

</comment></comment><comment><USER74> Auto-paging the output. I don't think I've ever run a command that exceeded the height of my screen that I didn't want to scroll back through to read anyways. Some programs get it right - `git diff` comes to mind.

</comment><comment><USER75> I don't know if it's solvable at the terminal level only, but I would love a terminal that never gets messed up so that I never have to type reset or close the window and open it up again.

<comment><USER42> It was solved more than six years ago. The cost is that you lose support for applications that make use of switchable 7-bit character sets: on the gripping hand a price that most people seem willing to pay nowadays.

* [https://news.ycombinator.com/item?id=16014824](https://news.ycombinator.com/item?id=16014824)

</comment></comment><comment><USER76> I would love to contribute to this group. How can I get involved?

<comment> terminal-survey We are currently doing most of the work offline, so it's difficult to collaborate with a far-reaching network of contributors at this point. However, if you drop me a note at < 34c3-terminal-survey at posteo dot de >, I can put you on the list of people to ping once we have something that can be put in front of more eyes.

</comment></comment><comment><USER77> It is difficult to build a TUI. Just to draw several progress bars might take a whole day to implement.

<comment><USER78> I think this issue is more one of poor modern TUI libraries than an issue with the underlying technology.

Drawing a progress bar with OpenGL is probably more difficult than the "go to start of line, reprint my characters" logic needed in the terminal, and yet raster graphics APIs are undoubtedly more powerful than VT escape sequences.

</comment></comment><comment><USER79> I am very interested in this, and would like to contribute. How do I get in touch with you?

<comment><USER37> Answer from OP

[https://news.ycombinator.com/item?id=16015163](https://news.ycombinator.com/item?id=16015163)

</comment></comment><comment><USER80> I always hate long output; Since there is no direct "roll up" most times

</comment><comment><USER81> I hate Bash and all of its relatives. No language where equality is tested with -eq should be in use in 2017; we can do so much better.

<comment><USER82> I actually kind of like it, powershell also has -eq, and there's no chance of mixing up assignment and equality operators.

<comment><USER42> You mix up the := operator with the = operator? (-:

There's no chance of mixing them up with the "test" command, note, which is what ajkjk was talking about (even though xe erroneously attributed this to the Bourne Again shell language), because the test command _has no_ assignment operator. Whereas what it _does_ have is a whole bunch of syntactic gotchas that bite people with depressing regularity.

* Miss quoting variables, and suddenly your unary operator turns into an expression that always evaluates true, because with 1 argument test merely tests whether the argument is non-blank, which a unary operator is of course.

* = is string comparison, and -eq is numeric comparison. Yes, you want the other one.

* ... but == is a non-standard bashism that does not work in scripts interpreted by /bin/sh (which is usually something like the Korn or Almquist shell) on many modern systems.

* ... and if you are using the Z, Korn, or Bourne Again shells, don't forget that you need to quote the < and > operators.

* Beware the variable whose value has a minus sign as its first character. All comparisons for safety need to be of the form x"$var" = x"something" .

<comment><USER82> "Real" languages use "=" and "==" ;)

Was unfamiliar with the minefield of bash issues, still, I do like the -eq operator, even if bash implements it poorly.

<comment><USER42> On the contrary, a real language uses .EQ. . == is for the chattering classes who use the # sign when posting to social media. You appear to be eating quiche. (-:

* [http://gordonbell.azurewebsites.net/ibm-026/ibm-026-ref-27.j...](http://gordonbell.azurewebsites.net/ibm-026/ibm-026-ref-27.jpg)

Rex Conn knows how a real language does relational operators.

* [https://jpsoft.com/help/conditionalexpressions.htm#r](https://jpsoft.com/help/conditionalexpressions.htm#r)

</comment></comment></comment></comment></comment><comment><USER83> built-in copy-paste feature

<comment><USER84> Copy paste with multiple buffers. I often have to copy some kind of unique ID, then copy paste a file name to search; on a Mac I can't do this because it doesn't support middle-button paste like X. I can do it on X but that still only supports two buffers; would be nice to have more.

</comment></comment><comment><USER85> If I were building a terminal from scratch... Hm.

Attempts to improve the terminal are not backwards-compatible or do not otherwise provide a clean upgrade path. I would _love_ to use one of those fancy graphical terms that comes up on HN every now and then, but because they only work with a special toolchain that speaks its language and its language only there's no way they'll ever gain critical mass and take off. Any attempt to improve the terminal has to be something that I could switch to on a whim and then gradually grow into.

I _really like_ the "curious fact" from higher in this thread and I think that it's important. Whatever the solution is, I think that it'll necessarily involve separating "business" logic from presentation logic, and giving presentation logic to the terminal while things under the shell handle the actual work. Right now, one of the biggest problems with writing a CLI tool is that TUI work is a _huge pain in the ass_. It's harder to make a table in the terminal than it is to make a table on the web! That's insane! And that suggests a straightforward solution: Move display logic into the terminal so that it can handle layout and rendering. And you do that the same way that that's been done in literally every situation that's ever been done: You ship a small program that constructs a view that can take advantage of a more favorable execution environment.

So what does it mean to "ship a program that constructs a view"? Well, even if your program is written in a deeply standardized, weak language (e.g. ANSI escape codes) it's still a program. Formal languages theory, hooray. So we're already operating in this formalism, which makes our job much easier and the solution relatively obvious - Instead of inventing an entirely new paradigm from the ground up we just need to jam a more powerful language into an unused corner of the existing one.

This is where I go down the rabbit hole, because I don't know enough about the specifics of ANSI escape sequences. My goal, essentially speaking, is to find a set of sequences of control characters (a language) that will be ignored by everything _except_ my New Terminal, map that set to some convenient programming language (ideally by a trivial "prefix-identity-suffix" construction), build a platform for building user interfaces that uses that programming language, and then build... something that augments existing programs with New Terminal front-ends? A lump of stuff into my shell RCs that detects New Terminal and augments the prompt strings with New Terminal apps that wrap the outputs of commands that look right?

Then the question is, what does my platform look like, and what convenient programming language am I using? I'd probably go with something like js or guile. Maybe just js so I can take advantage of extensive existing UI tooling. I mean, if you look at this sufficiently sideways, I've essentially duplicated the evolution of HTML+JS webapps - jam a new language (js script tags) into a corner of the existing language (html) that will be ignored by systems that don't understand the new thing and then implement a platform (DOM manipulation and such) that allows the creation of fancy user interfaces (webapps) using those tools. And really, I think that that's the clincher - that evolution happened when client machines became powerful enough that it was useful to move presentation logic out of the server and into the client, and that's exactly what we need to do with terminals.

(thought: interaction. callbacks return a sequence of characters that're typed into the terminal? so you can click on a table header and the client sorts and re-renders the table, or you can click on a button and to run a convenient follow-up invocation? ahhh, yeah - if the backend program (ls et al) is transient its interactions will render commands for follow-up operations, if it's persistent its interactions will render keystrokes for interacting with it - you'd click on the headers in top and it'd send `p`, `t`, etc. that's really clean.)

<comment> terminal-survey > I would love to use one of those fancy graphical terms that comes up on HN > every now and then

One of these (Black Screen) is among the many inspirations with which we started.

> Any attempt to improve the terminal has to be something that I could switch > to on a whim and then gradually grow into.

Backwards-compatibility is a hard requirement for us because of that. And oh boy, it causes a lot of pain.

> I've essentially duplicated the evolution of HTML+JS webapps

This is a huge fear of mine. We need to find a way of opening the GUI can-of- worms without ending up with terminals that are as bloated as contemporary web browsers.

<comment><USER85> > Backwards-compatibility is a hard requirement for us because of that. And oh > boy, it causes a lot of pain.

Yeah, it's a bitch. Sorry. :( I've seen one or two "rewrite everything and make it better enough that people switch" big-bang efforts succeed - I run fish, 'nuff said - but this is a rather more invasive change, and it doesn't have good fallbacks ("run bash for ten seconds").

I'm not sure there is a good solution here, not when I look at it from the formal languages perspective. The existing language (what's relevant to current functionality) contains nearly all sequences of elements of the available alphabet (bytes), so anything we do will collide with _some_ thing. Nobody was able to leave a specific exception to permit extension the way HTML did when it decided to silently ignore unrecognized tags. Though maybe the ANSI "application program command" escape codes might be usable? Either way, this really seems like a question of what you're going to have to choose to break, and that's never fun.

> This is a huge fear of mine. We need to find a way of opening the GUI can- > of-worms without ending up with terminals that are as bloated as > contemporary web browsers.

Pretty much. You have a titanic advantage, since you don't have to deal with styles at all and can probably start over with a non-hierarchical layout based on integer constraint satisfaction, but you're still stuck trying to bootstrap a small OS/environment. Maybe "only" the size of something like a well- designed video game modding API (factorio, kerbal space program, MMOs, etc).

Heh, emacs might be another thing you could look at, they're having some of these issues themselves.

\</comment></comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>

What are the "killer apps" for these features? `cat foo.jpg` is a parlor trick; what could you do that'd actually make me want to switch? We'd probably be looking for small but _effective_ quality-of-life things that anyone can use - for example, fish-shell got me with "it just works" completion and syntax highlighting.

Hmm. Every tabular output (ps, ls, df, docker, random stuff massaged with awk and cut) magically having sortable columns in the original data, no rerunning the command with a different flag? Parse `--help` to make a checkbox/textbox for each flag and a "do it" button that assembles the resulting invocation? A standardized set of "quick invocations" that a command can give to the terminal to be quickly invoked with something like `M-[[:digit:]]`, so that, say, the suggestions from `command-not-found` would be a single keystroke away, or ls could provide "cd to directory 1, 2, 3"?

</comment><comment><USER86> Love:

\- Being super productive with terminals

Hate:

\- The #1 thing by far in my book is not having better support for unicode. It is not possible to accurately determine the width of a unicode character in advance of printing it in the terminal. I'm aware that there are many non- printable and control characters with unicode that don't have a 'width', but even if you neglect those, the code that determines how wide a unicode characer is, is terminal specific and there is no way to access the information in advance in order to correctly align text that contains unicode, for example with whitespace padding.

This is the kind of problem that will never bother you until it does, but then when you do encounter it, you can beat your head against the wall for weeks without finding a satisfactory solution, and the only thing that comes close is something that detects aspects of your environment on every terminal out there.

I think that improving support for unicode in terminal is something that would be a good idea to do sooner rather than later, because unicode will only get more important, and in the meantime, people will continue to build abstractions upon very poor interfaces that will need to be supported in the future. Unicode is insanely complicated, so it might be too much work to support it fully, so one solution might be to expose some API that gives people the power to make their own work around (for example, through access to an snprintf like function for where n = max print width). You could add other kinds of 'empirical test' functions that allow you to avoid the work of actually understanding the entire unicode standard (which is still changing).

Here is a github repo that documents the unicode problems I have encountered:

[https://github.com/RobertElderSoftware/roberteldersoftwaredi...](https://github.com/RobertElderSoftware/roberteldersoftwarediff)

If I had to build one from scratch:

\- If I was building one from scratch, I would probably put a better focus on separating out all the different components that actually make up the 'terminal'. In a typical bash session, you've got: /bin/bash, ttys, ptys, the terminal emulator, readline (possibly), process groups, session leaders, file descriptors, etc. This stuff is all extremely difficult to learn, and it is very 'invisible' to the average user. Most people don't need to think about it, but when you want to do certain kinds of automation tasks, they become very important.

It would be cool, if each of these concepts was formalized to provide a well- defined interface and reduce tight coupling between these components. As it is, to an average user these concepts blur together and seem like they're 'the same thing'.

</comment><comment><USER87> Edit: nvm

<comment><USER18> Are you confusing the terminal and the shell there?

<comment><USER88> Your question makes me realise I don't really know the difference and could confuse it myself. Can quickly you clear that up for me?

<comment><USER18> Well, the terminal is a piece of software that emulates a literal terminal - <AUTHOR> hardware DEC VT100 for example. This was a device with a screen and a keyboard but no CPU that sat on your desk and was connected over a serial line to a shared computer like a VAX.

[https://en.wikipedia.org/wiki/VT100](https://en.wikipedia.org/wiki/VT100)

I actually used these, a later model, in the mid-late '90's:

[https://en.wikipedia.org/wiki/VT220](https://en.wikipedia.org/wiki/VT220)

The classic green text on black background look comes from these, tho' I always preferred amber.

A shell is the software that reads input from the keyboard, takes some action, which might be to run another program, and sends that output back to the screen. The terminal emulator you are using eg. xterm or PuTTY relays from your hardware keyboard on your PC to the shell, then renders what the shell sends back to it. The kernel's TTY drivers are the glue between them - <USER2> once meaning "teletype". In the old days between the VT on your desk and the VAX back in the machine room there would be LAT [https://en.wikipedia.org/wiki/Local_Area_Transport](https://en.wikipedia.org/wiki/Local_Area_Transport)

So it's a decoupled system, with the Unix philosophy of doing one thing well, and you are free to swap the terminal you use (xterm, rxvt, whatever) and the shell you prefer (csh, bash, zsh, etc) as you please, which you couldn't do if it were a monolithic program like CMD.EXE.

<comment><USER34> I wouldn't call CMD.exe monolithic, nor is it really a terminal emulator. It's just a command line interpreter that uses the same API as any other Windows console. I.e. bash.exe is a console application, and does not use CMD.exe.

</comment></comment></comment></comment></comment><comment><USER89> I wish you luck because the standards are a mess, but the terminal seems to have been 'good enough' for quite a long time (which is why all the standard originate in the 1980s). I think to make a new terminal stick, it'll need to do something that is impossible with the current implementations rather than just try to sort out the mess.

One possibility is graphical output. It's not easy to write a 'simple' application that produces graphics right now in the same way you can write one that outputs text to the terminal (also: 'moving on' from a simple design to a more polished one generally involves rewriting the graphical portion).

A more random pet peeve: when you run a command and it goes wrong, usually the most useful error message is the first one it displays, but the terminal will scroll to display the last errors which are usually less interesting. A 'workbook' style terminal (like you might see in a CAS) might ameliorate this problem? It also helps with a command outputting a giant pile of garbage because a parameter was wrong, as well as the issue where if you're running something like a compilation job over and over to fix errors it's hard to tell which messages were from the most recent vs the previous command.</comment>


Ask HN: Excel experts – Formula IDE in Excel (MVP screenshot) – is it useful? - <AUTHOR>

Inspired by two discussions that happened this week about problems with Excel I thought of a simple
Excel add-in and would love to hear your opinion.
The aim is to let Excel users write formulas in simple IDE inside Excel. Instead of editing each of them in a formula bar you could just edit all formulas in one file (or for more advanced projects in multiple files).
What are the advantages? You could save your formulas to a separate file and import them through the add-in. This lets you easily share your formulas with others and add version control and code review to your project.
Checkout this awesome MVP I've just built in Paint: http://i.imgur.com/yBaFArn.png
Questions I was inspired by:
Ask HN: Language compiled to Excel spreadsheets? https://news.ycombinator.com/item?id=9941086
Ask HN: What are the biggest problems with spreadsheets? https://news.ycombinator.com/item?id=9935357 <comment><USER2> _> What are the advantages? You could save your formulas to a separate file and import them through the add-in. This lets you easily share your formulas with others and add version control and code review to your project._

Is this plugin meant for programmers or non-programmers? The distinction is critical because...

 _> Inspired by two discussions [...]_

You have to be careful with criticisms about Excel made by _programmers_. Discussion on HN will skew toward the programmer skillset.

The mindset of the non-programmers that use Excel is very different from programmers. To many programmers, the use of Excel looks illogical. It's a spaghetti of dependencies when formulas refer to other formulas. A complex spreadsheet becomes a ball of mud.

Those criticisms are true but they completely miss the reason why non- programmers find Excel compelling: the UI starts with a visual grid of the "output".

On the other hand, a programmer's UI starts with a blank text file (ready for the programmer to type in "do while x<10" etc.

If one studies how all these disparate groups of _non-programmers_ use Excel, the grid's visual immediacy is the common feature that they all prioritize. Diverse groups of non-programmers such as:

\- the Wall Street quants playing with rows & columns in financial models,

\- the project manager using Excel as a grid for itemizing tasks instead of using MS Project,

\- the facilities manager using Excel as an adhoc inventory system instead of learning a database product like MS Access, FileMaker, or MySQL

It's true that Excel is spaghetti but non-programmers prioritize the grid over the resultant spaghetti. In contrast, programmers prioritize code organization (formulas) over the visual grid. These 2 groups are not even on the same wavelength.

Your proposed tool is helpful but it doesn't really address a burning need for _non-programmers_. For example, your mockup shows the formulas off to the side and disconnected _spatially_ from the cell. That separation is fine for programmers (who can mentally connect things like CSS rules in a .css file to elements in the .html) but not user-friendly for non-programmers.

<comment><AUTHOR> Thanks for this perspective.

As a programmer I haven't actually thought much about how important this link between a cell in a grid and its formula may be.

I have seen huge (i mean HUGE) Excel files full of complex formulas being built by non-programmers. Some even took whole night to recalculate. There was a programmers mindset emerging from those files - extracting common formulas to separate cells (DRY), writing 'unit' tests by using formatting (if result for sample input is less than 0 then make the cell red - which means someone broke the formula).

The question arises - is there a point where a non-programmer starts thinking like a programmer, on a different level of abstraction? Is it possible to teach non-programmers some basic programming practices to make their work easier?

</comment></comment><comment><USER3> I'll just relay my thoughts. It's a bit sour, but me and Excel we go way back. Perhaps you can find something in it:

1\. Anyone who can get an add-in pasted corporate software security can also use a better tool outside Excel. In other words: think carefully about the customer. Users don't buy plugins in larger businesses, etc.

2\. It looks pretty useful and would help users create a bit more structure in their sheets and calculations.

3\. My idea of why terrible Excelsheets seem to be the norm, is that 'build once-use once' does not exist in business. Too often your boss wants you to redo your calculation and after a few iterations, time not spent documenting / cleaning catches up with you in Excel.

Often you also build one workflow and apply it to many not-quite the same situations. Tweak a few cells here and there. Hence custom workflows per worksheet and again, broken (re-)usability.

Your tool would help to start with a more long term perspective, and help in iterating on a sheet. Might even be faster to type, than to click-point and type.

But my baseline response would be near number 1. Plugins from Excel to R and Python exist too, but still all the sheets I see internally, and code even professional consultants come pitching is in VBA or some proprietary format. The Venn-diagram between programming and Excel has no overlap imho.

<comment><USER4> _> 1\. Anyone who can get an add-in pasted corporate software security can also use a better tool outside Excel. In other words: think carefully about the customer._

What other tools are available? A lot of technical people don't choose Excel, but come into situations where Excel has been relied upon historically and the non-technical people do not want to move away from it. So I could see such a plugin having value in these situations (non-technical people continue to use the spreadsheet as-is, while the programmer improves it via the plugin), which I would imagine are quite common (I have been in this situation before).

 _> Users don't buy plugins in larger businesses, etc._

Fact or opinion?

<comment><USER5> >> Users don't buy plugins in larger businesses, etc.

>Fact or opinion?

Users definitely buy plugins, but these bring significant functionality and often tie-in to additional services. Financial data being the most familiar to me. These plugins, while wrapped in VBA, are often in C++ (again, finance world) for robustness and performance, and try to be as agnostic to whatever nutty layout or logic a user chooses to have for their spreadsheet.

So, agree, with the pragmatic assertion that technical people love Excel as a UI, but they're probably not necessarily developer-technical (could be, given the richness of Excel plugins can have on some platforms), but technical in another field and Excel is an easily hackable UI for what they really want to do, which is mainly, as the OP suggests, using Excel to change stuff and do what-ifs, which spreadsheets were designed to do (as if, to close the circle).

</comment></comment></comment><comment><USER6> Have you checked out PowerPivot? I've been developing in Excel for 15 years and created many a convoluted formula along the way. Two years ago I moved all Excel development to Powerpivot and I hardly write any formulas in "regular" Excel anymore. PowerPivot provides more of a formula IDE (along with DAX Studio), along with a ton of other functionality. I think it's clear that's the direction sophisticated Excel development is going.

<comment><AUTHOR> I haven't seen that. I tried installing it on my Excel but it looks like kind of pro version is needed for PowerPivot. I'll try to find some more information on it. Thanks!

</comment></comment><comment><USER7> Excel is already programmable via everything from Powershell to VB to F# via its .NET bindings. The problem isn't that anything is missing from Excel, it's that it's used by so many people who are not 10x software engineers that no higher-level approach will ever work with 99,5% of the Excel out there.

The people who are organized enough and use Excel enough to find value in saving formulas in a library are already extreme edge cases...and then you are selling into that tiny market against the idea of using full blown tools like Visual Studio and C#.

And it seems to me that really sound previously snakebit engineers aren't going to go around changing working software that isn't backed up by a suite of regression tests. The problem isn't Excel, it's bad code. The cause of the bad code is bad programming practice, and the reason for that is that the people programming are not programmers and even if they were they're under just give me a kludge time pressure.

Spreadsheets are successful because they're really easy to use. Excel dominates because making one that's userful for important work is really really hard.

Good luck.

</comment><comment><USER8> I like the concept, when debugging some complex sheets that could come in handy - though having all the formulas in a windows might hinder understanding the layout of the sheet, especially if you are lazy and don't label all your cells (or just know enough about excel to be dangerous).

I thought it would be cool if formulas would pop into little syntax highlighted text edit areas when double clicked (or some other meta-click)

I think having a look at some more complex sheets would be good. (Ask for your company's accounting department I'm sure they have some Excel monsters lurking on desktops).

<comment><AUTHOR> I like the concept of simple editor for the formula.

Maybe an editor that would extract all formulas from the sheet and give you different view after double click would be a good solution. On one hand you would still have your normal spreadsheet but you can go to a different level if you want to do refactoring etc.</comment></comment>


Ask HN: Second Part-Time Job? - <AUTHOR> I've had a stable (remote) SWE job for company A that pays 6-figures. I feel under-challenged and not super-excited about the industry (marketing), so a few years ago I took on a side-gig at company B in a completely different industry to learn new things, did that for about 8 months (not impacting my job at company A as I would work evenings). Then I quit company B (on good terms), for the following reasons 1)was not super happy with the engineering practices. Code that was produced by other engineers was - to my standards - not of high quality (testing wasn't enforced, random bugs would pop up, lots of patches etc) 2)B was in a complete startup-phase so big uncertainty about the future 3)got burnt out and wanted a shift to focus on open-source projects in the AI domain (which I built and still do, on the side, not making any $ for those currently but being excited about building them)
Now, years later, B has seemingly (survived?), raised $$$ and since I left on good terms they want me back (with higher base offer than what I currently make at A, and higher pay than what I was making last time I worked for them). So my options are
a) stay at a "boring" (remote) job at A (being under-challenged), decline offer from B and have time to work on open-source AI libraries (that really excites me) in hopes of productising those and making $
b) stay at a "boring" (remote) job at A and take on a side-gig at B as part-time in hopes that engineering practices have improved, make a lot more $$$ per paycheck, though sacrificing time spent on open-source AI libraries.
c) quit "boring" (remote) job at A, and join B full-time in hopes that engineering practices have improved and make a bit more $ than at A, and have time to work on open-source AI libraries
What option would be best in your opinion? <comment><USER2> I took a part time job (brewer) and was able to negotiate my hours at my day job (sysadmin) to 75%. It works out to about 50 hours a week, but I don't commute for either.

It was a really good decision for me, as I was very unhappy for a while. I usually work from 7-5 every day, and still have time for a social life and side projects. The brewery gives me perspective and a release from my frustrating sysadmin job, and the sysadmin job provides me good pay and mental stimulation. The result is I'm happy and productive at both places.

I guess in your options, it would be closest to B.

I think the key is to make sure you have limits on your hours in both areas, so that they don't take over your life. If your side projects are just for fun, a few hours here and there on weekends/evenings will be relaxing and you'll find time for them.</comment>