Alex Kladov

>I also think the "fix" for this is to basically stop informing crates.io about dev-dependencies. Hm, probably a crazy idea, but, given that we already modify Cargo.toml on publishing to...

Though, if someone's serious about building an extension here, a better starting point would perhaps be `prr --lsp`

FWIW, yesterday I published what I find a pretty neat API for property based testing: https://docs.rs/arbtest/latest/arbtest/ under the hood, that just uses some poor random numbers to populate buffer with...

https://mail.gnome.org/archives/dashboard-hackers/2004-October/msg00022.html details a solution to this problem.

Not that in this specific issues what we want is not “report a sequence of events that correctly reconstructs the state of the file system”, but a much weaker property...

Huh, indeed -- in the above, we indeed have only snippet, but we wrongly set InsertTextFormat.Snippet. everywhere.

What about namespacing at the call site? In python, you can design libraries for semi-qualified imports: ```Python import formats.json json.parse("{}") json.to_string(True) ``` In Kotlin, this could look like `parseJson("{}") /...

What about `map/forEach` combinations? Currently, IDE suggest to replace ```Kotlin for (fieldDecl in fieldsToAdd) { val field = psiFactory.createStructExprField(fieldDecl.name!!) expr.addFieldBefore(field, null) } ``` with ```Kotlin fieldsToAdd .map { psiFactory.createStructExprField(it.name!!) }...

> is that it does not know anything about side-effects. I believe this is not true in this particular case, because it is specifically about`.forEach`, which exists only for side...

Certainly! My point is that replacing a loop with a call chain with a `.forEach` as a termination operation is almost never a good idea, so it should not be...