TTY reader and writer

[marcthe12]

Terminal emulators support formatting via control and escape codes. If pandoc support reading or writing such "files"(most use case involve stdin or stdout). If it added It can be used in combination with a pager like less or more to read document formats on terminals with limited formats. A reader could be used store output of programs with the formatting intact in another format like html.

[alerque]

Terminal emulators support formatting via control and escape codes. If pandoc support reading or writing such "files" (most use case involve stdin or stdout). If it added It can be used in combination with a pager like less or more to read document formats on terminals with limited formats.

How would such a writer be any better than using an existing writer such as Markdown and adding a syntax highlighter inline before your pager? Ones like bat come to mind as being well suited for chaining with Pandoc to act as a viewer for any supported documents in the terminal.

Terminal control and escape codes vary between terminal emulators. This is not a world (TUI) that a document conversion program (CLI) wants to get involved in.

Even if it did, I don't think a reader for such a format makes any sense at all because the output format wouldn't have an editor. Importing such documents wouldn't even make sense for importing other TUI formatted outputs such as man pages or vim help documents because the sources for those documents make more sense than the rendered format.

A reader could be used store output of programs with the formatting intact in another format like html.

I don't understand what you are even saying here.

Overall as far as I do understand the gist of this feature request I think it is out of scope for Pandoc. Basically you are talking about ways of rendering document to the screen here here, not document content formats. If you were going to add a rendered format as a writer you might as well add a rasterised graphic stream output as well.

[mb21]

Agreed that this is probably out of scope... but see e.g. https://stackoverflow.com/questions/7599447/less-style-markdown-viewer-for-unix-systems

e.g. using groff (which comes preinstalled on macOS AFAIK):

pandoc input.txt -s -t man | groff -T utf8 -man -

[marcthe12]

Hmm. Maybe this out of scope. But still its worth a discussion as there is definitely a demand for rendering documents in a terminal. Groff(man) is close but since it specialized format they maybe some gotchas. Maybe a subset of markdown or a new format altogether

[alerque]

there is definitely a demand for rendering documents in a terminal

Of course there is, but I still think you are conflating the rendering process (a document viewer whose UI is a terminal, i.e. a TUI viewer) with the conversion process (Pandoc is a document format converter whose Ui is a command lite, i.e. a CLI utility).

There are lots of options for the former (have a look at bat, mdv, mdp, mdless for Markdown based ones, or lynx or wc3 for HTML based ones, or of course man itself for man, just use less for plain, any number of Wiki UI's for the various Wiki output formats, etc.)

Groff(man) is close but since it specialized format they maybe some gotchas. Maybe a subset of markdown or a new format altogether

Close to what? What would you even envision the rendered output would look like that is not covered by one of the Markdown or HTML based TUI's above? And if something isn't covered, why would this need a new document output format rather than just a new document viewer project?

[tarleb]

I'm closing this, as I believe it is (just very slightly!) out of scope, due to the variety of possible terminal presentations.

I note that a couple of specialized tools exist which might be of interest:

• patat for presentations;

• pandoc-terminal-writer which produces a colorful terminal output;

• CatPandoc which seems to have good table support;

• mandoc, which is just a Bourne Shell function:

  mandoc () { pandoc --to=man --standalone "$1" | man -l - }
  

• etc.

Please reopen if you think that a generic terminal output is possible and desirable.