technojamin

You'll never be able to draw the tiger how you want it unless you draw the tiger. Prompting is not drawing, it's commissioning from another creator.

Haha, I'll elaborate on that a bit. I don't recommend rolling your own setup to most people that I encourage to version their dotfiles. The vast majority of the developers I've met don't have any type of dotfiles setup, so I wouldn't want to recommend something I know would take significantly more work or overwhelm them. If they're going from no versioning to something, that's a huge improvement, and it's nice to get a lot of the advanced features for free.

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

I think it's the exact opposite of what you're saying. The maintainers sound like they're only considering the technical cost (and judging it not worth it) instead of factoring in the political consequences of keeping the same naming. I actually really respect those who value the technical over the political, but in a large-scale, public-facing project, some politics must be played.

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've checked out stow, chezmoi, yadm, and others over the years, but I originally started off by rolling my own dotfiles setup with a Git repo about 6 years ago: https://github.com/jaminthorns/environment

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.

Someone has never dealt with HIPAA laws and it shows.

This article pre-supposes that the primary way AI agents will do tasks for users will be through through usage of desktop applications instead of documented APIs. While desktop app usage could be very important during a transition period of agent-computer use, I think it makes far more sense that agents will standardize on the protocols that are already being developed, like MCP. An explicitly documented API will always be better for a machine to use than clicking around and navigating an interface for humans.

I use it for previewing files in `fzf` and `lf` (terminal file manager).

Maybe you should interrogate that temptation to reach for physical interfaces? It sounds like you're ignoring your own psychology and shaping yourself to the machines around you instead of thinking of how the machines could be shaped to you.

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.

I think that's perfectly understandable. File systems require the user to remember a hierarchy in their head (even if there are tools like breadcrumbs to help you out), and many people aren't willing or aren't able to hold an arbitrarily complex structure like that in their head. A name is a flat piece of information, no extra structure to imagine.

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 thought those were part of "the normal course of business" (quoting VP of Boring Company).

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

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

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

Here's a 22-line Elixir script that spins up a webserver: https://hexdocs.pm/plug/readme.html#hello-world-request-resp...

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?

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.

Beautiful article, though.

Not out of the box, but I use Hammerspoon to implement a global hotkey to show WezTerm: https://github.com/jaminthorns/environment/blob/a609e81f3f41...

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've definitely seen "zero-dependency" as a selling point for several packages in the past few years, that's always very refreshing.

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.

Regarding rename detection, it seems like that is actively being worked on, which is really encouraging! https://github.com/martinvonz/jj/pull/3574

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.

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?

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

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.

Git rerere basically solves this: https://git-scm.com/book/en/v2/Git-Tools-Rerere

Making a pivot to working on research-adjacent software instead of corporate software has been in the back of my mind over the past couple of years. Do you mind sharing a bit on how you went about your search and found your current job?

Elixir has a pretty nice graph library as well: https://hexdocs.pm/libgraph/api-reference.html

I've used it to do some dependency resolution for operation ordering.

Pipes in both of the languages you specified do function application, not composition, so they’re very much point-ful (you see the arguments you pass/get passed).

Here's a fantastic Veritasium video about snowflakes with a scientist that basically figured out all of the ways they can form: https://www.youtube.com/watch?v=ao2Jfm35XeE

Probably not, but those aren't photographs.

I've seen this in the past, but it looks like the "magic paint" feature was added since then, and it really delighted me when I discovered it. It's such an intuitive way to implement multi-select on a canvas.

fr fr

Here's a great video by Ordinary Things that talks about the development and proliferation of satellites over the past century, space debris, and how things could play out in the near future: https://www.youtube.com/watch?v=90N6IZnV85c

Especially relevant because Starlink has been causing numerous near-collisions over the past few years.