Open-source project
OXY2DEV/markview.nvim avatar
OXY2DEV/markview.nvim

markview.nvim: In-Buffer Markdown, LaTeX and Typst Preview for Neovim

A hackable markdown, Typst, latex, html(inline) & Asciidoc previewer for Neovim

3,653 stars108 forksLuaApache-2.0

At a glance

What is it?
markview.nvim renders Markdown, HTML, LaTeX, Typst and Asciidoc inside the Neovim buffer instead of a browser, with a hybrid mode that keeps the source editable. It suits people who already live in Neovim and want preview without a second window.
Who is it for?
Adopt markview.nvim if you write Markdown, LaTeX or Typst in Neovim and want the preview in the same buffer rather than a browser tab. Skip it if you need a rendered HTML or PDF artifact, or if your documents lean on syntax the README does not list.
Can I use it commercially?
Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 14 days ago.
What is it written in?
Mainly Lua, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 1, 2026, and from our analysis. They are not legal advice.

Editorial analysis

What markview.nvim solves, and for whom

The README describes markview.nvim as "a hackable Markdown, HTML, LaTeX, Typst & YAML previewer for Neovim." The key word is previewer, not renderer. It does not produce a file you open elsewhere. It changes how the buffer you are already editing is drawn, so the markup is styled in place.

That distinction decides the audience. If your workflow is write, save, switch to a browser, refresh, switch back, markview.nvim removes the switching. The README lists splitview, which it says allows "editing & previewing side-by-side", and a hybrid editing mode that allows "editing & previewing at the same time". People who write long Markdown documents, Typst notes or LaTeX-heavy prose in Neovim are the intended users. People who need a shareable artifact are not.

The repository topics line up with that scope: asciidoc, document-preview, latex, neovim, neovim-plugin, typst. There is no export pipeline in the topics or the feature list.

How the rendering actually reaches your buffer

The plugin is written in Lua and ships as a standard Neovim plugin layout: a lua/ directory, a plugin/ directory, a doc/ directory for help files, and a test/ directory. The README points to a wiki rather than keeping configuration and usage documentation in the repository, and it also lists a markview.nvim.wiki entry among the top-level items, which suggests the wiki content is present as a submodule.

Rendering happens through Neovim's extmark and highlight machinery rather than through a separate rendering server. Two README details support that reading. First, it advertises "Dynamic highlight groups that automatically updates with the colorscheme", which only makes sense if the preview is drawn with highlight groups in the live buffer. Second, it states that the plugin works with "tree-sitter injections", meaning previews can appear inside embedded code blocks in a host file rather than only in a standalone Markdown buffer.

The README also documents two features that are explicitly scoped. Wrap support is marked "markdown only, at the moment", and the wiki is referenced for "fixing visual glitches" or disabling it. Fancy comments are flagged as experimental: "Comments are still experimental! The original parser only supports basic features." Those two caveats are the clearest signal that the plugin is honest about where its coverage ends.

Installing markview.nvim and turning it on

The README's table of contents lists an Installation section, but the extracted content does not include its body, so the exact install snippet is not reproduced here. The repository follows the conventional Neovim plugin layout, so any plugin manager that can add a GitHub repository will work. The homepage field is empty, so the repository itself is the distribution point.

Because the README does not give the install command verbatim, the safest first step is to read the wiki's Usage and Configuration pages, which the README links at the top. What the README does confirm is a Configuration section and a Commands section, both delegated to the wiki, and a doc/ directory that ships with the repository. Once the plugin is loaded, opening a Markdown file should render the buffer with the plugin's styling. The README does not list the user commands in the extracted text, so check the wiki or the generated help file for their names.

For Asciidoc specifically, the README does not treat it as automatic. The feature list says Asciidoc preview is available "See integrations#Asciidoc", which points to the wiki's Usage page. Treat Asciidoc as a wired-up integration, not a default.

Where markview.nvim stops being the right tool

The plugin previews; it does not export. Nothing in the README's feature list describes producing HTML, PDF or an image from your source. If your document's destination is a published page, a printed PDF or a shared file, markview.nvim is a step in your editing loop, not the pipeline that ends it.

