41–50 of 204 posts
I love tab completion. 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?
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.
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 term…
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
Yes, changing the cursor position with the mouse while typing a command would be handy in some situations!
Earlier quoted context omitted.
This. I would love to be able to type "[command] --[tab]" and have it list all the options, and/or common options, so when I'm learning 'tar' I don't have to start typing, realize I've forgotten the command, and then have to go use man or --help or go Google it.
Have you checked out ZSH? It can do this nicely.
for example, i do the following:
anupam@virat ~ % autoload -Uz compinit
anupam@virat ~ % compinit
anupam@virat ~ % git a
add -- add file contents to index
am -- apply patches from a mailbox
apply -- apply patch to files and/or to index
archimport -- import an Arch repository into git
archive -- create archive of files from named tree
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…
> 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…
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.
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 term…
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.
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.