-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add fenced language syntaxes #28
base: master
Are you sure you want to change the base?
Conversation
Additionally, this resolves #27 |
e2ddbce
to
7b26ede
Compare
I'm not really sure how to reproduce the error showing up on Travis, considering everything runs fine within a nix shell locally |
Apparently it runs fine within a nix shell on Travis as well |
This is neat but I don't really want to add support for this unless the syntax is somewhat standardised by the community. |
Understandable. I don't know of any community syntax for this though, which is why I went with a leading comment, making it benign for anyone who doesn't use a syntax highlighter with support for it |
The leading block comment is I think the only sane approach, but could be slightly awkward in the case that someone already is using a block comment prior to a multiline string; maybe make it so that it scans the comment content for something like |
Some type of prefix could be handy to make it a bit more explicit. As far as flexibility goes though it's able to load any syntax available to vim itself, so long as you either know the name or have an alias that points to it |
This is the only sane approach which does not modify the string which would cause rebuilds. It can also be combined with vims included markdown fencing to reuse the same syntax highlighting mapping
|
6affa2b
to
0def802
Compare
Is it possible to disable this feature for very large buffers? I noticed this patch causes tremendous slowdown on Nixpkgs' |
This helps me: commit 490826cd7b80fa4df5ce61a43a2167b9fc7b131a
Author: Doron Behar <[email protected]>
Date: Sat Apr 22 12:57:07 2023 +0300
Allow to disable fenced highlighting
diff --git a/ftplugin/nix.vim b/ftplugin/nix.vim
index 134a0e7..2f7fb72 100644
--- a/ftplugin/nix.vim
+++ b/ftplugin/nix.vim
@@ -19,6 +19,10 @@ if get(g:, 'nix_recommended_style', 1)
\ softtabstop=2
\ expandtab
endif
+
+if get(b:, 'nix_disable_fenced_highlight', 0)
+ finish
+endif
" Borrowed from vim-markdown: https://github.com/plasticboy/vim-markdown/
if exists('g:vim_nix_fenced_languages') |
I'm still very interested in this feature, any chance to get it merged? |
Looking into this now. |
Thanks a lot for the beautiful work! I had some thoughts about this and I'm somewhat interested in getting things ready:
In the meantime I'll try to take a look at the code itself :) [1] NixOS/nixpkgs@0b5a0cb, vim/vim@86b4816#diff-5202ae314163489b5d9872596ccd1bcd9ec8215c64722447dc7ba3b6cbceadd5 |
Perhaps it's even best to make this opt-in instead. Performing syntax highlighting on string contents makes interpolation much harder to see which I feel like is something more common than its syntax complexity. For large code blocks it seems better to use a dedicated file, which also allows regular linting, lsp, etc. tools to be used. |
This is actually a very good point. Constructs such as |
I would love to see this merged in as an opt-in feature. Currently it can be quite difficult to work with language snippets that aren't directly in a mkDerivation phase. Adding such a feature, but not enabling it by default seems like a decent solution to me. |
I rarely use if get(b:, 'nix_disable_fenced_highlight', 0)
finish
endif Right before most of the code added here begins. This enables me to disable this feature for large files for example. |
FWIW I was able to fix the Lua parentheses problem with rainbow-delimiters.nvim, available in nixpkgs. |
This adds fenced syntax highlighting to Nix files by making use of a leading comment on multiline strings.
Edit: This borrows much of the loading code for fenced languages from https://github.com/plasticboy/vim-markdown/