Re: mhl linewrapping
Hi [2022-05-22 12:17] Ralph Corderoy > > 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 1. 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
Re: mhl linewrapping
Hi Philipp, > 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. > 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. $ cat mhl.format from: to: subject: : body:component="",format,formatarg=-42,formatarg=-c,nowrap $ $ /usr/lib/nmh/mhl -form ./mhl.format -fmtproc fmt -width 42 <`mhpath .` from: Philipp Takacs to: nmh-workers@nongnu.org subject: mhl linewrapping Hi The linewrapping in mhl is not realy good and I would like to implement some improvements. 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. 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. What do you think about this? Philipp $ -- Cheers, Ralph.
mhl linewrapping
Hi The linewrapping in mhl is not realy good and I would like to implement some improvements. 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. 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. What do you think about this? Philipp
