Tim Fischbach

TIL you can use registered custom properties in CSS to force computing a property value at a certain level in your DOM instead of just applying text based substitution. This can useful when working with nested containers and wanting to reference an outer container in via container query units.

"The computed value of a registered custom property is determined by the syntax of its registration. [...] If the specified value is a dimension literal (such as 50em), the computed value is the same value, but with the unit converted to the corresponding canonical unit for the type of value."

TIL if you want to split out multiple smaller changes from a larger one, you can use `jj split -r X -B X` to make sure the id of the remaining big change stays stable. #jj-vcs

Experimenting with a custom jj-pin script to make history cleanup in #jj-vcs feel safer. I often find myself tweaking a stack of changes moving things around without wanting to change the overall diff. Especially when there are conflicts to resolve, I want to be sure not to mess up.

With git I often used to do `git diff my-feature@{1}` after an interactive rebase instead. jj's more fine grain history rewrite commands are way more versatile, but no longer give me this well defined before/after by default.

Experimenting with a custom jj-pin script to make history cleanup in #jj-vcs feel safer. I often find myself tweaking a stack of changes moving things around without wanting to change the overall diff. Especially when there are conflicts to resolve, I want to be sure not to mess up.

I really like the squash workflow in #jj-vcs. But what are people using to inspect the resulting change? Do you always type out `jj diff -r @-`?

Current take on working with coding agents: Use them as an extra level of abstraction for the making, not for the made.

Expressing desired change in patterns and higher level concepts allows for more coarse grained steps while still being super-intentional about the targeted result.

Current take on working with coding agents: Use them as an extra level of abstraction for the making, not for the made.

So any attempt to use natural language or specs as the primary level of abstraction you operate on when thinking about your system, just removes you from the structural realities that should inform your decisions.

Current take on working with coding agents: Use them as an extra level of abstraction for the making, not for the made.

The big leverage when building a system comes from intentionally designing or incrementally redesigning it to make certain things simple. This means knowing the internal structure of your system.

Moreover, it seems to me that there is a third option beyond the “don’t look at the code” vibe coding approach and “big design up front” spec-driven development. That third option is an agent-based workflow, which I’d characterize by:

- Choosing step sizes that balance the cognitive load of the reviewer while enabling early integration and production rollout.

Moreover, it seems to me that there is a third option beyond the “don’t look at the code” vibe coding approach and “big design up front” spec-driven development. That third option is an agent-based workflow, which I’d characterize by:

- Reducing the mental load of code review by aiming to generate code that is mostly "as expected." Treating deviations from those expectations as early indicators that either the prompt is insufficient or the initial mental model is flawed.

Moreover, it seems to me that there is a third option beyond the “don’t look at the code” vibe coding approach and “big design up front” spec-driven development. That third option is an agent-based workflow, which I’d characterize by:

- Building exactly the amount of context in the prompt required for the agent to generate the desired code, including references to relevant prior art in the codebase.

Moreover, it seems to me that there is a third option beyond the “don’t look at the code” vibe coding approach and “big design up front” spec-driven development. That third option is an agent-based workflow, which I’d characterize by:

Ok, time for a new round of #emacs favorites. Today Magit. 🧵

I still prefer command line for updating the index via --patch mode of git add/reset/checkout. I like reviewing or discarding changes hunk by hunk while looking at a single fixed spot on the screen. In Magit, I tend to loose track of where I am when staging hunks by expanding changed files.

Ok, time for a new round of #emacs favorites. Today Magit. 🧵

Other features feel like another level of abstraction above the underlying git commands: Extending a commit via c e from Magit mode captures intention way more directly than typing `git commit --amend -C HEAD`.

Ok, time for a new round of #emacs favorites. Today Magit. 🧵

Having Emacs key bindings for common commands makes many actions more ergonomic - simple things like C-x g to quickly see a git status for the current project, or C-c g b to view a blame for the current file.

Ok, time for a new round of #emacs favorites. Today Magit. 🧵