Coverage is uneven across the five formats. Markdown gets wrap support; the README says wrap is "markdown only, at the moment". HTML support is enumerated as a fixed list of container and void elements: a, b, code, em, i, kbd, mark, pre, s, strike, del, strong, sub, sup, u, plus hr and br. Anything outside that list is not claimed. LaTeX support is described as "basic LaTeX syntax" with a named set of math commands including \frac{}, \sin{}, \cos{}, \tan{}, \sinh{}, \cosh{}, \tanh{}, \csc{}, \sec{} and \cot{}. A document using a command outside that set should not be assumed to render.

The fancy comments feature carries an explicit warning in the README that it is experimental and that "the original parser only supports basic features". Some of its extra syntax, including bold, italic, code, quoted text, @mentions, issue references and code blocks, is listed as needing an external parser. If you enable that feature expecting full fidelity, you will hit the boundary the README already drew.

How it differs from browser-based Markdown preview plugins

The common alternative in the Neovim ecosystem is a plugin that starts a local server and opens a browser tab showing rendered HTML, refreshed on save. The approach is fundamentally different from markview.nvim's.

A browser preview gives you the real HTML rendering path: the same engine a reader would see, with CSS, fonts and layout. It also gives you an artifact you can inspect. The cost is context switching and a second process. markview.nvim inverts both. There is no server and no browser, so nothing to keep running, and the preview is in the buffer you are typing in. The cost is that what you see is Neovim's rendering of the syntax, not a browser's, and the supported syntax is whatever the plugin implements.

If your Markdown is destined for a static site generator or a Git host's renderer, a browser preview is closer to the truth of the final output. If your Markdown is mostly for you, and you want to stop leaving the editor, markview.nvim's in-buffer approach is the one that removes the round trip. The README's Asciidoc, Typst and LaTeX coverage also means the plugin is not limited to Markdown, which a plain Markdown preview server usually is.

Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-17, which is recent. The release history shows v28.3.0 on 2026-05-16, v28.2.0 on 2026-04-24 and v28.1.0 on 2026-03-04. The version numbers move in large increments, and the README's own image paths reference a v27 directory while the README text refers to v25 and v27 assets in different places. That is a signal worth taking seriously: the project iterates in versioned waves, and documentation assets can lag behind the current release.

The practical upgrade cost follows from that. Configuration is the surface most likely to shift between major versions, and the README delegates configuration entirely to the wiki rather than keeping a stable reference in the repository. If you pin the plugin, read the CHANGELOG.md at the repository root before moving a major version, and re-check the wiki's Configuration page for renamed keys. The repository ships a test/ directory, which is a mild positive for change confidence, but the README does not describe a compatibility policy.

The licence is Apache-2.0, a permissive licence that permits commercial and private use and requires preservation of notices and the licence text. This is a description of the licence identifier, not legal advice; read the LICENSE file at the repository root for the actual terms.

Editorial conclusion

Adopt markview.nvim if you write Markdown, LaTeX or Typst in Neovim and want the preview in the same buffer rather than a browser tab. Skip it if you need a rendered HTML or PDF artifact, or if your documents lean on syntax the README does not list. Before committing, check the wiki's Usage page for Asciidoc wiring, and test one real document of your own, because the feature list is broader than the documented per-syntax coverage.

Frequently asked questions

How can I see a Markdown preview in Neovim with markview.nvim?

Install the plugin through your plugin manager and open a Markdown file; markview.nvim renders the preview inside the buffer rather than in a separate window. The README also documents a splitview mode for editing and previewing side-by-side, and a hybrid mode for doing both at once.

How do I use markview.nvim's Markdown preview?

The README lists a Configuration section and a Usage section, with detailed instructions on the project's wiki rather than in the repository. Configuration goes through the plugin's setup entry point, and the wiki's Usage page covers the modes and integrations.

How can I preview a Markdown file in Vim or Neovim with markview.nvim?

markview.nvim is a Neovim plugin, so it applies to Neovim rather than Vim. It works with tree-sitter injections, which the README says lets previews appear in embedded contexts as well as standalone Markdown buffers.

Official sources

  1. Issues
  2. License: Apache-2.0
  3. OXY2DEV/markview.nvim on GitHub
  4. README
  5. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/oxy2dev-markview-nvim.svg)](https://hysenlabs.com/projects/oxy2dev-markview-nvim)