Zed Editor Theme-Builder(zed.dev) |
Zed Editor Theme-Builder(zed.dev) |
For example, https://imgur.com/a/ia2GCgg -- top is VSCode, bottom is Zed. Both using Svelte, and using a similar theme.
- Angle brackets are a different color
- Capitalized built-in components are a different color
- Boolean props are a different color
- Brackets are colored differently than text.
The inspector is a game changer, clicking into these specific things in the preview they provide is super helpful.
I found one extension from a web search. Did you try this? https://zed.dev/extensions/svelte
But those are syntax highlights. What does this have to do with theming?
I'm not a Zed user, but https://zed.dev/docs/reference/all-settings#colorize-bracket... surely you can configure those.
The theme builder is good and easy to use, and I only needed a few minutes to make my own.
Syntax coloring is almost there, but still lacking (I use C/C++) Small visual adjustment like line height in the UI text is not configurable enough (only two settings)
Scrolling should have a smooth option, nothing prevents it, it should be super easy to add, I find it easier on the eyes when I move around code, especially on a 240Hz monitor.
The editing experience is good, quick launch, no crashes, responsive, not too memory hungry.
When trying to report it, I was presented with a form longer than my tax returns. Bug reporting seems like a good place for an AI. Both for the input and later categorization.
Besides, I never work on a laptop.
And this is a lame excuse. Smooth scrolling should also work when using keyboard with and pageup/pagedown, at least as an option and with some tuning preferences.
The defaults all feel very low contrast, gray on gray that makes the experience feel dull and off putting to me, even if the editor itself is great.
"experimental.theme_overrides": {
"background": "#111",
"panel.background": "#111",
"text": "#eee",
"text.muted": "#ccc",
"title_bar.background": "#111",
"tab_bar.background": "#111",
"toolbar.background": "#111",
"status_bar.background": "#111",
"element.selected": "#333",
"editor.background": "#000",
"editor.gutter.background": "#000"
}Whats next, ads inside file searches? (ubuntu blundered this way and soured the community) - "LQQKING for something? try new ai search by blah blah corp!"
So it's hard to 'invest' my time tweaking my editor and theme only to have it start to betray me in the future. VSCode has already gone down this path - signing commit messages with 'copilot'
In the end I fed some screenshots (and original ST4 config) to AI studio and it came up with something workable but not exactly a replica. Naturally different editors have different semantic tokens.
Last time I checked (about half an year ago) it was hardcoded and unconditional, so disabling it required a patch.
"markdown_preview_font_family": "Fira Sans Condensed",
"markdown_preview_theme": "Ayu Dark",
It was added a few months ago if I remember correctly.
edit: clarity
I usually look for a dark theme that looks good and then make a custom version with darker the background colors and brighter the foreground colors.
Maybe it's time for to start publishing high contrast dark themes instead of just fixing it for myself.
But I understand your point, no reason for it not to come with a couple good high contrast dark themes.
> The page you are trying to reach either does not exist, has been removed or you are not authorized to view it.
I’m from the same country as DHH. Personally, not terribly sad that he left.
https://github.com/zed-industries/zed/blob/c8f09caee42ea4e27...
At the moment it seems it's great for personal development and development in environments where concerns around IP are less of an issue.
It's not so clear how to use it in corporation context where you'd be in breach of employment contract accidentally because defaults mean sending confidential IP to 3rd parties.
Supporting basically-compliant Vulkan GPUs covers probably 99.9% of developer machines. You need a pretty big user base to make it make sense to support the last 0.1% of people without access to a proper GPU driver.
I hope Zed reaches that scale, since I really like the project. But right now I would be a bit disappointed if that was a priority.
also wrt scrolling, mice like the logitech mx master actually have what is in my opinion a much better solution where the scrollwheel is not stepped and has scrolling inertia, allowing you to have the same level of precision with scrolling as you do with a touchpad (im not sure if the vertical wheel on it is the same but regardless). Its in my opinion a similar jump in capability for mice as continous triggers were for game controllers. Something that must have been initially quite notable, but slowly became expected behaviour (except on the switch for some reason but whatever i guess)
* There's a standard way to enable high-resolution scroll reporting (pixel-level instead of line-level), but Apple doesn't use it.
* There's a standard approach to multi-touch digitizers/trackpads (documented and I think to some extent created by Microsoft, called PTP) which Apple doesn't support.
* Apple's own Magic Trackpad speaks a proprietary protocol and it appears you can only speak it if you claim to use their USB VID/PID. And I don't think doing that would go over well in a commercial product. (And if you do manage to speak it, it turns out their driver really doesn't do two-finger scrolling well with tiny trackpads anyway. They probably only tested it on the generous dimensions of their hardware.) (Also, it attaches to your entire device, so having an additional interface with a different driver doesn't appear to work either.)
But...you can inject smooth scrolling events via Core Graphics. So you can run a userspace program with accessibility permission that scrolls smoothly. And you can also communicate with USB devices from such a program. There are some existing programs for doing smooth scrolling with standard mice (Mac Mouse Fix is one). I'm writing a userspace driver for PTP to make my keyboard's built-in trackpad work properly.
> But...you can inject smooth scrolling events via Core Graphics.
Applications can choose to ignore synthetic events, IIRC. Probably not an issue for scrolling, but for instance Little Snitch can be configured to ignore synthetic inputs to its security settings.
I'd just be happy if it let me use the multiplier; don't care if it's not exactly pixels.
> Apple probably also didn't want to translate multitouch to scroll in hardware,
That much doesn't seem unique to Apple; both Windows and Linux appear to prefer accepting raw multitouch data.
> since scrolls are not reported the same in all contexts (e.g. applications can choose whether it locks to an axis; which axes it can lock to depends on the capabilities of the view; etc.)
I don't think they're actually taking advantage of this. My MBP's built-in trackpad will lock into pinch/rotate gestures when the cursor's over say Zed or iTerm2. (Zed's a bad example actually, as it has no accessibility tree to speak of. But I think it will lock into pinch/rotate anywhere.)
And for my own app, as far as I know (I'd be very happy to be corrected) there's no way to inspect a view to know what kinds of gestures it supports. It certainly would be nice to eliminate the possibility of locking into pinch/zoom in a place where that's meaningless but I don't see a way to do it.
> Applications can choose to ignore synthetic events, IIRC. Probably not an issue for scrolling, but for instance Little Snitch can be configured to ignore synthetic inputs to its security settings.
Yuck. I'm doing everything this way, including cursor movement and taps. I hope I don't come across such an app/configuration.