GNOME Bugzilla – Bug 721689
Visually differentiate each command
Last modified: 2021-06-10 20:39:45 UTC
When you scan through the output in a terminal, you really need to be able to see where each command ended and the next began. Right now this is quite hard to do, and is taxing on the user. It would be really good to look at ways to make each command visually stand out. There are two ways I can think of doing this: 1. Add a bit of line spacing after each command. This would create a visual break which the eye could pick up on. 2. Dim the text of the output from previous commands. This would differentiate the output from the previous command compared with other older output.
For 1., you can make extra space by putting it into PS1 (or precmd hook in zsh). However setting PS1 isn't really the domain of the terminal… For 2., not easy. The terminal doesn't know about 'previous command' or anything, it's just terminal output for it.
For 1., I think colors are easier to spot than empty lines, especially when combined with other tricks (background color, italics, underline etc.). Here's my bash prompt (simplified a bit), give it a try: PS1=$'\\[\e[0;3;38;5;34m\\]\u@\h:\w$\\[\e[0m\\] '
Created attachment 265684 [details] mockup for terminal visuals (In reply to comment #2) > For 1., I think colors are easier to spot than empty lines, ... To clarify - I'm not suggesting that a full line be added. The extra vertical space after the command should be less than a line; this breaks the repetition of the line spacing, thus grabbing attention. Colours are good as a way of differentiating the command prompt, and I'm in favour of them as part of a default configuration. Colours and helpful line spacing aren't mutually exclusive though, and can complement one another. I've attached a visual experiment to give an idea of what kind of improvements could be made.
This would break the fundamentals of what a "terminal" is (and has been for ~35-40 years), we'd need to restart and rewrite this part of computer history from scratch. It's not going to happen. A terminal is by design a device with a fixed grid of character cells, and with the ability to move the cursor around, either relatively (up/down/left/right) or absolutely (directly to a cell given by its coordinates), how would you define these actions? How would you control the properties of that partial line (background, but probably also some content)? To what extent would the height be controllable, e.g. half line only, or quarter, or almost arbitrary? Topmost line would possibly be cut which wouldn't look nice, and we'd need to figure out how the grid (window size hint) when resizing the window should work. If we're no longer aligning vertically, should we also no longer align horizontally either for flexibility and feature parity? I don't say it's impossible, but it'd cause tons of headache, compatibility issues, and would only make sense if all other popular terminals implemented it too and got library (ncurses/slang) support and significantly heavier application usage than just a half empty line between prompts (for which I don't see a demand, any applications requiring such a fine grained control are probably standalone graphical apps). This would be very complicated to lay down a good specification, very complicated to implement, and way too much ado about (almost) nothing.
For dimming, and idea for a giant horrible hack that you could experiment with: Assuming none of your commands uses any colors (not even resetting the color just for the purpose of turning off bold or something like that)... The prompt may have colors, that's okay. The terminal has a palette of 256 colors, of which only the first 16 are widely used. The palette is redefinable. You can define #16 to be white, #17-255 to be gray, and switch to #16 at the end of your first prompt. When the next prompt is printed, it could redefine #16 to gray, #17 to white, and switch to #17 for the next command line, and so on, rotating among 240 different logical colors so that always the most recently used is white, the rest are gray. Or just simply switch back and forth between two slightly different colors, without redefining the palette.
(In reply to comment #4) > This would break the fundamentals of what a "terminal" is (and has been for > ~35-40 years), we'd need to restart and rewrite this part of computer history > from scratch. It's not going to happen. ... The OS X Terminal allows you to set the line spacing; it would be interesting to see what they do for commands that use curses, etc.
But then it's applied between all the lines, isn't it? In that case it's purely a drawing thing, just as if you selected a different font, nothing to do with the actual logic. Unfortunately I don't have access to a Mac.
I've checked and the OS X Terminal dims the text of old output.
Please get a script(1) log for it, using simple commands.
iterm2 renders a mark in the left margin of the command prompt [http://iterm2.com/shell_integration.html#/section/home], maybe that's something to consider here?
If it's just about rendering a mark and nothing more, then I'd say no. You can already modify your prompt to begin with a Unicode triangle, and it's almost the same – with much bigger flexibility, since you have total control over which Unicode glyph you choose, plus its colors – and you get it for free, zero code change to vte/g-t, and a one-line change to .bashrc (PS1). Introducing special code all over vte (incl. figuring out how to store these in the stream, draw / update the display, increasing the padding on the left to make room for it, probably some people will object against it), requiring special integration with the shell, and probably not being able to customize its look and color, IMO it's just really not worth the trouble. I've already recommended a colored prompt in comment 2, it's already a huge win that you can have for free – it's strange to see that distros ship a totally boring prompt, and expect it from the terminal to help distinguinsh commands, but don't consider pimping up the prompt. (Just take a look at https://github.com/robbyrussell/oh-my-zsh/wiki/themes and stop to think for a moment: Do you really need something from the terminal that it doesn' offer yet?) (Nowadays I'm managing servers that are named after the characters of a certain cartoon. I've changed the prompt on all these hosts to begin with "▌" (U+258C left half block) in two colors that are specific to that particular cartoon figure. This is a great help both in locating the previous command, as well as in subconsciously telling me which host I'm logged in to.) -*-*-*- If, however, we'd take it a step further, and plan to offer e.g. a shortcut to jump to the beginning of the previous prompt, then it's definitely something to consider. (Although, we kinda have that too: you can use the terminal's search functionality for a constant text in your prompt (e.g. your username). Of course I understand it's really not convenient.) A shortcut key jumping to the next/previous prompt is definitely something I'd use frequently. The question in this case is probably how far are we planning to take it? Do we want to be an everything-but-the-kitchen-sink emulator like FinalTerm and iTerm, where the terminal does command completion, scp by dnd, context menus and so on? Or do we stop at just understanding where the shell prompt is? I'd say let's take some time to study what and how iTerm and FinalTerm do, look at the escape sequences they introduce, and maybe choose one or two that we find very useful and realistic to implement. As for the prompt, I might even be up for an approach where we don't add visual clues (we leave it to the user to add to their prompt), but with the extra escape sequences we know where a prompt is displayed and use it only for the shortcut key that jumps to the prev/next.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/7400.