[HN Gopher] Why is the terminal input so weird?
___________________________________________________________________
Why is the terminal input so weird?
Author : zachlloyd
Score : 96 points
Date : 2022-11-16 18:38 UTC (4 hours ago)
(HTM) web link (www.warp.dev)
(TXT) w3m dump (www.warp.dev)
| giantdude wrote:
| This is 'Hacker News'. Hackers like open source.
| VWWHFSfQ wrote:
| Let's be honest here, nobody is using this warp terminal as long
| as it's closed-source and especially not when it has built-in
| tracking.
|
| To the warp terminal developers:
|
| I'm sure your terminal program is great, but stop posting this
| content-marketing stuff here. It's not your audience.
| motbus3 wrote:
| learn vi set -o vi You are free
| CharlesW wrote:
| What do heavier terminal users think of Warp's philosophy vs.
| Fig's (which I've found useful as a relatively-light terminal
| user)? https://fig.io/
| brendanfalk wrote:
| Founder of Fig here. For context, Fig integrates with your
| existing terminal and shell.
|
| A few things we've found: 1. Developers are understandably
| opinionated about their terminal/shell setup. It's a matter of
| personal productivity. 2. We have noticed a general trend of
| more terminal use happening in IDE, not a standalone terminal.
| 3. Most terminal "collaboration" happens asynchronously not
| synchronously (e.g. shared scripts, CLIs, secrets etc as
| opposed to live terminal sharing) 4. Most of the collaboration
| happens at the shell level not the terminal level
|
| Given the above, we made the conscious conscious decision _not_
| to build our own terminal.
|
| Happy to elaborate more
| 0xbadcafebee wrote:
| > 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 software by hand using lines of
| source code in a text editor is pretty ridiculous to me. It's not
| that far removed from punch cards.
| maximus-decimus wrote:
| What would you prefer it to be? Audio recording of spoken
| words? Diagrams like Labview?
| solarkraft wrote:
| 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.
| __MatrixMan__ wrote:
| Sounds like emacs paredit mode. I tried to learn it, but in
| the end I waved the white flag and went back to vimming
| through invalid states to achieve the next valid one.
| nuancebydefault wrote:
| There is a big problem with graphical programming: it is
| very hard to diff graphs in a graphical way. How can you
| even give review comments on changes? How would an
| automatic merge work? Also, the benefit of graphic
| representation of an algorithm is that it gives an overview
| that is easier to understand. But the whole graph with the
| real details, is just harder to understand. But the details
| are necessary, they make simplistic software smarter and
| better.
| derefr wrote:
| You can do all that at the text level, if it makes the
| tooling easier; the tooling would just be operating on a
| canonically-chosen textual projective representation of
| graphical code (think: `go fmt`, but as a FUSE mount!),
| rather than against canonically textual code.
|
| Changes on the text layer would be propagated back down
| as changes to the persisted binary AST that the text
| represents.
|
| As such, any Unix tool used to manipulate text (and
| thereby textual source code), e.g. diff(1) + patch(1),
| could be used to manipulate the persisted binary AST
| _through_ the text. `sed -i` would still work, even.
|
| But you could also have _other_ tools, that manipulate
| the underlying binary AST directly; where the textual
| projection would be the thing to update in response.
| derefr wrote:
| In other words, text should be a projective UX for
| modifying an underlying graphical model; not a canonical
| storage format for code.
| 0xbadcafebee wrote:
| Ideally? That holographic interface Tony Stark uses. I would
| settle for a combination of SolidWorks and Visual Basic.
| SoldWorks to model and visualize the whole thing, pick it
| apart, run it. Visual Basic to assemble DCOM objects, add
| simple logic, design an interface. Export/import SolidWorks
| models and connect them to new models to re-use a whole
| "machine". Keep a corporate library of "machines", import one
| to do what you need, fork it and make a new one if it doesn't
| do what you want.
| maximus-decimus wrote:
| So a holographic LabView.
| solarkraft wrote:
| > 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.
| bombolo wrote:
| I hate autoformatters with a passion. They love to generate
| 3000 lines diff for a 3 lines change, and then I have to
| review that.
|
| Also git blame becomes kinda pointless.
| deanmen wrote:
| Just use `M-x shell` in emacs.
| ed25519FUUU wrote:
| What I don't like is the non-ergonomic way that text scrolls. If
| three lines appear then the cursor is moved down three lines. I'm
| always craning my neck to try and find where the input cursor is
| just to reset it constantly to the "top" of the screen. I'd love
| it if I could just "glue" it to the bottom or top so output
| doesn't change its location constantly.
| kevin_thibedeau wrote:
| You can use a VT100 escape to force the prompt to the bottom by
| moving the cursor to line 999 col 0:
| \[\033[999;0f\]
| steve1977 wrote:
| set -o emacs?
| ploum wrote:
| People who do not understand things are poised to reinvent them
| badly.
|
| The post manage to analyse terminal input without having
| acknowledging readline. So yeah, they have no idea what they are
| talking about.
|
| https://www.masteringemacs.org/article/keyboard-shortcuts-ev...
| brenns10 wrote:
| I also disagree with this article's approach, but it seems
| pretty disingenuous to say that they don't understand terminal
| input because they didn't mention readline. After all, this is
| a blog post on the site for a terminal implementation. They'd
| have to be unbelievably ignorant to not be aware of the role of
| readline here.
|
| They're not writing a technical deep dive, they're presenting
| their vision for a different approach. I think that vision is
| flawed but I'm not going to grade them on how deep they get
| into implementation details.
| sureglymop wrote:
| They fail to understand that this isn't a problem of the
| terminal at all... The terminals only job is to display output
| and to pass through input.
|
| They could write an "interactive shell" with mouse support that
| implements all those features and it would run in any pre
| existing terminal. They could even make this work with existing
| shells and it would work over ssh ect. Nothing against
| innovation but this is the wrong approach imo.
| MrWiffles wrote:
| I like the _idea_ of Warp, but I just can 't get past the whole
| "login required to use a terminal" thing. If you force a login to
| use your closed-source app, beta or not, I'm sorry, but I can't
| take any commitment to privacy you make seriously whatsoever. No
| matter how well-intentioned you may be. That well's been poisoned
| beyond redemption by far worse people than you and there's just
| no going back.
|
| Now if that login required barrier was removed, I'd at least be
| willing to give it a _try_. May not switch, but I 'd be willing
| to give it a chance. But as it stands? Hard pass.
| shric wrote:
| It also doesn't support/play nice with[1] tmux, which was a
| hard deal breaker for me.
|
| [1] https://github.com/warpdotdev/Warp/discussions/501
| qbit42 wrote:
| As a casual terminal user, I have found Warp to be a nice
| improvement over standard terminals. Although most of the issues
| raised in this article can be addressed with various shortcuts,
| it is nice to not have to remember these when I only pull up the
| terminal a couple times a week.
| hprotagonist wrote:
| if $EDITOR is properly configured, C-x C-e and hey presto, all is
| well for complex commands.
| lordleft wrote:
| Guys, it doesn't matter if you can edit terminal input in vim. If
| there's a way to do it in an even more ergonomic / user-friendly
| way, that's not intrinsically a bad thing. This entire comment
| thread makes us sound like tech-grognards.
|
| Warp's pricing model is a whole other issue though.
| bee_rider wrote:
| It isn't a bad thing that somebody is trying to find an
| alternative to the standard terminal. Good luck to them!
|
| But they decided to write a whole blog post making up problems
| about peoples' current workflow. People are naturally going to
| point out that they don't suffer from these problems.
|
| If warp didn't want it to matter, they could have not brought
| it up I guess.
| password1 wrote:
| What's the problem with the pricing? It seems pretty fair to
| me, free for users and paid for teams basically.
| zokier wrote:
| The problem with the whole article revolves around this
| paragraph:
|
| > In turn this means that anyone who has wanted to improve the
| terminal editing experience needs to do it at the shell level -
| and this is what some shells like fish try to do (as well how
| shell plugins like OhMyZsh work). They can only do so much
| though, and, crucially, _they can't make terminal input work
| overall in a less "weird" way._
|
| They provide no justification on why that would be true, and
| indeed I believe almost all of their fancy features could be
| built in terminal also. Their explanation on terminal input is
| ridiculously naive, largely ignoring how control characters can
| be used to do a lot of things.
| Arnavion wrote:
| And who decided that Warp's method is more ergonomic / user-
| friendly with such objective proof that it cannot be argued
| over?
| password1 wrote:
| Maybe some user research? It can be argued for sure though,
| everything can be argued over all the time forever.
| mostlysimilar wrote:
| I bit and was curious to try Warp. Downloaded it and it
| immediately made a request to a Google domain and then forced a
| sign-up window on me. I clicked their "why do we require an
| account" FAQ and the answer is "we think there are features that
| are better with a login."
|
| Absolute no from me, even if their terminal truly is better and
| innovative.
| otikik wrote:
| I am probably not going to try this, but I am glad it exists.
| shadeslayer_ wrote:
| I have been using Warp for the past couple of days and the
| autosuggestions when I'm working over SSH are pretty nifty, it
| probably saves me a fair amount of time everyday.
|
| Making a login required is absolutely unnecessary, though.
| drcongo wrote:
| I have one question about terminal input that I cannot work out
| how to work out.
|
| The setup: I'm on a Mac, I use iTerm for my terminal, Fish for my
| shell, and most often I'm inside a docker container also running
| Fish and using iPython.
|
| The question: When I Ctrl+W to delete a word in a Fish prompt,
| what counts as a word is different to what counts as a word in
| iPython. For instance, Ctrl+w at the end of this string
| `test.func('param1', 'param2')` produces...
|
| Fish: test.func('param1', 'param2'
|
| iPython: test.func('param1',
|
| Hit Ctrl+w again, and you get...
|
| Fish: test.func('param1', '
|
| iPython: all gone.
|
| This causes me to over delete in iPython many, many times per
| day. I'm guessing that the rough flow of the delete word signal
| is iTerm -> Fish -> iPython and that iPython is the thing that's
| being overzealous?
| theblazehen wrote:
| > I'm guessing that the rough flow of the delete word signal is
| iTerm -> Fish -> iPython and that iPython is the thing that's
| being overzealous?
|
| Almost correct. Once you launch iPython, Fish is out of the
| picture until you quit iPython. However yes iPython does handle
| Ctrl-W differently from your shell
| drcongo wrote:
| Thanks, that helps narrow it down. Next to work out how to
| make it behave more like fish, as Ctrl+w deleting the entire
| string `test.func('param1',` seems like madness to me.
| aap_ wrote:
| On plan 9 you can easily edit any text in a window. Seems like a
| sensible idea.
| biftek wrote:
| A lot of those complaints are non issues with the default
| terminal in MacOS.
|
| Option + mouse click moves the cursor to where ever, control+a|e
| move to the beginning or end of the line, option+arrow jumps
| words, and the arrows navigate up and down lines just fine...
| What am I missing?
| wmf wrote:
| You're missing the fact that those shortcuts are not
| discoverable.
| biftek wrote:
| And this app is more discoverable? Those shortcuts also work
| in any text field in MacOS, they aren't proprietary to just a
| terminal.
| shric wrote:
| Almost nothing in a shell is discoverable. Are these
| discoverable? ls, cat, $?, $@, <, >, >>, $(cmd), ${foo},
| $((2+2))
|
| If you can take the time to learn these (if not, why are you
| using a terminal?), then you can learn some shortcuts without
| them being "discoverable".
| quesera wrote:
| An oddball custom Terminal is not discoverable either.
|
| There's no substitute for learning the tools.
|
| If you ever find yourself thinking "weird that there's no way
| to _X_ ", in a shell or editor, you're probably wrong.
| bitwize wrote:
| $27 million in A round funding for a terminal emulator, folks.
| And it's written in Rust! For Macs only! All it needs is to
| detect and respond to the state of your gut bacteria and it'd be
| truly peak Hackernews.
|
| Good thing they got that funding a few months ago instead of now,
| when there's far less VC money sloshing around and the Juicero of
| the command line looks like a far less enticing proposition.
| shric wrote:
| Dark pattern #1: Allowing the user to download the app and only
| then requiring the user to login/signup. This is because you know
| very well almost nobody will bother to try your terminal if you
| make it clear you require a login up front. But if they've gone
| to the trouble of downloading it, dragging it to Applications and
| running it, then maybe they'll go all the way.
|
| Dark pattern #2: On sign-up, you "agree to our terms of service"
| but then you have the gall to say, on unsubscribe: "you are
| currently subscribed to our opt-in messaging. Do you want to
| remove yourself from opt-in messaging?"
|
| Agreeing to a 17 page terms of service document might be
| technically "opting in" to messaging (spam), but it sure isn't in
| spirit. Opting in is when you click on a, previously unchecked,
| check box that has "I'd like to receive marketing from you".
|
| I'm sure there's plenty more but I uninstalled it already.
| quesera wrote:
| I'm going to go straight to "Any terminal or shell which
| initiates network connections as part of its core execution
| model, is a huge no from me".
|
| Think about all the things you type into a shell, via a
| terminal!
| sli wrote:
| I've heard of warp but knew nothing about it. I thought you
| were responding to the post, so I was honestly stunned to
| realize this comment is about warp itself. That's when I
| noticed the "pricing" link at the top, and... they want
| companies to pay per month for a terminal emulator..? They
| must, because they don't put any actual pricing on that page.
| That, to me, means rent-seeking. For a terminal emulator.
| einherjae wrote:
| A lot of the complaints here can be solved by knowing that C-x e
| will drop you from bash into emacs to edit your current line,
| which then gives you any bells and whistles you've configured in
| emacs. Bonus is that this is generally available and doesn't
| require a newfangled set of tools.
| niemandhier wrote:
| 15 years and I never heard of that! Cool featue.
| puffoflogic wrote:
| TL;dr.
|
| In zsh (vi mode) I simply press shift-v and I am dropped into my
| $EDITOR with my current input loaded into a buffer. Of course I
| rarely need to do this because zsh vi mode covers 99% of my
| requirements.
|
| So, my tldr for an article I didn't finish reading: someone
| doesn't know how to use their tools and instead of learning they
| jumped on the internet to complain, and/or sell me a solution or
| something, idk.
| Stranger43 wrote:
| Interestingly for me this dont work with .zsh out of the box on
| my mac(i run a deliberately minimalist .zsh) what did you
| actually do to enable it.
|
| esc -> v does work both with bash and mksh on ubuntu with stock
| config but not out of the box with zsh on my macbook so i
| suspect there is something missing im my one line .zshrc file.
|
| Capital V is an actual vim command btw triggering linewise
| visual mode and that does somewhat seem to actually seem to be
| the functionality of shift-v by default in zsh.
| quesera wrote:
| > what did you actually do
|
| Enable vi mode (usually in .zshrc but you can test from the
| command line): set -o vi
|
| Invoke $EDITOR on the current command line:
| ls -la /tmp<Esc><v>
|
| That's Escape, then the lowercase v key (sequentially, not
| together)
|
| You can use up-arrow to go through command history, reach the
| one you want to rerun with modifications, then press Esc, v.
| nsdarren wrote:
| What's the point of this comment other than being
| snarky/attempting to show off? You should reflect on it,
| because this would be a better place if people like you just
| didn't bother replying.
|
| Maybe _you_ don 't find it valuable because your setup and mad
| vi skills offer you an alternative (which I'm very sure is just
| as feature-rich as what is described in the post, which you
| didn't read). Isn't it obvious how a more accessible solution
| might be useful to _some_ people?
|
| I for one welcome the efforts of the Warp team to improve
| terminal UX.
| kevdoran wrote:
| Warp looks fantastic! It looks like it's not OSS yet but they're
| considering it?
| https://github.com/warpdotdev/Warp/blob/main/LICENSE
| alokedesai wrote:
| Thank you for your kind words! We are planning to first open-
| source our Rust UI framework, and then parts and potentially
| all of our client. We want to make sure we get this right, both
| for our users and for Warp.
|
| Our current best-guess on how we'd do this is a more
| restrictive license that * allows for verifying security and
| privacy * allows individuals to build and tweak Warp * prevents
| another company from starting a commercial enterprise off of it
|
| We'd love more thoughts here though! Feel free to join the
| discussion at
| https://github.com/warpdotdev/Warp/discussions/400 if you're
| interested.
| apetresc wrote:
| 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.
| ploum wrote:
| 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?
| apetresc wrote:
| 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 :)
| terminal_d wrote:
| This is also available in bash. In emacs input mode (aka the
| default) one can press C-x C-e to edit the current command in
| an editor.
|
| `v` is also available in vi input mode.
| puffoflogic wrote:
| The biggest problem with zsh's vim mode is it's actually vi
| mode. I constantly want "])" and "aw" motions but they're not
| implemented :(
|
| But, like, this is obviously an entirely different class of
| problem from TFA, which is a skill issue.
| thefilmore wrote:
| Because you haven't `set -o vi`.
| chungy wrote:
| Emacs's term-mode already solves all of these supposed problems.
|
| I say supposed because they're really not all that big of a deal.
| OK, bash making it difficult to go backwards to previous lines
| is... annoying, at least until you press C-x C-e and do what you
| want anyway.
|
| The use of a mouse for something text-centered is pretty much
| foreign to me, too.
| tmtvl wrote:
| And of course for anyone who doesn't like term there's always
| shell and eshell. And if neither of those will suffice vterm is
| readily available from MELPA.
| sbbr wrote:
| golem> ed
|
| ? help ? ? ? quit ? exit ? bye ? hello? ? eat flaming death ? ^C
| ? ^C ? ^D ?
| kelseyfrog wrote:
| Seventy-five to one hundred percent of the author's complaints
| are addressed by the `fc` command and I'm surprised it hasn't
| been mentioned yet. Fc opens $EDITOR and upon exiting executes
| the saved contents. It's great for editing a complex command, but
| perhaps a tad obscure.
| davesmylie wrote:
| certainly pretty obscure. I'd been mucking around in shells for
| 20+ years before I found it. Now it's part of my core set of
| commands used constantly.
| [deleted]
| bitwize wrote:
| M-x shell in Emacs also covers most of the complaints.
|
| Galaxy brain: M-x eshell. Use regular Emacs commands from the
| shell! Define functions in Emacs Lisp, use them as shell
| commands!
| Arnavion wrote:
| Also bash supports Ctrl-X + Ctrl-E to open $EDITOR to edit the
| current prompt.
| quesera wrote:
| In vi mode (i.e. after "set -o vi") in bash or zsh, you can
| open $EDITOR on the current prompt contents with: Esc, then v
| jiripospisil wrote:
| If using iTerm2, you can also press Shift+Cmd+. and it will
| open a small window/prompt where you can type your command
| while still interacting with the terminal.
| gtm1260 wrote:
| This is awesome
| nathias wrote:
| your problem with terminal is that you don't grok vi
| terminal_d wrote:
| A lot of macOS users are suckers for any sort of themed-up
| applications that can be replicated in their normal setups
| without any extra software, had they just bothered to RTFM.
| wmf wrote:
| You're not wrong but historically a lot of money has been made
| selling thing to people who don't RTFM. I mean a _lot_.
| vander_elst wrote:
| TO better understand the architecture, how will this work if I
| want to use the shell in vi mode? IIUC that would not be possible
| with their setup, right? Warp would need to implement a vi mode,
| correct?
|
| Is it possible to work with vim in warp?
| alokedesai wrote:
| You can launch vim within Warp without any problems, but vi/vim
| mode for the line editor itself isn't supported in Warp just
| yet. You're correct that this is because we'd need to implement
| VI mode ourselves (tracking issue here [1] if you are
| interested).
|
| This is the tradeoff of building our own editor instead of
| using the shell's--we can build features that wouldn't be
| possible in the shell directly but it requires us to build
| features that already exist in the shell from scratch. So far,
| this tradeoff has been well-worth it to build what we think is
| a better experience when using the terminal.
|
| [1] https://github.com/warpdotdev/Warp/issues/159
| AndriyKunitsyn wrote:
| The developers seem to be proud that their shell is "Rust-based",
| they write it several times on the main page. But why would I
| care what a closed-source application is made with? Sorry if it's
| blunt, but I just don't get it.
| ksherlock wrote:
| Let me mention MPW - The Macintosh Programmer's Workshop for
| classic MacOS. The shell was a text editor, just like the text
| editor for editing code. When you hit enter (or command-return)
| it evaluated the current line or selection. Command results were
| included in the document. (This was strictly a dumb terminal so
| there were no vt100 escape codes or such to mess up the display)
|
| If you were confused about the command arguments you could run
| commando (or use ... as an argument) to bring up a GUI to select
| the flags.
|
| The Eddie text editor for BeOS and now MacOS X/XI/XII/XIII has a
| similar text-editor/shell hybrid.
|
| http://www.el34.com
| beej71 wrote:
| At the simplest level, this reminds me of input in C64 BASIC. You
| could hit RETURN anywhere on on any line and that line would get
| parsed as if you'd just types it in. You could cursor around,
| edit previously-entered lines, and so on. It was pretty neat.
| smoldesu wrote:
| 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? Frankly, I don't ever see
| this replacing iTerm 2 for most Mac developers.
|
| I wish you luck, but your product in it's current state is
| confusing to me. fish solves most of these issues for me and it
| runs on all my devices, free. All I'll say is that your
| competition is stiff.
| cosmotic wrote:
| Can you explain why free and/or open source is important to
| you? What sacrifices are you willing to make to maintain free
| and open source?
| danny_warp wrote:
| 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
| Arnavion wrote:
| >>My current terminal is Open Source and while it's not
| perfect, it's also Free.
|
| >The app is 100% free for any and all individuals.
|
| I assume the usage of the upper-case F in "Free" indicated
| libre, not gratis. Your comment is about the latter.
| derefr wrote:
| Could you separate that into "free for businesses if they
| only want the stuff individuals want; but you can pay for a
| corporate plan on top to enable extra stuff" -- i.e. open-
| core model?
|
| Maybe with a proprietary binary release that includes the
| corporate features, and an open-CI/CD binary release that
| doesn't, ala the Chrome/Chromium split?
| protomikron wrote:
| 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.
| titaniumtown wrote:
| of so if it's 100% free, where's the source code?
| cdelsolar wrote:
| That would be libre
| babypuncher wrote:
| "Libre" is just "Free" in Spanish.
| KronisLV wrote:
| > The business plan is to create collaborative and cloud-
| based features that businesses will be willing to pay for.
|
| You know what, that is fair. I know a lot of folks take an
| issue with software that is monetized and many are jumpy
| about software that might rugpull them and lock certain
| features behind a paywall some time down the line, or look
| into more aggressive forms of monetization, but at the same
| time a lot of software would probably be better made if it
| had stable financial backing.
|
| I'll probably keep using the most boring terminal setup
| that's possible just for the sake of not being an early
| adopter (which is just an excuse because I don't have a Mac),
| but I'm curious to see how this will play out in the long
| term, so good luck with your endeavor!
|
| > Please check out our pricing page to learn more.
|
| Here's the direct link: https://www.warp.dev/pricing
|
| And to save folks a click: Individual A
| modern terminal experience for individuals. Download now!
| Free Includes - Block Creation - A.I.
| Command Search - Workflows - Modern input text
| editing Team Advanced collaboration and
| support for teams. Coming soon. Pricing TBD
| Everything in Individual, Plus - Shared team
| configurations - Shared team workflows - Real-
| time terminal sharing - Shared terminal notebooks
| Enterprise Security, compliance, and flexible
| deployment. Coming soon. Pricing TBD Everything
| in Team, plus - Advanced security and compliance
| - Advanced team deployment - Integration with internal
| tools
| mhitza wrote:
| This terminal could be good for people learning a new
| commandline tool. Can fish shell show inline the documentation
| for the command flags during completion?
|
| Tools with better DX (developer experience) are a market that's
| been tapped into heavily in the past few years, personally I'm
| not surprised there's a pricing page. Would I pay for something
| like this? Probably never; I don't feel like I need to optimize
| my terminal workflow even if I have to reach for the manpage of
| a command from time to time.
| dgunay wrote:
| > can fish shell show inline docs
|
| Yes, it can. It's not the full docs of course, but tab
| completion for flags often comes with a one liner about what
| it does from the docs [1].
|
| [1]: https://blog.jpalardy.com/posts/fish-shell-is-awesome/
| brenns10 wrote:
| 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.
| zokier wrote:
| 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.
| alokedesai wrote:
| 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 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.
| vimda wrote:
| > 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...
| alokedesai wrote:
| We collaborated with thefuck to build our version of this
| :) TF is slightly different in that they actually _rerun_
| your last command to get the output since they don't have
| access to command output
| zokier wrote:
| > 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.
| danny_warp wrote:
| 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/getting-started/privacy#exhaustive-tel....
| bhauer wrote:
| Still too much telemetry in my opinion. Is it possible to opt
| out, perhaps for a price?
| danny_warp wrote:
| Yes! We are working on opt-out for telemetry.
| Zekio wrote:
| the fact it is an "opt-out" rather than "opt-in" you are
| working on, makes it an instant nope from me
| alokedesai wrote:
| 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.
| user3939382 wrote:
| It's a checkbox/boolean whose persisted value is checked in
| an if statement on your network calls.
|
| It shouldn't be opt out in the first place, it should be
| opt in.
| [deleted]
___________________________________________________________________
(page generated 2022-11-16 23:01 UTC)