How to manually choose Syntax highlighting for code files


#1

In Markdown there is a way to choose syntax highlighting manually by doing something like this:

2018-11-10%2006_35_48-How%20to%20manually%20choose%20Syntax%20highlighting%20for%20code%20files%20-%20Gitea
which results in

public static void main(String[] args){
// code
public static int number;
}

But when I have an actual code file, where I can’t just use Markdown, then Gitea chooses the syntax highlight automatically and sometimes it chooses wrongly. How can I force a specific highlight type?


#2

Use fenced code blocks. Try using all lower case and put a space between the language identifier and the three backticks.


#3

Either I missed something or you didn’t read the starting post. It’s not an .md and it wouldn’t make sense if a code file had to watch out to not use Markdown-specific commands by accident.


#4

I did miss it, sorry. Which language(s) is/are being improperly highlighted? First guess would be the highlighting library used has a bug. You should be able to address that by using the UI tmpl files to swap in a different library. Or submit a bug with an enhancement request on GitHub if you don’t have any luck here.


#5

I don’t think it is buggy, I think there are just too many languages to highlight. When I comment a bash script like #this is the comment then it turns on highlighting for a C language, because they usually have #DEFINEs.


#6

https://highlightjs.org/

Looks like Gitea is on highlight 9.11. Could you try using the latest lib and see if the issue persists? Perhaps the bug you’re seeing has been fixed in a more recent version. Given code reviews are being added to Gitea I could see a bump of that lib in the cards short-term.


#7

Well, I don’t think it’s a bug, per sé. And even if the new version would be better at automatically finding the correct highlighting scheme, it would still not be manual. If I could do it manually, I wouldn’t need to rely on anything but myself. I usually prefer this way.


#8

In that case you could take a stab at replacing highlight.js lib with something more deterministic. But I imagine this will shake out in the implementation of coffee reviews of it becomes a systemic problem. YMMV