Hi [2022-05-22 12:17] Ralph Corderoy <ra...@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