Closed TOMWT-qwq closed 1 month ago
When you say symbol do you mean operator
? If so we'd do this by first putting all the operators (including multi-character ones like !=
) into an array then using our own regex.either
function to build the actual regex.
Changes to minified artifacts in /build
, after gzip compression.
Total change +573 B
I cleaned up the PR a bit to better match our coding standards... but I think the reason this hasn't been done before if the issue with <
... sometimes it's an operator, sometimes it's the start of a template... so that case would need to be properly handled. (or maybe this will prove to be simpler in C++ since we only use it inside FUNCTION_TYPE_RE
)... not sure.
Right now there are a ton of failing markup tests... you'll need to go thru them and see which are operator related (which will simply need to be updated) and which are template related.
There is a line (you can uncomment) in the test/markup test code that will just "replace" the test result files with whatever we generate - it can be helpful for updating result files but if you do this please proof all the changes by hand to guarantee they are as expected.
Nothing is matched according to the tests. Is regex.escape(x)
working properly? I can't find its defination from the package downloaded here
So sorry I forgot to push the main file that does the linking... if pull and build it should work now.
Changes to minified artifacts in /build
, after gzip compression.
Total change +731 B
ok I'll deal with those tests
Those tests are strong and I've found some bugs :)
Some of the failed tests are related to Arduino.
Changes to minified artifacts in /build
, after gzip compression.
Total change +748 B
I set its relevance to 0 to make autodetect working.
Finally I've dealt with most of them except the template <>
Is ->
an operator?
I don't think it's a good idea to deal with these two cases in this PR. They are not related with operator.
::
and ->
(and :
in some special case, I found one in the tests) I think they should be detected as punctuation.<>
. I think they should be detected as quotes or smth else.Anyway let's finish this stage of my work. I'll deal with them in another two PRs.
@allejo Any thoughts on whether it might be OK to just accept that <>
as part of templates are going to be highlighted as operators (because it's too hard to distinguish) - for the increased fidelity of getting operators highlighted in general? I've long resisted this, but maybe in cases where it wouldn't break highlighting in general we should just embrace it?
I'll deal with them in another two PRs.
Let's see what allejo says. My concern is the template stuff may be very hard or even impossible to fix - so to accept this PR (separately) we'd have to be willing to accept that risk. So we need to decide we're open to that type of brokeness long-term or if we even want to still consider it broken.
Changes to minified artifacts in /build
, after gzip compression.
Total change +1.03 KB
Changes to minified artifacts in /build
, after gzip compression.
Total change +1.04 KB
I'm going to ask you what are we going to do next btw.
;
and ::
.::
and template <>
to the defination of a type and a function. I hope it can work for a structure of a::A<b::B<c::C>>>
.Any suggestion?
You know, a powerful part of hljs is contains: ["self"]
. However, a regex is not that powerful. I've tried to do smth, but it doesn't work as expected. I don't think we can recognize everything clearly like a complier now.
FUNCTION_DECLARATION
not matching overloading operator.Changes
OPERATOR
constant and added it somewhere.FUNCTION_DECLARATION
.