1. 7

In particular, this statement:

  1. Some time ago I added to Linux man(1) the capability to recognize HTML pages in the man hierachy and kick them over to the user’s Web browser. All Linux and *BSD distributions now ship this code.
  1.  

  2. 12

    Kind of interesting that his name does seem to show up in the linux man git repo at all. That is, http://git.savannah.gnu.org/cgit/man-db.git/log/?qt=author&q=esr (and every other permutation I have tried) return no commits. Also, reading the followups, it seems clear that esr lacks the ability to engage with reality - eg, as a typical example, when bugs in his suggested tool chain are mentioned here: https://lists.gnu.org/archive/html/groff/2014-02/msg00109.html his reply is basically ‘you are lying, these are not bugs, and also there are no bugs, and bugs are impossible because I would know if there were bugs’.

    Also, as seen here https://lists.gnu.org/archive/html/groff/2014-02/msg00106.html when someone directly refutes his core claims (that this code of his is in Linux and all *BSDs) he simply does not respond.

    1. 1

      Bleh, the first sentence should have been ⌜Kind of interesting that his name does not seem to show up in the linux man git repo at all.⌝. Posting while tired etc.

    2. 6

      Oh gahd…I’m all for killing info, but this seems…like an even-worse alternative.

      1. 1

        In my own research operating system I’m planning to use either markdown or something slightly custom (just to structure the all manpages in the same way).

        However, I’m eager to listen about simpler and cleaner alternatives!

        What are you thinking of?

        1. 4

          Ingo Schwarze at least has some strong feelings about why not Markdown, and I agree with the points made.

          Side note: You’re linking to an HTTPS page on GitHub Pages. People who don’t have an exception for GitHub’s GitHub Pages cert will experience an error there.

          1. 4

            The funny thing is that I agree with Schwarze about Markdown as a presentation language.

            And still I can’t find another language that can be consumed both as a plain text (via cat) and as input to produce nicer presentations (as HTML and/or PDF).

            In a perfect world I would hire a programmer to design and develop such language with me.
            But in a perfect world, I could pay the bills programming in C for Jehanne, not in Javascript for banks.
            Maybe in a perfect world we wouldn’t have neither Javascript nor banks (nor blockchains for what it worth)! :-D

            So if you have a better solution to propose I’m really eager to listen. Really!

            My requirements are rather simple: the language for Jehanne’s manual pages must be

            1. easy to read in source form (in UTF-8)
              1.5) semantic enough (maybe though the adoption of conventions) to build index and cross references
            2. precise enough to transform into a nice PDF

            1 and 1.5 are more important than 2.

            The only alternative to a (slighly customized) Markdown (that I know a bit) is AsciiDoc, that unfortunately is designed to be easily written, but not to be easy to read in source form.

            (thanks for the hint about the link… it was a typo… fixed!)

          2. 3

            I have little to no horse in the race of the source format; my nausea is a reaction to the presentation of the rendered form – emacs (even though I’m an emacs user!), HTML, and (worst of all) web browsers.

            I like man pages. In my pager, in my terminal. More terminal, less web.

            1. 1

              I agree so much that in Jehanne you will read manual pages with cat.
              And in a rio window, you won’t even need a pager.

              So my question is about presentation.

            2. 2

              What’s wrong with troff -man?

              1. 1

                Nothing!

                But cat is simpler.

                1. 2

                  So why are you looking for an alternative typesetting language?

                  If you’re using cat, man pages would have to be plain text, no?

                  1. 1

                    Yes, I even thought about simple plain text. And it is still an option!

                    But I guess that one can design a simple typesetting language to be very readable in source form.

                    It’s just a matter of trade offs. Markdown explores this design space.
                    I think we could have something even better and I would actively help in the design anyone who is interested, but Jehanne is a full operating system and it leaves me with no time for this.

                    Still implementing a compiler for such hypotetical language would be the only way to evaluate the trade-offs and to ensure that it is formal enough.

              2. 1

                Have you considered Perl’s pod?

                regarding /u/Shamar’s later post:

                1. debatable, but yes
                  1.5. yes, with L<name>
                2. yes
                1. 1

                  Didn’t know it, but to me the rumor / message ratio in source form is to high.

                  The primary consumption of the Jehanne’s manual pages will be through cat of sources.

                  Thus the markup must be minimal so that readers will rapidly learn to ignore it.

                  POD’s markup is simple to learn and use, but definitely not minimal.

                  Slightly extended Markdowns, such as the one of discount, are way more transparent.

                  I could design something better from this point of view, but people should learn it just to write Jehanne’s manpages and I should find a way to leverage existing tools.

                  It’s in no way impossible, but neither a priority nor a funny task.

            3. 4

              the horror. the horror.

              1. 1
                1. Jawbone all the world’s man page authors into cleaning up their markup so doclifter can interpret it structurally to clean XML and (through that) HTML.

                The W3C tried something like that with XHTML; it failed miserably, and HTML5 won because it works with existing documents. What hubris must it take to think that the whole world must bend to your parser, and not the other way around?

                1. 2

                  I don’t think the two situations are comparable. One is a question of how tens of millions of largely non-technical users create documents consumed by several parsers that are in a fierce war with each other for contolling access to an audience of billions. The other is a couple thousand software developers with a similar number of documents, so even if they refuse or are incapable, a single person could manually fix or fork the remainders.

                  1. 1

                    You’re totally right about the audience/scale. I still think it’s quite arrogant, when he could improve doclifter instead.

                    I had to look up the specific word he used, which prompted my reply:

                    Jawbone: attempt to persuade or pressure by the force of one’s position of authority

                2. 1

                  I don’t understand the opposition to this idea. Having command line documentation that opens up a HTML page in a browser is reasonably common. For instance, this is exactly what rustup docs does, which I use all the time. I agree that there’s something to be said for having documentation that is completely console-friendly and has no connection to a graphical screen, but it’s also the case that the entire linux command line ecosystem is old and adheres to a lot of conventions that made sense on machines of ~30-40 years ago (in some cases emulating even older terminals). I think it’s a good thing to consider ways to make the command line experience better by taking advantage of the graphical facilities that even the cheapest general-purpose computers have had for decades now.

                  1. 5

                    Almost all of my servers are headless, and a bunch of them are in DMZs where they cannot access the internet, and yet I still find myself needing access to the documentation that corresponds exactly to what is installed when I am doing sysadmin stuff fairly frequently. I don’t want to have to install X, a desktop environment, a graphical browser, and open the server up to the internet; to make esr’s suggestion work as he has claimed it is implemented requires all of those things. Also the suggested toolchain seems to be problematically buggy, according to the mailing list replies.

                    1. 1

                      What is a server? Is that something that runs my “serverless functions” and my containers?

                      1. 2

                        no, those run in the cloud

                      2. 1

                        I don’t want to have to install X, a desktop environment, a graphical browser, and open the server up to the internet

                        to be replaced by HTML browsed from within Emacs

                        I suppose you do get that anyway…

                      3. 1

                        the problem is deciding on a standard. this proposal is particularly bad because it invites documentation writers to assume their users will have the latest firefox/chrome/ie/safari installed, which kills compatibility with older, lower power computers that still function perfectly fine but for their interaction with the modern web. that is an immediate practical concern, then there is the general principle of code simplicity, which esr seems to be flaunting his defiance of.