171–180 of 185 posts
Earlier quoted context omitted.
The improvements made to the software by the developers over time.
It's been almost a year since this was last posted and their promised Linux build hasn't emerged. If they're working hard, their optics certainly don't reflect it.
Earlier quoted context omitted.
It's been almost a year since this was last posted and their promised Linux build hasn't emerged. If they're working hard, their optics certainly don't reflect it.
You just ignored everything they have shipped in this period and then claimed they aren't working hard because one item is missing.
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…
In other words, text should be a projective UX for modifying an underlying graphical model; not a canonical storage format for code.
Graphs as a projective UX for an underlying textual model sounds a bit more ... realistic. All those "graph programming" languages don't really seem practical for real projects precisely due to the lack of an ecosystem around them.
Earlier quoted context omitted.
It's been almost a year since this was last posted and their promised Linux build hasn't emerged. If they're working hard, their optics certainly don't reflect it.
You just ignored everything they have shipped in this period and then claimed they aren't working hard because one item is missing.
I wonder how many people upset about Warp here also use VS Code and don't bother turning telemetry off.
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.
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 .
Earlier quoted context omitted.
> But they decided to write a whole blog post making up problems about peoples’ current workflow. Not really, those are problems with current workflows. > People are naturally going to point out that they don’t suffer from these problems. They do, they just work around them or are used to them.
> They do, they just work around them or are used to them. That's trivially true for any "problem" that people "don't suffer from," and it's not that interesting. Problem: Input editing in the shell is hard if you can't remember the appropriate keyboard shortcuts and don't use the relevant features. Workaround: Remember keyboard shortcuts and use them. Blog-proposed workaround: Download our app. If people want to use…
Yes, and it's called denial and compromise.
>Workaround: Remember keyboard shortcuts and use them.
Notice how that's not a "workaround": it's resigning to the problem and suffering the limitations of the system. The very opposite of a workaround, which is finding an alternative easier solution to something being hard.
Earlier quoted context omitted.
In other words, text should be a projective UX for modifying an underlying graphical model; not a canonical storage format for code.
I'd go exactly the other way around since every programming tool under the sun already knows how to deal with text. Graphs as a projective UX for an underlying textual model sounds a bit more ... realistic. All those "graph programming" languages don't really seem practical for real projects precisely due to the lack of an ecosystem around them.
Think like: your syntax highlighter has no idea what your code when you're in the middle of typing, because once you type an opening parenthesis without yet having typed a closing one, your code no longer has any possible valid parse.
Ideally, you shouldn't be able to modify the text in ways that don't represent an atomic graphical operation in the first place. But if you enforce that, you can't really say that the textual representation is the canonical one. It's just a storage projection.
Earlier quoted context omitted.
> 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 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.
Yes thats how it works for me with bash and ksh(mksh) but with zsh esc -v does not launch $EDITOR but just puts me in visual mode inside of whatever it uses for readline. I even tried setting editor to something other then vi(scite) and it's clear that where bash and korn lauched $EDITOR on zsh does not. My .zsh file on macOS is literally just "set -o vi" I guess there is some kind of added magic here(are you using t…
My .zshrc is pretty minimal and hasn't changed in a very long time, but I did find this:
set -o vi
# command editing in vi mode (ESC-v)
autoload -U edit-command-line
zle -N edit-command-line
bindkey -M vicmd v edit-command-line