4:19 p.m.
Hello,
I should have released these patches a few time ago, but Alioth had troubles.
Sorry if this mail is a little bit long.
Some are still not "ready for production", and are provided to inform you
I'm working on those subjects (and also to grab some ideas).
I also had to work on the testsuite (the check script) and added a
stats.sh scripts for regression tests. Here are how this last script
formats regression tests statistics:
$ ./stats.sh orig work
IGN OK OK2 WOK1 WOK2 WOK3 PBS WDIFF
IGN 1698 0 0 0 0 0 0 0
OK 0 125 0 0 0 0 0 0
OK2 0 0 1564 4 2 0 0 0
WOK1 0 8 0 89 0 1 0 0
WOK2 0 0 0 0 208 0 0 1
WOK3 0 2 11 2 4 301 3 0
PBS 0 35 150 15 48 43 585 14
WDIFF 0 1 9 4 5 8 0 39
total: 4979 | 4979
(It takes two directories in argument, the two directories containing
results of the check script, i.e. the LISTE files. It creates a stats_work
directory.)
You can read this table like this:
11 man pages which were in the WOK3 category in orig are now in OK2.
Those pages can be found in stats_work/WOK3_OK2
The different categories are:
IGN man pages po4a refused to operate on (e.g. wad generated by
Pod::Man)
OK diff -uBb didn't see any difference
This can contain very rare misformatting
OK2 diff -uBb didn't see any difference after converting hyphens to
minus sign, `` to ", and '' to " in both man pages
This contains a little bit more misformatting, for example an man
page referring to an empty argument ('') should not display only ".
WOK1 wdiff doesn't see any difference after the same modifications
WOK2 This tries to detect changes in the hyphenation of words (but has
more false negative)
WOK3 This removes minus signs, and thus detects more changes in
hyphenation
PBS po4a preferred to stop processing the man page (non supported
macro, ...)
WDIFF These are probably bugs in po4a or in the man page (I started
reporting some of them in the BTS, which is another way of
improving po4a statistics)
In the table above, it is usually an improvement to have big numbers on
the bottom left corner (with the exception of the IGN column).
Here are the patches for the Man module:
+ comments
It recognize some (probably incorrect, but usual) comment lines.
Here are the results of the regression tests for this patch:
IGN OK OK2 WOK1 WOK2 WOK3 PBS WDIFF
IGN 1698 0 0 0 0 0 0 0
OK 0 125 0 0 0 0 0 0
OK2 0 0 1570 0 0 0 0 0
WOK1 0 0 0 98 0 0 0 0
WOK2 0 0 0 0 209 0 0 0
WOK3 0 0 0 0 0 323 0 0
PBS 0 0 3 0 1 1 885 0
WDIFF 0 0 1 1 0 1 0 63
+ nested_fonts
It deals with the nested font issue.
I have an idea on how to simplify it a lot, but I think it could be
applied, because it is doing a good job.
The only remaining issue is with "un-terminated" fonts, as in:
Hello, my name is \fINicolas \fBFRANÇOIS
IMHO, in groff, there is no nested font (with some exceptions, like
SB, and some italic and bold faces, or by using exotic tmac).
\fIfoo\fBbar\fR is equivalent to \fIfoo\fR\fBbar\fR (with the
exception of the \fP).
Here are the results of the regression tests for this patch:
IGN OK OK2 WOK1 WOK2 WOK3 PBS WDIFF
IGN 1698 0 0 0 0 0 0 0
OK 0 125 0 0 0 0 0 0
OK2 0 0 1562 0 0 0 8 0
WOK1 0 0 0 98 0 0 0 0
WOK2 0 0 0 0 209 0 0 0
WOK3 0 1 6 2 1 307 6 0
PBS 0 1 81 5 27 31 738 7
WDIFF 0 0 0 0 0 0 0 66
+ arg_next_line
It allows arguments to be provided on the next line for some macros
(.SH, .I, ..., .BR, ...)
It works fine, but would require some cleanup (lots of redundant
code).
It can be applied cleanly on CVS, but require the 'nested_fonts' patch
to operate cleanly.
Here are the results of the regression tests for this patch (with the
previous patch also applied):
IGN OK OK2 WOK1 WOK2 WOK3 PBS WDIFF
IGN 1698 0 0 0 0 0 0 0
OK 0 125 0 0 0 0 0 0
OK2 0 0 1567 1 0 0 0 2
WOK1 0 0 0 97 0 1 0 0
WOK2 0 0 0 0 209 0 0 0
WOK3 0 2 11 2 4 301 3 0
PBS 0 1 109 9 34 32 692 13
WDIFF 0 0 0 0 0 0 0 66
(here most of the new 'WDIFF' man pages are bug in the man page, and a
bug was filed in the BTS)
+ dot_lines
po4a generated some lines starting with a dot. In those cases, a \&
should be added to allow the line to be displayed. (for exemple:
.I ../file
is displayed in groff, but
\fI../fil/\fR won't be displayed
It also fix the same issue for lines starting by a "'"
IGN OK OK2 WOK1 WOK2 WOK3 PBS WDIFF
IGN 1698 0 0 0 0 0 0 0
OK 0 125 0 0 0 0 0 0
OK2 0 0 1570 0 0 0 0 0
WOK1 0 8 0 90 0 0 0 0
WOK2 0 0 0 0 209 0 0 0
WOK3 0 0 0 0 0 323 0 0
PBS 0 0 0 0 0 0 890 0
WDIFF 0 1 5 0 0 0 0 60
+ hyphen
I had a obligation to fix this because I said Martin that replacing
hyphens by minus signs were always allowed.
In fact, it should not be modified in
- .so/.mso arguments
- after a \s (font size modifier, e.g. \s-2)
I also added a comment on why I *hate* hyphens.
Here are the results of the regression tests for this patch:
IGN OK OK2 WOK1 WOK2 WOK3 PBS WDIFF
IGN 1698 0 0 0 0 0 0 0
OK 0 125 0 0 0 0 0 0
OK2 0 0 1570 0 0 0 0 0
WOK1 0 0 0 98 0 0 0 0
WOK2 0 0 0 0 209 0 0 0
WOK3 0 0 0 0 0 323 0 0
PBS 0 0 0 0 0 0 890 0
WDIFF 0 0 2 1 3 5 0 55
+ new_macros
Some new macros:
.R
.EX and .EE
.so and .mso
.cs
minimal support (when no argument is given) for:
.ce
.ul
.cu
Here are the results of the regression tests for this patch:
IGN OK OK2 WOK1 WOK2 WOK3 PBS WDIFF
IGN 1698 0 0 0 0 0 0 0
OK 0 125 0 0 0 0 0 0
OK2 0 0 1570 0 0 0 0 0
WOK1 0 0 0 98 0 0 0 0
WOK2 0 0 0 0 209 0 0 0
WOK3 0 0 0 0 0 323 0 0
PBS 0 27 11 0 0 1 843 8
WDIFF 0 0 0 0 0 0 0 66
+ escape
It tries to deal with the \c escape.
It still need some work.
+ others
some other minor points that I could isolate from my working directory
+ split_args
This fix an issue for the limits.conf man page.
It was also reported in #268904
It adds one string for the translation.
+ all
all the above patch, and more.
It also contains some comments that should be removed.
The results are presented in the first table.
Comments (and commits;) are welcome.
Thanks for those who read this mail to the end,
--
Nekral
6:28 p.m.
Sorry for the delay.
On Wed, Sep 22, 2004 at 11:19:30PM +0200, Nicolas François wrote:
Hello,
I should have released these patches a few time ago, but Alioth had troubles.
Yeah, you really should. Now, you'll have to create an account on alioth so
that we can give you the cvs write access, so that you can commit them
yourself...
Sorry if this mail is a little bit long.
You must be kidding... Thanks for your work on po4a. And my answer is even
longer :)
Some are still not "ready for production", and are provided
to inform you
I'm working on those subjects (and also to grab some ideas).
ok, here we go.
formats regression tests statistics:
$ ./stats.sh orig work
IGN OK OK2 WOK1 WOK2 WOK3 PBS WDIFF
IGN 1698 0 0 0 0 0 0 0
OK 0 125 0 0 0 0 0 0
OK2 0 0 1564 4 2 0 0 0
WOK1 0 8 0 89 0 1 0 0
WOK2 0 0 0 0 208 0 0 1
WOK3 0 2 11 2 4 301 3 0
PBS 0 35 150 15 48 43 585 14
WDIFF 0 1 9 4 5 8 0 39
total: 4979 | 4979
Please add "was \ is" (or the contrary ;) in the upper left cell of the tab
to help my understanding.
The different categories are:
IGN man pages po4a refused to operate on (e.g. wad generated by
Pod::Man)
OK diff -uBb didn't see any difference
This can contain very rare misformatting
OK2 diff -uBb didn't see any difference after converting hyphens to
minus sign, `` to ", and '' to " in both man pages
This contains a little bit more misformatting, for example an man
page referring to an empty argument ('') should not display only ".
WOK1 wdiff doesn't see any difference after the same modifications
WOK2 This tries to detect changes in the hyphenation of words (but has
more false negative)
WOK3 This removes minus signs, and thus detects more changes in
hyphenation
PBS po4a preferred to stop processing the man page (non supported
macro, ...)
WDIFF These are probably bugs in po4a or in the man page (I started
reporting some of them in the BTS, which is another way of
improving po4a statistics)
In the table above, it is usually an improvement to have big numbers on
the bottom left corner (with the exception of the IGN column).
Please put this as comment in the script (at least, if not by default under
the table).
Where is the WOK category (diff sees a difference, but not wdiff even before
edition) ?
Here are the patches for the Man module:
+ comments
It recognize some (probably incorrect, but usual) comment lines.
Here are the results of the regression tests for this patch:
Question: the info groff part you cite in comment seems to imply that
.B toto \" a comment
is a valid construct, but this is not handled by the code. You should at
least add a comment stating so, shouldn't you?
That being said, if this feature is not used by the existing pages, don't
bother implementing (=> let's commit).
+ nested_fonts
It deals with the nested font issue.
I have an idea on how to simplify it a lot, but I think it could be
applied, because it is doing a good job.
The only remaining issue is with "un-terminated" fonts, as in:
Hello, my name is \fINicolas \fBFRANÇOIS
IMHO, in groff, there is no nested font (with some exceptions, like
SB, and some italic and bold faces, or by using exotic tmac).
\fIfoo\fBbar\fR is equivalent to \fIfoo\fR\fBbar\fR (with the
exception of the \fP).
Mmm. That's a very tought problem. As you saw in the code, I already tried
to tackle it, in vain so far. I must admit that the regression result you
show are rather impressive.
But I do not like this patch anyway, for several reasons:
- no print "NEKRAL: bla" should remain. Change them to debugging statements
or regular (translated) warnings, or whatever. Add a new debugging
category if needed. Same for "# print STDERR bla".
- you are kind of cheating by not die()ing when you said in the comments
that you should... It removes a lot of PBS :)
If the pages are ok afterward, then remove the fixme asking to die. If
not, die. Undetected errors are worse for the user than unprocessed
pages. He can always change the structure of the page to make po4a happy.
- you say that a proper implementation of \fP needs to keep track of the
font used at the end of the last paragraph. Are we in bold after
\fB\fI\fB\fP\fP ? (in which case, we need to keep track of the whole
stack)
- this is really complex, I'm concerned about maintaining the beast when
you leave. Ie, you shouldn't have said you have a simpler solution in
mind, now I want to see it ;)
- there is one stylistic rule I like in Perl: if you use a given variable
only once, remove it, you don't need it. @tmp_array1 falls in that
category. Likewise, I'd prefer to write (! $old eq "") as ($old ne
"")
[please don't get offended by those stylistic remarks, this code is
incredibly hairly, I'd like to keep it under control]
- I'm not sure I understand the "two concecutive \fR are not needed" part
What about the following:
while ($str =~ /^(.*)\\fR # Get the beginning, until a \fR
# Now, get the middle
((?: # [this parenthesis clusters, don't capture]
[^\\] # the middle is either not '\'
| # or
\\(?!f) # '\', but not followed by 'f' (look ahead)
)*)
\\fR # end sentinel
(.*)$/sx) {# use x modifier to add documentation and space
$str = "$1\\fR$2$3";
}
Ok, I admit, this is not tested at all, and I just discovered the
"negative look ahead" black magic in man perlre, I may well be wrong.
I'm
sure you'll correct me if it's the case, since you use this magic
elsewhere.
We should use the x modifier more often to document the REs.
All that to say that I'd prefer to keep this one out of the CVS for now.
+ arg_next_line
It allows arguments to be provided on the next line for some macros
(.SH, .I, ..., .BR, ...)
It works fine, but would require some cleanup (lots of redundant
code).
Erm. You'll say I'm picky, but I'd prefer you to do this cleanup before
commit :)
It can be applied cleanly on CVS, but require the
'nested_fonts' patch
to operate cleanly.
Well, you really should send us more mails to avoid having to deal with
interdepending patches. Those beast are sooo nasty to deal with, I'm really
sorry for you.
(here most of the new 'WDIFF' man pages are bug in the
man page, and a
bug was filed in the BTS)
Hey, cool.
+ dot_lines
po4a generated some lines starting with a dot. In those cases, a \&
should be added to allow the line to be displayed. (for exemple:
.I ../file
is displayed in groff, but
\fI../fil/\fR won't be displayed
It also fix the same issue for lines starting by a "'"
Arg, I'm so bad! I thought I got this one years ago. Thanks for chasing it.
Why don't you change it in paragraphs after the wrap? You'd get 'em all, and
the code for that would be in only one location.
For example, you may want to merge your change to the
$str =~ s/\n([.'"])/ $1/mg; #'
just before. What about:
$str =~ s/^ # at the begin of line
(?:\\f.)? # possibly followed by a font modifier
([.'"]) # avoid '.' and '''
/\\&$1$2 # add \& in front to fix it
/mgx;
Same story, not tested at all.
+ hyphen
I had a obligation to fix this because I said Martin that replacing
hyphens by minus signs were always allowed.
In fact, it should not be modified in
- .so/.mso arguments
- after a \s (font size modifier, e.g. \s-2)
I also added a comment on why I *hate* hyphens.
I like this one ;)
Change all items to an itemize in the comment, and, if you don't mind,
remove your name. That's just a suggestion. No need to overload the code
with who hate hyphen the most. I do to. But, by the way, add your name to
the authors of this module, and of po4a.
Please document the RE. I'm sure I'll forget that ?<! means negative look
behind until I'll need to read it ;)
s/they most of the time break/they break most of the time/
+ new_macros
Some new macros:
.R
.EX and .EE
.so and .mso
.cs
minimal support (when no argument is given) for:
.ce
.ul
.cu
This one is not in the tarbal. :-/
+ escape
It tries to deal with the \c escape.
It still need some work.
Kill the die I did put if it's not needed anymore.
You could override the pushline function, if you understand Perl objects. I
don't.
What is the effect of \c, again?
+ others
some other minor points that I could isolate from my working directory
What is the change for cdrdao ? It deals with non escaped leading spaces, am
I right? Does it still deal with not leading spaces? I don't think so. you
may want to kill those ^
Ok for the SH macro.
For the space at the begining of paragraph, shouldn't it be handled along
with ' or . at the beginning of line?
+ split_args
This fix an issue for the limits.conf man page.
It was also reported in #268904
It adds one string for the translation.
Ok, I tried to understand your bug report three times, in vain. It's not now
at 1 am that I will understand the patch. I belive you on this one.
+ all
all the above patch, and more.
It also contains some comments that should be removed.
The results are presented in the first table.
Nope, forget about this one ;)
Comments (and commits;) are welcome.
I will commit some of them (I'm now offline), but I'd really prefer you to
get the write access. It would help you concentrating on the bugs instead of
playing with interdependent patches.
Did you use quilt, at least? ;)
Thanks for those who read this mail to the end,
Many many thanks to you.
Mt.
PS: I forgot whether you're on the list, thus the cc.
11:03 a.m.
On Fri, Sep 24, 2004 at 01:28:23AM +0200, Martin Quinson wrote:
On Wed, Sep 22, 2004 at 11:19:30PM +0200, Nicolas François wrote:
> I should have released these patches a few time ago, but Alioth had troubles.
Yeah, you really should. Now, you'll have to create an account on alioth so
that we can give you the cvs write access, so that you can commit them
yourself...
Alioth is up and running again. Here is my account: nekral-guest.
> formats regression tests statistics:
> $ ./stats.sh orig work
> IGN OK OK2 WOK1 WOK2 WOK3 PBS WDIFF
[...]
> IGN 1698 0 0 0 0 0 0 0
Please add "was \ is" (or the contrary ;) in the upper left cell of the tab
to help my understanding.
Done. (In fact dir1\dir2)
> The different categories are:
> IGN man pages po4a refused to operate on (e.g. wad generated by
> Pod::Man)
[...]
> WDIFF These are probably bugs in po4a or in the man page (I
started
> reporting some of them in the BTS, which is another way of
> improving po4a statistics)
>
> In the table above, it is usually an improvement to have big numbers on
> the bottom left corner (with the exception of the IGN column).
Please put this as comment in the script (at least, if not by default under
the table).
Done. I added a Usage for both scripts.
The categories are documented in check, because stats.sh could be used
with any other regression test tool.
Where is the WOK category (diff sees a difference, but not wdiff even
before
edition) ?
I tried not to have too much categories, because they increase the
execution time.
I propose to add more categories latter, when there will be less WDIFF.
At this time, I'm not sure I'm reading WOK1 and WOK2 as very different.
> Here are the patches for the Man module:
>
> + comments
> It recognize some (probably incorrect, but usual) comment lines.
> Here are the results of the regression tests for this patch:
Question: the info groff part you cite in comment seems to imply that
.B toto \" a comment
is a valid construct, but this is not handled by the code. You should at
least add a comment stating so, shouldn't you?
Yes, it is valid. (At least it is recognized as such by my groff).
My problem was: Ok, I recognized a comment inside a paragraph, what
should I do with this comment ?
Can I show it in the po (and how?)? Is there any interest in doing this?
Can I just trash the comments?
That being said, if this feature is not used by the existing pages,
don't
bother implementing (=> let's commit).
At this time, '.B toto \" a comment' will generate
'\fBtoto \" a comment\fR', which is buggy because the Bold font is
not terminated and \" may mask the end of the paragraph.
It is largely used for commenting .de, .if,... (but those macros are not
supported (and will probably never be).
I've tried a grep on my pages, but there was to much noise. However The
issue should have raise in the regression test, so I think it is not used
at this time.
Maybe a die could do the trick ("comments are not supported yet, please
contact ...")
> + nested_fonts
> It deals with the nested font issue.
> I have an idea on how to simplify it a lot, but I think it could be
> applied, because it is doing a good job.
> The only remaining issue is with "un-terminated" fonts, as in:
> Hello, my name is \fINicolas \fBFRANÇOIS
> IMHO, in groff, there is no nested font (with some exceptions, like
> SB, and some italic and bold faces, or by using exotic tmac).
> \fIfoo\fBbar\fR is equivalent to \fIfoo\fR\fBbar\fR (with the
> exception of the \fP).
Mmm. That's a very tought problem. As you saw in the code, I already tried
to tackle it, in vain so far. I must admit that the regression result you
show are rather impressive.
But I do not like this patch anyway, for several reasons:
- no print "NEKRAL: bla" should remain. Change them to debugging statements
or regular (translated) warnings, or whatever. Add a new debugging
category if needed. Same for "# print STDERR bla".
- you are kind of cheating by not die()ing when you said in the comments
that you should... It removes a lot of PBS :)
If the pages are ok afterward, then remove the fixme asking to die. If
not, die. Undetected errors are worse for the user than unprocessed
pages. He can always change the structure of the page to make po4a happy.
- you say that a proper implementation of \fP needs to keep track of the
font used at the end of the last paragraph. Are we in bold after
\fB\fI\fB\fP\fP ? (in which case, we need to keep track of the whole
stack)
Yes.
That's the reason why I replace \fP by the exact font (starting from the left).
In the patch a loop is in charge of replacing \fB\fI\fB\fP\fP by:
\fB\fI\fB\fI\fP
and then
\fB\fI\fB\fI\fB
And then I can clean up the "nested fonts"
I Think doing this can avoid keeping track of the whole stack
Another insane example:
.BI t1 t2 t3\fRt4\fIt5 t6\fPt7\fPt8 t9
(such groff requests were found)
- this is really complex, I'm concerned about maintaining the
beast when
you leave. Ie, you shouldn't have said you have a simpler solution in
mind, now I want to see it ;)
1) change all font modifiers (e.g. .B, .RI,...) to the corresponding \f
I'm thinking of doing this in shiftline (any objection ?), because I
need to handle these lines in parse, in the .TP, .SH, and maybe other
macro subroutines.
Then in pre_trans:
2) split the paragraph on \f
3) play with the first letters of each element of this array
(they can be [1-9],B,I,R,CW,P,s(-|+)[0-9])
- If the first letter is not recognized, then die (or give a \f to the
translator)
- If two consecutive elements start with the same font, merge them
A special care shall be taken for the first elements (maybe the two first,
because of \fP) and for the last (maybe the last two) elements.
I will probably do this with a global context that will keep the
current and previous font (which will be reset by some macros like
.SH).
I will do some experiments on this.
I think this will be better, cleaner, smaller.
- there is one stylistic rule I like in Perl: if you use a given
variable
only once, remove it, you don't need it. @tmp_array1 falls in that
category. Likewise, I'd prefer to write (! $old eq "") as ($old ne
"")
[please don't get offended by those stylistic remarks, this code is
incredibly hairly, I'd like to keep it under control]
I didn't knew ne ;) thanks!
How can I remove a variable (or maybe you mean I could have done it
without using variable with map)?
Using perldoc is still a little bit confusing for me. So please, no
hesitation on stylistic comments.
- I'm not sure I understand the "two concecutive \fR are
not needed" part
What about the following:
while ($str =~ /^(.*)\\fR # Get the beginning, until a \fR
# Now, get the middle
((?: # [this parenthesis clusters, don't capture]
[^\\] # the middle is either not '\'
| # or
\\(?!f) # '\', but not followed by 'f' (look ahead)
)*)
\\fR # end sentinel
(.*)$/sx) {# use x modifier to add documentation and space
$str = "$1\\fR$2$3";
}
Ok, I admit, this is not tested at all, and I just discovered the
"negative look ahead" black magic in man perlre, I may well be wrong.
I'm
sure you'll correct me if it's the case, since you use this magic
elsewhere.
Yes. This is equivalent. I've tested it (with some minor changes).
I will use it, but this will be removed once I will have another font
algorithm.
We should use the x modifier more often to document the REs.
Right!
I'm not sure I can still read my regexp now!
All that to say that I'd prefer to keep this one out of the CVS
for now.
> + arg_next_line
> It allows arguments to be provided on the next line for some macros
> (.SH, .I, ..., .BR, ...)
>
> It works fine, but would require some cleanup (lots of redundant
> code).
Erm. You'll say I'm picky, but I'd prefer you to do this cleanup before
commit :)
I never said the patches were ready for commit;)
> + dot_lines
> po4a generated some lines starting with a dot. In those cases, a \&
> should be added to allow the line to be displayed. (for exemple:
> .I ../file
> is displayed in groff, but
> \fI../fil/\fR won't be displayed
> It also fix the same issue for lines starting by a "'"
Arg, I'm so bad! I thought I got this one years ago. Thanks for chasing it.
Why don't you change it in paragraphs after the wrap? You'd get 'em all, and
the code for that would be in only one location.
For example, you may want to merge your change to the
$str =~ s/\n([.'"])/ $1/mg; #'
just before. What about:
$str =~ s/^ # at the begin of line
(?:\\f.)? # possibly followed by a font modifier
([.'"]) # avoid '.' and '''
/\\&$1$2 # add \& in front to fix it
/mgx;
You're right, doing it in post_trans is better.
However, there's currently a minor bug with .TP:
.TP
.BI foo bar
will proposes for translation the ".BR foo bar" string instead of
"B<foo>I<bar>".
This issue doesn't raise any difference in the regression test, but
escaping the leading dot add some pages to WDIFF.
So I only propose a degraded mode:
# # No . on first char, or nroff will think it's a macro
- $str =~ s/\n([.'"])/ $1/mg; #'
+ unless (defined $self->{type} && $self->{type} =~ m/^TP$/) {
+ # This doesn't work when the translated string start
+ # by a macro (which should be avoided).
+ # At this time, .TP lines followed by .B, .BI,... produce
+ # such strings.
+ # This will be fixed latter.
+ #
+ # Only "." are handled now.
+ # "'" will be handled latter (when it will also be handled in the
+ # parse subroutine.
+ $str =~ s/^( # at the beginning of a line
+ (?:[BI]<)? # possibly followed by a font modifier
+ [.]) # avoid "." and "'"
+ /\\&$1/mgx; # add \& in front to fix it
+ }
+ $str =~ s/\n([.'])/\n\\&$1/mg; # degraded mode for "'", and
"." in TP
+ # (doesn't handle the first line)
The unless, a part of the comments and the last regexp could be
removed latter. As ' could be added to [.] latter.
This seems to work fine. I will prepare a patch or commit it.
> + new_macros
> Some new macros:
> .R
> .EX and .EE
> .so and .mso
> .cs
> minimal support (when no argument is given) for:
> .ce
> .ul
> .cu
This one is not in the tarbal. :-/
It should be attached this time.
Do you think the .so/.mso part is OK ?
> + escape
> It tries to deal with the \c escape.
> It still need some work.
Kill the die I did put if it's not needed anymore.
You could override the pushline function, if you understand Perl objects. I
don't.
I've done some tests. Overriding pushline is OK. I will try to handle \c
there.
What is the effect of \c, again?
info groff --index-search "Line Control"
> + others
> some other minor points that I could isolate from my working directory
What is the change for cdrdao ? It deals with non escaped leading spaces, am
I right? Does it still deal with not leading spaces? I don't think so. you
may want to kill those ^
cdrdao uses:
.IP CATALOG\ "ddddddddddddd"
(Here, the quote have to be displayed)
When this passes through pushmacro, additional quotes shouldn't be added,
because
.IP "CATALOG\ "ddddddddddddd""
(this is understood by groff as an IP request with 2 arguments: 'CATALOG\ '
and 'ddddddddddddd""')
The regexp proposed in the patch would be shorter with a negative
look-behind regexp.
Ok for the SH macro.
Do you think it could be done in the $macro{'SH'} sub ?
For the space at the begining of paragraph, shouldn't it be
handled along
with ' or . at the beginning of line?
> + split_args
> This fix an issue for the limits.conf man page.
> It was also reported in #268904
> It adds one string for the translation.
Ok, I tried to understand your bug report three times, in vain. It's not now
at 1 am that I will understand the patch. I belive you on this one.
It is probably useful for only one man page. It may not
Did you use quilt, at least? ;)
No.
After two mails bounced by Alioth I had a look at the diff and thought it
was time to split it in different patches.
PS: I forgot whether you're on the list, thus the cc.
I'm on the list, but thanks for the cc (it permitted me to receive it
some days before).
--
Nekral
4:16 a.m.
On Sun, Sep 26, 2004 at 06:03:54PM +0200, Nicolas François wrote:
On Fri, Sep 24, 2004 at 01:28:23AM +0200, Martin Quinson wrote:
> On Wed, Sep 22, 2004 at 11:19:30PM +0200, Nicolas François wrote:
Alioth is up and running again. Here is my account: nekral-guest.
Done. You have the commit right. Please use it, but do not abuse it :)
If you want we can stick to the current model for a while, where I review
and commit your patches. But I gave you the cvs commit right so that at
least trivial changes (such as the usage of the testsuite stuff) can go
faster.
> > + comments
> > It recognize some (probably incorrect, but usual) comment lines.
> > Here are the results of the regression tests for this patch:
>
> Question: the info groff part you cite in comment seems to imply that
> .B toto \" a comment
> is a valid construct, but this is not handled by the code. You should at
> least add a comment stating so, shouldn't you?
Yes, it is valid. (At least it is recognized as such by my groff).
My problem was: Ok, I recognized a comment inside a paragraph, what
should I do with this comment ?
Can I show it in the po (and how?)? Is there any interest in doing this?
Can I just trash the comments?
I'd say: push it to the po file. The only issue is that it shows a flaw in
po4a. Modules have no way [I could remember of] to push comments into the po
file :-/
Ok, I've added one. It's not tested yet, but if you pass "comment"
=>
"your_comment" at the end of the translate arguments, it should do the
trick. Now, we should integrate this cleanly into the man module (having a
variable dedicated to the storage of the comments, and used when pushing
translations), but I don't want to interfer with your current changes in
that file.
If you test it yourself, the comments should end on lines begining with:
#.
Let's keep it on the todo for now.
> > + nested_fonts
> > It deals with the nested font issue.
> > I have an idea on how to simplify it a lot, but I think it could be
> > applied, because it is doing a good job.
> > The only remaining issue is with "un-terminated" fonts, as in:
> > Hello, my name is \fINicolas \fBFRANÇOIS
> > IMHO, in groff, there is no nested font (with some exceptions, like
> > SB, and some italic and bold faces, or by using exotic tmac).
> > \fIfoo\fBbar\fR is equivalent to \fIfoo\fR\fBbar\fR (with the
> > exception of the \fP).
>
> Mmm. That's a very tought problem. As you saw in the code, I already tried
> to tackle it, in vain so far. I must admit that the regression result you
> show are rather impressive.
>
> But I do not like this patch anyway, for several reasons:
If you don't mind I'll let it maturate on your side. I've so little time
myself...
1) change all font modifiers (e.g. .B, .RI,...) to the corresponding
\f
I'm thinking of doing this in shiftline (any objection ?), because I
need to handle these lines in parse, in the .TP, .SH, and maybe other
macro subroutines.
overiding shiftline could be a good idea. You may want to handle some parts
of the chaos in a "upper layer". But please make sure to document this.
Then in pre_trans:
2) split the paragraph on \f
3) play with the first letters of each element of this array
(they can be [1-9],B,I,R,CW,P,s(-|+)[0-9])
- If the first letter is not recognized, then die (or give a \f to the
translator)
- If two consecutive elements start with the same font, merge them
A special care shall be taken for the first elements (maybe the two first,
because of \fP) and for the last (maybe the last two) elements.
I will probably do this with a global context that will keep the
current and previous font (which will be reset by some macros like
.SH).
I will do some experiments on this.
I think this will be better, cleaner, smaller.
Sounds very good to me.
> - there is one stylistic rule I like in Perl: if you use a
given variable
> only once, remove it, you don't need it. @tmp_array1 falls in that
> category. Likewise, I'd prefer to write (! $old eq "") as ($old ne
"")
> [please don't get offended by those stylistic remarks, this code is
> incredibly hairly, I'd like to keep it under control]
I didn't knew ne ;) thanks!
How can I remove a variable (or maybe you mean I could have done it
without using variable with map)?
Simply change something like
@toto = split(/\n/, $toto);
foreach (@toto) {}
to
foreach (split(/\n/, $toto)) {}
since @toto is used only once beside its initialization, it's useless. Of
course, some times, you want to keep useless variables to make the code more
readable. I don't felt it was the case here, but express yourself ;)
> We should use the x modifier more often to document the REs.
Right!
I'm not sure I can still read my regexp now!
I will try to do so more often, too.
> All that to say that I'd prefer to keep this one out of the
CVS for now.
>
> > + arg_next_line
> > It allows arguments to be provided on the next line for some macros
> > (.SH, .I, ..., .BR, ...)
> >
> > It works fine, but would require some cleanup (lots of redundant
> > code).
> Erm. You'll say I'm picky, but I'd prefer you to do this cleanup before
> commit :)
I never said the patches were ready for commit;)
Ok, let's leave this one maturate, too.
> > + dot_lines
[...]
> Why don't you change it in paragraphs after the wrap?
You'd get 'em all, and
> the code for that would be in only one location.
>
> For example, you may want to merge your change to the
> $str =~ s/\n([.'"])/ $1/mg; #'
> just before. What about:
> $str =~ s/^ # at the begin of line
> (?:\\f.)? # possibly followed by a font modifier
> ([.'"]) # avoid '.' and '''
> /\\&$1$2 # add \& in front to fix it
> /mgx;
You're right, doing it in post_trans is better.
However, there's currently a minor bug with .TP:
[...]
So I only propose a degraded mode:
[..]
This seems to work fine. I will prepare a patch or commit it.
Please do so, this one looks good too.
> > + new_macros
It should be attached this time.
Do you think the .so/.mso part is OK ?
Nope, it's not. But you had no way to know it. Btw, I commited all the others.
For the sgml module, the policy is to include all the translations in only
one po file, no matter how many source file there is. This is because it's
very difficult to parse a sgml sub-file alone. Where it's included in the
main document is important, as long as the entities defined in the prolog of
the main document, and so on.
So, I'd like to follow the same policy for the man pages. I know that it
will result in dupplicate in the translations, but, well, translators can
use compendiums.
The prefered handling of .so is thus to read the included file, and then
unshift all its lines (begining by the end, of course) into the
transtractor. Of course, this should be a function of the TransTractor
itself such as includefile($). But we didn't agree with Jordi on the
function prototype and syntax before my vacations...
> > + escape
> > It tries to deal with the \c escape.
> > It still need some work.
I've done some tests. Overriding pushline is OK. I will try to handle \c
there.
Go ahead, dude.
> > + others
> > some other minor points that I could isolate from my working directory
>
> What is the change for cdrdao ? It deals with non escaped leading spaces, am
> I right? Does it still deal with not leading spaces? I don't think so. you
> may want to kill those ^
cdrdao uses:
.IP CATALOG\ "ddddddddddddd"
(Here, the quote have to be displayed)
When this passes through pushmacro, additional quotes shouldn't be added,
because
.IP "CATALOG\ "ddddddddddddd""
(this is understood by groff as an IP request with 2 arguments: 'CATALOG\ '
and 'ddddddddddddd""')
Commited with this explanation.
The regexp proposed in the patch would be shorter with a negative
look-behind regexp.
Feel free to shorten it, it it keeps readable (or use /x, or both ;).
> Ok for the SH macro.
Do you think it could be done in the $macro{'SH'} sub ?
I dunno. Now, it's commited as you said, and I dunno what could be the best.
Keeping all the $wrapmode handling at the same location or all the .SH
action at the same place. It's kinda the same.
> For the space at the begining of paragraph, shouldn't it be
handled along
> with ' or . at the beginning of line?
[again ;]
That's the bounced part:
@@ -986,9 +987,13 @@ $macro{'ps'}=\&untranslated;
# .so filename Include source file.
# .mso groff variant of .so (other search path)
$macro{'so'}= $macro{'mso'} = sub {
- die "po4a::man: ".sprintf(
- dgettext("po4a","This page includes another file with '%s'.
This is not supported yet, but will soon."),
+ print STDERR "po4a::man: ".sprintf(
+ dgettext("po4a","This page includes another file with '%s'.
Don't forget to translate this file, and to make it available at the right
place."),
$_[1])."\n",;
+ my ($self,$macroname,$macroarg)=(shift,shift,join(" ",@_));
+
+ $self->pushmacro($macroname,
+ $self->t($macroarg));
};
# .sp Skip one line vertically.
# .sp N Space vertical distance N
Thanks so much for your work on po4a,
Mt.
3:49 p.m.
On Mon, Sep 27, 2004 at 11:16:39AM +0200, Martin Quinson wrote:
On Sun, Sep 26, 2004 at 06:03:54PM +0200, Nicolas François wrote:
> On Fri, Sep 24, 2004 at 01:28:23AM +0200, Martin Quinson wrote:
> > On Wed, Sep 22, 2004 at 11:19:30PM +0200, Nicolas François wrote:
>
> Alioth is up and running again. Here is my account: nekral-guest.
Done. You have the commit right. Please use it, but do not abuse it :)
OK, thank you. I've started using it:
- one fix in the patch you committed for me
- documentation of the scripts
If you want we can stick to the current model for a while, where I
review
and commit your patches. But I gave you the cvs commit right so that at
least trivial changes (such as the usage of the testsuite stuff) can go
faster.
For the biggest parts, I will send a patch to the list for a review.
> My problem was: Ok, I recognized a comment inside a paragraph,
what
> should I do with this comment ?
> Can I show it in the po (and how?)? Is there any interest in doing this?
> Can I just trash the comments?
I'd say: push it to the po file. The only issue is that it shows a flaw in
po4a. Modules have no way [I could remember of] to push comments into the po
file :-/
Ok, I've added one. It's not tested yet, but if you pass "comment"
=>
"your_comment" at the end of the translate arguments, it should do the
trick. Now, we should integrate this cleanly into the man module (having a
variable dedicated to the storage of the comments, and used when pushing
translations), but I don't want to interfer with your current changes in
that file.
Nice. I will try it and see if it can be useful for the translators (I'm
wondering if there isn't too much comments in some man pages)
> > > + nested_fonts
[...]
I've got a font stack now.
It works fine with the regression tests. It may need some more tests at
the po level (see if the po is OK)
Do you want all the \f font modifiers to disappear from the po?
If this is the case, I will add some marks for others fonts (I've already
added a CW for the Constant Width font).
Do you think \s-1 (reduce the size by one point) should be given to the
translators? Is S<-1> better?
If you don't mind I'll let it maturate on your side. I've
so little time
myself...
> 1) change all font modifiers (e.g. .B, .RI,...) to the corresponding \f
> I'm thinking of doing this in shiftline (any objection ?), because I
> need to handle these lines in parse, in the .TP, .SH, and maybe other
> macro subroutines.
overiding shiftline could be a good idea. You may want to handle some parts
of the chaos in a "upper layer". But please make sure to document this.
Overriding shiftline works fine. There is however a possible issue: it may
break unshiftline (I will probably override it with a die, or add a FILO
stack of the unshifted lines, which will be used by shiftline).
I'm also wondering which ref I should return when multiple lines have been
shifted with the Transtractor shiftline.
> Do you think the .so/.mso part is OK ?
Nope, it's not. But you had no way to know it. Btw, I commited all the others.
For the sgml module, the policy is to include all the translations in only
one po file, no matter how many source file there is. This is because it's
very difficult to parse a sgml sub-file alone. Where it's included in the
main document is important, as long as the entities defined in the prolog of
the main document, and so on.
So, I'd like to follow the same policy for the man pages. I know that it
will result in dupplicate in the translations, but, well, translators can
use compendiums.
The prefered handling of .so is thus to read the included file, and then
unshift all its lines (begining by the end, of course) into the
transtractor. Of course, this should be a function of the TransTractor
itself such as includefile($). But we didn't agree with Jordi on the
function prototype and syntax before my vacations...
If the file only consist in a .so (majority of the man pages which use a
.so), a warning/die could be use to recomment to only copy the original
file / make a symlink.
.mso are probably not translatable (they include tmac files, i.e.
definition of macros)
To increase the number of man pages used by the regression test, I added a
-M option to po4a-normalize (to specify the master charset).
I would appreciate if somebody more used to po4a could have a look at
which options could be useful for po4a-normalize.
I attach to this mail the following patches:
Man.pm.splitargs.patch
add a splitargs function (which is at this time hardcoded in parse)
This patch is just a code reorganization. It should not change
anything (I need this function in another place, and it may
simplify the parse function).
All the code from the splitargs function comes from the parse
function.
The regression test doesn't show any difference.
Man.pm.splitargs.fonts.patch
(have to be applied after the previous one)
add the font stack
it mostly consist in a do_fonts function, called in pre_trans.
There is also set_regular and set_font.
If you think something need more comments, please tell me.
I've used static variables, but I'm not sure it is the right way
to do this.
I've also changed a little bit the handling of .B and .BI macros
(they return to the Roman font, not the previous font).
Here are the results of the regression tests:
dir1:splitargs
dir2:splitargs.fonts
dir1\dir2 IGN OK OK2 WOK1 WOK2 WOK3 PBS WDIFF
IGN 1734 0 0 0 0 0 0 0
OK 0 124 0 0 0 0 0 0
OK2 0 0 1588 0 0 1 4 0
WOK1 0 0 0 107 0 0 1 0
WOK2 0 0 0 0 222 1 2 0
WOK3 0 1 13 2 2 318 6 0
PBS 0 1 132 10 41 55 596 12
WDIFF 0 0 0 0 0 0 0 52
total: 5025 | 5025
Man.pm.splitargs.fonts.shiftline.patch
(have to be applied after the previous one)
add a shiftline function
It mostly uses code from the parse function (continuation after a
It permit (or will permit) to benefit from this part of the parse
function in some macro subroutines. (e.g. at this time, a ".B"
macro called after a TP (groff's indented paragraph with label) is
kept in the po, instead of providing a B<...> to the translator)
Here are the results of the regression tests:
dir1:splitargs.fonts
dir2:splitargs.fonts.shiftline
dir1\dir2 IGN OK OK2 WOK1 WOK2 WOK3 PBS WDIFF
IGN 1734 0 0 0 0 0 0 0
OK 0 126 0 0 0 0 0 0
OK2 0 0 1729 1 0 0 1 2
WOK1 0 0 0 118 0 0 1 0
WOK2 0 0 0 0 265 0 0 0
WOK3 0 1 8 3 7 353 1 2
PBS 0 0 0 0 0 0 609 0
WDIFF 0 0 0 0 0 0 4 60
total: 5025 | 5025
These patches introduce some issues (for a dozen of pages). These issues
are under control, and will be fixed later (I wanted to keep those patches
as simple as possible).
These patches mostly allow more pages for translation, and further
corrections.
Any comment (even stylistic) will be appreciated.
Subroutines' name and position can also be changed before inclusion in CVS.
Kind Regards
--
Nekral
5:39 p.m.
On Sun, Oct 10, 2004 at 10:49:10PM +0200, Nicolas François wrote:
On Mon, Sep 27, 2004 at 11:16:39AM +0200, Martin Quinson wrote:
> On Sun, Sep 26, 2004 at 06:03:54PM +0200, Nicolas François wrote:
> > On Fri, Sep 24, 2004 at 01:28:23AM +0200, Martin Quinson wrote:
> > > On Wed, Sep 22, 2004 at 11:19:30PM +0200, Nicolas François wrote:
> >
> > Alioth is up and running again. Here is my account: nekral-guest.
>
> Done. You have the commit right. Please use it, but do not abuse it :)
OK, thank you. I've started using it:
- one fix in the patch you committed for me
- documentation of the scripts
[...]
Martin, we need to review these patches, otherwise this work will get
lost (or committed ;)).
If you do not have time, I can try to have a look this week-end.
Denis
6:03 a.m.
Hello Denis,
On Wed, Oct 27, 2004 at 12:39:34AM +0200, Denis Barbier wrote:
Martin, we need to review these patches, otherwise this work will
get
lost (or committed ;)).
If you do not have time, I can try to have a look this week-end.
Martin wrote me last week that he doesn't have a lot of time currently.
If you want to have a look at them this week-end, you can mail me any
question, or we can arrange an IRC meeting if you prefer.
--
Nekral
12:14 p.m.
On Fri, Oct 29, 2004 at 01:03:39PM +0200, Nicolas François wrote:
Hello Denis,
On Wed, Oct 27, 2004 at 12:39:34AM +0200, Denis Barbier wrote:
> Martin, we need to review these patches, otherwise this work will get
> lost (or committed ;)).
> If you do not have time, I can try to have a look this week-end.
Martin wrote me last week that he doesn't have a lot of time currently.
If you want to have a look at them this week-end, you can mail me any
question, or we can arrange an IRC meeting if you prefer.
Ok, usually I have some free time between 20:00 and 22:00 UTC.
My nick is bouz. Which channel are you using?
Choosing a French speaking channel may be a good idea ;)
(Unless other people are interested)
Denis
1:57 p.m.
On Fri, Oct 29, 2004 at 07:14:10PM +0200, Denis Barbier wrote:
Ok, usually I have some free time between 20:00 and 22:00 UTC.
My nick is bouz. Which channel are you using?
Choosing a French speaking channel may be a good idea ;)
(Unless other people are interested)
I've seen some persons using #po4a on Freenode. There is usually ...
nobody, so it may be a French speaking channel;)
I may be late for 20:00, but I will try to be there.
--
Nekral
8:04 p.m.
Hello all,
I could defend my patches on IRC in front of Denis yesterday ;)
I've got the log of the irc session, and can share it if Denis agree.
(note : it won't be useful if you can't read french)
Denis proposed some modifications on the patches, which I will do, test
and probably commit this week-end.
Aside from the review of the patches, we discussed about these points :
(all but the last one are related to the man module)
- quotes
\(lq and \(rq are transformed to `` and '' before the translation and
reversed back to \(lq and \(rq in the groff page.
This can be an issue in the following string (I'm pretty sure I've
seen something like this somewhere, but can find it back) :
You can provide an empty argument with --arg ''
(we don't want a single double quote, but a double single quote here)
or (in man aptitude) :
``aptitude markauto '~slibs'''
(this is probably impossible to detect which couple of single quote
has to be converted to \(rq in such a string)
An idea could be to use UTF-8 quotes, but this force using UTF-8 POs,
and would require a -L option for po4a-translate (for example french
manpages should be converted to iso-8859-1)
Another idea is to keep the conversion of \(lq and \(rq, and let the
user use her quotes in the translation.
- non ASCII in msgid strings
currently, msgids can contain xA0 (non breaking space) characters,
which cause warnings during execution of po4a or msgcat on the po.
- groff's font size modifier
.SB macro is no more handled with my patches (but was buggy).
".SB foo bar" should be equivalent to ".SM \fBfoo bar\f(P or R)"
A special handling could be necessary for .SM, not to break sentences
(this wont be easy to test, because size doesn't matter in terminals)
Other font size modifiers (\s-n \s+n) are currently given to the
translator, who may be not aware of groff.
- -M option for po4a-normalize
Adding this option should be OK.
This may be only useful for me : it allow to use more pages for
the regression test tool (most of the non ASCII characters are due to
author names, which is something I can't blame;)
I hope I didn't forget / misunderstood anything.
Regards,
--
Nekral
2:19 p.m.
On Sun, Oct 31, 2004 at 02:04:02AM +0100, Nicolas François wrote:
Denis proposed some modifications on the patches, which I will do,
test
and probably commit this week-end.
Remembering Martin is off-line during week-ends.
I would like to give him a chance to stop me before the commit, that I'm
delaying to Thursday.
BTW, here are the modified patches.
Regards,
--
Nekral
8:57 a.m.
On Mon, Nov 01, 2004 at 09:19:16PM +0100, Nicolas François wrote:
On Sun, Oct 31, 2004 at 02:04:02AM +0100, Nicolas François wrote:
> Denis proposed some modifications on the patches, which I will do, test
> and probably commit this week-end.
Remembering Martin is off-line during week-ends.
I am not anymore. We finally received our ADSL box. Yuhu.
I would like to give him a chance to stop me before the commit, that
I'm
delaying to Thursday.
I'm not crazy. I won't stop you from commiting them... I had a very quick
glance and it looks good to me. Moreover, it was written by you and reviewed
by Denis. And you tested it throughfully.
Go ahead and commit that stuff, I'm ashamed to brake you guys.
Mt.
6:30 a.m.
On Wed, Oct 27, 2004 at 12:39:34AM +0200, Denis Barbier wrote:
On Sun, Oct 10, 2004 at 10:49:10PM +0200, Nicolas François wrote:
> On Mon, Sep 27, 2004 at 11:16:39AM +0200, Martin Quinson wrote:
> > On Sun, Sep 26, 2004 at 06:03:54PM +0200, Nicolas François wrote:
> > > On Fri, Sep 24, 2004 at 01:28:23AM +0200, Martin Quinson wrote:
> > > > On Wed, Sep 22, 2004 at 11:19:30PM +0200, Nicolas François wrote:
> > >
> > > Alioth is up and running again. Here is my account: nekral-guest.
> >
> > Done. You have the commit right. Please use it, but do not abuse it :)
>
> OK, thank you. I've started using it:
> - one fix in the patch you committed for me
> - documentation of the scripts
[...]
Martin, we need to review these patches, otherwise this work will get
lost (or committed ;)).
Hi there,
I'm really sorry, but I keep being completely swamped by real life. Just to
give you an idea of my current situation, I found again my debian signed PGP
key a month ago, and I didn't found the time to copy it on my current laptop
yet.
If you do not have time, I can try to have a look this week-end.
Yes, please. Any kind of help is warmly welcome. I feel very bad wrt Nekral
who submitted those patches. I'm rather sure they do improve po4a. Bloking
them that way is very rude from me.
After chrismas may be a better time frame, but it's not even sure...
Sorry again, Mt.
9:15 a.m.
Just to inform you of what I commited so far:
On Wed, Sep 22, 2004 at 11:19:30PM +0200, Nicolas François wrote:
I also had to work on the testsuite (the check script) and added a
stats.sh scripts for regression tests. Here are how this last script
formats regression tests statistics:
committed, even if I had some remarks against them (they are still to do).
+ comments
It recognize some (probably incorrect, but usual) comment lines.
commited.
+ nested_fonts
It deals with the nested font issue.
I have an idea on how to simplify it a lot, but I think it could be
applied, because it is doing a good job.
not commited. I really don't like this one as is, sorry.
+ arg_next_line
It allows arguments to be provided on the next line for some macros
(.SH, .I, ..., .BR, ...)
not commited since it depends on the previous one, and since it still needs
some cleanup, as you said.
+ dot_lines
po4a generated some lines starting with a dot. In those cases, a \&
should be added to allow the line to be displayed. (for exemple:
.I ../file
is displayed in groff, but
\fI../fil/\fR won't be displayed
It also fix the same issue for lines starting by a "'"
not commited.
What about the code factorisation I spoke about yesterday? Note that it's a
minor remark, not a veto.
+ hyphen
I had a obligation to fix this because I said Martin that replacing
hyphens by minus signs were always allowed.
In fact, it should not be modified in
- .so/.mso arguments
- after a \s (font size modifier, e.g. \s-2)
I also added a comment on why I *hate* hyphens.
Committed, with the changes I advocated, plus the handling of the mso macro
here, which were missing from your patch (yeah, I added 3 letters to your
patch ;)
+ new_macros
Some new macros:
.R
.EX and .EE
.so and .mso
.cs
minimal support (when no argument is given) for:
.ce
.ul
.cu
This one wasn't in tarball.
+ escape
It tries to deal with the \c escape.
It still need some work.
not commited. I'm not convinced here. Missing documentation?
+ others
some other minor points that I could isolate from my working directory
Took the wrapping resetting on .SH, but not the others changes, for the
reasons I told you.
+ split_args
This fix an issue for the limits.conf man page.
It was also reported in #268904
It adds one string for the translation.
This one gives me headaches since a while, commited. :)
Thanks for your time, and have a nice week-end (I'm offline on weekends).
Mt.
7354
days inactive
7400
days old
13 comments
5 participants
participants (5)
-
Denis Barbier -
Martin Quinson -
Martin Quinson -
Nicolas François -
Nicolas Fran�ois