Cole
@cole-miller.net
I work on the Zed code editor and post about classical music
what is the probability that at the ith step we see a bug that was already fixed in a previous step? (for realism we could have the p_n obey a power law)
November 7, 2025 at 6:20 AM
what is the probability that at the ith step we see a bug that was already fixed in a previous step? (for realism we could have the p_n obey a power law)
not right now but I like the idea of adding this with a smart default like what GitHub has! and we could read your .gitattributes to look for patterns with the `binary` or `linguist-generated` attributes so we’re compatible with other tools
November 6, 2025 at 9:43 PM
not right now but I like the idea of adding this with a smart default like what GitHub has! and we could read your .gitattributes to look for patterns with the `binary` or `linguist-generated` attributes so we’re compatible with other tools
yep! first-class support for WSL remote projects
October 15, 2025 at 11:51 PM
yep! first-class support for WSL remote projects
I don’t think I’ve ever heard a gavotte I didn’t like tbh
October 7, 2025 at 7:18 PM
I don’t think I’ve ever heard a gavotte I didn’t like tbh
I have a soft spot for Op. 119 no. 4
August 14, 2025 at 1:23 AM
I have a soft spot for Op. 119 no. 4
(from the new matklad post)
July 13, 2025 at 12:15 AM
(from the new matklad post)
Reposted by Cole
In true Zed style, the Debugger exists because our community made it happen. Special thanks to Remco and Anthony for all their work on this. What a PR! github.com/zed-industri...
Debugger implementation by RemcoSmitsDev · Pull Request #13433 · zed-industries/zed
DISCLAIMER As of 6th March 2025, debugger is still in development. We plan to merge it behind a staff-only feature flag for staff use only, followed by non-public release and then finally a public...
github.com
June 18, 2025 at 5:56 PM
In true Zed style, the Debugger exists because our community made it happen. Special thanks to Remco and Anthony for all their work on this. What a PR! github.com/zed-industri...
With `async fn` you can't express "where the async happens" in one signature this way--I think you'd have to split out a sync function.
Another benefit: we have separate main-thread and background-pool executors, and to construct a `Task` you have to declare in that scope which one you want to use.
Another benefit: we have separate main-thread and background-pool executors, and to construct a `Task` you have to declare in that scope which one you want to use.
June 16, 2025 at 1:16 AM
With `async fn` you can't express "where the async happens" in one signature this way--I think you'd have to split out a sync function.
Another benefit: we have separate main-thread and background-pool executors, and to construct a `Task` you have to declare in that scope which one you want to use.
Another benefit: we have separate main-thread and background-pool executors, and to construct a `Task` you have to declare in that scope which one you want to use.
..."this function does some synchronous work, and then uses its outputs to launch an asynchronous task"; that might look like
fn foo(x: Input) -> Result<Task<Option<Output>>>
and then you can handle the sync error synchronously in the caller, before awaiting or storing the task.
fn foo(x: Input) -> Result<Task<Option<Output>>>
and then you can handle the sync error synchronously in the caller, before awaiting or storing the task.
June 16, 2025 at 1:16 AM
..."this function does some synchronous work, and then uses its outputs to launch an asynchronous task"; that might look like
fn foo(x: Input) -> Result<Task<Option<Output>>>
and then you can handle the sync error synchronously in the caller, before awaiting or storing the task.
fn foo(x: Input) -> Result<Task<Option<Output>>>
and then you can handle the sync error synchronously in the caller, before awaiting or storing the task.