Timeline for Goodbye, Prettify. Hello highlight.js! Swapping out our Syntax Highlighter
Current License: CC BY-SA 4.0
33 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 25, 2021 at 22:47 | comment | added | BeeOnRope | I've started an effort to add x86asm as a supported highlight language on SO: meta.stackoverflow.com/questions/412543/…. | |
| Nov 7, 2020 at 14:38 | comment | added | Josh Goebel | Assembly might be easier to classify than others though so IF you truly kept it as simple as just comments and labels then perhaps it wouldn't be that hard for a simple classifier to figure out which comment style was being used. | |
| Nov 7, 2020 at 1:56 | comment | added | Peter Cordes |
@JoshGoebel: I (and probably others) had been using lang-asm or lang-assembly in the rare cases where it highlighted wrong from auto-detection (based on tags and/or content), since that gave the appearance of working. So yes, we would need to invent a naming convention.
|
|
| Nov 6, 2020 at 22:00 | comment | added | Josh Goebel | "There are only two hard things in Computer Science: cache invalidation and naming things." :-) I'm not sure why the names would change... name them whatever you've always named them... If there was no pattern before your suggestion doesn't seem awful. :-) | |
| Nov 6, 2020 at 21:18 | comment | added | Peter Cordes |
@JoshGoebel: Right, so then the problem becomes naming the different grammars. Do we want something like asm-hashcomment? That seems bad and not something anyone would ever guess, and not future-proof if more specific new grammars did get added. So I guess we'd want something future-proof like asm-gas or asm-att or assembly-att / asm-mips / etc. (GNU assembler for x86, MIPS, etc.) mapping to one grammar vs. asm-nasm / asm-masm / asm-yasm / asm-fasm / etc (Intel-syntax with ; comments) all mapping to another grammar. And asm-arm for @ comments.
|
|
| Nov 6, 2020 at 16:33 | comment | added | Josh Goebel | @PeterCordes Yes of course I certainly didn't mean a SINGLE grammar... although if two assemblers shared the same comment syntax and you were purposely being that minimal then you could indeed reuse the grammar, but you'd need one grammar per ruleset of course. Still it'd be ridiculously small. And yes labels would be nice and easy. | |
| Nov 6, 2020 at 8:57 | comment | added | Peter Cordes |
@JoshGoebel: As I pointed out in my answer, different assembly languages have different comments characters (and some use # as part of the syntax for numeric literals in some contexts), but yes a couple different simple grammars for different comment chars could work. And yes, doing nothing but comments would be totally fine and vastly better than nothing; good asm style already makes most other things visually easy. A few refinements could include a color for label: labels. Some other easy things I can think of would be anti-helpful in badly-formatted asm (like insns not indented).
|
|
| Nov 6, 2020 at 8:53 | comment | added | Josh Goebel | @PeterCordes I think long-term SE will load more grammars dynamically... (which is the real solution here)... but if not they should probably consider some tiny custom grammars... if all you MOSTLY care about is comments that's only a tiny amount code to make a grammar that would just only highlight comments, and leave everything else alone with 0 false positives. | |
| Nov 5, 2020 at 1:38 | comment | added | Peter Cordes |
@JoshGoebel: Highlight.js seems to do ok with lang-bash for GNU assembler (# comment character, and a line-oriented language). e.g. I gave it a try for here which was once again a disaster by default. Agreed it would be interesting to have a look at exactly what the old system was doing; I remember lang-assembly not working perfectly but usually being fairly reasonable. But I don't remember any of the details of random words that would get highlighted differently from others that I could use to guess a language. There were some, though. :P
|
|
| Oct 28, 2020 at 3:07 | comment | added | Josh Goebel | @PeterCordes It would be super interesting if someone had a way to find out which Prettify grammar was actually being used in the past if that seemed to work so well... SE could always choose to force assembly to any grammar they wanted that provided good highlighting results (if they choose not to build in the explicit assembler grammars). | |
| Oct 8, 2020 at 17:00 | comment | added | Ross Ridge | Assembly code was always randomly coloured on StackOverflow. No one seemed to care though. Despite another answer saying no colour is better than wrong colour most people just seem to want pretty colours. The current everything is green syntax highlighting that assembly usually gets I suppose is technically better, but doesn't give people the pretty colours they want, or provide any useful syntax highlighting. | |
| Oct 8, 2020 at 10:55 | comment | added | Luuklag |
Yes, it never was supported. It would either get highlighted as default or something else based on the other tags of the question.
|
|
| Oct 8, 2020 at 9:47 | history | edited | Peter Cordes | CC BY-SA 4.0 |
added 896 characters in body
|
| Oct 8, 2020 at 9:40 | comment | added | Peter Cordes |
@Luuklag: Wait a minute, so lang-asm / lang-assembly has never been supported on SO? And it just happened to get auto-detection based on syntax and do something which turned out to be useful in most cases with prettify.js, unlike with highlight.js? I guess in hindsight it was probably treating GAS code like some other language with # comments. Anyway, in practice it's still a regression in practical results, however we want to classify it and maybe do something about it in the future. At least that explains why x86 NASM syntax highlighting isn't working.
|
|
| Oct 8, 2020 at 9:26 | comment | added | Luuklag | @PeterCordes that language is not supported by SE. They only support the languages in the other link: meta.stackexchange.com/questions/184108/…. So this is no bug, but a feature request to add a certain language to the highlighter. | |
| Oct 8, 2020 at 9:22 | comment | added | Peter Cordes |
@Luuklag: I checked github.com/highlightjs/highlight.js/blob/master/… linked from the question, as you suggested. lang-x86asm is the same as what I'd already been getting for the block in this answer. Auto-selection is by far not the only problem. Even overriding to the correct asm syntax (x86asm is supposed to be NASM) gives a pretty messy results for the NASM syntax in this answer. I don't have enough interest in syntax highlighting to sort this out, just to report it the major regression from how asm syntax highlighting used to work on SO.
|
|
| Oct 8, 2020 at 9:18 | history | edited | Peter Cordes | CC BY-SA 4.0 |
added 553 characters in body
|
| Oct 8, 2020 at 9:05 | comment | added | Luuklag |
@PeterCordes you might want to check the list of supported languages, and try out a few by explicitly setting the highlighting languages for a codeblock. If you end up with a reasonable result with a certain language selected that would make more sense as a FR. It could also be that other tags on the question influence the selected language, so then it might be helpful to force highlighting to default.
|
|
| Oct 8, 2020 at 9:01 | comment | added | Peter Cordes | @Luuklag: asm syntax highlighting used to at least sort of work before the change, I think. I don't have a clear memory (or screenshot) of exactly how any specific code blocks looked before the change, except that comments did used to get grayed out. When I posted this, asm syntax highlighting had gotten vastly worse, to the point of being much worse than nothing. It's improved some in the past week or two, but still doesn't gray out comments as well or as reliably. | |
| Oct 8, 2020 at 8:57 | comment | added | Luuklag | I dont think anything is broken here. It just isn't supported by SE. Check the list of supported languages linked to in the "Question". | |
| Oct 8, 2020 at 1:11 | comment | added | Josh Goebel | Oh. I had no idea that it could use tags. Most of the discussion that I’ve read is just about markdown overrides Yes, SO could map one alias to multiple auto-detects if they wanted to. Or do neat things with multi-tag. I’m not sure they actually have written any of that logic though. Stack overflow may not be loading those asm grammars at all though I’m not sure. | |
| Oct 7, 2020 at 23:04 | history | edited | Peter Cordes | CC BY-SA 4.0 |
added 1436 characters in body
|
| Oct 7, 2020 at 21:30 | comment | added | Peter Cordes |
@JoshGoebel: That was referring to how Stack Overflow uses it, not upstream highlight.js. When there's no specific language override for highlighting, Stack Overflow detects languages via tags on the question. By looking at tags like [arm] as well as [assembly], Stack Overflow should (in theory) be able to pick the right asm syntax highlighting. For cases like explicit lang-asm overrides in the markdown (which isn't explicit enough: doesn't say which flavour), Stack Overflow could (in theory) auto-detect which syntax to highlight for.
|
|
| Oct 7, 2020 at 21:01 | comment | added | Josh Goebel | Ah our x86 seems to be NASM syntax, or at least that's what the comment says. github.com/highlightjs/highlight.js/blob/master/src/languages/… @PeterCordes I don't know what you mean with all the talk of tagging... I was just clarifying that Highlight.js does not have a single "asm" or "assembly" grammar... so that label doesn't mean anything unless SO chooses to alias is to one of our individual grammars - which I'm not sure is a great idea. | |
| Oct 7, 2020 at 20:46 | comment | added | Peter Cordes |
@JoshGoebel: But for x86 specifically, there are many different syntaxes. Even using different comment characters (gnu-assembler for x86 using # vs. almost everything else using ;) and separately AT&T vs Intel. (GAS .intel_syntax still uses # as a comment character). Questions are often not tagged gnu-assembler or att even if they happen to use that syntax. There are also some syntaxes like goasm that are somewhat different. I don't know how significant some of those differences are for syntax highlighting. But for non-x86, tags should disambiguate nicely.
|
|
| Oct 7, 2020 at 20:43 | comment | added | Peter Cordes |
@JoshGoebel: All questions tagged [assembly] should also be tagged with an ISA, as per assembly tag-usage guidelines. I already edit asm question that are missing such a tag to add it. (The question volume is low enough to keep up with and see literally every asm question.) A few are tagged with multiple ISAs, for questions about the ARM equivalent of some x86 thing, for example.
|
|
| Oct 7, 2020 at 17:06 | comment | added | Josh Goebel | FYI: Highlight.js has no generic "assembly" grammar. We currently have ARM asm, AVR asm, MIPS asm, and x86 asm. So for best results SO would have to include all of these (or whichever is popular) or someone would have to create a 3rd party generic "assembly" grammar and SO would have to use that for code tagged "assembly". | |
| Oct 1, 2020 at 21:43 | comment | added | Peter Cordes |
@Ruslan: yeah, it looks that way for me now, but didn't before. (Now matching what I see on SO if I add <!-- language: lang-asm --> to the linked answer in the edit box, which I haven't saved because the highlighting is still worse than nothing for that answer). Perhaps changed when P.Mort. saved an edit, or silently changed rendering at some point without re-saving the question. Clearly highlight.js is being worked on.
|
|
| Oct 1, 2020 at 19:49 | comment | added | Ruslan |
Actually, on my system your example code is highlighted, but this highlighting doesn't make any sense at all. See the screenshot: the hex literals aren't recognized; even if I change them to Intel-style 34h, the h is still black. The words like to, of, for, is are blue, which also makes no sense for assembly.
|
|
| Sep 25, 2020 at 17:48 | history | edited | This_is_NOT_a_forum | CC BY-SA 4.0 |
Active reading [<http://stackoverflow.com/legal/trademark-guidance> (the last section - scroll down - "Proper Use of the Stack Exchange Name" - "As a name, Stack Overflow, is always written "Stack Overflow" (two words, capital letters).")].
|
| Sep 23, 2020 at 0:44 | comment | added | Cody Gray - on strike | "SO asm answers tend to be more heavily commented than you'd do in real life..." I see you haven't read much of my real-world assembly code. :-) To be fair, I do often write for a person who doesn't understand the basics, since that person is often me 6-8 months later. | |
| Sep 19, 2020 at 14:11 | history | edited | Peter Cordes | CC BY-SA 4.0 |
added 778 characters in body
|
| Sep 19, 2020 at 13:58 | history | answered | Peter Cordes | CC BY-SA 4.0 |
