Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tell HN: Groff needs your help

news.ycombinator.com

Post reply on HN
Print view View original

51–60 of 67 posts

Re: Tell HN: Groff needs your help

#51

Post by pflanze »

lucb1e wrote: post #9

I'm going to be frank: why? I've recently looked into making my own manpage and it's a pretty old looking system. The docs are not really clear but using some examples and trial and error I got there. My point is though, why does it need a maintainer? The system feels old enough to get deprecated instead of keeping it alive, let alone bring out new releases. I haven't spent more than a day working with groff though,…

Perhaps you'll be interested in this discussion of markup format and tool chain alternatives to GNU info (in the context of Emacs):

http://lwn.net/Articles/625072/

(It got no interest on HN: https://news.ycombinator.com/item?id=8911625)

Re: Tell HN: Groff needs your help

#52

Post by lucb1e »

rhizome31 wrote: post #35
zokier wrote: post #24

I think the obsession with "being maintained" is somewhat unhealthy phenomenon in the FOSS world. If the code works and does what you want then why would it need constant fiddling and consistent stream of releases?

The code may need to be adapted to evolving environments. Security bugs might be discovered. In this case I guess "being maintained" just means that someone will react to such events if they happen.

Couldn't programmers from major GNU/Linux distributions be signed up for this duty? They compile new OSes and if they want man pages (heck, who doesn't want man pages?) then it's also up to them to make it work in the new OS. Security bugs can be forwarded to those people by Gnu (assuming they support and host the project).

This may not work for everything, they're not going to maintain any old system, but things that we want to keep around but for which there are not necessarily dedicated maintainers to keep it up...

Re: Tell HN: Groff needs your help

#53

Post by cogburnd02 »

rakoo wrote: post #48
mseepgood wrote: post #39

Earlier quoted context omitted.

These are manpages http://imgur.com/a/JZfTr

While I like the venerable look they have, those books aren't what you use daily to document yourself on how your machine works. I was speaking about those manpages we use when we don't know what the letters are for in the itemized output of rsync, for instance.

> While I like the venerable look they have, those books aren't what you use daily to document yourself on how your machine works.

But you can create pretty hard-copy versions of the manpages on your system with groff, the same way these books were created with troff (which groff is a replacement for.)

Re: Tell HN: Groff needs your help

#54

Post by takluyver »

101914 wrote: post #30
zokier wrote: post #24

I think the obsession with "being maintained" is somewhat unhealthy phenomenon in the FOSS world. If the code works and does what you want then why would it need constant fiddling and consistent stream of releases?

I would go further and call this an obsession with using software that is literally changing by the day, in a constant state of flux. There seems a desire among those users who comment in forums to see recent commits to the software they use as if infrequent commits or no commits in years suggests there is something wrong with the software. To me, it is the constant changes and updates that give me pause when choosin…

> as if infrequent commits or no commits in years suggests there is something wrong with the software.

I would be reluctant to start using a package that wasn't actively developed. Libraries, APIs and even languages evolve, and I don't want to be stuck relying on old versions of other things because of one package that isn't being updated. You might say that all the other pieces should take version compatibility much more seriously, to avoid this problem, but that's not the world we're in.

More importantly, since all non trivial software has bugs, if there have been no commits for years, either no-one's using it and finding the bugs, or the maintainer isn't merging people's patches. Both options sound bad for me as a user.

I understand that a program could theoretically be 'done', not requiring any further changes, but I think there's hardly any software that could conceivably be so 'done' it wouldn't have any commits in months or years. I've just looked up a few of the most stable major projects I can think of: the Linux kernel, Apache and Subversion all have multiple commits within the last day. GNU coreutils only has five in the last week.

Re: Tell HN: Groff needs your help

#55

Post by cogburnd02 »

lucb1e wrote: post #47
anjbe wrote: post #41

Earlier quoted context omitted.

> What I meant is writing new pages in a newer language (insert random lightweight text based format, preferably one where the 'see also' part is linkable) A little bit of manpage history: Roff has been around since the beginning of Unix (in fact, the group at Bell Labs who developed Unix got funding by convincing managers they could come up with a good typesetting system). Roff supports a variety of macro sets; for…

Okay, I didn't know all that. Perhaps groff is a better language than I was aware of and there is sure something to say for keeping it available. But is it really all used? I have never heard of searching man pages by e.g. return type (in section 2 or 3 I assume this would be), nor does hyperlinking work (perhaps due to the pager, but still). If only 1% of the people use it, then either it's up to them to maintain it…

> I have never heard of searching man pages by e.g. return type (in section 2 or 3 I assume this would be).

I'm not sure what you mean by return type, but if you want to, I think you can section your manpages however you want; i.e. you can have section 1 be 'games' instead of 6 if you want to, it just makes installing manpages more difficult.

Re: Tell HN: Groff needs your help

#56

Post by kazinator »

cogburnd02 wrote: post #45
kazinator wrote: post #44

I am the maintainer of a man page that turns into a 260+ page PDF document in letter size. I haven't hacked on groff, but I recently I did a whole bunch of work on the man2html program from the man tools. That code is extremely hacky, like you wouldn't believe! http://www.kylheku.com/cgit/man/ I have it so that a man page can detect whether it's being compiled by groff or by man2html and re-target some of its macros.…

Keep in mind, groff can itself generate HTML. I think it may need some pre- and post-processing to do it, though too, because (I think) what are links in the HTML version end up being footnotes in the pdf/ps version. Could be wrong about that, though.

The HTML from groff's HTML back-end is pretty much useless garbage.

Re: Tell HN: Groff needs your help

#57

Post by cogburnd02 »

microtonal wrote: post #7
DanBC wrote: post #4

The Groff Mission Statement looks interesting. http://www.gnu.org/software/groff/groff-mission-statement.ht...

The question is - do we really need the typesetting part? I had a troff phase (bought some books) ten years ago. But the community of users is small, its capabilities are eclipsed by TeX, and the language is quite arcane. One could even go a step further and argue that writing man pages would be much easier (and presumably more man pages would be written) if the markup language was switched to e.g. Markdown by defaul…

> do we really need the typesetting part?

I think so; producing high-quality printed manpages is useful, at least to me.

> the community of users is small

So tell your friends to use groff! :-D

> its capabilities are eclipsed by TeX

In what way? Yes, TeX can do complex mathematics better, but most documents that people want to publish don't terribly need complex math that much.

> and the language is quite arcane.

What specifically is 'arcane' about it, versus something like TeX or markdown?

> One could...argue that writing man pages would be much easier...if the markup language was switched to e.g. Markdown by default.

But then someone would have to rewrite the existing corpus of manpages, and as others have pointed out, using markdown loses some semantics.

I think keeping that functionality in pandoc is the right way to go.

Re: Tell HN: Groff needs your help

#58

Post by kazinator »

rhizome31 wrote: post #35
zokier wrote: post #24

I think the obsession with "being maintained" is somewhat unhealthy phenomenon in the FOSS world. If the code works and does what you want then why would it need constant fiddling and consistent stream of releases?

The code may need to be adapted to evolving environments. Security bugs might be discovered. In this case I guess "being maintained" just means that someone will react to such events if they happen.

You can write a Groff-like text processor to the 1990 POSIX environment and it will work in a 2015 environment just fine.

Re: Tell HN: Groff needs your help

#59

Post by cogburnd02 »

anjbe wrote: post #42
thristian wrote: post #33

Earlier quoted context omitted.

Really? What are these better versions?

There are a couple of other troff implementations in use today. Mandoc is very new and focuses on providing a complete solution for a system that uses manpages: it renders manpages in the terminal or to HTML on the fly, provides a database for semantic search of manuals, and is probably the second most common manpage renderer in common use (after Groff). It’s the default renderer on OpenBSD, FreeBSD, DragonFly BSD, N…

I've looked at the kind of PDFs heirloom troff can make, on an iPad, and my eyes, just, wow. There aren't words. If Debian would put heirloom troff in its base-install (along with, say, E.B Garamond or Junicode) instead of groff, there'd probably be more people (1) making beautiful man pages, and (2) viewing man pages graphically (with evince or another PDF viewer) than ever before. It's not like there's a licensing problem, AFAICT.

I have not seen a PDF made by mandoc that made me react that way. :-|

Re: Tell HN: Groff needs your help

#60

Post by cogburnd02 »

kazinator wrote: post #56
cogburnd02 wrote: post #45

Earlier quoted context omitted.

Keep in mind, groff can itself generate HTML. I think it may need some pre- and post-processing to do it, though too, because (I think) what are links in the HTML version end up being footnotes in the pdf/ps version. Could be wrong about that, though.

The HTML from groff's HTML back-end is pretty much useless garbage.

Well, get into that code, and improve it! :-)
Post reply on HN