14 ms·

Ask HN: What do you love/hate about terminals? Would you change them?

• useranme 9y ago
  I love tab completion. I hate that the terminal and the browser are two different applications.
  • thinkMOAR 9y ago
    shivers thank god they are two different applications. And i'd prefer the two very different functions remain separate programs, i don't need my terminal client to be vulnerable for browser issues (or vice versa).
  • dotancohen 9y ago
    They don't have to be! See: w3m and vimperator / Tridactyl
    • tbrock 9y ago
      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
  • wojcikstefan 9y ago
    > I hate that the terminal and the browser are two different applications. I'm curious, why would you want that? What is the benefit of having these two applications with separate concerns becoming one?
• tylercubell 9y ago
  Edit: nvm
  • gaius 9y ago
    Are you confusing the terminal and the shell there?
    • duiker101 9y ago
      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?
      • gaius 9y ago
        Well, the terminal is a piece of software that emulates a literal terminal - a 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 - TTY 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.
        • joombaga 9y ago
• notalex 9y ago
  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.
• pm215 9y ago
  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.
  • deleted 9y ago
    [deleted]
  • stevewillows 9y ago
    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.
    • signa11 9y ago
      iirc, there is a program called 'nl' that should do the trick
      • jwilk 9y ago
        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.)
        • stevewillows 9y ago
          well, would you look at that! -n is great. > sed -n 16p filename > newfile where 16 is the line number.. this is it! That's quite handy.
        • signa11 9y ago
          > ... 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...
• gaius 9y ago
  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.
  • jstimpfle 9y ago
    Totally agree. That's the idea of a terminal. There are times and places for other more featureful technologies as well, but these are, well, not terminals... But still, do you have any "small" things that could be improved. There was someone suggesting that any keypresses / releases should be sent (also Shift/Ctrl etc). I like that to some extent, but I'm afraid it already breaks a lot of usecases. Maybe the question should be more like, as a DevOp / Sysadmin / Developer, what does your ideal environment look like? And the answers will be as varied as the people asked.
  • JdeBP 9y ago
    * https://news.ycombinator.com/item?id=8595907 https://news.ycombinator.com/item?id=8595907 * https://news.ycombinator.com/item?id=16014573 https://news.ycombinator.com/item?id=16014573 Enjoy.
  • jdc0589 9y ago
    > 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.
    • pecg 9y ago
      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.
      • 9y ago
• kapauldo 9y ago
  I love screen and tmux, but page up and down and copy paste are hard.
