Monthly Archives: January 2026

Neovim and LaTeX with LazyVim, part 2: customizations

This is a follow-up to the first post on Neovim and LaTeX.

I love LaTeX, but I don’t love LaTeX noise. If you use LazyVim’s lang.tex extra, you’ve probably seen a familiar friend pop up in your editor diagnostics: Underfull \hbox. It’s usually harmless, but it’s distracting—especially when you’re trying to focus on content. In this post, I’ll show two clean ways to silence those warnings: one for VimTeX’s quickfix and one for TexLab’s LSP diagnostics, without turning off the good stuff.

In LazyVim’s Tex extra, those Underfull \hbox … messages are coming from VimTeX’s Quickfix parsing (it’s enabled by default in the extra). VimTeX lets you hide specific warnings by regex-matching them with g:vimtex_quickfix_ignore_filters.

Create a custom plugin specification, e.g., “~/.config/nvim/lua/plugins/extend-vimtex.lua”, with these contents:

Restart Neovim, and the quickfix list will no longer contain those warnings.

However, you’re still seeing “Underfull \hbox” as LSP diagnostics (not quickfix), that’s coming from TexLab (separate configuration):

You need to create another custom plugin specification for customizing the TexLab LSP, e.g., “~/.config/nvim/lua/plugins/extend-lspconfig.lua”:

Restart, and also the editor’s inline warnings of that space will be gone.

If you don’t like that deep specification, in LazyVim, you don’t have to restate the whole opts = { servers = { texlab = { … }}} block. You can patch the existing LSP config in a tiny opts = function(_, opts) ... end snippet (LazyVim shows this pattern for extending defaults, and also documents the opts.setup hook for server setup).

Here’s an alternative configuration:

Though it’s a bit longer.

The final result of this series of tutorials can be found here: https://github.com/LorenzoBettini/lazyvim-tex. Branches will denote the state of the repository for a specific blog post section.

Stay tuned for more blog posts on LaTeX and Neovim! 🙂

Stop VS Code’s Java LSP from Rewriting Your Eclipse .classpath with m2e-apt Entries

How to prevent JDT LS (via m2e) from adding generated-sources APT folders and org.eclipse.jdt.apt prefs to an Eclipse+Maven project in VS Code.

If you open a Maven Java project in Visual Studio Code that also contains Eclipse project metadata (.project, .classpath, .settings/…), you might notice that VS Code’s Java tooling (JDT Language Server) “helpfully” edits your Eclipse files.

In particular, it may keep re-inserting entries like these into your .classpath:

…and it may also create this file:

.settings/org.eclipse.jdt.apt.core.prefs

VS Code Java support is powered by Eclipse JDT Language Server (JDT LS). When it detects Eclipse metadata (.project / .classpath), it will often use Eclipse-style project configuration and keep it synchronized.

For Maven projects, JDT LS relies on m2e (the “Maven integration for Eclipse”), and in many setups m2e-apt is present as well. m2e-apt is the component that manages annotation processing (APT) integration and, as part of that, it adds the standard “generated sources” folders into .classpath.

I find that very annoying!

If your project doesn’t use annotation processing and you don’t want these Eclipse files constantly modified, and you remove the entries, Visual Studio Code will re-add them when you open the projects in Visual Studio Code. If you open the projects from Eclipse and you “update” the Maven projects, Eclipse will remove the entries… and so on and so forth!

Here’s how to fix things for good.

The fix: disable m2e-apt at the project level

m2e-apt supports overriding its activation per-project using a Maven property:

Add this to your pom.xml

Put it under the regular Maven <properties> section:

That’s it. After this, m2e-apt will stop treating your project as something it should manage, and VS Code/JDT LS will no longer keep reintroducing those APT-related .classpath entries.

Note: The documentation mentions a “settings section” in the POM. There is no settings element in pom.xml; Maven “settings” live in ~/.m2/settings.xml. In the POM, this is implemented via a property, so properties (or a profile’s properties) is the right place.

Refresh VS Code so it stops regenerating the files

After editing the POM, VS Code may still have cached the project configuration. Do this once:

  1. Open the Command Palette
  2. Run: Java: Clean Java Language Server Workspace
  3. Let the Java server restart and re-import the project

Then you can delete the unwanted entries/files one last time:

  • Remove the APT-related classpathentry … m2e-apt … blocks from .classpath
  • Delete .settings/org.eclipse.jdt.apt.core.prefs if you don’t want it around

They should not come back.

If you only want to disable it in certain environments, you can place the property in a Maven profile or in the pom file of a single project.

Happy (quiet) classpaths! 😉