[Feature request] Add option to control or disable indentation of paragraphs in terminal output

[itshog]

Would it be possible to add a command line option which disables the indentation of normal paragraphs in -tterm output? I'm thinking about something like --term-no-indent for disabling indentation globally, or --term-indent=code,lists,paragraphs,tables... to specify exactly what should be indented if we need more granularity.

My use case for this is using lowdown for previewing markdown files in vifm (but I guess the same applies for almost every terminal file manager), and having so much empty space between the file list and the preview looks ugly and needlessly shrinks the space for the actual text (I'm attaching a couple of screenshots to show what I mean). I know that I could just pipe the output into sed 's/^ *//g' to remove the leading white spaces, but this lacks granularity (it doesn't differentiate between paragraphs, lists, code blocks etc.) and needs an external utility to accomplish something that IMO could be an option in lowdown itself.

Anyway, thanks for the great piece of software!

[kristapsdz]

If you have control of the software from source, you can edit term.h line 167 to be

static const struct pfx pfx_body =  { "", 0 };

This is the style applied by terminal output to regular text. I think a better feature request would be to read in a file, if provided, that styles the text in a non-hard-coded way.

[itshog]

If you have control of the software from source, you can edit term.h line 167 to be

static const struct pfx pfx_body =    { "", 0 };

This is the style applied by terminal output to regular text. I think a better feature request would be to read in a file, if provided, that styles the text in a non-hard-coded way.

Thanks for the response! Honestly, in my opinion the details of the implementation for this feature don't matter that much from the end user point of view: it could be a command line flag, it could be a user-provided file containing information about the style, it could be some sort of configuration file in ~/.config or something else, as long as it achieves the aforementioned granularity that piping into sed doesn't have.