Re: [groff] [Groff] It is time to modernise "groff"

On Wed, Feb 21, 2018 at 03:03:48PM -0500, Dave Kemper wrote: > Subject: Re: [groff] [Groff] It is time to modernise "groff" > > On 9/4/17, G. Branden Robinson wrote: > > At 2017-08-31T20:54:10+, Bjarni Ingi Gislason wrote: > >> p) Remove the '-a' option (the ASCII approximation output). > >

Re: [groff] [Groff] Next release - maintainership

Catching up with some old groff-list email: On 9/16/17, Bertrand Garrigues wrote: > I can take in charge part of the job of the maintainer: the build > system, making release; I've also studied src/roff/troff source code and > I'm planning to propose changes in `troff' to support Knuth-Plass > p

Re: [groff] [Groff] It is time to modernise "groff"

More catching up... On 9/4/17, G. Branden Robinson wrote: > At 2017-08-31T20:54:10+, Bjarni Ingi Gislason wrote: >> p) Remove the '-a' option (the ASCII approximation output). > > I didn't even know this existed. Looking at what it spits out, I find > myself wondering what good it is. As o

Re: [groff] [Groff] Next release - maintainership

Hi, Dave Kemper wrote on Wed, Feb 21, 2018 at 02:26:15PM -0500: > Does it make any sense to split groff into two packages: one that is > just the base groff system, and one that is just the macro sets? I don't think it makes much sense. You can hardly use *roff without macros (well, there are r

[groff] Macros in their own package ...

I'll vote for having the macros in their own packages. The possibility of having macro packages which were compatible with more than one *roff is appealing. Having the Z macro set where the differences between the Aroff and Broff versions were clearly documented would be useful. To have a Z macr

Re: [groff] Release Candidate 1.22.3.rc1

On Sat, Feb 17 2018 at 03:43:53 PM, Colin Watson wrote: > On Sat, Feb 17, 2018 at 12:40:57PM +, Ralph Corderoy wrote: >> Hi Bertrand, >> >> > git clone https://git.savannah.gnu.org/git/groff.git >> > cd groff >> > git checkout 1.22.3.rc1 >> > ./bootstrap >> >> ./bootstrap fails here.

Re: [groff] Release Candidate 1.22.3.rc1

Hi Ralph, On Sat, Feb 17 2018 at 01:05:38 PM, Ralph Corderoy wrote: > Various compilation warnings result, that you probably know about. > > Output includes > > common.roff: elapsed time: 0 seconds > common.roff: elapsed time: 0 seconds > troff: ../doc/automake.mom:54: can't transpar

Re: [groff] [Groff] Next release - maintainership

Thanks, Ingo. You make some good points. A few responses inlined below. On 2/21/18, Ingo Schwarze wrote: > Dave Kemper wrote on Wed, Feb 21, 2018 at 02:26:15PM -0500: > >> Does it make any sense to split groff into two packages: one that is >> just the base groff system, and one that is just t

[groff] Macro in separate packages

(changing the subject) Hi Dave, On Wed, Feb 21 2018 at 06:18:40 PM, Dave Kemper wrote: > On 2/21/18, Ingo Schwarze wrote: >> Sure, maintaining macro sets is an easier task than maintaining the >> complicated automake / autoconf / C++ beast as a whole. But i don't >> see how splitting out *easie

Re: [groff] Macros in their own package ...

Apropos of compatibility outside `groff`... Does anybody know of an exhaustive list of *roff implementations still in common use? (Including legacy repositories of historical interest) The current Roff interpreters I'm aware of are: 1. *GNU Troff * (~1989/

[groff] Comments about the bug report #42675 (long)

Title: \} considered as macro argument regarding register .$ The reported bug (#42675) is a panic one. (Later I checked the whole earlier "discussion" on the "groff" list. The whole shows me such a lack of thinking; it is just reacting and "don't think about it, neither before and especiall

Re: [groff] Release Candidate 1.22.3.rc1

On Wed, Feb 21, 2018, Bertrand Garrigues wrote: > > troff: ../contrib/mom/examples/mon_premier_doc.mom:134: can't > > translate character code 168 to special character 'ad' in transparent > > throughput > > troff: ../contrib/mom/examples/typesetting.mom:130: warning: can't find > > special

Re: [groff] Macro in separate packages

On Thu, Feb 22, 2018, Bertrand Garrigues wrote: > The other thing is that you probably want to have official release of > macro packages independantly from releases of the core system. If there > is real need for that then we could make some stable branches and > intermediate releases, following t