agentleFS
lervaglervag/vimtex/AGENTS.md

vimtex

AGENTS.md6.4k starsChanged 5 years agoMITView on GitHub

VimTeX is a filetype plugin for Vim/Neovim providing LaTeX (and BibTeX) support: compilation, PDF viewing, completion, syntax, folding, motions, text objects, TOC, quickfix parsing. Bulk of the code is Vimscript under autoload/; a small and growing part is Lua under lua/vimtex/. Requires recent Vim / Neovim (see README "Requirements" for specific version requirements); CI tests both. - Never commit unless asked. Leave changes in the working tree; the maintainer writes the commits. The same goes for pushing, tagging, and opening…

We split this AGENTS.md into the rules it gives an agent

3 rules. About 0 are common, 1 is distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Never commit unless asked: Leave changes in the working tree.

    line 17
  2. Very specific:

    Test scripts start with set nocompatible / let &rtp = '../..,' .

    line 54
  3. Very specific:

    When adding a backend, copy the _template.vim where one exists and keep the interface identical — the dispatcher calls it by constructed …

    line 107

≈ “Common” is an estimate: at least 1 in 5 of the 36,368 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
AGENTS.md

CLAUDE.md

This file provides guidance to AI code agents when working with code in this repository.

What this is

VimTeX is a filetype plugin for Vim/Neovim providing LaTeX (and BibTeX) support: compilation, PDF viewing, completion, syntax, folding, motions, text objects, TOC, quickfix parsing. Bulk of the code is Vimscript under autoload/; a small and growing part is Lua under lua/vimtex/.

Requires recent Vim / Neovim (see README "Requirements" for specific version requirements); CI tests both.

Working agreements

  • Never commit unless asked. Leave changes in the working tree; the maintainer writes the commits. The same goes for pushing, tagging, and opening pull requests.
  • Never reply to GitHub issues, discussions, or pull request threads unless asked. Reading them for context is fine; posting is not.
  • Write tests early, but run them late. Writing the test first is usually the right first step: for a bug, a failing test that reproduces it; for a feature, a test that exercises the intended API, since that is the best way to see how the code will feel to use in practice. What should not happen is running the suite after every individual change — that interrupts the flow of thought. Work through the design and implementation, then run the tests as a final stage.

Tests

Tests are Makefile-driven Vim scripts. They live in test/test-*/ and are plain .vim files run with a clean editor via -u.

