91–100 of 204 posts
- 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.
Earlier quoted context omitted.
"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.
> "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 h…
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).
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…
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.
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.
I hate that commands are difficult to discover.
I would love to contribute to this group. How can I get involved?
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.
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)
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.