61–70 of 185 posts
Earlier quoted context omitted.
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…
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/
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
Earlier quoted context omitted.
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…
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…
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.
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.
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.
Earlier quoted context omitted.
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…
It shouldn’t be opt out in the first place, it should be opt in.
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…
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…
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.
Earlier quoted context omitted.
What would you prefer it to be? Audio recording of spoken words? Diagrams like Labview?
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 wh…