Live data from Hacker News

Why is the terminal input so weird?

warp.dev

41–50 of 185 posts

Re: Why is the terminal input so weird?

#41

> This post is about why terminal-based input seems stuck in the 80s It's actually more 60s/70s, when the first terminals, command-line prompts, and shells were built. The reason why it's stuck there is technology has only improved iteratively rather than revolutionarily. The "lets add another layer of abstraction" form of innovation, rather than outside-the-box thinking and reinvention. The fact that we still write…

> The fact that we still write software by hand using lines of source code in a text editor is pretty ridiculous to me.

Agreed. This makes some changes that could be simple unnecessarily hard. Formatting shouldn't even be a thing. FWIW though, having an auto-formatter on save has solved a big chunk of that pain for me.

Re: Why is the terminal input so weird?

#43
A lot to be said about this - setting aside the privacy/login/pricing stuff, I think the problems and solutions here are vastly overstated.

Yeah, terminal input is odd at times. Doubly so if your main prior experience is entering text into HTML textareas. There's a learning curve, but there's a benefit to tackling that curve. For one, you get readline editing, which is _far_ more powerful than the textarea comparison, and it's customizable. For another, if you need to use your editor to manage a larger command, you have that exact option (see Ctrl-X Ctrl-E in bash/readline). That editor can be vim, or it could be your pimped out VSCode with Copilot. Bash doesn't care.

When you think about it, that's a good 70% of the article's complaints resolved. Trouble navigating through lines of command input? Learn your readline keybindings, or just pop it open in your editor of choice, which also grants you syntax highlighting and whatever else.

The other 30% of what article proposes are pretty decent ideas. Why _isn't_ there a way to hover over a command and see a snippet from its manual page, or to hover over a command-line flag or option, and see the data from the manual page? We have bash-completion which can provide us command-specific completion, what about docs? Many new features can be added to the current architecture. For example, OSC 52 allows terminal apps to send data to the clipboard so long as the terminal emulator supports it. I don't see why similar extensions couldn't enable applications to annotate text with documentation, etc. But that doesn't require the terminal to take over all the line editing: it's just incremental improvement to the current system.

And that's where I think this article and approach are wrong. Maybe it works with the user's shell, but what about Python? GDB? Or the myriad other command line tools I use on a daily basis? As it is now, my terminal is responsible for being the best "terminal emulator" possible. It handles input, draws to my screen, and does it fast. It doesn't need to concern itself with supporting GDB: it is a terminal, and that's that. I'd rather not see these layers get smooshed. Let's focus on improving the current system so that GDB, readline, and the other pieces of the puzzle can incrementally improve the situation.

Re: Why is the terminal input so weird?

#44
post #30

Warp currently requires a login to enable cloud-based features, like A.I. Command Search and Block Sharing, along with team features on the roadmap. In case there was any confusion, Warp never sends the contents of terminal commands and outputs to our servers (unless a user explicitly chooses to use the "Block Sharing" feature). What Warp currently sends in regard to telemetry is listed here: https://docs.warp.dev/ge…

Still too much telemetry in my opinion. Is it possible to opt out, perhaps for a price?

We are actively working on making telemetry opt out. We are very sympathetic to concerns about telemetry and data collection and try to be as transparent as possible about what we collect and why. We only collect metadata and never command input or output (you can see the full list of events we track here: https://docs.warp.dev/getting-started/privacy#exhaustive-tel....

We initially required telemetry for all users while in beta so that we could have a better understand of usage patterns and improve the product in its early stages. As we mature, we are able to better extrapolate from a larger sample size without requiring telemetry.

Re: Why is the terminal input so weird?

#45
post #7
post #2

I can edit the terminal input line with full vim-mode in my shell (zsh). In fact, in normal mode I can even hit 'v' and edit the line in a full vim session to zip around however I want, do completions, etc. It's pretty close to the platonic ideal method of input I could imagine.

I’m also using vim mode in zsh with simply "bindkey -v". I’m interested by your "v" as full vim session shortcut. Do you mind sharing the config?

It's this section of my .zshrc here:

  # edit long commands
  autoload -U edit-command-line
  bindkey -M vicmd v edit-command-line
That `edit-command-line` autoload script is part of zshcontrib and should be installed by default on any recent zsh distribution. I've never encountered a server I've ssh'ed into that didn't have it. Enjoy :)

Re: Why is the terminal input so weird?

#46
post #30

