On Wed, 26 Aug 2020 at 11:35, sebb <[email protected]> wrote: > > I have just discovered that convertToWrapped joins the output lines > using LF only, but expects the input to be CRLF. > This seems to be a bug, but means it's not necessary to revert back > after conversion. > > It also occurs to me that the correct line-length for wrapping depends > on the output device. > > Maybe it would be sensible to set the length to a high number so the > wrapped lines are completely unwrapped? > This would leave the wrapping to the device.
I've just done a test using width=1000, and it works a lot better than the default. So it's just a question of how large to make the width. > On Wed, 19 Aug 2020 at 12:05, sebb <[email protected]> wrote: > > > > On Wed, 19 Aug 2020 at 09:33, Daniel Gruno <[email protected]> wrote: > > > > > > On 18/08/2020 21.29, sebb wrote: > > > > I wondered about that. > > > > > > > > Now that the reformat is done after MID generation, it would not > > > > affect the generators. > > > > And it would only need to be done for f=f types. > > > > > > > > Also in theory it would only need to be done for mbox imports -- > > > > AFAICT live messages *should* have CRLF line terminators. > > > > > > > > > > > > > I've added a LF->CRLF conversion option to the .unflow(), but I have it > > > disabled by default for now, need to figure out the unit tests as they > > > would fail since the resulting body is different from PM <=0.12. > > > > Indeed. > > > > > Perhaps I need to work in some sort of version checks in the unit tests. > > > > I suggest leaving the conversion as an option to make testing easier. > > (It does not have to default to false, as long as it can be overridden) > > > > Most tests would not be affected (f=f is not that common). > > There could be some tests specifically to test the wrapping behaviour; > > these would need to be skipped for earlier versions. > > This could perhaps be done by requiring the dkim generator as an argument?