• daniel12fsp 9y ago
  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
  • swiley 9y ago
    That would only need a modification to the GNU readline library (if it doesn't already support it.)
  • yoodenvranx 9y ago
    Yes, changing the cursor position with the mouse while typing a command would be handy in some situations!
    • neilsimp1 9y ago
      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.
      • yoodenvranx 9y ago
        > 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.
• bugshideout 9y ago
  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
  • O_H_E 9y ago
    Terminology does allow you to click a file after ls
• skrebbel 9y ago
  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.
  • jstanley 9y ago
    Text mode is handy because it works transparently over SSH.
    • skrebbel 9y ago
      Sounds like a solvable problem, right? The same protocol that allows the shell to communicate with the terminal window can be used over SSH. I don't know much about how SSH works, but there has to be a way to communicate between the daemon and the client that both support this protocol and send the data separate from the screen content? In the typical case where you SSH from your own terminal window your ssh client just forwards the connection to your terminal window and done. It's not like anything stops working when this stuff isn't there. It's just like colors in that respect.
  • swiley 9y ago
    >Modern IDEs can tell me exactly what can follow after a certain piece of text I don't think that's computable in a terminal.
    • skrebbel 9y ago
      It could be, if there was a standard format or protocol by which a shell can ask a command what flags/options make sense in what context. A bit like how man pages are a standard format for static docs, every tool could ship "autocomplete files" which tell a shell how to build the autocomplete. These files could even contain runnable code (in sh or something) without an additional security risk - after all, they came with a program that you're about to run :-) I'm sure there's all kinds of challenges with this when you go deeper, but when even a relatively lightweight tool like VS Code can give me perfect C# IntelliSense on every major OS, I find it a bit abysmal that unzipping a file from the terminal is non-trivial.
• polygot 9y ago
  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".
  • joombaga 9y ago
    What long archaic command are you running? 'clear; reset' usually does it for me.
    • polygot 9y ago
      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-bar-corrupted-after-catting-a-binary-file-how-to-reset https://unix.stackexchange.com/questions/49886/tmux-status-b... stty sane; printf '\033k%s\033\\\033]2;%s\007' "`basename "$SHELL"`" "`uname -n`"; tput reset; tmux refresh
  • terminal-survey 9y ago
    Our draft already contains a command for "set terminal into ignore-escape-sequences mode". I added that last week when someone showed how to hide malicious code in "git diff" by using specifically crafted control sequences.
  • JdeBP 9y ago
    Two errors there. 1. "reset" is six keypresses long, seven if you use the Control+J approach (although terminal control codes do not affect the line discipline and won't by themselves upset the newline settings of the line discipline in the first place), and not really archaic or long. On many terminal emulators, there is a menu option on the emulator that does the very same thing. 2. The mosh people addressed this problem years ago, and made a lot of noise about doing so. It's mainly a matter of just not supporting the old ISO/IEC 2022 control sequences for changing 7-bit character sets. See https://news.ycombinator.com/item?id=13904008 https://news.ycombinator.com/item?id=13904008 for more.
• sajithdilshan 9y ago
  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
• yoodenvranx 9y ago
  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.
  • terminal-survey 9y ago
    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).
• ivanbakel 9y ago
  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.
• dsr_ 9y ago
  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.
• nhooyr 9y ago
  I would love to contribute to this group. How can I get involved?
  • terminal-survey 9y ago
    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.
• ansible 9y ago
  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.
  • jstimpfle 9y ago
    "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.
    • jitl 9y ago
      There are already terminals and cat implementations that can display 24-bit images just fine in the terminal, by using special escape codes that each encode a pixel. No changes to the IO model needed. https://github.com/saitoha/PySixel/blob/master/README.rst https://github.com/saitoha/PySixel/blob/master/README.rst
      • jstimpfle 9y ago
        Sure - this is what I mean by "protocol". In the case of the image format you linked even cat does work, because the image format contains pre-rendered escape sequences. This does not work in general (e.g. for JPEG or other formats) - where you need a program that does the transformation into escape sequences.
    • lornemalvo 9y ago
      While plain `cat` does not work, using escape sequences and providing support in the terminal emulator allows already to display images inline. See the iTerm2 implementation here: https://www.iterm2.com/documentation-images.html https://www.iterm2.com/documentation-images.html Making plain `cat` work too should not be too big of a problem with some small support from the running shell. iTerm2 also knows when a command is starting to run/exits, parsing the output it retrieved from STDOUT in between by matching it against some magic numbers and displaying the content accordingly is not too difficult.
• mmjaa 9y ago
  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.
  • JdeBP 9y ago
    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-hardware-terminal https://hackaday.io/project/13273-diy-vt100-a-miniature-hard... * https://hackaday.com/2010/02/24/oscilloscope-doubles-as-a-serial-terminal/ https://hackaday.com/2010/02/24/oscilloscope-doubles-as-a-se... * https://tech.scargill.net/vt100-terminal-for-hc2016/ https://tech.scargill.net/vt100-terminal-for-hc2016/
    • mmjaa 9y ago
      Quite nice .. I wonder if there'd be demand for an upscale version of these, sort of more turnkey and less hack.
• tezza 9y ago
  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 ?
• carreau 9y ago
  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 <a> 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.
  • signa11 9y ago
    changing terminal-titles is just a google search away. or perhaps i am missing something fundamental. may you please elaborate? thanks!
    • carreau 9y ago
      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 ?
      • signa11 9y ago
        > 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)'
• rhizome31 9y ago
  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.
  • JdeBP 9y ago
    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
• evolighting 9y ago
  I always hate long output; Since there is no direct "roll up" most times
• beefhash 9y ago
  > - 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.
  • pecg 9y ago
    Couldn't agree more with you. Simplicity is the key to a sane world. I haven't had any problems with colors or fonts with st since I dropped urxvt in favor of the former. It is also harmful to assume that bash is always present, or worst, that it is the default shell; I've spent a reasonable amount of time learning how to effectively write portable shell scripts that can run in any Unix-like system, because portability is important. Bash is huge, and that makes it more prone to error and bugs, not to mention slower, the perfect balance I've found between speed and interactivity is mksh, I know dash can be faster, but it only works for scripting, as an interactive shell it sucks, and that's ok.
  • 9y ago
• mediamonster 9y ago
  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.
  • JdeBP 9y ago
    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.
• logicalshift 9y ago
  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.
• padthai 9y ago
  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.
• jstewartmobile 9y ago
  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.
• baq 9y ago
  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.
  • terminal-survey 9y ago
    > 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.
    • foobarian 9y ago
      I use an eternal history setup for bash, with bash session tags that let me sort history by tag for correct backward-search behavior. (edit) Not to imply this functionality belongs to a terminal, far from it. But it's nice to have access to 2 years of shell commands :-)
    • chainsaw10 9y ago
      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).
      • baq 9y ago
        thanks, i'm sure you've just saved a couple hours for a future me :)
