E.g., it's more similar to how Adobe Illustrator and other C++ graphics programs render content than it is how a web browser engine renders HTML and CSS.
That's an implementation details and doesn't answer the higher level product incongruency. Tool A, used to design for technology B, doesn't output files in technology B format. It's fine to point out that Tool a uses technology C under the hood, but that's the tail wagging the dog, and doesn't make sense, even if there's an explanation for it.
To address your point specifically though, Webflow is (at least from my perspective) the inevitable result of the line of thinking you're pursuing. So I'd be curious what you think of Figma vs. Webflow, and why those two products have their relative market positions.
I.e., "Tool A, used to design for technology B, doesn't output files in technology B format. [...] doesn't make much sense".
E.g., why not just use Webflow then? From my understanding, that's what it does, that's what it's made for.
Adding to the sh implementation, `find -L "$HOME" -maxdepth 1 -type l -exec rm {} +` will clean up dead symlinks in your home directory, e.g., if a dotfile is deleted because it's not needed anymore.
That is essentially the 2nd solution recommended. I think ghostty could do this itself as a hack. If the target binary is ssh (heuristic, but, ok), inject TERM=xterm-256color into env of the child process at launch.
I guess it isn't a huge deal to have every user to modify their ssh_config instead, but it's an ergonomic pain point for many new users.
Ah, good point, this isn’t `oh-my-zsh` but it does require a couple of options to work as described:
1. `setopt autopushd pushdsilent`: This is the key component, `autopushd` automatically adds directories to the directory stack (and `pushdsilent` option does it without echoing added directories). Without this option, there’s no directory stack to traverse (unless directories are first manually added to it with `pushd` [for completion, `popd` pops directories off the stack navigating back to those directories]). `autopushd` just calls `pushd` on the current directory after each `cd`.
2. To get a menu, Zsh completion also has to be loaded, e.g., `autoload -Uz compinit && compinit -C`
3. Finally `zstyle ':completion:*' menu select` is optional, but that highlights the selected match, which is a nicer UI in my opinion.
Those are the options I used to get this working with `zsh -f` (which starts Zsh with a default config).
I think you're misunderstanding the authors intention. Fuzzy finding is the banner feature of zoxide, i.e., it's only a better cd because it includes that feature. Everything else is just the necessary table stakes features in order to make zoxide a viable cd alternative. E.g., it's not notable that zoxide copies the rest of the useful features from cd in Bash, because that's exactly what it would need to do in order to be a cd replacement.
What you could argue with is whether there's a point to replacing the cd built-in in order to include fizzy finding (personally I don't see the point of this either). But the reason all the other cd features are included is in order to make that viable.
How are you using Zsh history to navigate to specific folders? E.g., does that mean you always start your `cd` from the home directory (e.g., `~`)? I'm asking because it's usually less key strokes to `cd` to a relative directory (assuming you're working in several related directories). But then the `cd` entry in your history would assume a specific starting path (and therefore wouldn't be universally helpful to recall from history)?
Also, re:
> the problem is that means I have to constantly check I did get the result I wanted, and that I haven't accidentally gone to the wrong place.
Is there a reason you don't add your current path to your prompt? I don't know how I'd work without that, never knowing which directory I'm in.
I like using fzf combined with zsh's shell history filtering.
You can type `cd ~` and press CTRL+r to immediately fuzzy match commands you've run with `cd ~`. fzf naturally ranks paths to cd into on top. If you find that too noisy you can just hit CTRL+r with an empty prompt and then search for `^cd ~` to only find cd commands.
If you want to go into ultra lazy mode you can also type `cd ` and spam the up / down arrows to only show commands from your history where you cd'd into a directory. That use case is also covered in the above post. I normally don't use this for changing directories but it can be done.
The premise is the same: Dump history into fzf and add a grep/awk.
My point was that requiring a new shell (or even history) is a limiting factor here, and either backwards search over commands (as suggested ITT), or just plan fzf directory changes are more functional and already integrated into bash.
`cd foo` is useless in history if you're not already in foo's parent directory. This is the problem Zoxide solves, `z foo` will still do something useful in that case. (Side note about fzf, recursively fuzzy finding subdirectories fine for some use cases, but it doesn't scale as well as Zoxide.)
Yes, the marginal improvements from changing your entire shell are not to be disregarded. I'll change to asserting that it's entirely possible to do a nice 80/20 without changing shells.
What do you mean? Zoxide isn't a shell, it's just a CLI program. It doesn't involve changing shells, you can see the list of supported shells in the README (it's more comparable to fzf than a shell, it ships with optional shell integrations the same way fzf does).
How did you get all the way down here and lose the fact that top level comment is about zsh and finding past commands, and also changing directories? Was it not you that brought up zsh?
And I that brought up bash examples to show how it might be done? We've gone around in circles lads back on the bus.
To me, the interesting conversation here is between these three workflows:
1. Recursive directory fuzzy-search
2. Searching history for `cd` commands
3. Zoxide-style matching visited directories
Which are all ways to make it easier to traverse directories.
For my part, the thrust of your argument seemed to be advocating for #1, so that's what I was responding to (since this is a thread on #3, I'm mainly focusing on why you'd use that instead of #1 or #2, but all three are workable).
All of these can be implemented in any of the common shells. I didn't see anyone making a case for a specific shell here, I think the mentions of a specific shell are incidental (e.g., what people happen to use).
My logic (take it or leave it) is that since zsh is not the default distro nearly anywhere (Kali?), a randomly selected person who might read that advice (and subsequent advice ITT), would likely find "Use ZSH" includes a shell change and therefore more learning curve than "add a few lines to .bashrc".
This is getting off topic, pedantic, and (maybe?) argumentative so I'm calling it quits. Cheers.
I use autojump, which is a lot like zoxide (possible predates it). It stores all the directories you've visited in an SQLite DB (along with the rank for each). I wrote a shell keybinding that presents me with fzf, along with the directories I've visited, in rank order.
With just a few keystrokes, I can visit any directory I've ever visited, really fast. It doesn't need to be the top ranking directory for my query.
Yeah the problem with this approach to me is populating the history with a bunch of cd to absolute paths to begin with, which is not something I'd do natural (I have many ways I'm navigating the file system), and definitely wouldn't do manually. Not having to populate that list is the advantage of zoxide.
- Recursive directory tab completion isn't viable for many key use cases (it'll hang with both monorepos and networked volumes). The only thing that makes zoxide viable is that it only matches against visited directories. (Similarly fzf doesn't have much of a relation here besides encouraging recursive fuzzy matching, which I tend to avoid because it doesn't scale to complex directory structures.)
- Zoxide is probably sponsored by Warp, I doubt they have a relation beyond that, I'm not sure but they don't have much of a synergy beyond both being written in Rust. (The main point of relevance here is Warp is venture funded.)
- Zoxide having a database outside of the shell is actually a huge advantage to me, because it makes it easy to access your database outside of the shell (e.g., Zoxide integration in Vim).
I think that's ok if you have absolute paths mixed in.
If I have some long path like ~/src/open-source/dotfiles or /home/nick/src/open-source/dotfiles it all works with fuzzy matching. You can hit CTRL+r and then search for "cd dotfiles" and it finds it. The ~ isn't necessary, you can also do "^cd dotfiles"` for a tighter list of matches for paths that are more ambigious with other non-cd commands.
It's not that I always use absolute/home-relative paths, but I'm almost always working from the same folders for the context: if I'm working on a project, I'll be in the project directory and work relative to that the vast majority of the time, for example. I also use the substring history search which makes it more useful for the equivalent to zoxide's case.
And I do have my path in my prompt, I'm not talking about something that actually takes time, but more interrupts flow (for me, as I say, I get how for other people it'd work better).
The issue for me with this approach is one: It assumes a clear root for a project (e.g., your base you're cd-ing off of), I think that's only good assumption for small-scale projects? E.g., sufficient complexity, for programming at least, necessitates modularity which dilutes the concept of a "root".
The other issue is that it creates a separate "hop" which adds key strokes and cognitive load (i.e., I can't just jump directly to a subdirectory or related directory I first have to jump to a "junction" directory then to my destination).
In any event, I could see how that would be a reasonable approach in the absence zoxide, but those are the reasons I personally still prefer zoxide. (For the record, zoxide has some nice techniques for making a match more specific, e.g., `z foo bar` will hop to a dir containing `bar` only if it's in a subdirectory containing `foo`.
Mcfly[1] takes your working directory into account when searching shell history.
From the readme:
> The key feature of McFly is smart command prioritization powered by a small neural network that runs in real time. The goal is for the command you want to run to always be one of the top suggestions.
> When suggesting a command, McFly takes into consideration:
- The directory where you ran the command. You're likely to run that command in the same directory in the future.
- What commands you typed before the command (e.g., the command's execution context).
- How often you run the command.
- When you last ran the command.
- If you've selected the command in McFly before.
- The command's historical exit status. You probably don't want to run old failed commands.
I love that mode in Atuin. I can never remember which of the run commands to use between make/cmake/bazel/yarn/npm/uv and hitting ctrl-r twice and scrolling up is better than having to root around in a readme, which I may or may not have bothered to write for my future self.
Oh I forgot about "just"! (and I have Opinions about that name.) Add that to the list. Making order from chaos is not unfamiliar to me. Previously I standardized on make and was fastidious about making makefiles, but with atuin, command directory history the extra effort to create makefiles became superfluous.
I used to have this fantasy that after I die, someone will care enough to go through my ~/projects folder and go through everything I worked on, and all those makefiles and readmes were going to help them, but no one cares that much for me. I'm okay with that, depressing as it is.
That's not default behavior in most shells (e.g., `autocd` in Zsh, and, for the record, that's also not default up arrow behavior in Bash or Zsh [it is in Fish]).
But my question is specifically about relative vs. absolute paths when recalling directory traversal from history. I'm still struggling to follow how you'd use Zsh history as a zoxide replacement without always using absolute paths.
Apple is practically the most antithetical to "free software" company around, yet Apple maintains perhaps the largest fleet of local-first apps in existence, e.g., off the top of my head: Calendar, Contacts, Keynote, Mail, Notes, Numbers, Photos, and Pages (these are all examples of apps that support multi-device sync and/or real-time collaboration).
I think the truth of your statement is more that free software tends towards what you might call "offline" software (e.g., software that doesn't sync or offer real-time collaboration), because there's more friction for having a syncing backend with free software.
Maybe the distinction is in that word "app." We started calling programs "apps" when smart phones came out. Smart phones are remote-first, and it makes sense (or it did) as long as you think of a phone as your terminal into... something.
Your examples are all programs that predate mobile, even though they are available on mobile (are they local-first on mobile too?).
Not sure I'm following, what's the importance of the term "app"?
(And yes, they're all local first on mobile as well.)
(Also Notes and Photos were mobile apps on the iPhone first [not that it really matters, just FYI].)
Apple continues to release new apps under this model today (i.e., local first), e.g., https://en.wikipedia.org/wiki/Freeform_(Apple). In my mind, the evidence just points to Apple thinking local-first is the best approach for the software on their devices.
The Windows desktop version of Microsoft's suite is probably bigger, more widely used, and just as local-first than Apple's suite, with the exception of the new version of Outlook that's still very far from replacing the traditional and local-first version. (They haven't tried to do any such replacement of the rest of their suite.)
> Local-first was the first kind of app. Way up into the 2000s, you'd use your local excel/word/etc, and the sync mechanism was calling your file annual_accounts_final_v3_amend_v5_final(3).xls
The problem with "human understandable" with respect to resolving syncing conflicts, is that's not an achievable goal for anything that's not text first. E.g., visual and audio content will never fit well into that model.
Nothing. But that's not what the comment I was replying to was suggesting:
> It requires file formats that are ideally as human understandable as machine-readable, or at least diffable/mergable in a way where both humans and machines can understand the process and results.
What you're proposing is tracking and merging operations rather than the result of those operations (which is roughly the basis of CRDTs as well).
I do think there's some problems with that approach as well though (e.g., what do you do about computationally expensive changes like 3D renders?). But for the parts of the app that fit well into this model, we're already seeing collaborative editing implemented this way, e.g., both Lightroom and Photoshop support it.
To be clear though, I think the only sensible way to process merges in this world is via a GUI application that can represent the artifact being merged (e.g., visual/audio content). So you still wouldn't use Git to merge conflicts with this approach (e.g., a simple reason why is that what's to stop an underlying binary asset that a stack of operations is being applied to from having conflicting changes if you're just using Git?). Even some non-binary edits can't be represented as "human readable" text, e.g., say adding a layer of a vector drawing of rabbit.
Figma isn't a web app in the traditional sense of the word, it's a C++ app with a WebAssembly compile target. https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
E.g., it's more similar to how Adobe Illustrator and other C++ graphics programs render content than it is how a web browser engine renders HTML and CSS.
reply