Did you compare if this affects the performance?

Quickly comparing one file with and without this, the syntax time doesn't seem to be affected, but this added lots of additional checks. Probably the regex checks are fast anyway as it will just stop when the string doesn't start with #_. Maybe check count increases a lot as this has 5 different regexes checking for #_ and the different parenthesis, so it has to do a bit of duplicated work to check for #_ again for each case.

Also, this doesn't support case with multiple #_ combined to ignore map key value pairs, like #_#_:foo "bar". Probably unfeasible to support that using regexes.

One side effect of changing the style for code forms after #_ is that it breaks the indentation. Indentation uses the syntax rules to find forms etc.

 (defn foo [bar]
 #_
 (let [a 1]
 (+ 1
 2
 3)))
;; =>
(defn foo [bar]
 #_
 (let [a 1]
 (+ 1
 2
 3)))

Another is that motions that deal with elements, like ae used to work inside commented out forms. Maybe also cpp or such commands from fireplace or others? Like (+ ...) in the example, now these select the whole commented out form.

Do you know if we could still parse the commented out forms like previously, but only change the color?

One side effect of changing the style for code forms after #_ is that it breaks the indentation. Indentation uses the syntax rules to find forms etc.

I've pushed a small fix for this.

Another is that motions that deal with elements, like ae used to work inside commented out forms. Maybe also cpp or such commands from fireplace or others? Like (+ ...) in the example, now these select the whole commented out form.

Would you mind trying them again with the patch I just pushed? If they still don't work I might make the highlighting of this optional (disabled by default) or even revert the change entirely until I find a way to make this work without breaking keybindings.

Do you know if we could still parse the commented out forms like previously, but only change the color?

As far as I know, this isn't possible using the syntax file, but "text properties" might be able to.

Indent works now.

Text objects (confused with motions in previous comment) still don't work.

For context:
https://github.com/guns/vim-sexp/blob/master/plugin/sexp.vim#L269
https://github.com/guns/vim-sexp/blob/master/autoload/sexp.vim#L1434

There are some notes about "contained" syntax rules also here:
https://github.com/guns/vim-sexp/blob/master/autoload/sexp.vim#L458-L474

Looking at clojureCommentReaderMacroForm, it is still parsing every form inside the comment, as that is needed anyway to count the parenthesis to find the end of macro form. There is just some small difference in this syntax rule compared to others.

I've found the source of the problem. Vim-sexp will ignore syntax regions containing "comment". The way to fix this is to rename clojureCommentReaderMacro and clojureCommentReaderMacroForm to not contain the word "comment".

Now I'm not sure whether I should:

1. rename it,
2. make it optional, or
3. remove the feature entirely.

The fact that it isn't possible to correctly syntax highlight stacked #_s is making me lean more towards removing this change.

I've pushed a commit to rename it for now although I'm still considering making it optional or removing it.

I thought I tested that myself, but yeah, works now. Strange that they check for partial matches of syntax names, but maybe that is a feature.

Not quite sure yet what's best solution here. I'm used to #_ not affecting syntax coloring, but it would also be nice to have. Though would be indeed even better if we could support stacked macros.