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.

Besides the mentioned lack of blame functionality[1], things like path filtering (`git log -- `), file-following with rename detection (`git log --follow -- `), pickaxe (`git log -S `), and range evolution (`git log -L,:`) are missing. These tools have all become pretty indispensable to me in my day-to-day work since I've learned them, and I know I can still use them since jj can use Git as a backend, but I don't think I could adopt a tool that doesn't have them as first-class features.

Do any regular users of Jujutsu have thoughts on this?

[1] https://github.com/martinvonz/jj?tab=readme-ov-file#status