Hi Klemens, Klemens Nanni wrote on Sat, Jan 16, 2021 at 10:31:49AM +0100:
> On rare occasions I'd like to use the following idiom to read manuals in > browsers, mostly to better readability and navigation of long sections: > > MANPAGER=netsurf-gtk3 man -Thtml jq > > (jq(1) has lots of examples and HTML is nicer to read when it comes to > literal input and output for example.) Indeed, on rare occasions, such idioms are useful for various purposes. > My problem is that browsers fail to render HTML as such in case the > temporary file generated by mandoc(1) lack a file extension, i.e. > `$browser /tmp/man.abc123' will show literal HTML code whereas > `$browser /tmp/man.abc123.html' will actually render it. Software deriving the file type from the file name extension is stupid and un-UNIXy. Such behaviour also tends to be dangerous for obvious reasons. Admittedly, such behaviour is widespread in the Web context - even httpd(8) derives file types from file name extensions... Not all browsers fall into that trap, and some explicitly allow specifying the file type, for example $ MANPAGER="lynx --force_html" man -T html ls But i agree that lack of such support is maybe not a sufficent reason to refrain from using a browser one wants to use for other reasons, so the feature you propose seems useful to me, and i agree with your general direction. > HTML is the only output type I've encountered problem with so far. > PDF/mupdf(1) for example works fine with arbitrary file names: > > MANPAGER=mupdf man -Tpdf jq > > Diff below makes mandoc produce temporary files with the ".html" suffix > in case `-Thtml' was specified. Sounds sound, i see no downside. > It feels a bit off to do this for HTML only, That part doesn't seem that bad to me. Abusing filename extensions is particularly widespread on the web, so it feels unsurprising that HTML may need more handholding than other modes. > but it greatly improves > accessibility for me and is simple enough. If need be, the suffix > handling could be easily extended to cover more output types in the > future. > > Feedback? Objections? OK? It's maybe just a bikeshed, but could you put the logic selecting the filename extension (either "" or ".html") at the place where term_tag_init() is called? That (main.c) is the module where the OUTT_ constants are defined, so it's the natural place to make decisions based on them. Then just pass a third const char * into term_tag_init(). Or do you see any downside that approach might have? *If* people ever request the same for PDF, it makes adding that even easier. Also, maybe put the new argument in the middle position because it is only related to the first argument and not to the second. Finally and KNFly, please refrain from using function calls as variable initializers. Yours, Ingo
