Vim highlights Unicode control points as misspelled words. So correctly spelled words with Unicode strikethrough (overline, ...) always appear misspelled. Ideally this would be corrected as a setting in Vim spell, which doesn't appear to exist currently. In the meantime, it would be acceptable to me to have a small fix that excludes text that possesses control points from the highlighting functionality, whether or not that text is misspelled.


1. the quick brown fox
2. quisdjdfsdfsdf quisdjdfsdfsdf
3. t̶h̶e̶ ̶q̶u̶i̶c̶k̶ ̶b̶r̶o̶w̶n̶ ̶f̶o̶x̶
4. q̶u̶i̶s̶d̶j̶d̶f̶s̶d̶f̶s̶d̶f̶ ̶q̶u̶i̶s̶d̶j̶d̶f̶s̶d̶f̶s̶d̶f̶


a screenshot of the above example text in vim with red undercurls

These lines use the Unicode control point \u0336 for strikethrough. For more on this refer to 2 or 3.

The below assumes spell check is on using the default highlighting. I will use "red" for "red undercurled in the understood places." I use set spelllang=en_us.

Current situation:

Line 1 is not red, it is spelled correctly
Line 2 is red, it is not spelled correctly
Line 3 is red, even though it is spelled correctly, it contains strikethroughs
Line 4 is red, the strikethoughs make it red regardless of spelling

Desired situation:

Line 1 is not red, it is spelled correctly
Line 2 is red, it is not spelled correctly
Line 3 is not red
Line 4 is either not red, or alternatively, red by virtue of being misspelled

I have tried

syntax match strikethroughNoSpell PATTERN contains=@NoSpell

unsuccessfully, variously using \u0336 and [:cntrl:] and offsets at PATTERN.

Aside from highlighting tricks, should anyone go on to implement the vim spell setting, note that beyond the current behavior, it is desirable both to turn mispelled highlighting completely off in the case of certain control points, and to, in the presence of certain control points, distinguish between correctly spelled and mispelled words. The rationale is that sometimes struck words are not worth considering anymore for the purposes of spell checking, and sometimes they are.

  • Spellchecking is done on the sequence of bytes in the buffer, not on some out-of-band logic that is unknown to Vim, so those are definitely misspelled words, in any language. The only way out of this that makes sense would be to add them to your dictionary.
    – romainl
    Commented Jun 23, 2023 at 5:15
  • I agree with your diagnosis, disagree with most forms of "this is how it should be," excepting perhaps disciplined simplicity. Adding to dictionary multiplies the dictionary weight linearly in the number of supported control points. It seems more reasonable to make a small change, if possible, to the part of the spellchecker that reads the byte buffer. Such a change should be performance invariant. Commented Jun 23, 2023 at 12:47

1 Answer 1


As mentioned in the comment, the spell checking engine does work on the bytes in the buffer and therefore considers the combining characters as part of the item to spell check.

Interestingly, searching just for the combining characters does not work, at least not with the default regex engine, but it works with the old engine. This is a bug, I'll report it to Vim in a second (Bug: 12579)

That means, you can at least make the spell checking engine skip those items, by adding the following syntax rule that uses the old-regex engine (see :h two-engines) for matching those combining chars.

syntax match strikethroughNoSpell /\%#=1\%u336/ contains=@NoSpell

I also notice (at least in Gvim on Windows with the current font) some drawing artifacts, e.g. the drawing combining character is not drawn above the base characters, but behind it. Which besides looking funny breaks cursor movement.

Ah, but this only works, if one switches back to the old font rendering GDI and not using DirectDraw rendering see :h renderoptions. Looks like another bug here (Bug: 12580)

  • Just commenting to praise this remarkably knowledgeable and energetic answer - thank you. Commented Jun 23, 2023 at 12:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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