Preferences

cirwin
Joined 1,249 karma

  1. We'd love to (and, tbh, likely will).

    Search had been a blocker, but that's coming soon; beyond that not sure that there's any reason other than inertia. Alacritty is totally fine, but excited for the Ghostty focus on performance (obviously), and the font rendering stuff looks excellent (though TBD how much of that we can "just use" vs needing to copy-pasta)

  2. You can configure an arbitrary command to connect to ACP in your settings, maybe something like:

    {"agent_servers": { "Container Gemini": { "command": "ssh", "arguments": ["hostname", "gemini", "--experimental-acp"] } }

    could work?

  3. Author here. Seemed like the least bad of the options.

    Being able to comment out sections of a config file easily is a prime use-case; and that really implies using newlines as delimiters, and well, you fall into this trap..

  4. We currently download node if the system version isn't recent enough (we used to always download it, but I fixed that...).
  5. Zed maintainer here.

    We use node.js to run a number of language servers and formatters (which are often written in node due to the VSCode ancestry...).

    There've been a lot of requests to disable language servers by default; but I think that's not the right default for most users – things should work out of the box.

    That said, better control over this is definitely something we will add.

  6. I’ve been working on https://conl.dev, which fixes/removes YAMLs problematic features.

    Trying to find a tag-line for it I like, maybe “markdown for config”?

  7. This inspired me to write https://conl.dev

    I agree with his premise that TOML is not user friendly, but INI is not useful enough. CONL attempts to land in the gap

  8. `go tool` doesn't require a rebuild, but it does checking that the tool is up-to-date (which requires doing at least a bit of work).

    This is one of the main advantages of using `go tool` over the "hope that contributors to have the right version installed" approach. As the version of the tool required by the project evolves, it continues to work.

    Interestingly, when I was first working on the proposal, `go run` deliberately did not cache the built binary. That meant that `go tool` was much faster because it only had to do the check instead of re-running the `link` step. In Go 1.24 that was changed (both to support `go tool`, but also for some other work they are planning) so this advantage of `go tool` is not needed anymore.

  9. Primary contributor to the feature here.

    We went back on forth on this a lot, but it boiled down to wanting only one dependency graph per module instead of two. This simplifies things like security scanners, and other workflows that analyze your dependencies.

    A `// tool` comment would be a nice addition, it's probably not impossible to add, but the code is quite fiddly.

    Luckily for library authors, although it does impact version selection for projects who use your module; those projects do not get `// indirect` lines in their go.mod because those packages are not required when building their module.

  10. For me (maintainer of Zed's vim mode) it comes down to a few things:

    1. LSPs differ per-language, and so I'm never sure whether I'll get lucky today or not. It's more reliable for small changes to talk about them in terms of the text.

    2. LSPs are also quite slow. For example in Zed I can do a quick local rename with `ga` to multi-cursor onto matching words and then `s new_name` to change it. (For larger or cross-file renames I still use the LSP).

    3. I err as a human continually, for example in Rust a string is `"a"` and a char is `'a'`. It's easy for my javascript addled brain to use the wrong quotes. I don't know of any LSP operation that does "convert string literal into char literal" (or vice versa), but in vim, it's easy.

    We are slowly pulling in support for various vim plugins; but the tail is long and I am not likely to build a vim-compatible Lua (or VimScript :D) API any time soon.

    For example, most of vim-surround already works so you could get the most used parts of mini.surround to work with just a few keybindings `"s a":["vim::PushOperator", { "AddSurrounds": {} }]`, but rebuilding every plugin is a labor of love :D.

  11. I’ve been working on a configuration format [1] that looks surprisingly similar to this!

    That said, the expectation in CONL is that the entire structure is one document. A separate syntax for multiline comments also enables nice things like syntax highlighting the nested portions.

    I do like the purity of just a = b, but it seems harder to provide good error messages with so much flexibility

    1: https://github.com/ConradIrwin/conl

  12. Nice – I like your verbatim syntax for multiline strings!

    I went with indentation because a very common use-case in a configuration file is commenting out lines. Even with CSON-like comma rules, you still need to balance your {} and []s. Indentation balances itself most* of the time.

  13. Funnily enough, I've been working on solving the same problem concurrently. Though in my _very_ biased opinion; I think CONL is easier to read and write:

    https://github.com/ConradIrwin/conl

      value = example
    
      map
        a = b
    
      list
        = 1
        = 2
    
      multiline_value = """bash
        #!/usr/bin/bash
        echo "hello world"
  14. I wrote something like this for contact auto completion - running in the browser we had to ensure that both tree construction was fast, and also that completion was instantaneous. So the next level of optimization is to amortize tree construction over searches (using the observation that most of the tree is never accessed)

    https://github.com/superhuman/trie-ing

  15. A failure rate of ~once every two years is so tiny compared to the rate of failure introduced by other things (from human error, on up); and for many time-related things being off by a second is irrelevant (or again tiny compared to all the other sources of noise in measuring time). So it seems reasonable to me to ignore leap seconds in the vast majority of projects.

    That said, modern cloud environments do hide this problem for you with leap smearing [1], which seems like the ideal fix. It'd be nice to see the world move to smeared time by default so that one-day = 86400 seconds stays consistent (as does 1 second = 10e9 nano-seconds); but the length of the smallest subdivisions of time perceived by your computer varies intentionally as well as randomly.

    [1] https://developers.google.com/time/smear

  16. This is great!

    A few more exciting things are happening with file-systems in Chrome that will make this a lot better soon.

    Firstly OPFS gives you a private sandboxed filesystem you can access with `await navigator.storage.getDirectory()` to avoid the permission prompt.

    Secondly "Augmented OPFS" is coming to web workers, which will give you the ability to read/write partial files with `file.createSyncAccessHandle()`.

    There's a demo of this working from the Chrome team here: https://github.com/rstz/emscripten-pthreadfs/tree/main/pthre...

    And a more thorough write-up here: https://docs.google.com/document/d/1SmfDdmLRDo6_FoJMl5w1DVum...

This user hasn’t submitted anything.