It's good to have more documentation on Zig by the community, but I'm gonna throw in a bit of criticism.

One major thing I appreciate about the official Zig Language Reference is that it is no-pagination single html page that I can ctrl+f https://ziglang.org/documentation/master/ I wish more projects published their docs like that.

When I read, my mouse is busy selecting different parts of the text that I'm thinking about.

1. I don't want to move my mouse off the text to click the "next" button.

2. I don't want to move my mouse off the text to expand TOC items.

3. I don't want to waste my time on switching between pages back and forth.

I prefer the raw text on a long scrollable, non-interactive page with TOC on the side.

Otherwise, great to see more guides on the Zig topic.

I just use one-liner git command that I put into a script

    git -c status.showUntrackedFiles=no --git-dir=$HOME/.dotfiles --work-tree=$HOME "$@"

+1 I've been using this for almost ten years. It's straightforward, easy to add files, and there are no symlinks to deal with.

When people ask me which tool I use to manage my dotfiles, I tell them about this little-known tool called `git`. ;)

Side note: I use an shell alias instead, but it's pretty much the same.

`alias home="git --work-tree=$HOME --git-dir=$HOME/.files.git"`

OP's first sentence refers to limitations of "version control $HOME" ... What are the limitations?

Ah, that is what OP was referring to.

Well, you can't have different configs for different hosts. Other than that, I can't quickly recall what other limitations are, I see none. I really like the simplicity of the "pure git" approach.

My dotfiles repo dates back to 2018, I'm happy user of this git one-liner for the past 6 years.

> you can't have different configs for different hosts

You can? Git is a DVCS, that's kinda the point of the Distributed part (although most people use it as a centralized VCS.

I have not only host specific configs, but also (host specific) work configs. It's really easy to merge/cherry pick changes between them.

> Well, you can't have different configs for different hosts

Though you can use git branches, but I prefer not to

Might be niche but for me - I have config files outside $HOME, I use a number of `.gitignore`-aware tools (tree, fuzzy finder), and I just don't like `git status` telling me I'm in a repo in any subdir of $HOME.

That's why I use --git-dir=$HOME/.dotfiles

I rename .git directory to .dotfiles in my $HOME

I agree that signing by a central authority makes sense. As the readme mentions, I don't have anything against notarization as a concept.

I specifically don't like how painfull Apple does it. (Google for "notarization hell macos")

This is my pet project that I do for fun and for free. Bowing my head to Apple every time I want to release a new version is not fun. Waking up in the middle of the night, because Apple revoked the app (https://github.com/nikitabobko/AeroSpace/issues/167) is not fun.

AeroSpace is a tool for developers by developers. Developers can audit the code and install the app from sources

If you have normalizations enabled, you don't need to "switch into a vertical stack"

Given this layout:

    h_tiles
    ├── window1 (focused)
    ├── window2
    └── window3

`move left` will produce this layout:

    h_tiles
    ├── window1 (focused)
    └── v_tiles
        ├── window2
        └── window3

Ah, so it does. I suppose this is an instance of my mental model not having adjusted.

For what it's worth, this video from i3 really helped me visualize how i3 and related WMs deal with windows - https://www.youtube.com/watch?v=AWA8Pl57UBY

1. The "AeroSpace" name means a space for your windows without friction

2. I myself consider the virtual emulation of workspaces to be the strongest feature of the AeroSpace. If I could disable the workspace switching animation in yabai or Amethyst (with SIP enabled, of course), I'd probably not bother myself creating AeroSpace. That's what the "space" part in the app name means. It resembles the strongest feature of AeroSpace - workspaces

re 2: an added benefit of not using actual macOS spaces is that it seems (at least from my limited usage) to be much more reliable than yabai (not blaming yabai here, of course).

I also tried implementing an i3 like workspace numbering/creating on top of yabai - it was an uphill battle due to how limited native macOS space management is and I never finished, so thank you for creating AeroSpace :)

