robenkleene

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).

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).

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).

`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.)

- 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).

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.

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`.

This will hang if you have too many subdirectories (e.g., a good-sized company's monorepo). A networked volumes will also often cause it to hang.

(PS: In Zsh `cd -<tab>` will show a pop up menu of all directories in the history stack.)

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.

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.

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.

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.

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.

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.

Excel and Word both support real-time collaboration and sync, e.g., https://support.microsoft.com/en-us/office/collaborate-on-wo...

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.

> The merge workflow is not inherently complicated or convoluted. It's just that git is.

What makes merging in git complicated? And what's better about darcs and mercurial?

(PS Not disagreeing just curious, I've worked in Mercurial and git and personally I've never noticed a difference, but that doesn't mean there isn't one.)

> I do feel that one of the interesting things to happen to software in recent years is how most super-popular native applications (most of those developed by Apple) have nosedived in quality, while web applications have done a tremendous job maintaining their quality. Many web experiences are now superior to native experiences, certainly due to nosediving native quality, but also I suspect because the web has always standardized on one stack, HTML/CSS/JS, and we get to reap the benefits of 30+ years of startlingly stable infrastructural consistency.

I'd be curious which apps you'd consider the best examples of this high quality experience? The only web app I even think is worth commenting on is Figma, which is easily the best web app I've ever used, but an app I'd only rank as mid-tier overall. VS Code is the closest analogy, VS Code is clearly a great app overall, in that it solves it's need very effectively, but its not an app I exudes quality the way the apps listed here do https://news.ycombinator.com/item?id=45252567 (as an example of how VS Code doesn't exude quality, note how when VS Code loads it's UI elements for the first time, each element pops in separately, instead of the entire UI displaying instantly and simultaneously, this creates the impression of the app struggling to display its textual UI). I think Figma is slightly worse than VS Code, mainly because it's a web app, which presents all sorts of problems inherent to the platform, e.g.:

- Conflicts between keyboard shortcuts with the browser/web app split

- Bizarre tacked-on native-app affordances (e.g., breaking the back button and high-jacking the right-click contextual menu, both to essentially disguise the fact it's a web app?)

- Poor fit with the URL overall as a UI element (e.g., what does the URL mean when you're knee-deep in a single component in a larger document?)

In summary, the web's core UI elements just don't seem fit well with desktop use cases. I can understand web apps being a nice compromise, e.g., collaborating on Google Docs/Figma is a good practical fit (the web helps with a lot of the challenge of collaborating on the same doc). But they never feel pleasant or high quality to me.

There's some truth to the software getting worse, but it's also a different world (e.g., I see the decline as being a result of supporting different devices [and especially syncing between them]). But my point is more that still making the best GUI software around is pretty good for a company of Apple's size and complex priorities! (I don't think Apple makes software that's better than everyone else, but I do think most of their core apps are on par with the best.)

> Most apps are buggy & sloppy, including Finder, Calendar, Mail, Music, and Clock.

Relative to what? E.g., which GUI apps are better than these? I'd list all of those apps (except Music, and maybe Clock, which I don't use enough to judge) as some of the strongest GUI apps I use today (although Notes, Logic Pro, and Final Cut would be my top three apps Apple makes today, in that order). Note that doesn't mean those apps are without flaws, but I'd be hard pressed to name anything definitively better. Ableton Live/MaxMSP is probably the only non-Apple ecosystem GUI app I can think of that I'd consider first rate (I might add Sublime Text/Sublime Merge, but I haven't used those enough to say definitively). Acorn, OmniGraffle, OmniOutliner, NetNewsWire, Transmit, Things, BBEdit, are all Apple ecosystem apps I use regularly that I'd consider great, but I don't think any of those are definitively better than Apple's first-party apps. So curious what software you're comparing Apple's apps to that you'd consider definitively better than them?

(Regarding Mail and Calendar, curious if you're using those with Gmail or Exchange. Mail/Calendar only work ok with those services.)

> Delight is overblown, in my opinion. I think most of the people truly delighted by fancy animation are just other designers.

Appreciating delight (for it's own sake) in software design I'd consider a core trait of (old-school?) Apple fans. E.g., lamenting the decline of whimsy in the post-Jobs era.

I don't know of a canonical piece that summarizes this idea, but it's referenced a bit in this short piece https://daringfireball.net/linked/2024/12/05/festivitas

I think there's truth to it being relatively niche, appreciating delight that is, but it's certainly not confined just to designers. E.g., like I'm saying here, a core trait of Apple fans is appreciating these kinds of details.

Fair point, I elaborated what I mean here https://news.ycombinator.com/item?id=45116976

To address your specific point in the same way: When we're talking about programmers using abstractions, we're usually not talking about the programming language their using, we're talking about the UI framework, networking libraries, etc... they're using. Those are the APIs their calling with their code, and those are all abstractions that are all implemented at (roughly) the same level of abstraction as the programmer's day-to-day work. I'd expect a programmer to be able to re-implement those if necessary.

Note, I'm not saying there are never situations where you'd delegate something that you can do yourself (the whole concept of apprenticeship is based on doing just that). Just that it's not an expectation, e.g., you don't expect a CEO to be able to do the CTO's job.

I guess I'm not 100% sure I agree with my original point though, should a programmer working on JavaScript for a website's frontend be able to implement a browser engine. Probably not, but the original point I was trying to make is I would expect a programmer working on a browser engine to be able to re-implement any abstractions that they're using in their day-to-day work if necessary.

This is such a funny example because language is the main way that we communicate with LLMs. Which means you can make tie both of your points together in the same example: If you take a scene and describe it in words, then have an LLM reconstruct the scene from the description, you'd likely get a scene that looks very different then the original source. This simultaneous makes both your point and the person you're responding to's point:

1. Language is an abstraction and it's not deterministic (it's really lossy)

2. LLMs behave differently than the abstractions involved in building software, where normally if you gave the same input, you'd expect the same output.

One argument for abstraction being different from delegation, is when a programmer uses an abstraction, I'd expect the programmer to be able to work without the abstraction, if necessary, and also be able to build their own abstractions. I wouldn't have that expectation with delegation.

Summary of the original author's (Alex Russell) background from his about page (https://infrequently.org/about-me/) (it seemed odd to me to just focus on his most recent role):

> Microsoft Partner Product Architect on the Edge team and Blink API OWNER. It is my professional mission to build a web that works for everyone.

> From 2008-2021, I was a software engineer at Google working on Chrome, Blink, and the web platform. I served as the first Web Standards Tech Lead for Chrome (2015-2021) and was a three-time elected member of the W3C Technical Architecture Group (2013-2019) and a representative to TC39 for a decade.

On the IDE marketshare question, the Stackoverflow Developer Survey asks questions like this and I always jump to that section. Here's my comment on HN summarizing the most recent survey https://news.ycombinator.com/item?id=44725015

I also wrote about VS Code's early rising with a focus on marketshare here https://blog.robenkleene.com/2020/09/21/the-era-of-visual-st...

I also think your observation about VS Code's rise forcing JetBrains into a corner is spot on.

On a side tangent, I find it odd that the whole VS Code phenomena is under analyzed. Before VS Code, text editors and IDEs were one of the healthiest software categories around, with the market leader hovering around 35%, which is great for competition enforcing quality (DAWs are still like this today). Now text editors have become more like the Adobe suite, where there's in 800 lb gorilla doing whatever it wants and everyone else is competing over scraps (if you say VS Code is actually good though, Photoshop was amazing when it made its rise too). Developers just let this happen to their core tool without anyone really talking about?

Don't know the context for that snippet you're sharing, but the issue for OSC 52 support for clipboard syncing is marked as `Open` in the Mosh repo https://github.com/mobile-shell/mosh/issues/637

Eternal Terminal works as well as Mosh for me and supports OSC52. I switched to et in order to sync my remote tmux clipboard with my local clipboard.

Doesn't SSH drop if the connection drops? I keep my connections with Mosh/Eternal Terminal open for weeks or even months at a time, when devices are going in and out connectivity many times.