• JdeBP 9y ago
  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=ce7b9f50c3fadbad22feeb28e4429ad9bee02bcc https://cgit.freedesktop.org/systemd/systemd/commit/?id=ce7b... * https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/8fQ9t9pmUuT https://plus.google.com/+LennartPoetteringTheOneAndOnly/post... * 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
  • jstewartmobile 9y ago
    Your stack exchange post is epic. Thank you! I have some reading to do...
• btschaegg 9y ago
  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
  • terminal-survey 9y ago
    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.
    • btschaegg 9y ago
      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 ;-) ).
      • terminal-survey 9y ago
        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).
  • bitwize 9y ago
    So basically, you hate ASCII and Unicode.
• brianon99 9y ago
  It is difficult to build a TUI. Just to draw several progress bars might take a whole day to implement.
  • jitl 9y ago
    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.
• ordu 9y ago
  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.
  • terminal-survey 9y ago
    > At first I would state one curious fact: [...] That part is so nicely said I might just steal it for our manifesto. :)
• robertelder 9y ago
  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/roberteldersoftwarediff https://github.com/RobertElderSoftware/roberteldersoftwaredi... 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'.
• icc97 9y ago
  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.
  • JdeBP 9y ago
    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.
• jacques_chester 9y ago
  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.
  • terminal-survey 9y ago
    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.
    • geokon 9y ago
      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
• terminal-survey 9y ago
  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.
• falcolas 9y ago
  > 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.
• TheCondor 9y ago
  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.
• dmytrish 9y ago
  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.
• SAI_Peregrinus 9y ago
  I like that they're easy to automate actions with. I hate that commands are difficult to discover.
  • O_H_E 9y ago
    Exactly what I think
• n34r 9y ago
  built-in copy-paste feature
  • foobarian 9y ago
    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.
• nmstoker 9y ago
  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)
• dmytrish 9y ago
  > 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.
• SteveMorin 9y ago
  I am very interested in this, and would like to contribute. How do I get in touch with you?
  • O_H_E 9y ago
    Answer from OP https://news.ycombinator.com/item?id=16015163 https://news.ycombinator.com/item?id=16015163
• ajkjk 9y ago
  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.
  • d0lph 9y ago
    I actually kind of like it, powershell also has -eq, and there's no chance of mixing up assignment and equality operators.
    • JdeBP 9y ago
      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" .
      • d0lph 9y ago
        "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.
        • JdeBP 9y ago
          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.jpg http://gordonbell.azurewebsites.net/ibm-026/ibm-026-ref-27.j... Rex Conn knows how a real language does relational operators. * https://jpsoft.com/help/conditionalexpressions.htm#r https://jpsoft.com/help/conditionalexpressions.htm#r
• gwbas1c 9y ago
  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.
  • geocar 9y ago
    > 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.
    • gwbas1c 9y ago
      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.
• jdc0589 9y ago
  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.
  • mr_overalls 9y ago
    At the risk of starting a quasi-religious argument, the object-orientation of Powershell is one of the things I really like about it.
    • jdc0589 9y ago
      I don't really care about how they tried to solve it, I'm just glad they addressed it.
    • tonyedgecombe 9y ago
      It is nice although quite difficult if you are just an occasional user.
      • jdc0589 9y ago
• nathcd 9y ago
  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
• happyhotpocket 9y ago
  I want a terminal that writes from the top down instead of from the bottom up.
  • terminal-survey 9y ago
    You mean that it should scroll in the opposite direction?
• saulrh 9y ago
  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.)
• sametmax 9y ago
  # 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.
• waqf 9y ago
  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.
  • EpicEng 9y ago
    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.)
    • terminal-survey 9y ago
      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.
      • deleted 9y ago
        [deleted]
      • EpicEng 9y ago
        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 :)
        • 9y ago
• erikj 9y ago
  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.
  • baq 9y ago
    looks like powershell stole at least some of those ideas, which makes sense given what it is.
  • jstimpfle 9y ago
    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.
    • erikj 9y ago
      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.
• matt_wulfeck 9y ago
  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.
• dandare 9y ago
  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.
• shortoncash 9y ago
  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.
• ravenstine 9y ago
  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.
  • sigjuice 9y ago
    M-x shell in Emacs lets you use your mouse.
• hungerstrike 9y ago
  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.
• EliRivers 9y ago
  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.
• otron 9y ago
  > - 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.
• acrooks 9y ago
  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.
  • adambyrtek 9y ago
    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/
• bitwize 9y ago
  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.
• tremaali 9y ago
  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.
• JasuM 9y ago
  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"