[FR] Custom language support

[janvoo]

The plugin is excellent. I'm successfully using it for my psql (Postgres) client using another language (lua) to configure, so I've some issues with code highlighting. It would be great if one could configure any not predefined language with custom settings.

[chlohal]

This would entail a large refactor of the plugin. It's something which would be doable, but I'm not sure if/when it would land.

For now, we do have Lua support. I'm afraid that I might not understand, and I'm sorry if so, but would this work for your use case?

[janvoo]

I guess I didn't describe my use case in enough detail, sorry. This is a kind of workaround. I need my SQL code to run in psql (terminal client for Postgres). So I configured Lua (which I don't use at all) as psql:

lua path: psql
lua arguments: -d mydatabase -U myuser -f

My code looks like this:

| ```lua
| select * from my_table;
| ```

And it works perfectly fine except for the syntax highlighting (Well, I change the tags from lua to sql at the end of the work to have proper highlighting in my docs). I'd be happy if I could specify SQL (instead of lua) and the plugin worked as before.

[chlohal]

I see, thanks! For now, the quickest way to land the feature would be to add sql as a predefined language: I can do that today, and it will probably be merged in the next release. Would that be acceptable?

[chlohal]

Also, @twibiral @milan338 do you guys have any opinions on custom language support?

[janvoo]

Yes, that would solve my problem, thank you.

For a more general solution, it might be worth thinking not about languages but about tags, e.g.

custom tag: sql
interpreter path: psql
interpreter arguments: -d mydatabase -U myuser -f

[milan338]

Custom languages sound like a good idea, maybe we could have a section in the settings for custom languages where the user is able to add their own path / args / injects etc. and have it tie into the existing pipeline just by specifying the language name on a codeblock, though I think some refactoring of the large if / else chain for running a language would need to be cleaned up for that to work.

[twibiral]

As @milan338 said, custom language support sounds like a great idea! I think we can add it after some refactoring.

@janvoo It would also be possible to simply add psql support as a regular language. I opened issue #195 for this and will implement it when I have time for it.

[twibiral]

As minor info: SQL is now supported with release 1.7.0 (Also see #195)

[mayurankv]

Custom languages sound like a good idea, maybe we could have a section in the settings for custom languages where the user is able to add their own path / args / injects etc. and have it tie into the existing pipeline just by specifying the language name on a codeblock, though I think some refactoring of the large if / else chain for running a language would need to be cleaned up for that to work.

In reference to this, I'm looking into doing a cleanup of the settings interface which would most likely remove the need for the chained run commands. I will try and do this so that new programs could be trivially added (which definitely appeared to be possible when I looked into how many more simple languages were added).