When longer paragraphs have no line breaks in the middle, I get the warning:

chktex: WARNING -- ChkTeX does not handle lines over 509 bytes correctly. Some errors and line numbers may be wrong in this file.

I've found a report of a similar issue at ChkTeX: warn of lines that are too long and therefore generate erroneous warnings. In their case, they used LaTeX-Workshop and also went quite far in other research. It seems likely ChkTeX is not geared for (some?) Windows environments. The OP of that post knocked up some code to identify which lines are too long.

One workaround is to manually add line breaks, but that is a pain and adds inconvenience for colleagues.

My environment:

  • Windows 11
  • VS Code version 1.67.1 (LaTeX extension version 1.2.0)
  • One MiKTeX Utility 1.2 (MiKTeX 22.3)
  • ChkTeX v1.7.6

So, my question: is there a fix or better workaround for this?

  • 2
    509 bytes is a pretty long source line ....
    – Joseph Wright
    May 16, 2022 at 10:57
  • VS Code should be able to do hard wraps automatically so use hard wraps instead of soft wraps. That also helps for easier diffs if you use version control for collaboration.
    – TeXnician
    May 16, 2022 at 11:48
  • Couldn't you configure your editor to insert line breaks automatically every x characters?
    – Ingmar
    May 17, 2022 at 5:44
  • @TeXnician and Ingmar. VSCode does not have a native setting for hard wraps, but you've prompted me to look into it and I've found there are plug-ins available. Will experiment. One complexity is that I collaborate with someone who variously uses a Mac and a Linux system (anything but Windows) and who tends to rely on soft wraps for their stuff. May 17, 2022 at 12:14
  • 1
    FYI: Use the VsCode package Rewrap to hard wrap your text to specific lengths (works on Windows). @JosephWright Source code yes, but this affects text you write for a paper or thesis in LaTex.
    – ahi
    Dec 4, 2022 at 14:23

2 Answers 2


Sorry it's causing you problems. This is a bug/limitation in the current implementation of ChkTeX. It simply uses the BUFSIZ macro which is apparently much smaller on Windows systems than on Linux or Mac. I don't use Windows, so I've never run across it myself (in a real-life situation). I knew it was a theoretical problem, but didn't know people were actually seeing it in normal usage.

I could use a different global limit that's higher, but that's not really a fix. But, it would be better than the current situation if people on Windows are actually running into the limit.

When I think of handling the resizing in C myself I just lose all desire to fix it. I keep thinking I should rewrite it in C++ so I could use std::string (or maybe something even higher level like python). It would end up being more maintainable, but I don't have much motivation for that either since it wouldn't get any new features and would likely introduce new bugs.

But, knowing people actually hit the limit should be enough motivation for me to do something.

  • Nice to know the root cause is known. Maybe a temporary "fix" could be to use a hard-coded large number. Feels bad hard-coding stuff like that, but according to Controlling Buffering (The GNU C Library) BUFSIZ is only guaranteed to be a minimum of 256 and it's not always necessary to use that specific value for buffer sizes. Seemingly most systems exceed that value anyway. I'm assuming "256" means "256 bytes", though it's not clear to me from the article. Me not being a C programmer. May 17, 2022 at 12:31
  • 1
    I have increased it to 4096 (bytes) for 1.7.8. It's not as good a fix as I was hoping (since it's still limited). But if you have 4k lines, you might want to rethink your life anyway. :) Dec 19, 2022 at 19:25

Add this line in "settings.json":

"latex.linter.enabled": false

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .