3

I have a bunch of (spagetti) fortran code that is in fixed form, but without the line length restrictions. As such, it gets some odd highlighting:

Standard highlighting

I've tried 3 different ways to get it to highlight correctly, but none of them work.

  1. Add setlocal textwidth=132 to .vimrc
  2. Add let fortran_free_source=1; setlocal comments=:!,:*,:C,:c to .vimrc
  3. Create new syntax file that implements both the above changes for fortran_free_source=1 and fortran_fixed_source=1.

Option 1 does nothing. Option 2 doesn't recognize C as a comment string. Option 3 also does nothing.

Any ideas what's wrong here?

Edit: Also, running :verbose set [setting]? in all the above cases returns the expected result (ie. For option 1, it'll say that textwidth=132 and that it was set from .vimrc)

| improve this question | | | | |
  • 1
    What's the extension of the file? Try this: syn clear fortranSerialNumber. Or try to add let g:fortran_has_tabs = 1 to your vimrc. Looking at the syntax file for Fortran, that's what I came up with... – filbranden Dec 18 '19 at 23:58
  • 1
    syn clear fortranSerialNumber worked! The extension of the file is *.f. I'm not sure why it does (feel free to add to add an answer and I'll mark it as correct). @filbranden – James Wright Dec 20 '19 at 22:14
  • 1
    Also, for stragglers, this SO answer is probably helpful: stackoverflow.com/a/9505434/7564988 – James Wright Dec 20 '19 at 22:15
2

Looking at the Fortran syntax file, I could find that the source of that highlighting past column 72 is coming from this rule on line 358:

syn match fortranSerialNumber excludenl "^.\{73,}$"lc=72

As you can see, columns 73 and 72 are hardcoded into this rule, so setting 'textwidth' will not really affect this particular rule and won't really work to fix this.

(You can also see this rule is defined inside a if (b:fortran_fixed_source == 1) and the ftplugin/fortran.vim file sets this buffer variable for files with the .f, .f77 or .for extensions. That also matches your comment regarding the extension of your file.)

In order to work around this, one option is to undo the effect of that particular rule, which you can do by clearing it after the syntax file is loaded.

To do that, you can create a new file ~/.vim/after/syntax/fortran.vim and add the following line there:

syn clear fortranSerialNumber

This will undo the syntax highlighting past column 72 in your Fortran files. Placing the file being in the after/ directory ensures it's loaded after the main syntax highlighting rules, so it will have a rule to delete there.

See :help mysyntaxfile-add for more details on customizing syntax rules in Vim.

Please note that this change will affect all Fortran files (more specifically, fixed source ones, which use this rule.) If you want something more localized, to a single project only, you might need to do some adjustments to only remove the rule depending on the specific file. (An option to consider to implement this is to use an alternative file type, on the 'filetype' setting, that will source the fortran.vim files and add modifications. Another option is to use multiple filetypes in 'filetype', separated by a dot ., so you can keep fortran and add one more for your specific customizations.)


There's one more option to consider. Looking around the definition of the fortranSerialNumber, it's inside a block that checks that the fortran_have_tabs variable is unset (presumably because if you're using tab characters, it's harder to check for a specific column, since tab sizes can vary.)

So you might be able to prevent the definition of this rule by adding this to your vimrc:

let g:fortran_have_tabs = 1

The advantage of this approach is that you can simply configure it from your vimrc file, no need to mess with anything inside the ~/.vim tree.

On the other hand, setting this will have a few other side effects. There are two other rules inside that block that won't get set (the rules seem to highlight errors in labels, which seem to be expected in specific columns.) There's also another rule regarding tab characters themselves. If you're fine with these side effects (considering you're breaking some rules by going past column 72, I guess you might?), then consider this as a possible solution for the issue as well.

| improve this answer | | | | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.