> seriously, where is the setting to have a different ui size vs ui font size
Search for font size in preferences.
You'll see a 'font size' under 'buffer' (editor), under 'UI Font', and under 'Agent Panel' to let you control font sizes in all of those places independently.
> Is there any editor still being being developed and focusing on the experience of coding by hand?
Zed lets you hand-edit too! It's fast and decent. vim, neovim, Emacs, Helix, and JetBrains products continue to do that well too. There are still more traditional IDEs/editors than pure AI ones.
You can also toggle AI features off in Zed from preferences if you want to.
ah I forgot a word, I meant the ui icon size. If I bump up the ui font size so that I can distinguish the icons apart on my large monitor, the ui text becomes comically large.
I do use Zed without AI features, it's just a bit of a disappointment (though understandable) since it was originally marketed as just a nice speedy editor.
I don't think changing icon size independent of UI font size would be a dealbreaker for many. (I'm quite happy having icons that scale in line with font size, but then I use the Material Icon Theme, which is easy to scan at most sizes.)
I use zed every day, but the git view is still buggy and unreliable for me. It often chooses the wrong folder---a subfolder rather than the root of my git project---and shows that there are no changes. And sometimes, even when the right folder is selected, it will still incorrectly say there are no changes.
Another bug is that clicking on new files in the git UI doesn't bring up their diff---you need to click them twice to open the file. I'd like to have those files included in the diff view just like other files are.
I'd love for there to be an easier way to get to the "view file history" view---I didn't realize that it existed until I tried searching for it. I'd love a "line history" view like GitLens has, as well.
Just injecting this here: What I've been missing is an equivalent for GitHub's "blame prior revision" feature to quickly follow through the history of individual source lines.
If you're taking suggestions I'd like to be able to see when I'm over the 72 character limit, last time I checked there was no way to know inside Zed when writing the commit message though I might be wrong. Other than that I think Zed's great and multi-buffer editing is really swell.
I like their vision, though, this is compelling to me:
> What if it was easier to for a team to work together than it is to work alone?
It generally _is_ easier to work alone with git. UI and DX experiments feel worthwhile. lazygit and Magit are both widely used and loved, for example, but largely focus on the single user experience.
Then in System Settings set "swipe between full-screen applications" to "off" in Trackpad settings under "more gestures" so that BTT's shortcut applies instead of the system-level one.
Works well. No extra software needed if you already have BTT, which is worth the money for me purely for "alt+drag a window from anywhere" style window movement. That setting is buried deep under BetterTouchTool Settings → Window Snapping & Moving → Moving & Resizing Modifier Keys: https://cleanshot.com/share/mnF9xBkW
I tried both. BetterTouchTool does support the no-animation left/right space actions, but on my machine InstantSpaceSwitcher felt a bit snappier for actually moving between spaces, so I kept that for my keyboard shortcuts for previous/next space and direct jumps to a specific desktop. I still use BTT for Mission Control / spaces preview. So for me the final setup is: InstantSpaceSwitcher for fast space switching, BTT only where it still adds something.
that is weird, BTT's space switching should really be instant when used via keyboard shortcuts. (Developer of BTT here)
One advantage of BTT's current implementation is that it still allows you to move windows to the next/previous space while dragging them and simultaneously executing the "Move Left / Right a space" action. In that case there will be an animation but it will at least work.
I like that BTT lets you tune the swipe gesture sensitivity too (Settings → Trackpad → Swipes). I made it more sensitive (0.15) and swiping between Spaces feels very snappy.
Also great from the same developer BetterSnapTool. This is always the first software that I install on my Mac as it allows me to move windows around with keyboard shortcuts. There's many others doing that but I have a license already and only use these 5 key mappings.
- Which models in the list are the best for my selected task? (If you don't track these things regularly, the list is a little overwhelming.) Sorting by various benchmark scores might be useful?
- How much more system resources do I need to run the models currently listed at F, D or C at B, A, or S-tier levels? (Perhaps if you hover over the score, it could tell you?)
`codespeak build` — takes the spec and turns it into code via LLM, like a non-deterministic compiler.
`codespeak takeover` — reads a file and creates a spec from it.
You can progressively opt in ("mixed mode") so it only touches files you allow it to (and makes new ones if needed).
Pros:
- Formalised version of the "agentic engineering" many are already doing, but might actually get people to store their specs and decisions in a concise way that seems more sane than committing your entire meandering chat session.
- Encouraging people to review spec and code side-by-side at a file level seems reasonable. Could even build an IDE/plugin around that concept to auto-load/navigate the spec and code side-by-side like their examples: https://codespeak.dev/shrink-factor/markitdown-eml. If tokens per second for popular models continues to improve, could even update the spec by hand and see the code regenerate live on the fly, perhaps via `codespeak watch`.
- Reduces the code you have to write by 5-10x. Largely by convincing you not to write it any more. Our graphics cards write the code for us in this timeline and many people are even happy about it.
- As models improve, could optionally re-run `build` against the same original spec. (Why do that if the output already produces the intended result and the test suite still passes? Presumably for simpler code. Or faster output. Or lower memory use. Or simply _different_ bugs.)
- Moves programming back toward structured thinking backed by a committed artifact and a solid two-word command you can run, instead of actively having conversations with far away GPUs like that's normal now.
- Could theoretically swap out the build target language if you grow to trust the build process to be your babelfish/specfish. Kind of Haxe with Markdown.
Cons:
- Seems to be gated by their login, can't bring your own model?
- Suspect the labs can all clone this concept very easily. `claude build` and `claude spec`?
The idea of a non-deterministic 'build' command had me cringing at first. But formalising a process many are using anyway that currently feels pretty sloppy perhaps isn't so terrible.
If nothing else, writing `build` is a lot quicker and maintains a whisker of self-respect. At least compared to typing, "please take this spec and adapt the Python accordingly" followed 2 minutes later by, "I updated the spec to deal with the edge-case you missed, try again but don't miss anything this time".
> I think we can do much better than chat interfaces if we're willing to put in the design and engineering work. We can still use large language models, but we can build much better interfaces to them.
Love this premise. The 'semantic code tree' is pretty compelling, and the meme categorisation example does a great job of curating the large collection.
Surely it's different every time you load the project, or every time you add a file, though, due to the non-deterministic nature of the models? The author doesn't mention it, but I suppose you could cache initially generated categories and ask it to assign new files to them unless they're distinct.
> In 56% of eval cases, the skill was never invoked. The agent had access to the documentation but didn't use it. Adding the skill produced no improvement over baseline.
> …
> Skills aren't useless. The AGENTS.md approach provides broad, horizontal improvements to how agents work with Next.js across all tasks. Skills work better for vertical, action-specific workflows that users explicitly trigger,
https://www.youtube.com/@rubykaigi4884/videos
reply