quilt-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Quilt-dev] [patch 06/26] Use groff_man(7)s EX and EE macros for exa


From: Jean Delvare
Subject: Re: [Quilt-dev] [patch 06/26] Use groff_man(7)s EX and EE macros for examples.
Date: Wed, 20 Jun 2018 11:24:34 +0200

On Sat, 16 Jun 2018 12:22:38 -0400, address@hidden 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.

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.

Thanks,
-- 
Jean Delvare
SUSE L3 Support



reply via email to

[Prev in Thread] Current Thread [Next in Thread]