[trojita] [Bug 360205] Inconsistent TAB parsing in Subject header

https://bugs.kde.org/show_bug.cgi?id=360205 veggero changed: What|Removed |Added Resolution|--- |INTENTIONAL CC|

[trojita] [Bug 360205] Inconsistent TAB parsing in Subject header

https://bugs.kde.org/show_bug.cgi?id=360205 --- Comment #20 from Thomas Lübking --- (In reply to Erik Quaeghebeur from comment #19) > I hope you don't mind the effort spent too much. *Your* efforts? ;-) Questioning things and justification is never wasted time ever.

[trojita] [Bug 360205] Inconsistent TAB parsing in Subject header

https://bugs.kde.org/show_bug.cgi?id=360205 --- Comment #19 from Erik Quaeghebeur --- (In reply to Jan Kundrát from comment #17) > > [...], I think that it's going to be much more common to see tabs as an > accident. (In reply to Thomas Lübking from comment

[trojita] [Bug 360205] Inconsistent TAB parsing in Subject header

https://bugs.kde.org/show_bug.cgi?id=360205 --- Comment #18 from Thomas Lübking --- Fwwi, mutt displays "?" for tabs (didn't try newline) I actually wonder about the trigger of this - few MUAs will (easily) allow to enter a tab into the subject (but jump to the next

[trojita] [Bug 360205] Inconsistent TAB parsing in Subject header

https://bugs.kde.org/show_bug.cgi?id=360205 --- Comment #17 from Jan Kundrát --- > I feel that 1. includes faithful representation of the message subject and > content, including tabs. If a tab is there, it is either by intent (which we > should consider), or by some error (which

[trojita] [Bug 360205] Inconsistent TAB parsing in Subject header

https://bugs.kde.org/show_bug.cgi?id=360205 --- Comment #16 from Erik Quaeghebeur --- (In reply to Jan Kundrát from comment #14) > > [...] If anything, my today's vote > :) is to ensure that newlines do not lead to visible line breaks (think > possible

[trojita] [Bug 360205] Inconsistent TAB parsing in Subject header

https://bugs.kde.org/show_bug.cgi?id=360205 --- Comment #15 from Thomas Lübking --- (In reply to Jan Kundrát from comment #14) > While you're changing this, try to consider a situation where the subject > consists of just one overly long sequence of characters with

[trojita] [Bug 360205] Inconsistent TAB parsing in Subject header

https://bugs.kde.org/show_bug.cgi?id=360205 --- Comment #14 from Jan Kundrát --- > -subDate += QStringLiteral(" large;\">%1").arg(e.subject.toHtmlEscaped()); > +subDate += QStringLiteral(" white-space:pre;\">%1").arg(e.subject.toHtmlEscaped()); While you're changing this,

[trojita] [Bug 360205] Inconsistent TAB parsing in Subject header

https://bugs.kde.org/show_bug.cgi?id=360205 --- Comment #13 from Thomas Lübking --- The message works here (it's pre-wrapped) and lead me to a solution that should work for you: diff --git a/src/Gui/EnvelopeView.cpp b/src/Gui/EnvelopeView.cpp index 1850456..14c049a

[trojita] [Bug 360205] Inconsistent TAB parsing in Subject header

https://bugs.kde.org/show_bug.cgi?id=360205 --- Comment #12 from Erik Quaeghebeur --- (In reply to Jan Kundrát from comment #6) > > If it is ‘a longer stretch of white space’, then using an em-space would be > > more appropriate than a normal space. > > Sounds

[trojita] [Bug 360205] Inconsistent TAB parsing in Subject header

https://bugs.kde.org/show_bug.cgi?id=360205 --- Comment #11 from Pali Rohár --- On Monday 07 March 2016 15:05:24 Erik Quaeghebeur via KDE Bugzilla wrote: > https://bugs.kde.org/show_bug.cgi?id=360205 > > --- Comment #10 from Erik Quaeghebeur

[trojita] [Bug 360205] Inconsistent TAB parsing in Subject header

https://bugs.kde.org/show_bug.cgi?id=360205 --- Comment #10 from Erik Quaeghebeur --- (In reply to Jan Kundrát from comment #8) > > More generally, as far as I've understood (and modulo folding), > > a header value MUST NOT contain any line breaks. > > There is

[trojita] [Bug 360205] Inconsistent TAB parsing in Subject header

https://bugs.kde.org/show_bug.cgi?id=360205 --- Comment #9 from Pali Rohár --- On Monday 07 March 2016 13:17:45 Erik Quaeghebeur via KDE Bugzilla wrote: > https://bugs.kde.org/show_bug.cgi?id=360205 > > --- Comment #7 from Erik Quaeghebeur

[trojita] [Bug 360205] Inconsistent TAB parsing in Subject header

https://bugs.kde.org/show_bug.cgi?id=360205 --- Comment #6 from Jan Kundrát --- > If it is ‘a longer stretch of white space’, then using an em-space would be > more appropriate than a normal space. Sounds like plan -- please submit a patch for this. > Hm... is there restriction

[trojita] [Bug 360205] Inconsistent TAB parsing in Subject header

https://bugs.kde.org/show_bug.cgi?id=360205 --- Comment #5 from Pali Rohár --- On Monday 07 March 2016 12:31:08 Erik Quaeghebeur via KDE Bugzilla wrote: > line-breaks in subjects are not allowed. Hm... is there restriction in RFC for this? Just asking. -- You are

[trojita] [Bug 360205] Inconsistent TAB parsing in Subject header

https://bugs.kde.org/show_bug.cgi?id=360205 --- Comment #4 from Erik Quaeghebeur --- (In reply to Jan Kundrát from comment #3) > I wonder what is a correct rendering of \t in a GUI with non-monospace > fonts. How do you expect to see them, and what it the use

[trojita] [Bug 360205] Inconsistent TAB parsing in Subject header

https://bugs.kde.org/show_bug.cgi?id=360205 --- Comment #3 from Jan Kundrát --- I wonder what is a correct rendering of \t in a GUI with non-monospace fonts. How do you expect to see them, and what it the use case behind showing them in a different way than "just space"? -- You

[trojita] [Bug 360205] Inconsistent TAB parsing in Subject header

https://bugs.kde.org/show_bug.cgi?id=360205 --- Comment #2 from Erik Quaeghebeur --- (In reply to Thomas Lübking from comment #1) > "toHtmlEscaped()" > The concept of a tabulator doesn't exist in html and I *assume* the function > won't translate it to a stack of

[trojita] [Bug 360205] Inconsistent TAB parsing in Subject header

https://bugs.kde.org/show_bug.cgi?id=360205 --- Comment #1 from Thomas Lübking --- "toHtmlEscaped()" The concept of a tabulator doesn't exist in html and I *assume* the function won't translate it to a stack of 's Kinda "wontfix" (notably for window titles, WMs will