[Top][All Lists]

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

Re: [Nmh-workers] Poor behavior of %(putaddr)

From: Bill Wohler
Subject: Re: [Nmh-workers] Poor behavior of %(putaddr)
Date: Sat, 14 Jan 2012 09:26:07 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Ken Hornstein <address@hidden> writes:

> Earl Hood mentioned that he was running into problems with "repl"
> hanging, and I ran into the same thing as well during some testing
> here, so I went and tracked down the problem.  Basically, it boils
> down to the use of %(putaddr) when "num" is zero.
> %(putaddr) uses the "num" register as a field width.  If "num" is zero
> (and many times it is if you don't explicitly set it), then it ends up
> basically performing badly (you would eventually get a whole lot of newlines
> in your draft).  This has been a problem for approximately forever.
> Having this just hang because of a poorly written mh-format file
> seems wrong.  Suggestions on a good solution?  Fixing the format
> scanner code so it behaves better is a possibility (but I'm not
> sure what "better" is in this case), but I am wondering if the
> format code should kick out an error when it runs into this situation.

mh-format says this:

       When a function or component escape is interpreted and the result
       will be immediately printed, an optional field width can be
       specified to print the field in exactly a given number of

Note the text, "optional field width." Thus, I think that if num is
zero, %(putaddr) should emit its entire contents, subject to any line
length restrictions in play. I don't think it should be an error if the
field width is missing/0 as the documentation clearly states that it is

Bill Wohler <address@hidden> aka <address@hidden>

reply via email to

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