make                                 # run everything (as CI does, with -j1)
make test-toc                        # run one test directory
make test/test-toc/test-general      # run one test file (test-general.vim)
MYVIM="vim -T dumb --not-a-term -n" make   # run with vanilla vim instead of nvim
  • The root Makefile is a thin wrapper that forwards to test/Makefile; the same targets work from within test/ (cd test && make test-toc) and via make -C test ....
  • MYVIM defaults to nvim --clean --headless.
  • The subdirectory Makefiles export INMAKE=1. Most test scripts contain if empty($INMAKE) | finish | endif so that running nvim -u test-foo.vim by hand drops you into an interactive session with the fixture loaded, while make runs the assertions.
  • Assertions use Vim's assert_* functions plus helpers in autoload/vimtex/test.vim (vimtex#test#finished() — must be the last call, it prints v:errors and cquits on failure; also #completion(), #keys(), #main()).
  • Test scripts start with set nocompatible / let &rtp = '../..,' . &rtp / filetype plugin on to load the working tree copy of VimTeX.
  • Some tests need latexmk/TeX Live, wget, and chronic (moreutils). docker/Dockerfile reproduces the CI environment.
  • test/example-* are manual playground setups, test/issues/NNNN are issue-specific reproductions, test/perf-* and *-speed/*-timing are benchmarks (the timing ones are ordered last by test/Makefile).

Docs site

mise run web-build / mise run web-host build and serve the site (Hugo landing page from README.md + doc/vimtex.txt rendered by Neovim's gen_help_html.lua); see web/scripts/build.sh.

Architecture

Entry points. ftplugin/tex.vim and ftplugin/bib.vim call vimtex#init(). syntax/tex.vim and indent/tex.vim are separate entry points (they are not loaded via vimtex#init()). after/ftplugin/tex.vim checks for conflicts with other plugins. plugin/vimtex.vim defines only what must be global (notably :VimtexInverseSearch) — this is why VimTeX must not be lazy loaded by a plugin manager.

Module auto-discovery. autoload/vimtex.vim globs autoload/vimtex/*.vim into s:modules and calls vimtex#<mod>#init_buffer() for each, ignoring E117 when the function doesn't exist. So a new submodule is wired up simply by creating the file and optionally defining:

  • vimtex#<mod>#init_buffer() — buffer-local mappings, commands, autocommands
  • vimtex#<mod>#init_state(state) — add data to the project state

State. autoload/vimtex/state.vim maps a buffer to a project state object (b:vimtex, id in b:vimtex_id), created by vimtex#state#class#new() in state/class.vim. One state per LaTeX project (main file), shared across all buffers of a multi-file project; sub-files may additionally get a "local" state (vimtex#state#init_local()). Cleanup happens on BufWipeout and VimLeave.

Backend dispatch. Several subsystems pick an implementation by option and call into a per-backend file with a uniform interface:

SubsystemDispatcherBackends
compilecompiler.vimcompiler/{latexmk,tectonic,arara,latexrun,texpresso,generic}.vim (#init() returns a state object; _template.vim is the base)
viewview.vimview/{zathura,mupdf,sioyek,skim,general,...}.vim (#new() returns an object with .view())
quickfixqf.vimqf/{latexlog,pulp,bibtex,biblatex,pplatex}.vim
foldfold.vimfold/*.vim, one file per fold type
completioncomplete.vimcontext-dependent completers; complete/<pkg> are keyword lists, complete/tools maps commands to unicode
context menucontext.vimcontext/*.vim
text objectstext_obj.vimtext_obj/{targets,cmdtargets,envtargets}.vim
jobs / uijobs.vim, ui.vimjobs/{vim,neovim}.vim, ui/{vim,nvim,legacy}.vim (editor abstraction)
parsingparser.vimparser/{tex,bib,toc,fls,auxiliary,fixme}.vim

When adding a backend, copy the _template.vim where one exists and keep the interface identical — the dispatcher calls it by constructed function name (e.g. vimtex#view#{g:vimtex_view_method}#new()).

Options. All g:vimtex_* defaults are declared in one place, autoload/vimtex/options.vim, via s:init_option(); that file also holds deprecation checks and default highlight groups. A new option must be added there and documented in doc/vimtex.txt.

Syntax. syntax/tex.vim is thin; rules live in autoload/vimtex/syntax/core.vim with package-specific rules in autoload/vimtex/syntax/p/<package>.vim (loaded on demand via syntax/packages.vim) and syntax/nested.vim for embedded languages. autoload/vimtex/syntax.vim is the query API used by the rest of the code (e.g. vimtex#syntax#in_mathzone()) — not the rules themselves.

Other cross-cutting APIs used widely: delim.vim (vimtex#delim#get_surrounding()), cmd.vim (vimtex#cmd#get_current()), cache.vim (vimtex#cache#open/close, persistent under $XDG_CACHE_HOME/vimtex), log.vim, pos.vim, util.vim, debug.vim.

DOCUMENTATION.md is the maintained high-level tour of this structure — update it when the structure changes.

Conventions

Vimscript style (see CONTRIBUTING.md): shiftwidth=2, no tabs, max 80 columns, single-quoted strings, abort on functions, l: prefix on locals, s: for script-local. Functions are folded with markers: each function ends with a trailing " }}}1 line and the header ends with " {{{1. Keep related functions grouped so the folded file reads as an outline.

Lua style: .stylua.toml — 80 columns, 2 spaces, double quotes preferred, no parentheses on single-argument calls.

Vimscript linting: .vintrc.yaml configures vint.

Documentation: doc/vimtex.txt follows Vim help syntax — max 80 columns, section separators of =, subsection separators of -, tags right-aligned at column 79, and every section listed in the table of contents. Cross-reference with help tags (|vimtex-foo|) rather than backticks; a |Foo| link resolves even when the tag is defined as *:Foo*. Regenerate doc/tags with :helptags doc when tags change.

Commits: conventional commits, parsed by cliff.toml for the changelog — feat, fix, doc, perf, merge appear in the changelog; test and chore are skipped. Scopes are used freely (e.g. feat(view): ...). Development happens on master.

Download now (ZIP)

Trending

Steady: 0 new projects took it in the last 4 weeks, none the 4 weeks before.thin data

Week of Aug 30: 0 new projectsWeek of Sep 6: 0 new projectsWeek of Sep 13: 0 new projectsWeek of Sep 20: 0 new projectsWeek of Sep 27: 0 new projectsWeek of Oct 4: 0 new projectsWeek of Oct 11: 0 new projectsWeek of Oct 18: 0 new projects
Aug 2026Sep 2026Oct 2026
New projects taking a version of this file each week, over the 8 weeks our latest run read: only 0 in all, so this is a hint, not a trend.

Who's talking about lervag/vimtex

The biggest 5 of 55 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 55

Talked about on GitHub, Bluesky, Stack Overflow and Hacker News (55 times).

On GitHub · 50

45 more on GitHub
  • Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.

    Of the AGENTS.md files we read, the 28,693 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.