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

[Bill Wohler]

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
       characters.

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
optional.

-- 
Bill Wohler <address@hidden> aka <address@hidden>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD