Giovanni Zaccaria

This claude-generated solution looks very clean and idiomatic to me, even much better than the one provided in the crate [scraper-proc-macro](https://github.com/mainrs/scraper-proc-macro) ```rust use proc_macro::TokenStream; use quote::quote; use syn::{parse_macro_input, LitStr}; #[proc_macro]...

If integrated, would you put it inside the selector module or in a dedicated macro module? It could also be integrated as an additional `macro` feature

I was reading that a `proc_macro` needs to live necessarely in a separate crate, so yes, this is true, it would be quite invasive as an addition though, but yet...

In order to avoid cyclic crate dependencies it would be better to ship `scraper_proc_macros` separately. Otherwise `scraper` would have to depend on it, which is not possible. Correct me if...

> The macro should generate a selector representation directly, without requiring parsing at run time. I confirm that the macro provided by Claude executes the parser at runtime, but it...

The selectors_core, selectors_macros solution would eliminate the version coherence problem between the compile time and the runtime versions of `Selector::parse()`. Therefore I would prefer this solution over the one adopting...

Unfortunately, since `SelectorsList` does not implement `ToTokens`, we cannot reuse the result computed by `parse` at complite time. We would need to submit a PR to the maintainers of the...

So you're asking for a function that returns a Node instead of an ElementRef. What would be the benefit of this?

Could you show me the kind of syntax that you would like to achieve? About your question, I would have to try.

Detatch panics in three situations: 1. If its parent doesn't have any children (__impossible__) 2. If it's the first and not only child of its parent, but it doesn't have...