At 2018-06-20T11:24:34+0200, Jean Delvare wrote: > On Sat, 16 Jun 2018 12:22:38 -0400, g.branden.robin...@gmail.com wrote: > > This eliminates the use of low-level requests in this man page (the > > groffism ".fam" to change the font family and the switching off and > > on of fill mode with ".nf" and ".fi".) > > > > Index: quilt/doc/quilt.1.in > > =================================================================== > > --- quilt.orig/doc/quilt.1.in > > +++ quilt/doc/quilt.1.in > > @@ -149,9 +149,7 @@ Inherits the existing value of $LESS if > > environment, otherwise defaults to "-FRSX". > > .SH FILES > > .SS "Example of working tree" > > -.fam C > > -.RS > > -.nf > > +.EX > > work/ > > âââ patches/ > > â âââ series (list of patches to apply) > > @@ -167,9 +165,7 @@ work/ > > â â âââ ... > > â âââ ... > > âââ ... > > I have trouble applying this patch. Because of the special characters > used to represent the example working tree, the mail was sent as: > > Content-Type: text/plain; charset="iso-8859-15" > Content-Transfer-Encoding: quoted-printable > > I don't think charset="iso-8859-15" can be right in the first place, > as the special characters in question are not part of that character > set. > > In practice, the first hunk gets applied with fuzz 2, and the rest of > the patch is ignored completely. > > I had a vague memory that "formail" could be used to "decode" such > transfer encodings but it doesn't seem to work this time. Any idea how > to solve this problem? > > I could redo the patch manually, but patches 13, 24 and 25 suffer from > the same problem, so I would prefer to have a clean and fast way to get > all such patches applied. > > Oh wait, "qprint -d" seems to be doing the trick. It complains when > processing the email headers (which contain a log of "=" signs but are > not encoded) but seems to decode the patch itself just fine. > > Nevertheless, a valid charset value (presumably "utf-8") would make the > patch readable in the email client too, which would be convenient.
I admit I have no idea what caused my email to be sent using that locale--whether my MUA made that terrible decision or GMail mangled it somehow. If you need a re-send on this, I'll double-check the point. > Patch itself looks good to me, I'm just curious why you removed one > indentation level for the first example and added one indentation > level for the second example? I don't really care but this seems > inconsistent so not really in line with your current effort. I have no clear memory--but looking back at it, I have to guess that I was trying to preserve the fact that the second example was indented, albeit using a different mechanism (leading spaces). Leading spaces tend to get inexperienced *roff users into trouble. I'll quote some new groff 1.23 documentation. --snip-- A line that begins with one or more spaces causes a break. The spaces are output at the beginning of the next line without being _adjusted_ (see below); however, this behavior can be modified (*note Leading Space Traps::). Again, macro packages may provide other methods of producing indented paragraphs. Trailing spaces on text lines are discarded.(1) (*note Breaking-Footnote-1::) --snip-- When filling is disabled, it's hard for anything too shocking to happen as a result of leading space usage, but for simplicity I would urge man page authors to rely solely on man(7) macro calls for indentation management. And in fact, I have an undocumented[1] style checker in groff man(7) that sets up a macro to complain if leading spaces are used. (It catches more serious problems, too, like calling a macro with the wrong number of arguments.) Back to the issue at hand--if you'd like the indentation of the examples to be the same, that's easily done. Regards, Branden [1] https://savannah.gnu.org/bugs/index.php?62042
signature.asc
Description: PGP signature
_______________________________________________ Quilt-dev mailing list Quilt-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/quilt-dev
