Timeline for Adding x86 assembly language syntax highlighting to Google Prettify
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 20, 2017 at 10:29 | history | edited | CommunityBot |
replaced http://meta.stackexchange.com/ with https://meta.stackexchange.com/
|
|
| Jan 18, 2017 at 11:49 | comment | added | Blindman67 | Having had another look and a few experiments suggests that the order of the different types is important. When items have been matched they will not be matched again even if they match other regexps . Thus comments first ensures all comments are safe from further matches. Then in order of easy to match to hardest Keywords, types, literals, punctuation, and so on. In the end you are left with the mnemonics and registers which you can class on position more so than textual content. | |
| Jan 18, 2017 at 7:21 | comment | added | Cody Gray | What I think would make this more readable would be to break up the regexes onto multiple lines and/or to introduce variables that store the long lists of identifiers (and then concatenate those when building the regex. Either of those would go a long way towards increasing readability and maintainability, without vastly increasing the cost or complexity, but I couldn't find a way to do this. | |
| Jan 18, 2017 at 7:20 | comment | added | Cody Gray | Oh, that's a good point, @blindman. I didn't think about the bottleneck being DOM manipulation. Still, I imagine that, like any language, it's possible for someone who is a complete novice to write something so pathologically sub-optimal that it might matter, which is why I asked. As for creating from a higher-level data source, that's intriguing, but I wouldn't know where to begin. I also am hesitant to try and convince the Google Prettify maintainers to accept a sub-project that generates this one language module, so I'd have to maintain that as a separate project myself. Is that worth it? | |
| Jan 17, 2017 at 23:35 | comment | added | Blindman67 |
You should not get to worried about RegExp performance. The parsing of any code via regexp will take much less time than updating the DOM with the new styles (That is the real bottleneck). I would also suggest that you not write the lang-???.js files directly but create it from a higher level data source (something a little more human readable). This will make it easier to stay up to date, allow you apply optimisations (for regexp) that are hard for us humans to spot, and save you a ton of hard fiddly work.
|
|
| Jan 17, 2017 at 11:26 | answer | added | Peter Taylor | timeline score: 1 | |
| Jan 17, 2017 at 6:48 | comment | added | Der Kommissar | This is gorgeous! | |
| Jan 17, 2017 at 6:16 | history | asked | Cody Gray | CC BY-SA 3.0 |