firasdib
Allow clicking explanation to open the quick reference entry
Best demonstrated with an example: Imagine someone sends you a regex that contains \d++ and you get this explanation:
\d++matches a digit (equal to [0-9]) ++ Quantifier — Matches between one and unlimited times, as many times as possible, without giving back (possessive)
It would be nice to be able to click the words highlighted with bold:
- whole first line: open "meta sequences > any digit"
-
++: open "quantifiers > one or more of a" -
Quantifier: open "quantifiers" section -
(possessive): open "quantifiers > possessive"
Potential conflicts: if the quick reference is collapsed is should be expanded. If there's an active search in quick ref, don't clear it just pop up the entry above it. If there's an active search and opening a section, clear the search first.
This is not a bad idea, but it requires a lot of work, because there is no 1:1 mapping between EVERY token and the quickref.
Besides the conflicts you mentioned, we need to handle cases where tokens don't exist, or map them to nearby. For example, the quickref only has *+ for possessive quantifiers, not ++.
Perhaps the better solution would be to fill some data into the search field of the quiz, and then see what it brings up? But again, that isn't going to be perfect either.
I see no easy fix for this.
I think a best effort implementation would be enough. I'm happy to help out a little, by doing some mapping. Assuming you have a list of explanation entries as code, or some structure we can amend to map to quick ref entries.
we need to handle cases where tokens don't exist, or map them to nearby.
Map as much as possible. Maybe add a little (i) or similar indicator where the mapping is available, and no icon in other places?
Alternatively mapping everything to quick-ref where the entry would be and if the entry is not found try the parent, etc. (I'm not familiar with the structure, so this might be not possible)
the quickref only has *+ for possessive quantifiers, not ++.
I do think that if ++ is not in quickref yet, it would deserve a place there. Seeing ++ as an example to *+ is a bit confusing. This is just a particular example though. This idea might uncover shortcomings in the quickref which needs a bit of expanding. I don't think that's a bad thing.
I see no easy fix for this.
It feels like we're going for a perfect solution. Since this is a new feature and nothing is clickable in explanation except down/up arrows to expand. I do think adding links wherever possible would be a nice addition, even if it's a partial implementation at first.
I just want to think through all scenarios before we commit to this, as it's going to be a lot of work.
++ and *+ is the same thing, as the quickref is referring to the possessive quantifier, caused by the final +. Adding all permutations would never work, {m,n}+ etc.
I think giving each token a 'search string' for the quickref which they autofill and user can look at those tokens would be a good solution.
However, that tree is already very busy. It will be hard knowing what is and what isn't clickable. How do we deal with that? Some token explanations use other tokens as explanation.
I think giving each token a 'search string' for the quickref which they autofill and user can look at those tokens would be a good solution.
As a fallback, in most cases you can match up. e.g. anything with a backslash, group stuff, basic quantifiers, flags can go to their corresponding entries.
Although the usual *+ is an interesting one: "*+ Quantifier", which one is more important, the * or the + part?
I think in case of combined ones the beginning would go to base i.e. *+ Quantifier would link to * and (possessive) would link to ++. Sidenote: Can I contribute to quick ref?
It will be hard knowing what is and what isn't clickable.
Whatever changes to cursor: pointer is clickable?! I'm not sure I see what you're looking for here. Maybe a tooltip like "Reveal this in Quick Reference" to reinforce where the click goes.
Some token explanations use other tokens as explanation.
If you give me some tricky regexes I would be happy to find which entries should be linked and where. I do think some of these have to be decided on a case by case basis and incrementally amended.
Good idea, there should be a not too long, finite list, of things you map to and mapped things. Instead of anyone pulling off a long list of everything, you should try to implement them on the go, start with simple thing like \d etc. and slowly but surely get all tokens
