alecthomas
Pascal
github.com support Pascal highlighting via pas:
uses fphttpclient;
var m1: TFPHTTPClient;
var s1: string;
begin
m1 := TFPHTTPClient.Create(nil);
s1 := m1.get('https://speedtest.lax.hivelocity.net');
writeln(s1);
end.
Top Pascal repo has 5,000 stars:
https://github.com/stascorp/rdpwrap
this is more than the top repos for Ada, D, R and Tcl, which are currently supported:
- https://github.com/alecthomas/chroma/blob/master/lexers/a/ada.go
- https://github.com/alecthomas/chroma/blob/master/lexers/d/d.go
- https://github.com/alecthomas/chroma/blob/master/lexers/r/r.go
- https://github.com/alecthomas/chroma/blob/master/lexers/t/tcl.go
It's not about popularity, it's about ease of porting. Pygments Delphi lexer is not a regex based lexer, so it's not possible to automatically translate it into Go.
I mean yeah, but we could start somewhere. Keyword, string and comment highlighting would go a long way.
Keyword, string and comment highlighting would go a long way.
For which language? Pygments covers Turbo Pascal, Borland Delphi, and Free Pascal. I don't know the difference, and other people that see this issue may neither.
@Jos512 the one I care about is Free Pascal - but I can understand if people may be interested in the others
+1
I would even spare a few bucks to see this implemented in order to move Chroma/Gitea/Codeberg forward.
I still have some problems writing lexers from scratch, but I played a little bit with Chroma and I obtained this.
+1
Would be happy to see this implemented. Codeberg relies on your library. https://codeberg.org/Codeberg/Community/issues/752
There is a beautiful objectpascal extension for VS Code (https://www.omnipascal.com) with all the syntax highlighting needed. The syntax highlighting is defined in the objectpascal.plist xml file in the syntaxes folder of the package wosi.omnipascal-x.xx.x. The definition are regex based, so maybe someone can work with that to translate it. I would love to see this for our gitea hosted repos.
Just to set expectations: lexers are entirely community contributed.
Lexers in Chroma are XML and the CLI tool can be used to test them, so there's no Go knowledge required. There are also instructions in the README on how to convert Pygments lexers.
Just to set expectations: lexers are entirely community contributed.
Lexers in Chroma are XML and the CLI tool can be used to test them, so there's no Go knowledge required. There are also instructions in the README on how to convert Pygments lexers.
I just tried to understand the workflow of editing/creating new lexers and styles and test them using the CLI tool. I wanted to start with an existing lexer/style and look at the output, then make adjustments and look at the results again. Therefore I copied the c.xml lexer file and the monokai.xml style file along with a test.c source code file to the working directory.
When I call the command with the lexer xml file, the resulting HTML file does not show the expected result.
./chroma -l c.xml -s monokai.xml -f html test.c > test.html
If I use the internal lexer, the results are as expected.
./chroma -l c -s monokai.xml -f html test.c > test.html
Have I got this completely wrong or is this a bug? (I used the latest [2.10.0] release)
Apologies, looks like there was a bug. That should be fixed in 2.11.1:
🐚 ~/dev/chroma $ chroma -f tokens -l $PWD/lexers/embedded/c.xml ./lexers/embedded/test.c
&Token{CommentPreproc, "#include"}
&Token{Text, " "}
&Token{CommentPreprocFile, "<stdio.h>"}
&Token{CommentPreproc, "\n"}
&Token{Text, "\n"}
&Token{KeywordType, "int"}
&Token{Text, " "}
&Token{NameFunction, "main"}
&Token{Punctuation, "()"}
&Token{Text, " "}
&Token{Punctuation, "{}"}
&Token{Text, "\n"}
Apologies, looks like there was a bug. That should be fixed in 2.11.1:
Thanks for the quick fix!
#883 I created a pull request. Hopefully this issue can be closed soon...