Ahh, yeah. In the beginning, Rust was built around the idea that individual files and invoking rustc are internal details, only relevant for integration into some other build system like Bazel, and that “normal” Rust projects need to be inside a Cargo project structure.

There is in-development work to have official support for something along the lines of rust-script, but it’s still just that… in development. If you want to keep an eye on it, here is the tracking issue.

That’s not how it’s supposed to be.

but for example Vec::new() doesn’t highlight anything at all.

If I do Vec::new(foo, bar), I get expected 0 arguments, found 2 (rust-analyzer E0107).

but things like passing too many arguments into the println macro doesn’t throw an error.

I don’t get that either, but I’m still running with the Vim configuration I setup on my previous PC from 2011, where I turned off checks that require calling cargo check or cargo clippy in the background. From what I remember, a properly functioning default rust-analyzer config should pick up and display anything cargo check will catch and you can switch it to cargo clippy for even stricter results.

Or how shown in this example, it did not autocomplete the clone method, while also just accepting .clo; at the end of a String (it also didn’t autocomplete “String”).

I get clone(), clone_into(), and clone_from() as proposed completions for .clo on my as-you-type completions for foo where let foo = String::new(); and it proposed a whole bunch of things, with String at the top when I typed Stri. (eg. the stringify! macro, OsString, mixed in with various results from other crates in the project like serde)

Fair. That would have been more constructive… I think I didn’t do that because it still would have felt like encouraging off-topicness.

Signal to noise ratio.

Aside from possibly making them feel better, it doesn’t benefit anyone for them to drop into a topic about thing X and say nothing but “I use thing Y. I don’t like thing X.” and it wastes other people’s time either scrolling past it or clearing out their RSS reader, depending on how they follow things.

…and I could just as easily disparage those frameworks and give concrete reasons, but I don’t. If you don’t have something constructive to say, please be courteous and say nothing.

Depending on your preferences, there’s also Nom if you prefer parser combinators, or lalrpop or grmtools if you prefer LR(1) parsing.

Since reading Which Parsing Approach by Laurence Tratt (author of grmtools), my plan for my own parsing projects has been to use an LR(1) parser generator for the stronger compile-time guarantees.

Thanks. Being the biggest name, Zola is definitely on my list of things to investigate.

I’ll try to fit in sampling it at some point in the near future as a candidate for building on.

I just decided to finally double down and do the work to switch away from WordPress to GitHub Pages and:

• Jekyll is still hell to get running locally for testing without erroring out during the install
• Pelican seems like it’d be more trouble than it’s worth to get what I want
• I insist that no links be broken in the switchover (Doing this to my standards was a big part of what I wound up procrastinating, since I basically need to install WordPress locally and then write something which spiders the entire site and verifies that each path is also present in the new site and the page’s contents are identical when run through a filter to cut away the site template and normalize any irrelevant rendering differences.)
• I already have a pulldown-cmark-based CLI that I wrote a couple of years ago to render single documents and it’d be nice to retrofit it (or at least its features) onto something Rust-based for my blog. (Hell, just a couple of days ago, after implementing support for shortcodes, I got carried away implementing a complete set of shortcodes for rendering depictions of gamepad buttons like :btn-l-snes: within passages of text. Bit of a shame, though, that I’d have to either patch pulldown-cmark or maintain the smart punctuation and strikethrough extensions externally, if I want to hook in shortcodes early enough in the pipeline to be able to implement Compose key-inspired ones like :'e:/:e': → é or :~n:/:n~: → ñ without breaking things.)
• Since my plans for comments are, to the best of my knowledge, unique, I need something in a language I’m willing to hack on and potentially maintain my own fork of. (Jekyll would have been achieved via a preprocessor.)
• I want something where I’m at least willing to port the internal broken link detection from one of my old bespoke Python static site generators, which means either Python or Rust. (Ideally, I’ll also re-create the support for performing HTML and CSS validation on the generated output.)
• Given how many things I either have in my existing single-page renderer (eg. automatic ToC generation with a bespoke scrollspy implementation, Syntect integration, ```svgbob fenced code blocks which produce rendered diagrams, <price></price> tags which provide currency-conversion estimation tooltips with the exchange rate defined in a central location, etc.) or have plans for (eg. plotters-generated charts with some kind contributed extension equivalent to matplotlib’s xkcd mode because it’s important, Wikipedia-style infobox sidebars, etc.), I want to experiment with a WebAssembly-based plugin API so I’m not throwing the kitchen sink in.