> Von: ted.hard...@wlandres.net
>
> My own feelings about this sort of question is that grog is a
> facility which can have its uses, but is not one which I would
> recommend for general use. The reason is that it sets up a
> command line which is formed in terms of requests that grog
> detects in
On 27-May-2014 15:37:35 Werner LEMBERG wrote:
>
>> Why not allowing (not forcing) this additional first line also for
>> every other files written in some `groff' language document?
>
> You rather mean: Why not make groff accept such a line to invoke
> preprocessors?
>
> I think that this approa
> Why not allowing (not forcing) this additional first line also for
> every other files written in some `groff' language document?
You rather mean: Why not make groff accept such a line to invoke
preprocessors?
I think that this approach is too simplistic; for example, it doesn't
allow for prep
> Von: "Werner LEMBERG"
>
> > Now grog accepts not only the 4 characters, but all 8 from groff's
> > options. That will not hurt anything.
>
> Well, yes, but currently only `man' interprets this comment, and `man'
> exclusively wants a leading ' and nothing else...
>
> > How about handling thi
>> I suggest that grog accepts
>>
>> .\" t
>>
>> under protest only, this is, it emits a warning that the line should
>> be changed to
>>
>> '\" t
>
> The protest of grog will come later.
Thanks.
> Now grog accepts not only the 4 characters, but all 8 from groff's
> options. That will not h
> Von: "Werner LEMBERG"
> Betreff: Re: [Groff] `groff_char.7' works only for `man', but not for `groff'
>
> >> I changed grog, such that lines starting with . (period) or '
> >> (apostrophe) are both regarded as equal (only within `grog&#x
>>> However, the source file for groff_char.7 (.../man/groff_char.man)
>>> has:
>>> .\" t
Thanks, this is fixed now.
>> I changed grog, such that lines starting with . (period) or '
>> (apostrophe) are both regarded as equal (only within `grog').
>
> Why? I guess users are more l
I agree with Keith.
I was responsible for HP's man pages for five years. The '\"
convention is very well established and should be maintained for
full compatibility. Adding new "features in this manner does
nothing but add contamination and confusion to the noise.
If grog doesn't follow the '\
On 26/05/14 23:19, Bernd Warken wrote:
> The usage of '\" for the first line could be done within a short time.
> But `grog' uses both methods '\" and .\".
>
> It seems to be good to use logical stuff and leave space for
> other stuff as well, as `grog' does now.
>
> Better don't ask were the man
> Von: "Keith Marshall"
>
> > I changed grog, such that lines starting with . (period) or '
> > (apostrophe) are both regarded as equal (only within `grog').
>
> Why? I guess users are more likely rely on man(1), rather than on grog,
> for reading man pages. The convention is dictated by man,
> Von: "Keith Marshall"
>
> > I changed grog, such that lines starting with . (period) or '
> > (apostrophe) are both regarded as equal (only within `grog').
>
> Why? I guess users are more likely rely on man(1), rather than on grog,
> for reading man pages. The convention is dictated by man,
On 26/05/14 20:37, Bernd Warken wrote:
>> Von: "Dale Snell"
>>
>> You might look at the source for the groff_char.7 man page.
>> According to groff_man(7)
>>
>>If a preprocessor like tbl or eqn is needed, it has become
>>common to make the first line of the man page look like this:
>>
>>
> Von: "Dale Snell"
>
> You might look at the source for the groff_char.7 man page.
> According to groff_man(7)
>
>If a preprocessor like tbl or eqn is needed, it has become
>common to make the first line of the man page look like this:
>
> '\" word
This "word" is a col
On Mon, 26 May 2014 16:43:30 +0200
"Bernd Warken" wrote:
>
>
> > Von: "Werner LEMBERG"
> >
> > Please be more specific. Using current git on my GNU/Linux box, the
> > call
> >
> > groff -Tutf8 -t -man groff_char.n | less
> >
> > displays just fine.
>
> You are right. I just forgot to in
> Von: "Werner LEMBERG"
>
> Please be more specific. Using current git on my GNU/Linux box, the
> call
>
> groff -Tutf8 -t -man groff_char.n | less
>
> displays just fine.
You are right. I just forgot to include `-t'. So something must be done
in `grog'.
Thanks
Bernd Warken
> It's curious, but groff_char.7 works correctly under `man', but its
> tables become very strange under all kinds of `groff -T'. This
> includes the actual git version with tables `l l l l l lx', but also
> an earlier version with older form of tables without x.
Please be more specific. Using
It's curious, but groff_char.7 works correctly under `man', but
its tables become very strange under all kinds of `groff -T'.
This includes the actual git version with tables `l l l l l lx',
but also an earlier version with older form of tables without x.
Bernd Warken
17 matches
Mail list logo