I actually use it in tandem with yabai now - I added an "exec-on-window-hide"[0] option similar to "exec-on-workspace-change", and use it to make the hidden windows transparent (and to make them visible again)[1].

I wonder if hooks like that would be a good way to have a nice middle-ground to let people who don't care as much about SIP to extend upon AeroSpace's model?

I'll probably send over a pull request for your consideration soon.

[0] https://github.com/irth/AeroSpace/commit/54b48aa0edf9817031c...

[1] https://gist.github.com/irth/0bc96778c6073c756d3bb657f1bfe8b...

Hi, AeroSpace author speaking :)

> Windows get repositioned by normal interactions and the window manager is not able to wrangle them

I'm certainly biased, but no, I don't face issues like that

> and connecting external monitors is a disaster

Connecting and disconnecting external monitors is an important use case for me as well. I dedicated my time to support specifically this case, so hopefully it works correctly for other users as well

I'm a long time Amethyst user, but going to try AeroSpace out!

Based on the documentation the toml syntax is stretched quite a bit to implement some logic and callbacks. Have you considered some scripting language to make it easier to do, or is the need for this kind of advanced use so little that it's not really a problem?

When I started the project, I kept it simple, so I started with the static config

The complexity of the config has grown since then, with the bigest (and, actually, the only) problem being on-window-detected callback as you mentioned.

I've been thinking about using a scripting language like Lua, but I haven't made my mind yet whether it's worth it

It impacts only AeroSpace

I'm curious whether you've figured out a good monetization strategy for Atuin. The article doesn't answer that question.

Like you said, you won't be paying your rent with sponsors any time soon, but you've already quit your job. Are you living on your savings, and trying to come up with valuable paid features meanwhile? Is it the plan?

Anyway, good luck with whatever you're up to! Building a good monetization strategy is hard

> Are you living on your savings, and trying to come up with valuable paid features meanwhile

Correct! I do already have a bunch of ideas I'd like to explore, will share more soon.

I'm lucky to have had a pretty good career so far, so my savings are more than enough for the next year or so

Thank you!

> I'd be more than willing to try another tiling window manager on Mac if there's one out there that truly works

Hello, AeroSpace author speaking :)

I'd be happy if you could try AeroSpace (it's and i3-like window manager for macOS) and report me back if it loses track of windows.

https://github.com/nikitabobko/AeroSpace

The architecture of AeroSpace is that on every user input that may change window configuration (new window created, window moved, window resized, new app launched, etc), AeroSpace runs the same idempotent operation (I call it "refresh session") that tries to detect new window, checks all invariants, re-layouts windows, etc.

The "refresh session" performs all the mentioned steps regardless of the user input nature (it doesn't matter whether the window is moved, or a new app is launched)

I believe that this architecture may lose windows only if the macOS API returns invalid data.

I have been using AeroSpace for quite a while myself and I'm happy with it

Just tried it and my initial impressions are hugely positive. The main things missing that I frequently use like wrap around for focus and assigning applications to specific workspaces already have open issues that you've engaged on too!

I've been using i3 for over a decade now and hate using any computer that doesn't have it, been trying to find a suitable substitute for my work mac for ages. Amethyst, rectangle, magnet, yabai, each had its own problems. The virtual workspace idea is genius and solves some of the biggest issues with those alternatives. This is by far the closest thing to i3 on mac I've seen. Thank you so much for making this.

My suggestion: open up a way to take donations to the project, and/or sell a packaged version on the mac app store. I'd be happy to pay good money for this.

Very cool, looks great. Seems to hew pretty closely to i3 from what I could tell in the demo video. Will definitely give this a try. Thanks for your work on this!

The demo looks pretty nice! I'll be trying this out over the weekend and report any issues. Thanks for building this!

You might want to check out AeroSpace :) https://github.com/nikitabobko/AeroSpace

AeroSpace reimplements workspaces by emulating them. https://github.com/nikitabobko/AeroSpace/blob/main/docs/guid...

The result is that workspace switching is instant, and disabling SIP is not required

Note: I'm the author of AeroSpace

This is awesome.