If I leave the language out of the code, then I can use colour just fine, like so
printf("%d. file has been created\r",i);
fflush(stdout);But if I add a language, say 'c', then it all goes pear shaped and the colour tags are no longer parsed.
printf("%d. file has been created\r",i);
fflush(stdout);Jump to PostThat's the intended behaviour. When using language-specific tags, snippets are already color-coded. If you want to point out something specific, refer to it by line. If you absolutely have to point something out via color, use non language specific tags.
Jump to PostExactly.
I thought that was blatantly obvious.
I mean if you tagged something as red with c++ code tags it would hardly stand out amongst the other mix of colours.
Jump to PostOne possibility to consider is to allow BOLD and ITALIC using language-specific tags. Just a thought.
Jump to PostBold and italic tags are already being used with the language-specific tags for specific keywords. For example, in the line
printf("%d. file has been created\r",i);the word "printf" is actually in bold in contrast to the rest of the line. However, bold font is hard to distinguish in Courier New …
That's the intended behaviour. When using language-specific tags, snippets are already color-coded. If you want to point out something specific, refer to it by line. If you absolutely have to point something out via color, use non language specific tags.
Exactly.
I thought that was blatantly obvious.
I mean if you tagged something as red with c++ code tags it would hardly stand out amongst the other mix of colours.
One possibility to consider is to allow BOLD and ITALIC using language-specific tags. Just a thought.
Bold and italic tags are already being used with the language-specific tags for specific keywords. For example, in the line
printf("%d. file has been created\r",i);the word "printf" is actually in bold in contrast to the rest of the line. However, bold font is hard to distinguish in Courier New (or any fixed width font, for that matter). In fact, when I was very anti-color, and before we had syntax-specific code tags, the reason I conceded to allowing color was because people pointed out that bold and italic tags were not doing a good enough job pointing out specific lines in code.
Wouldn't it be better if your parser at least removed the color tags from syntax-highlighted code? Some people aren't aware that color tags don't work in syntax-highlighted code tags (or they paste it from their editor, which for some reason has the code all colored), and then all we see is a bunch of BBCode crap.
Wouldn't it be better if your parser at least removed the color tags from syntax-highlighted code? Some people aren't aware that color tags don't work in syntax-highlighted code tags (or they paste it from their editor, which for some reason has the code all colored), and then all we see is a bunch of BBCode crap.
Nyah. If they want to screw up their code and post without a PREVIEW, let them. We just don't have to read it since they didn't care enough to verify their post.:icon_twisted:
What if someone wants to type code that uses the [param=value] format? If someone types [x=y] in their code it should be stripped?
What if someone wants to type code that uses the [param=value] format? If someone types [x=y] in their code it should be stripped?
Well, you would only strip [color=xxx], [b], [i], etc. And considering that it would be parsed anyway if they had just used a normal
tag, what difference does it make?[code]
tag, what difference does it make?
Because this way people have a method for when they NEED to use such things in their code. If both code methods stripped them, they'd be SOL to display any code in bbcode format.
>If both code methods stripped them, they'd be SOL to display any code in bbcode format.
There's always [ noparse ].
[noparse][color=red]text[/color][/noparse]I'm guessing that people who need to post such bbcode in code tags that know enough about the code tag behavior are also aware of the noparse tag. It seems like a pretty weak argument, in any case.
> It seems like a pretty weak argument, in any case.
It's just as weak as the argument as to why code snippets should start behaving differently than they ever have before by starting to strip characters. :)
Addendum: You should also note that someone wouldn't necessarily be intentionally typing bbcode and therefore think of using the noparse tag. Anything in the format [x=y] would be parsed.
>Anything in the format [x=y] would be parsed.
I'm not requesting that all BBcode is parsed, just that , , , and are stripped (assuming the parser finds their respective closing tags). The only time I've ever seen the aforementioned tags present in code tags is when someone was trying to format their code.
That's really hard to integrate into our existing highlighter.
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.