Syntax folding of Vim scripts

Many syntax files provide fold information. Unfortunately, the officially distributed vimscript syntax file did not until version 7.1-76, and even now only provides limited support. You will need to define your own syntax folding, or resign yourself to inserting fold markers all over the place (which, incidentally, the vim.vim syntax file does). Here is a good set of syntax folding definitions that you can at least use as a starting point.

Contents

The code at the end of this tip allows folding of various Vim script constructs via foldmethod=syntax. Put it in after/syntax/vim.vim, located either in your system-wide or home Vim directory (see :help after-directory).

To use these folds, put setlocal foldmethod=syntax in after/ftplugin/vim.vim. While you're at it, it also makes sense to avoid folding in the command window (q:). You can use the following fragment for that:

Alternatively, you can use an autocommand or a mapping to enable folding. If using an autocommand, the FileType and Syntax events are probably the best ones to use. Calling zR as well when you do this will start with all the folds open when loading the file.

These syntax groups set up regions between start and end patterns as long as they don't start within certain syntax groups such as comments, strings, or the lhs of a mapping, and attempt to skip over commented-out end patterns with the skip pattern.

A syntax cluster (:help :syn-cluster) called vimNoFold is defined to easily exclude certain syntax items from containing a fold. The containedin option is set to @vimNoFold to make sure the fold definitions do not match in areas such as comments, syntax definitions, embedded scripts, and the like. The syntax items contained in @vimNoFold were determined through (a) finding an error and (b) looking at vim.vim to determine which ones are triggering the syntax folding that shouldn't be. It is useful to display the highlight group under the cursor while debugging in this way.

Most of the syntax rules have "begin" and "end" keywords that set up a simple syntax region, using keepend to allow syntax highlighting of end markers and extend to allow nesting.

The "if...else...endif" construct is a little different and works as follows:

vimFoldIfContainer is a simple transparent region with no folding that matches the entire if...endif region

vimFoldIf is only contained in vimFoldIfContainer, and matches if...else or if...elseif, then backs up the endmarker match to allow another match on the else(if). This folds the first part of if...else...endif constructs.

vimFoldElseIf is also only contained in the container, and will match any number of elseif...else(if) groups. This also backs up the endmarker match to allow another match on it to start the next region.

vimFoldElse is also only contained in the container, and will match the final possible group: else...endif.

Note that the contained groups do not have the "extend" argument, meaning that even if the "else" does not match to end the group, the group will not extend beyond the confines of the vimFoldIfContainer (which ends at "endif") because vimFoldIfContainer uses keepend.

These syntax folds are not perfect, and suffer from at least the following:

The syntax definitions are fairly complex. Sometimes, especially when deleting or commenting out an "else", "catch", or "finally", you will need to type :syn sync fromstart to update the fold information. You may want to map this command to a key if you need to do it often.

The "skip" group could probably be improved. Currently, it will attempt to skip single and double-quoted strings, and comments.

Some keywords (such as "else" and "catch") must be preceded by nothing but whitespace to properly trigger fold behavior; this may or may not be an issue depending on your coding style.

If you use reserved words like "while" or "if" for purposes other than Vim language constructs, these fold definitions may incorrectly match them to start a fold. The definitions have an extensive vimNoFold group in an attempt to prevent this, but it can still be fooled. Try to avoid such keywords if you can, especially for variable names. Note: because of the "extend" part of the fold definitions, an incorrect match may cause incorrect syntax highlighting as well as incorrect folding.

While the start-of-region keywords (if, while, etc.) will not start within a group in the vimNoFold cluster, end-of-region keywords (endif, endwhile, etc.) are not similarly protected. Only the skip group protects these.

Rework so that fold groups contain top-level language constructs instead of being contained within them. This approach would make more sense conceptually, and could potentially be less dependent on the specific names in the distributed syntax file. The current @vimNoFold cluster is getting very long and probably still doesn't cover everything. It is very difficult to maintain; I frequently find new groups to add, especially when examining other syntax files.

Explain excerpts from the script in the tip proper, with the full script at the end as it is currently.

I've been thinking about the re-implementation. We certainly need a more robust design, but the method used here (contain in everything, use keepend and extend, add exceptions through trial and error) is probably the easiest, and sufficient for many purposes. I think we should still do the re-implementation, but may just include it as a patch to the distributed vim.vim on the vim scripts website, and note the link here. Thoughts?

Also, this script is big enough that it should probably be linked to as a sub-page. Excerpts can be included in the tip to explain what is going on, but the giant script at the end is very unwieldy for a "tip" page. It is more of a script.

Has anybody tried to make a patch to integrate this functionality into the official vim syntax script? It seems to me, that we would benefit more if these changes could be merged into the official syntax file. I am pretty sure, Charles would include them. Chrisbra 09:26, September 16, 2011 (UTC)

I'm currently unable to log in to wikia. Yes, I contacted Dr. Chip back in in December 2007 about these. He added functions and a couple other items but only said he'd "consider if/else folding". We might try again, I suppose. --Fritzophrenic