Re: mhl linewrapping

[Philipp]

Hi

[2022-05-22 12:17] Ralph Corderoy <ralph@inputplus.co.uk>
> > First of all it depends on the terminalsize, if the size is not given
> > by the arguments.  This leads to diffrent linewrapping on reply
> > depending on the size of the terminal.  This could be fixed by going
> > to some default width when stdout is not a tty.
>
> It would seem right to only use the terminal to set the width when the
> output is a TTY.  There is already a default width of 80, mentioned in
> mhl(1), if the terminal width can't be found so my initial thought it
> that would do.

I'm currently looking at the code and for me it looks like if the size
can't detected it default to 10000. I might have missed something.

> > Next it only supports hard linewrapping.  Therefor sometimes words and
> > links get split.  Some support for softwrapping would be nice.  So mhl
> > could search for the last whitespace befor the selected width.
>
> Are you just talking about the body component or all of them?  Are you
> aware of -fmtproc, etc?  Some versions of fmt(1), for example, do
> other nice things like trying to avoid the word ‘I’ at the end of
> the line.  Other formatters might re-introduce two spaces after the end
> of a sentence.

I'm talking about all components. Of course most importend is the
body. I'm aware that you can do powerfull formating with an external
fmtproc. I just think it would be better to have a basic softwrapping in
nmh itself, because nmh should be able to create sane replies without
dependencies.

For the other components there is already a comment in mhl explaining
that putstr should know about atomics of addresses and dates. I would
start with working on this.

Philipp