Skip to content
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

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Conversation

rummik
Copy link

@rummik rummik commented Sep 2, 2019

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/

{
  installPhase = /* sh */ ''
    mkdir -p $out
    cp -r ftdetect ftplugin indent syntax $out
  '';

  vimrc = writeText "vimrc" /* vim */ ''
    filetype off
    set rtp+=${vader}
    set rtp+=${src}
   '';
}

image

@rummik
Copy link
Author

rummik commented Sep 2, 2019

Additionally, this resolves #27

@rummik
Copy link
Author

rummik commented Sep 2, 2019

I'm not really sure how to reproduce the error showing up on Travis, considering everything runs fine within a nix shell locally

@rummik
Copy link
Author

rummik commented Sep 2, 2019

Apparently it runs fine within a nix shell on Travis as well

@rummik rummik changed the title Initial work for fenced language syntaxes Add fenced language syntaxes Sep 30, 2019
@LnL7
Copy link
Owner

LnL7 commented Jun 22, 2020

This is neat but I don't really want to add support for this unless the syntax is somewhat standardised by the community.

@rummik
Copy link
Author

rummik commented Jun 23, 2020

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

@Shados
Copy link

Shados commented Jun 24, 2020

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 ft=sh so it is a little more explicit/flexible?

@rummik
Copy link
Author

rummik commented Jun 30, 2020

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

@SuperSandro2000
Copy link

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

let g:vim_nix_fenced_languages = g:markdown_fenced_languages

@dasJ
Copy link

dasJ commented Sep 28, 2021

I've been using this for a couple of months now and one thing I noticed is syntax highlighting breaking after antristrings with the same quoting as the outer strings and sometimes when the editor is split.

image

@doronbehar
Copy link
Contributor

Is it possible to disable this feature for very large buffers? I noticed this patch causes tremendous slowdown on Nixpkgs' all-packages.nix..

@doronbehar
Copy link
Contributor

doronbehar commented Apr 22, 2023

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')

@pinpox
Copy link

pinpox commented May 8, 2023

I'm still very interested in this feature, any chance to get it merged?

@equill
Copy link

equill commented May 8, 2023

Looking into this now.

@agentx3
Copy link

agentx3 commented May 16, 2023

Does lua syntax fencing work for anyone else? For some reason mine really hates right parentheses
image
image

@Ma27
Copy link
Collaborator

Ma27 commented Jul 29, 2023

Thanks a lot for the beautiful work!

I had some thoughts about this and I'm somewhat interested in getting things ready:

  • as @LnL7 already stated, I'm also rather hesitant about merging this as-is considering that this plugin is the de-facto standard for syntax highlighting on nix[1] and I don't feel well with introducing a new standard noone else has agreed on. We should at least discuss this with the maintainers of nix-mode[2] and the vscode integration[3] to cover the vast majority of editors. Perhaps we should even discuss this on nixpkgs itself. That'd also have the nice side-effect that it would be OK to introduce these tags where appropriate (and we could benefit from proper syntax highlighting at way more places).
    So ccing @matthewbauer @jnoortheen what do you think of this approach? It has the benefit that it would work for any kind of expression (and additionally it's clear which language is in use ;-) ). We should probably open up a discussion in nixpkgs itself for this, but I'd like to hear your opinion first.
  • I can confirm the lua issue @agentx3 has reported, would you mind looking into it @rummik ?
  • I tried this plugin out on all-packages.nix and I didn't get any highlighting at all. Perhaps we should automatically disable this feature for either well-known large files (e.g. yarn.nix, hackage-packages.nix, all-packages.nix) or dynamically switch it off for files >n lines. A static opt-out switch should also exist IMHO.
  • Question: has anybody investigated whether an LSP can be thrown against e.g. a block of Python code? Didn't work out of the box for me (using latest nvim-lspconfig and neovim 0.9.1), but I haven't looked closely, yet.

In the meantime I'll try to take a look at the code itself :)

[1] NixOS/nixpkgs@0b5a0cb, vim/vim@86b4816#diff-5202ae314163489b5d9872596ccd1bcd9ec8215c64722447dc7ba3b6cbceadd5
[2] https://github.com/nixos/nix-mode
[3] https://github.com/nix-community/vscode-nix-ide

@LnL7
Copy link
Owner

LnL7 commented Jul 29, 2023

A static opt-out switch should also exist IMHO.

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.

@Ma27
Copy link
Collaborator

Ma27 commented Jul 29, 2023

This is actually a very good point. Constructs such as ''${ will actually cause highlighting problems as well.

@jakehamilton
Copy link

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.

@doronbehar
Copy link
Contributor

I rarely use /* sh */ in my code, due to the problem mentioned above regarding constructs such as ''${, but I enabled this feature in my fork's master branch, with a small addition:

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.

@donovanglover
Copy link

FWIW I was able to fix the Lua parentheses problem with rainbow-delimiters.nvim, available in nixpkgs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.