Extract candidates with variants in Clojure/ClojureScript keywords #18338
Conversation
|
o/ I'm fairly unfamiliar with ClojureScript (so maybe there's an obvious answer) but is there a reason to use keyword literals for class lists rather than strings? |
|
Like to my knowledge you can't write classes like |
|
@thecrypticace No worries! There are a lot of different reasons why keywords are preferred in Clojure, but the most basic one comes down to types: precisely because it's not a string, but captures something symbolic. It disambiguates, in your editor, and at runtime, from things you actually do want to capture in strings: names, text, etc. So, a combination of being both general enough, and specific enough, makes it useful. Other than that, keywords are interned: the keyword A common DSL for writing HTML and CSS within the Clojure community is called Hiccup, and looks like this: [:p
[:span.bg-white "Hello"]
[:span#unique.text-red-500 "World"]]The semantics are As for numbers, the intention was that eg. |
|
Ah okay that's helpful — thanks! I left a comment. I think you mean't variant and not pseudo-class (e.g. |
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
thecrypticace
changed the title
|
Thanks! This will be in the next release. You can use our insiders build before then to test it: It may take about 15–30m before it's built and available on NPM. |
|
Many thanks @thecrypticace! |
…#18345) ## Summary In a form like, ```clojure (if condition :bg-white :bg-black) ``` `:bg-black` will fail to extract, while `:bg-white` is extracted as expected. This PR fixes this case, implements more comprehensive candidate filtering, and supersedes a previous PR. Having recently submitted a PR for handling another special case with Clojure keywords (the presence of `:` inside of keywords), I thought it best to invert the previous strategy: Instead of handling special cases one by one, consume keywords according to the Clojure reader spec. Consume nothing else, other than strings. Because of this, this PR is a tad more invasive rather than additive, for which I apologize. The strategy is this: - Strings begin with a `"` and ends with an unescaped `"`. Consume everything between these delimiters (existing case). - Keywords begin with `:`, and end with whitespace, or one out of a small set of specific reserved characters. Everything else is a valid character in a keyword. Consume everything between these delimiters, and apply the class splitting previously contained in the outer loop. My previous special case handling of `:` inside of keywords in #18338 is now redundant (and is removed), as this is a more general solution. - Discard _everything else_. I'm hoping that a strategy that is based on Clojure's definition of strings and keywords will pre-empt any further issues with edge cases. Closes #18344. ## Test plan - Added failing tests. - `cargo test` -> failure - Added fix - `cargo test` -> success --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2 participants
Summary
Taking a shot at fixing my own complaint from #18336.
Added failing test and fix for extracting classes containing a pseudo-class from Clojure keywords. Eg.,
:hover:text->"hover:text". This would previously produce["hover", "text"].Test plan
cargo test.cargo testhas no further complaints.ATT: @RobinMalfait