Warp currently requires a login to enable cloud-based features, like A.I. Command Search and Block Sharing, along with team features on the roadmap. In case there was any confusion, Warp never sends the contents of terminal commands and outputs to our servers (unless a user explicitly chooses to use the "Block Sharing" feature). What Warp currently sends in regard to telemetry is listed here: https://docs.warp.dev/ge…

Still too much telemetry in my opinion. Is it possible to opt out, perhaps for a price?

Yes! We are working on opt-out for telemetry.

Re: Why is the terminal input so weird?

#47
post #3

As much as I'd like to encourage the rethinking of input methods, any terminal with a "Pricing" page is an instant nope from me. My current terminal is Open Source and while it's not perfect, it's also Free. That matters more to me than mouse input or IDE autosuggestions. If you're going to treat Linux users as a second-class citizen and charge for corporate usage, who are you hoping your target audience will be? Fra…

The app is 100% free for any and all individuals. The business plan is to create collaborative and cloud-based features that businesses will be willing to pay for. Please check out our pricing page to learn more. Please note that our business model is not about collecting and monetizing any of your personal data. https://www.warp.dev/privacy

It has to be open-source (meaning (A)GPL, MIT, BSD, Apache, etc.) to be even considered by bigger organizations (especially in Europe). I worked with medium and large organizations and if you're fully open-source you can even get funding [to help distributing open source infrastructure software], but if you do the "shady open-core" model I can't use it at least where I work.

Re: Why is the terminal input so weird?

#48

> This post is about why terminal-based input seems stuck in the 80s It's actually more 60s/70s, when the first terminals, command-line prompts, and shells were built. The reason why it's stuck there is technology has only improved iteratively rather than revolutionarily. The "lets add another layer of abstraction" form of innovation, rather than outside-the-box thinking and reinvention. The fact that we still write…

What would you prefer it to be? Audio recording of spoken words? Diagrams like Labview?

Code is really a tree of stuff. There are are somewhat more powerful editing paradigms for trees than bare text.

The editor I'm imagining looks and works a lot like your typical code view, but has a better understanding of the semantics and makes things there are keyboard shortcuts for more visible. From the top of my head: First-class code folding and commenting and actions primarily on blocks rather than lines. e.g. if you disable ("comment out") an if-statement, either disable the whole block or the wrapping of the inside code with the condition. It's very rare that you want to do something in between and in textually based languages this action is much harder than it needs to be without producing a syntax error.

An important part of GUI design is to avoid the possibility for invalid states, but text-based code editing in its current form produces a lot of them, totally unnecessarily and annoyingly so, in my opinion.

I'm sure that tools with features like this already exist, but they're certainly not popular.

Re: Why is the terminal input so weird?

#49
post #4

Although I don't like terminals, I think the article overstates the problems to significant degree. The fact that text editors running in terminal still manage to have "ide-like" experience (including mouse input!) proves that you can do a lot with terminals. I still think that trying to move beyond terminals is good idea, but it's important to distinguish what is impossible, and what is just ugly/hacky to do.

Aloke from the Warp team here--you're totally right that some of these features (syntax highlighting) can be accomplished within the terminal using an editor. In a traditional terminal--you'd have to spend time configuring your shell to get this to work instead of getting these features by default. Some of these features are near-impossible given the current terminal-shell abstraction, however. For example, a traditi…

> it can't suggest a next command to run based on the output of the previous command

thefuck (https://github.com/nvbn/thefuck#how-it-works) does exactly that...

Re: Why is the terminal input so weird?

#50
post #4

Although I don't like terminals, I think the article overstates the problems to significant degree. The fact that text editors running in terminal still manage to have "ide-like" experience (including mouse input!) proves that you can do a lot with terminals. I still think that trying to move beyond terminals is good idea, but it's important to distinguish what is impossible, and what is just ugly/hacky to do.

Aloke from the Warp team here--you're totally right that some of these features (syntax highlighting) can be accomplished within the terminal using an editor. In a traditional terminal--you'd have to spend time configuring your shell to get this to work instead of getting these features by default. Some of these features are near-impossible given the current terminal-shell abstraction, however. For example, a traditi…

> For example, a traditional terminal has no concept of command input/output, which means that it can't suggest a next command to run based on the output of the previous command.

Neither does wayland or whatever. Point being that you can treat terminals as dumb character cell grid display with slightly wonky input mechanism and get quite far ignoring/working around all the traditional line-oriented stuff.

Post reply on HN