Re: [Nmh-workers] Thoughts: header/address parsing

[David Levine]

Ralph wrote:

> Aside, it would be nice if scan's -width grew an "infinite" value as
> 9999 is a little kludgy.  I was thinking `0',

There's an old enhancement request for that:

    http://savannah.nongnu.org/bugs/?15274

> So then I played a little bit.
> 
>     $ scan -format '%{subject}' .
>     123456
>     $ scan -width 3 -format '%{subject}' .
>     12
> 
> Huh?

> I think -width is avoiding printing in the last column to avoid an
> unwanted linefeed?  Either that, or it's out by one.  I don't suppose
> it's deliberately counting the `\n'.
> 
> Anyway, it's a bit off-putting to get `12' for a `-width 3', especially
> after reading the fine man page.

Agreed, but it's been that way a long time.  And I'm reluctant
to change it because it could break user scripts.

I think that a fix for both of these should include:

1) Instead of callers allocating the space for the fmt_scan()
   output, have fmt_scan() do it.  Callers would pass a **char
   instead of a char array and be responsible for free'ing the
   space when they're done.

2) fmt_scan() would use some function of width as the initial
   size of the space and realloc by 2X as needed.

3) To not break existing user scripts, width would continue to
   include the trailing newline.  Add support for an optional
   profile setting to not include the trailing newline.

4) Add support for 0 width indicating infinite width.

Or, for now, just document that -width includes the newline and
wait for the next dive into the format code.

David