the upstream maintainer of mandoc.
In summary: there are quite some things in NetBSD base that could/should
be updated to more current versions. See below for the full response.
=== start of quote.
Date: Fri, 17 Apr 2015 12:34:15 +0200
From: Ingo Schwarze
Subject: Re: Request to reconsider remo
On Apr 6, 2015, at 6:05 PM, Ron Swiernik wrote:
So let me get this right, you replaced a GENERIC text formatting
tool with one
that ONLY knows how to manual pages. Now you want to move groff out
of the base
into pkgsrc leaving a tool that ONLY knows how to format
Why maintain a fork, when
The GNU approach for groff, was to treat all the
incompatibilities of the various nroff's as features
and support them -- 'A ONE RING APPROACH'.
Of course, now documents are made on GNU-LINUX systems,
and there is no reason for anyone to remember which
features of the language provided by groff,
Hi all,
Julian H. Stacey wrote:
Code vandals will make any BSD less attractive to users, who would
less complain, than silently leave, & not stay to later contribute
to the BSD community.
Those who would ignore BSDs' Unix legacy: Better play with free remit Linux.
well put.
I do agr
> (I would not complain if other obnoxious uses of C++, particularly newly
> added ones that greatly increase build time, left our tree, on the other
> hand...)
>
> Thor
Maybe NetBSD might like how FreeBSD does it:
https://svnweb.freebsd.org/base/head/Makefile.inc1?revision=280992&view=
On Apr 8, 2015, at 12:47 PM, Thor Lancelot Simon wrote:
> To me, the simplest and most elegant solution would look to be replacing
> groff with heirloom troff as the formatter for what we have that isn't
> mandoc.
Amen to that.
Pulling troff from any UNIX distribution is just digging it a shal
On Wed, Apr 08, 2015 at 01:16:06PM -0500, David Young wrote:
>
> Document preparation is important. Deleting the only or best document
> preparation system in NetBSD (supposing that is even what's going on)
> is pretty lame, but it seems to me that neither *roff nor an MS Office
> knock-off will
On Apr 8, 2015, at 13:16, David Young wrote:
>
> On Tue, Apr 07, 2015 at 11:27:02AM +, Ron Swiernik wrote:
>> Again this is an enhancement? Can mandoc handle tbl and pic input?
>>
>> UNIX has had the *roff tool suite for a long time. A text formatter is how
>> they
>> got support from manag
On Tue, Apr 07, 2015 at 11:27:02AM +, Ron Swiernik wrote:
> Again this is an enhancement? Can mandoc handle tbl and pic input?
>
> UNIX has had the *roff tool suite for a long time. A text formatter is how
> they
> got support from management to continue work on UNIX. I doubt we would be
> ta
On 4/8/15 10:41 AM, Julian H. Stacey wrote:
> A multi- decades BSD developer friend & I discussed:
> It's a liability that there's no managers on *BSD.org projects to
> control the immature & instill perspective, explaining:
Hi, Julian.
But there is such a body for NetBSD; it's the Board of Direc
Ron Swiernik wrote:
> Again this is an enhancement? Can mandoc handle tbl and pic input?
>
> UNIX has had the *roff tool suite for a long time. A text formatter is how
> they
> got support from management to continue work on UNIX. I doubt we would be
> talking about UNIX today if it wasn't for th
etbsd-users@NetBSD.org
Subject: Aw: Re: Re: Request to reconsider removal of groff from base system
Thor Lancelot Simon wrote:
> mandoc(1) does not process roff.
Very simplified described it acts somehow like "nroff -mandoc ..." or "troff
-mandoc ...".
There it understands
; netbsd-users@NetBSD.org; Gerard Lally
Subject: Re: Request to reconsider removal of groff from base system
On Mon, Apr 06, 2015 at 10:05:51PM +, Ron Swiernik wrote:
> Even Microsoft gives you Wordpad with the OS
And NetBSD base has vi and fmt...
Mar
On Tue 07 Apr 2015 at 13:57:45 +0200, carsten.ku...@arcor.de wrote:
> > Again this is an enhancement? Can mandoc handle tbl and pic input?
>
> It can handle tbl input. I'm not shure about pic but there may not be
> many manpages using pic.
Various X manual pages are mishandled in NetBSD 6. I look
> Again this is an enhancement? Can mandoc handle tbl and pic input?
It can handle tbl input. I'm not shure about pic but there may not be many
manpages using pic.
> UNIX has had the *roff tool suite for a long time. A text formatter is how
> they
> got support from management to continue work o
On Mon, Apr 06, 2015 at 10:05:51PM +, Ron Swiernik wrote:
> Even Microsoft gives you Wordpad with the OS
And NetBSD base has vi and fmt...
Martin
Kamil Rytarowski [n...@gmx.com]
Sent: Sunday, April 05, 2015 16:55
To: Kamil Rytarowski
Cc: netbsd-users@NetBSD.org; Gerard Lally
Subject: Re: Request to reconsider removal of groff from base system
Me wrote:
> If the author is familiar with groff I see the solution in changing
> the preference
Thor Lancelot Simon wrote:
> mandoc(1) does not process roff.
Very simplified described it acts somehow like "nroff -mandoc ..." or "troff
-mandoc ...".
There it understands a large subset of the nroff/troff language.
(Only a few useres need real nroff/troff for typesetting other documents than
On Sun, Apr 05, 2015 at 11:59:50AM +0200, carsten.ku...@arcor.de wrote:
>
> Nevertheless also heirloom troff is better suited as a package and
> not as part of the base system. mandoc(1) is IMHO the suited roff
> tool for the base today.
mandoc(1) does not process roff.
Thor
Me wrote:
> If the author is familiar with groff I see the solution in changing
> the preferences, but add in providing textproc/groff-minimal to
> pkgsrc. Probably with a man page in the NetBSD base with description
> what happened to groff, and how to get it back.
>
Excuse me for typo. The right
"Greg A. Woods" wrote:
> The real original Troff in its modern UTF-8 using form would probably be
> a much better alternative (and it's probably smaller too):
>
>http://heirloom.sourceforge.net/doctools.html
This is a abandoned 32 bit only version which has many unfixed bugs.
The mainta
Greg A. Woods wrote:
> At Tue, 31 Mar 2015 12:24:51 +0100, Gerard Lally
> wrote:
> Subject: Request to reconsider removal of groff from base system
> >
> > As someone who uses groff as a lightweight alternative to TeX and
> > friends**
>
> I would argue that groff is far from lightweight, even
At Tue, 31 Mar 2015 12:24:51 +0100, Gerard Lally
wrote:
Subject: Request to reconsider removal of groff from base system
>
> As someone who uses groff as a lightweight alternative to TeX and
> friends**
I would argue that groff is far from lightweight, even within the
confines of Troff-like sys
On Tue, Mar 31, 2015 at 12:24:51PM +0100, Gerard Lally wrote:
>
> As someone who uses groff as a lightweight alternative to TeX and
> friends**
FWIW, I have developed a minimal TeX system: kerTeX
(http://www.kergis.com/kertex.html) (french; english at
http://www.kergis.com/en/kertex.html).
A min
At date and time Tue, 31 Mar 2015 15:18:36 +0200, tlaronde wrote:
> On Tue, Mar 31, 2015 at 12:24:51PM +0100, Gerard Lally wrote:
> >
> > As someone who uses groff as a lightweight alternative to TeX and
> > friends**
>
> FWIW, I have developed a minimal TeX system: kerTeX
> (http://www.kergis.com
Eric Haszlakiewicz writes:
> How much space do you expect it to actually actually take up? If all
> you want is groff, dont't install pkgsrc itself, just pkg_add the
> groff package!
It pulls in a lot now, by inspection of the package, including
ghostscript.
pgpUX0WXb6s2K.pgp
Description: PG
On March 31, 2015 7:24:51 AM EDT, Gerard Lally
wrote:
>While reading the INSTALL notes for amd64 today, I learned that
>groff(1)
>is to be phased out in a future release, since man pages are handled
>with mandoc(1), and groff(1) can still be found in pkgsrc as
>textproc/groff.
>
>As someone who
Gerard Lally writes:
> While reading the INSTALL notes for amd64 today, I learned that groff(1)
> is to be phased out in a future release, since man pages are handled
> with mandoc(1), and groff(1) can still be found in pkgsrc as textproc/groff.
>
> As someone who uses groff as a lightweight alt
28 matches
Mail list logo
