Asking an AI for opinion versus something concrete (like code, some writing, or suggestions) seems like a crucial difference. I've experimented with crossing that line, but I've always recognized the agency I'd be losing if I did, because it essentially requires a leap of faith, and I don't (and might never) have trust in the objectivity of LLMs.
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.
I love WezTerm! In the author's spirit of obsessive tweaking, here's a completely inconsequential configuration change I made.
By default, WezTerm doesn't have a scrollbar, but you can easily enable it with:
config.enable_scroll_bar = true
But now you always have a scrollbar, just a big line on the side when there's no scrollback or you're in alternate screen mode. Horrible! So, here's an event handler that will automatically hide the scrollbar when not needed, giving it the same behavior as scrollbars in modern applications:
-- 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)
And that kinda sums up the development philosophy of WezTerm. It has basically all the building blocks you'd ever need with nice APIs. It's set up quite usably by default, but anything that's missing you can probably implement yourself.
Quite possibly, but I use it daily with no issues. It’s also pretty easy to write your own prompt and then make it async with this plugin: https://github.com/acomagu/fish-async-prompt
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?
> 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?
I believe the prompt was: "Please compose a backhanded comment about Elixir I can post in a Hacker News thread about an Elixir blog post. The content of said blog post is irrelevant, I just want people to know I prefer Python."
This seems like the obvious solution to me. You don't know what the user's eyes are looking at, so making the highlighting a visual representation of what's in the viewport seems preferable than nominating a single section as "current".
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.
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...
Note that this does only the “show/hide’ the window part;
The iTerm2 hotkey window, is a floating window, which for example also works in a space with another Fullscreen window/app opened (without moving to another space.)
Jujutsu seems really cool, and I love that I can use it in a Git repository alongside other contributors that don't. It seems like a lot of logging features from Git aren't present, though.
Besides the mentioned lack of blame functionality[1], things like path filtering (`git log -- <PATH>`), file-following with rename detection (`git log --follow -- <FILE>`), pickaxe (`git log -S <CODE>`), and range evolution (`git log -L<START>,<END>:<FILE>`) 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?
Following up late to this, but, broadly speaking: we mostly just haven't added these features because users haven't asked for them and we haven't otherwise gotten around to it. That's basically it. They would all be useful and/or welcome (assuming we were happy with the implementation.)
(We also don't want to necessarily just straight-up copy raw implementations, but improve on them where we can. But most of the asks here are pretty straightforward, I admit.)
I completely missed the `<PATHS>` argument despite being the first thing documented under `jj log`. That's definitely the most critical feature out of my list, thank you for pointing that out!
Also, it's great to hear that you're willing to accept contributions for those features. If/when Jujutsu gains critical mass, I imagine that someone will end up contributing these features.
What? That's a weirdly money-minded question. I'm not gonna do some Google interview-esque estimation question to answer that, but I'll elaborate on how I use those features, because I enjoy discussing them.
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.
I've got to give Atom a lot of credit for laying the groundwork for VS Code, but I can't imagine ever going back to use it. I doubt this project will ever get the performance to an acceptable level, since it seems like that was never an architectural goal for Atom. VS Code proved that it was absolutely possible to have a performant editor written with web technologies, you just need to prioritize it from the start. That's true for any application, of course, but not something web developers are accustomed to (especially not a decade ago).
It made me a bit nostalgic trying it out again, though. I used Atom for about a year before switching to VS Code, and I remember the vibrant community around it. It definitely fulfilled it's goal of being hackable, since there were extensions that completely extended the UI in some pretty neat/silly ways.
I'm old enough to have been told I should get off emacs and start using Atom because it's the future ^tm on here around 2016. Since then the only thing that's changed is that I'm using more responsive emacs configuration and I've figured out how to use shiftL and shiftR for `()'.
When people ask why you should use old software this is it. You learn it one and it runs forever.
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.