Comments URL: https://news.ycombinator.com/item?id=48939766

Points: 6

# Comments: 0

But, for the people who value the "toolbench" of their craft, investing in it over time, and having it grow with them long-term, I will absolutely proselytize the reasons I've stayed with my custom-built setup. You're clearly one of those people, thanks for sharing. :)

It seems to me like you're viewing the playing of politics as a no-brainer, which is a very different mindset from a Linux contributor. I don't think people get into kernel maintenance to play politics.

I don't really recommend it to others, since there's all these great tools that have the features you need (per-machine config, secrets, templating), but I get a deep satisfaction from the fact that I understand every part of this setup from top to bottom. It only has the functionality I need, and I know it doesn't depend on anything that might become unmaintained since it's just POSIX shell scripts.

Even still, I might eventually make the jump to something like chezmoi or nix if I'm not able to implement something I need easily, but that hasn't happened yet.

Not that I haven't done exactly the same thing as you, I never keep paper around and my handwriting has gotten terrible. I'm saying this to myself and others as well.

It sounds like you made that leap of faith and regretted it, but thankfully pivoted to something grounded in reality. Thanks for sharing your experience.

By default, WezTerm doesn't have a scrollbar, but you can easily enable it with:

  config.enable_scroll_bar = true

  -- Hide the scrollbar when there is no scrollback or alternate screen is active
  wezterm.on("update-status", function(window, pane)
    local overrides = window:get_config_overrides() or {}
    local dimensions = pane:get_dimensions()

    overrides.enable_scroll_bar = dimensions.scrollback_rows > dimensions.viewport_rows and not pane:is_alt_screen_active()

    window:set_config_overrides(overrides)
  end)

There's another single-file example on that page that shows how to implement routing. The reason AI probably gave you a more fleshed out project structure is because people typically default to using Phoenix (Elixir's equivalent of Rails) instead of going for something simpler like Plug.

After getting a result you didn't like with AI, did you try refining your prompt to state that you wanted a single-file structure?

In fact the final solution is pretty bad. Sure, it looks nice when I scroll down, but when I use the alternative navigation method of clicking the sidebar items, it just scrolls to unexpected places.

Beautiful article, though.

I don't have a keybinding to hide, but you could easily achieve that by inspecting the active window with `hs.window.focusedWindow()`/`hs.window.frontmostWindow()` and making the behavior conditional based on the application: https://www.hammerspoon.org/docs/hs.window.html#focusedWindo...

In WezTerm, you can control whether the terminal is always on top with the `ToggleAlwaysOnTop` action: https://wezfurlong.org/wezterm/config/lua/keyassignment/Togg...

I use line range history the most, multiple times per day, since it's a much better alternative to line blame in most situations. You get the full historical context of a line instead of just the last commit.

File blame is really useful when I'm encountering new code, and I want to quickly find out who has the most "responsibility" over it, oftentimes so I can go and ask them about it if I need more clarification.

File history is especially useful when I come back to a file that I originally wrote or was familiar with, some time has passed, and now I want to re-familiarize myself with all the changes since the last time I was familiar (could be years). Rename detection is useful when there are repository-wide restructures, which has happened a couple of time in the main repository I work on. Otherwise, your history will cut off at that refactor, which is really irritating.

I use path history like file history, but to re-familiarize myself with large modules (admittedly less often than file history, but it comes up).

I'm newer to pickaxe, but I've used it 2 or 3 times in the past year to track some chunks of code throughout a refactor. That's how a lot of these little tools that Git has work. You might only use them a few times per year, but when you need them, they're really amazing.

It seems like Jujutsu focuses a lot on the commit authoring and modification flows, and it looks like it offers improvements in those areas, but I don't see much functionality in the history investigation area. They might be considered niche features to some, but I think this functionality becomes more valuable the older and larger a codebase gets.