All emails created by Trojita Compose window are flowed without any user warning or notification about it! Content-Type contains "format=flowed" attribute. This is wrong for more reasons: 1) Trojita automatically wrap long lines in Compose window, so user think that lines are really wrapped at that position as Compose window wrapped it. This just confuse users and Trojita lies about what is really wraped and what not! And this is bug. 2) Unwrapped flowed emails stretched to full width of email window are really hard to read and looks ugly. If quoted parts are wrapped at e.g. 80 chars but non quoted parts are not, those emails looks even more ugly. Trojita should wrap long lines so emails would be more readable. Or at least provide some way to configure line wrapping. In some mailing lists flowed emails are forbidden because of those problems. Trojita should be email client which can be used also for mailing lists. Reproducible: Always
(In reply to Pali Rohár from comment #0) > All emails created by Trojita Compose window are flowed without any user > warning or notification about it! Content-Type contains "format=flowed" > attribute. Right, that's not a bug, that's a feature. Pasted text doesn't get wrapped, btw, unless its lines end up with a space. > 1) Trojita automatically wrap long lines in Compose window, so user think > that lines are really wrapped at that position as Compose window wrapped it. > > This just confuse users and Trojita lies about what is really wraped and > what not! And this is bug. The serialization which gets sent over the wire is properly wrapped. If a MUA on the other side of the wire does not support format=flowed (i.e., a legacy mailer or if there's something on the way mangling data), the user sees hard-wrapped text. I don't see a bug in here. > 2) Unwrapped flowed emails stretched to full width of email window are > really hard to read and looks ugly. If quoted parts are wrapped at e.g. 80 > chars but non quoted parts are not, those emails looks even more ugly. That's likely a result of a non-flowed quotation. We cannot do much here; if others send non-flowed data, we cannot reflow them automatically. Patches which add a user-settable preference for maximal text width (via CSS, just rendering-wise) are welcome; in fact, you can create such a CSS rule today and put it into your user-defined CSS styling. Alternatively, well, do not resize the window too much. Why do you resize it if you do not expect the text content to fit it? > In some mailing lists flowed emails are forbidden because of those problems. > Trojita should be email client which can be used also for mailing lists. Which mailing lists are these? There's an old version of mailman which filters out format=flowed and other Content-Type parameters by accident, but that's been fixed already. If someone filters out format=flowed on purpose to "protect" their users, then well, there's nothing to stop such nonsense of course.
(In reply to Jan Kundrát from comment #1) > (In reply to Pali Rohár from comment #0) > > All emails created by Trojita Compose window are flowed without any user > > warning or notification about it! Content-Type contains "format=flowed" > > attribute. > > Right, that's not a bug, that's a feature. > It is bug. I as user I'm not informed about such evil thing! > Pasted text doesn't get wrapped, btw, unless its lines end up with a space. > And this is another bug. Pasted plain text with space at the end is properly shown in compose window, but when sending email trojita damage its content. > > 1) Trojita automatically wrap long lines in Compose window, so user think > > that lines are really wrapped at that position as Compose window wrapped it. > > > > This just confuse users and Trojita lies about what is really wraped and > > what not! And this is bug. > > The serialization which gets sent over the wire is properly wrapped. If a > MUA on the other side of the wire does not support format=flowed (i.e., a > legacy mailer or if there's something on the way mangling data), the user > sees hard-wrapped text. I don't see a bug in here. > Problem is that Compose window automatically wrap written text. But that text is not really wrapped after sending email. This is bug. Compose window show something different as what will be sent. > > 2) Unwrapped flowed emails stretched to full width of email window are > > really hard to read and looks ugly. If quoted parts are wrapped at e.g. 80 > > chars but non quoted parts are not, those emails looks even more ugly. > > That's likely a result of a non-flowed quotation. We cannot do much here; if > others send non-flowed data, we cannot reflow them automatically. > Yes we can! Disable sending flowed emails. > Patches which add a user-settable preference for maximal text width (via > CSS, just rendering-wise) are welcome; in fact, you can create such a CSS > rule today and put it into your user-defined CSS styling. Alternatively, > well, do not resize the window too much. Why do you resize it if you do not > expect the text content to fit it? > This is not problem only in Trojita, but in *all* other email clients. Some of them implements buggy flowed formatting, some correctly and some nothing. It means that *one* text/plain email is rendered differenly across different emails and web clients. We have there text/plain format and I expected that it renders semi-similar in all clients. Apparently this flowed format killed it. Plus there is buggy Gmail web behaviour... > > In some mailing lists flowed emails are forbidden because of those problems. > > Trojita should be email client which can be used also for mailing lists. > > Which mailing lists are these? E.g. LKML. > There's an old version of mailman which > filters out format=flowed and other Content-Type parameters by accident, but > that's been fixed already. > > If someone filters out format=flowed on purpose to "protect" their users, > then well, there's nothing to stop such nonsense of course. Emails are not modified and "forbidden" word is not enforced. But it does not mean that people will start screaming on you to fix your email client or stop sending unformatted/unreadable (=flowed) emails.
(In reply to Pali Rohár from comment #2) > It is bug. I as user I'm not informed about such evil thing! Do you mind linking a discussion that lines out *why* this is evil. > This is bug. Totally OT, but "This is *a* bug." "This is bug." is tarzan speech and makes you sound incredibly dull ;-) > nothing. It means that *one* text/plain email is rendered differenly across > different emails and web clients. errr.. "email" is not "pdf", 'key? Not even html is rendered consistently. Use pdf for such purposes (or a rasterized representation, iow. an image) > Emails are not modified and "forbidden" word is not enforced. But it does > not mean that people will start screaming on you to fix your email client or > stop sending unformatted/unreadable (=flowed) emails. I suggest to link the discussion and offending mail in question to see what and why went wrong in the particular case. As Jan pointed out: format=flowed is optional. If a client doesn't support it, it will just get hard-wrapped text. I assume some client takes the format=flowed mail and fails to handle the data properly and displays everything in one line (instead of dynamically wrapping it) - at least in quotes. It's however important to understand whether there's actually a bug in trojitá's implementation or we need to adapt for other (broken) clients. Asking the user on what to do with the composed mail is imo hardly an option - how should eg. my mom decide what's the proper format here? She'd rather be interested in sending purple comic sans htmls mails :-P
(In reply to Thomas Lübking from comment #3) > (In reply to Pali Rohár from comment #2) > > It is bug. I as user I'm not informed about such evil thing! > > Do you mind linking a discussion that lines out *why* this is evil. > > > This is bug. > Totally OT, but "This is *a* bug." > "This is bug." is tarzan speech and makes you sound incredibly dull ;-) > > > nothing. It means that *one* text/plain email is rendered differenly across > > different emails and web clients. > > errr.. "email" is not "pdf", 'key? > Not even html is rendered consistently. > Use pdf for such purposes (or a rasterized representation, iow. an image) > > > Emails are not modified and "forbidden" word is not enforced. But it does > > not mean that people will start screaming on you to fix your email client or > > stop sending unformatted/unreadable (=flowed) emails. > > I suggest to link the discussion and offending mail in question to see what > and why went wrong in the particular case. > As Jan pointed out: format=flowed is optional. If a client doesn't support > it, it will just get hard-wrapped text. > https://www.kernel.org/doc/Documentation/SubmittingPatches https://www.kernel.org/doc/Documentation/email-clients.txt https://lwn.net/Articles/237228/ > I assume some client takes the format=flowed mail and fails to handle the > data properly and displays everything in one line (instead of dynamically > wrapping it) - at least in quotes. > Problem is when you quote email which is *not* format=flowed. It will looks like: | > short text | > another short line | > | my new very very very very very very very very very very very very long line..... | another my very very very very very very very very very very very very very very long line... For recipients which properly support format=flowed quoted text cannot be wrapped or lines joined. But new text (under quote) can be wrapped at any word and wrapping depends on renderer. And by default (correct) clients show it at full width of window. Which leads to ugly looking email. > It's however important to understand whether there's actually a bug in > trojitá's implementation or we need to adapt for other (broken) clients. > There are two bugs in trojita compose window: 1) It automatically wrap lines at specific lenght independent from window width --> So I as user thinks that newly written email will be wrapped at those positions But because we use format=flowed there is no real wrapping (for clients which understands format=flowed) 2) If I paste external plain text into compose window which contains spaces at the end of copied lines, then format=flowed caused to remove those explicit line breaks. And of course there are bugs in other broken webmails and other clients (like thunderbird). So we can ignore those bugs and still unconditionally without any user option send format=flowed emails, or try to adapt and allow users to add option when they know that their email will be sent to people without proper format=flowed rendering. > Asking the user on what to do with the composed mail is imo hardly an option > - how should eg. my mom decide what's the proper format here? > If your mom is using Gmail or any other web service, *we* know answer. And if power user is using Trojita *he* would know answer. > She'd rather be interested in sending purple comic sans htmls mails :-P If we do not agree on default settings, why not introduce option which allow users to enable/disable format=flowed and auto wrap at 72 chars (or other number)?
I agree that a soft-wrap (wrap indicator) would be a better solution for the editor. As of a usable solution (and wrt to lkml) I'd say what you actually want is a "verbatim" button, ie. something that leads to _no_ text processing, for you do neither want manipulation of whitespace, nor static word wrap (breaking patches), nor anything - right? The mail is to be send byte-by-byte as written and the receiver is supposed to be able to handle that. We might even want to visualize whitespace by ␊␍␉␠, resp. by · for spaces or leave spaces untouched and indicate tabs by · (more readable) in that mode (in case bugzilla will now screw the UTF-8 chars: "NL" "LF" "CR" "HT" "SP" resp. a middle-dot instead of "SP") though this is rather overhead (trojitá is a mail client and no code editor and sending patches by mail inline is sick to begin with) PS: I object the stance "trojitá for the pros, the fools shall use webmail" - I have used the gmail webmailer and *nobody* should have to use that (and the other webmailers are hardly better)
(In reply to Thomas Lübking from comment #5) > As of a usable solution (and wrt to lkml) I'd say what you actually want is > a "verbatim" button, ie. something that leads to _no_ text processing, for > you do neither want manipulation of whitespace, nor static word wrap > (breaking patches), nor anything - right? > The mail is to be send byte-by-byte as written and the receiver is supposed > to be able to handle that. > Yes, I would be happy with such option.
Jan, how do you feel about such mode? It's actually a very specific requirement to cross all mail conventions in order to send patches or other text as inline comments. It's probably still relevant for a certain, tech-affine, user group and the choice is easy enough to understand to confront any user with it - at least when we toggle off autowrapping in the editor ;-)
Another suggestion: Monospaced font in compose window indicate that written email/text is probably unformatted resp. preformatted. So if you accept solution for "verbatim" button/option, what about using monospaced font only in that "verbatim" mode and in other use some non-monospaced font?
I talked about this with Pali in private as well. I'll be happy to accept a patch which disables auto wrapping in the composer. The other bug with pasted text whose lines end up with a space being flowed together is a real bug which should be fixed, too. What I very strongly object to is calling format=flowed an evil thing (especially without providing any specific examples of how exactly these things have become evil). I also dislike the idea of a toggle for disabling format=flowed when replying to non-flowed mails because the end result is going to be a universe where a single non-flowing client effectively disables flowing in all replies. A special note about LKML -- the way I understand their workflow, they appear to strongly favor sending patches inline rather than Content-Disposition: inline. That's of course broken (one cannot even easily save such a patch into a file because well, it's a part of a longer text with unrelated stuff, unless of course the entire body of your mail is in fact a patch, which then works by definition, but... Anyway, this is what Linus allegedly said in a LKML FAQ: > If I get a patch in an attachment (other than a "Text/PLAIN" type > attachment with no mangling and that pretty much all mail readers and > all tools will see as a normal body), I simply WILL NOT apply it unless > I have strong reason to. I usually wont even bother looking at it, > unless I expected something special from the sender. > > Really. Don't send patches as attachments. > > Linus To me, these two parts don't really fit into each other (what does Linus call an attachment, exactly?), but I don't really care anymore at this point. It's also interesting that the FAQ happens to recommend Mozilla users to use attachments :): > A caveat applies for people using a Mozilla Mail client. Andrew Morton noted that Mozilla mangles > spaces in column zero when patches are included in the message body. Fortunately, Mozilla Mail > sends patch attachments as type text/plain or text/x-patch (depending on the presence of a file > extension), so it's safe to send patches as attachments instead. That said, I see the value of being able to paste large chunks of preformatted stuff, such as code examples, into format=flowed e-mails. I can see that this is useful, and format=flowed supports such a mode just fine. I think that a proper™ solution to this problem is teaching the composer to keep track of flowed vs. unflowed text on a per-paragraph basis. IIRC there's a QTextDocument underneath and it supports (some more or less complicated) way of adding custom properties to text paragraphs. Perhaps it would make some sense to keep track of the is-flowed-enabled property for each of them, and to reflect that in the UI. This will also solve the problem of "> quoted text" quite neatly (yes, that "evil" format=flowed enables you to start lines with ">" and to not mark them as a quotation) if we add another property for that thing. We could even provide some UI clues to the user, with,. say, a different color of the quoted text, and a different background color for non-flowed and therefore preformatted text chunks, with context menus for control and what not. Opinions? Disabling the auto-wrapped rendering in the composer is a good thing as well, IMHO. My preference is going this complex-but-IMHO-more-correct route rather than adding a custom mode to the composer which shows each special whitespace char using its Unicode rendering equivalent.
(In reply to Pali Rohár from comment #8) > Another suggestion: Monospaced font in compose window indicate that > written email/text is probably unformatted resp. preformatted. No. :-P 1. "probably" means just more confusion 2. everyone has the right to demand writing/using monospace or whatever font s/he wishes - even if I don't put patches inline (what is, to repeat myself, sick) I often type code snippets, function bodies etc.
On Monday 17 August 2015 09:07:51 Jan Kundrát wrote: > https://bugs.kde.org/show_bug.cgi?id=351354 > > --- Comment #9 from Jan Kundrát <jkt@kde.org> --- > I talked about this with Pali in private as well. I'll be happy to accept a > patch which disables auto wrapping in the composer. The other bug with pasted > text whose lines end up with a space being flowed together is a real bug which > should be fixed, too. > To be honest I would like to have option to compose emails with wrapped lines at specified width. > What I very strongly object to is calling format=flowed an evil thing > (especially without providing any specific examples of how exactly these things > have become evil). Reason is very bad support across different email clients (e.g. popular Thunderbird) and also web mail clients (e.g. very popular GMail). They do not implement format=flowed correctly. Another reason is that format=flowed is not backward compatible with text/plain. Chars like '>' and ' ' are special meanings. And because of that you are not able to generate preformatted text/plain emails. > I also dislike the idea of a toggle for disabling > format=flowed when replying to non-flowed mails because the end result is going > to be a universe where a single non-flowing client effectively disables flowing > in all replies. > And I dislike emails where quoted parts are hard-wrapped at 72 chars and reply to that quoted parts are wrapped as email client wants. I'm not the only one for who these emails look ugly. And also I dislike if some software (=email client) is trying to be more intelligent as user who use it. If I write monospaced plain/text email, I would expect that it is monospaced plain/text. But we can continue in this subjective discussion... There are 3 ways how we can finish it: 1) Trojita will support only your subjective use-case 2) Trojita will support only my subjective use-case 3) Trojita will support both our both subjective use-cases via config option in either compose window or settings dialog. As I already expressed my feelings and problems with format=flowed I will not use any email client which forbid me to compose text/plain email. > A special note about LKML -- the way I understand their workflow, they appear > to strongly favor sending patches inline rather than Content-Disposition: > inline. That's of course broken (one cannot even easily save such a patch into > a file because well, It is possible and it is easy: copy and paste. > it's a part of a longer text with unrelated stuff, unless > of course the entire body of your mail is in fact a patch, which then works by > definition, but... > And basically yes. Lines which do not start with +/- are comments in patch file. So you use whole email (with all headers!) as patch file. And this is standard feature of git. It generate rfc2822 email from commit and can apply email into git repository as commit. > Anyway, this is what Linus allegedly said in a LKML FAQ: > > > If I get a patch in an attachment (other than a "Text/PLAIN" type > > attachment with no mangling and that pretty much all mail readers and > > all tools will see as a normal body), I simply WILL NOT apply it unless > > I have strong reason to. I usually wont even bother looking at it, > > unless I expected something special from the sender. > > > > Really. Don't send patches as attachments. > > > > Linus > > To me, these two parts don't really fit into each other Where is problem? > (what does Linus call an attachment, exactly?), Email which contains multipart MIME part. > but I don't really care anymore at this point. Then you basically do not care about anybody in linux kernel development and also in other projects which have similar preferences. You can say that Trojita wont support such projects, because subjective point of view is different as subjective point of view of those projects. > It's > also interesting that the FAQ happens to recommend Mozilla users to use > attachments :): > > > A caveat applies for people using a Mozilla Mail client. Andrew Morton noted that Mozilla mangles > > spaces in column zero when patches are included in the message body. Fortunately, Mozilla Mail > > sends patch attachments as type text/plain or text/x-patch (depending on the presence of a file > > extension), so it's safe to send patches as attachments instead. > > That said, I see the value of being able to paste large chunks of preformatted > stuff, such as code examples, into format=flowed e-mails. I can see that this > is useful, and format=flowed supports such a mode just fine. > And then there are incompatibility with clean text/plain emails. It is not possible to generate such email which will be compatible with both format=flowed and clean text/plain (without format=flowed). > I think that a proper™ solution to this problem is teaching the composer to > keep track of flowed vs. unflowed text on a per-paragraph basis. IIRC there's a > QTextDocument underneath and it supports (some more or less complicated) way of > adding custom properties to text paragraphs. Perhaps it would make some sense > to keep track of the is-flowed-enabled property for each of them, and to > reflect that in the UI. This will also solve the problem of "> quoted text" > quite neatly > (yes, that "evil" format=flowed enables you to start lines with > ">" and to not mark them as a quotation) I know that, I read RFC 3676. It is great that something like that somebody wrote on paper (err. into RFC), but using technology which is broken by lot of other popular (web) clients is not solution. > if we add another property for that > thing. We could even provide some UI clues to the user, with,. say, a different > color of the quoted text, and a different background color for non-flowed and > therefore preformatted text chunks, with context menus for control and what > not. Opinions? > > Disabling the auto-wrapped rendering in the composer is a good thing as well, > IMHO. > > My preference is going this complex-but-IMHO-more-correct route rather than > adding a custom mode to the composer which shows each special whitespace char > using its Unicode rendering equivalent. >
(In reply to Pali Rohár from comment #11) > To be honest I would like to have option to compose emails with wrapped > lines at specified width. I do not understand any technical rationale behind this. Trying to work around alleged crappiness of other software is something which can be better addressed by other means (see my earlier replies). > > What I very strongly object to is calling format=flowed an evil thing > > (especially without providing any specific examples of how exactly these things > > have become evil). > > Reason is very bad support across different email clients (e.g. popular > Thunderbird) and also web mail clients (e.g. very popular GMail). They > do not implement format=flowed correctly. I've asked you a couple of times for specific, accurate examples. Please show us the data, not your impression that "it's broken", because that won't get you anywhere. Screenshots with a description on why their content sucks are preferred by me here. > Another reason is that format=flowed is not backward compatible with > text/plain. Chars like '>' and ' ' are special meanings. And because of > that you are not able to generate preformatted text/plain emails. That description is incorrect. There is a limitation in the current version of Trojita where entering these characters into the composer at a specific point within a paragraph triggers this problem. This bug is addressed by my proposal in comment #9. The reason for why the bug still exists is a lack of time combined with the fact that I haven't produced content which triggers this bug in the past three years or so. Was I composing LKML patches in Trojita, I can imagine that these would have been fixed already. Patches are welcome. > And I dislike emails where quoted parts are hard-wrapped at 72 chars and > reply to that quoted parts are wrapped as email client wants. > > I'm not the only one for who these emails look ugly. Ask the guys who send you these e-mails to send using format=flowed, then. I understand your point. Your preference is to not mix flowed and non-flowed e-mail for aesthetic reasons. My preference is to mix them because I tend to focus on the new, unquoted part, and having auto wrapping in there at render time is a benefit for my aesthetic perception. Your proposal effectively undoes format=flowed benefits for everyone as long as there's a single non-flowed user. That's not something which I would like Trojita to do. > And also I dislike if some software (=email client) is trying to be more > intelligent as user who use it. If I write monospaced plain/text email, > I would expect that it is monospaced plain/text. Press the Enter key within the composer to activate manual line breaks, then. I've already told you a couple of times that I'll be happy to accept a patch which disables auto-wrapped rendering in the composer because you have a point here. I do not disagree with you in that one -- this auto-wrapped appearance within the renderer can indeed be misleading. I also think that this patch could have been written, tested and merged during the time we spent arguing about this. Could you please submit it? :) > 1) Trojita will support only your subjective use-case > 2) Trojita will support only my subjective use-case > 3) Trojita will support both our both subjective use-cases via config > option in either compose window or settings dialog. I've provided a couple of points on why 3) is wrong. > > A special note about LKML -- the way I understand their workflow, they appear > > to strongly favor sending patches inline rather than Content-Disposition: > > inline. That's of course broken (one cannot even easily save such a patch into > > a file because well, > > It is possible and it is easy: copy and paste. That sounds like one extra manual step compared to the obvious route: "Save". I quite frankly do not understand why copy-paste is allegedly easier. The same LKML FAQ also discourages using, say, base64 Content-Transfer-Encoding. That's at level 11 on my personal insanity scale, to use a Linus-ish term. > And basically yes. Lines which do not start with +/- are comments in > patch file. So you use whole email (with all headers!) as patch file. > > And this is standard feature of git. It generate rfc2822 email from > commit and can apply email into git repository as commit. I'm aware of that feature of git. Why do you want to use Trojita for sending these e-mails when you have git send-email, though? > > > If I get a patch in an attachment (other than a "Text/PLAIN" type > > > attachment with no mangling and that pretty much all mail readers and > > > all tools will see as a normal body), I simply WILL NOT apply it unless > > > I have strong reason to. I usually wont even bother looking at it, > > > unless I expected something special from the sender. > > > > > > Really. Don't send patches as attachments. > > > > > > Linus > > > > To me, these two parts don't really fit into each other > > Where is problem? "don't send patches as attachments" vs. "incline patches as a separate MIME part are OK". For the record, the thing which Linus accepts and that I happen to like is exactly how `git format-patch --inline` works. > > (what does Linus call an attachment, exactly?), > > Email which contains multipart MIME part. And that's where I disagree with him. IMHO, a reasonable way of sending e-mails with patches is this one: + Content-Type: multipart/mixed + Content-Type: text/plain; format=flowed - this is the part where you describe your patch + Content-Type: text/x-patch Content-Disposition: inline; filename=0001-foo-bar.patch - this is the thing which gets shown inline (except on gmail's web interface, sure) and allows quoting and replying as you wish > > but I don't really care anymore at this point. > > Then you basically do not care about anybody in linux kernel development > and also in other projects which have similar preferences. > > You can say that Trojita wont support such projects, because subjective > point of view is different as subjective point of view of those > projects. If you're sending unmodified patches as provided by git send-email or git-format-patch or how exactly is that tool called, I quite frankly do not understand why you want Trojita to send these patches through. Could you please clarify when Trojita enters this picture? As you probably know, I'm not on LKML and I don't participate in the kernel development, so I might be missing something utterly obvious. Please educate me on that. > And then there are incompatibility with clean text/plain emails. It is > not possible to generate such email which will be compatible with both > format=flowed and clean text/plain (without format=flowed). What problems and incompatibilities are these? Are you referring to the fact that a "Content-Type: text/plain; format=flowed; delsp=yes" cannot be literally pasted from a client which is not aware of format-flowed in case the patch includes lines which start with a space? Where do you intend to draw the line while still conforming to various RFCs which mandate certain line lenghts? Are various CTEs OK? Is quoted-printable OK but base64 not OK for some reason? Why is format=flowed different, in case my understanding of your motivation is correct? > I know that, I read RFC 3676. It is great that something like that > somebody wrote on paper (err. into RFC), but using technology which is > broken by lot of other popular (web) clients is not solution. Please provide a model and the intended use case of the features and feature removals that you're proposing. Note that it's hard to argue for LKML-style workflow *and* for supporting inferior webmails at the same time; even the LKML FAQ acknowledges that. In other words, please describe how exactly you want to use Trojita, and what end results do you expect to see in various clients. Please be descriptive and go into details -- if you want to, for example, copy-paste from GMail's web interface straight to your `git am`, include that expectation in your description. If you fancy a copy-paste from `git diff` right to Trojita's composer, say so as well.
On Monday 17 August 2015 11:45:22 Jan Kundrát wrote: > In other words, please describe how exactly you want to use Trojita, and what > end results do you expect to see in various clients. Allow to (somehow) compose text/plain email without format=flowed. Ideally with ability (for me) to enable/disable hard line wrap at 72 chars. This ability allows me to do basically anything with patches, code, external preformatted text without worrying about damaging preformatted contents. End result would be Utf-8 encoded email with 8-bit transfer encoding (or some QP/BASE64 fallback if SMTP is not 8bit capable) with one text/plain MIME part which is not format=flowed.
(In reply to Pali Rohár from comment #13) > Allow to (somehow) compose text/plain email without format=flowed. You're describing your expectation of a proper way towards achieving a certain goal. Thank you for that, but I asked about the end goal.
> --- Comment #14 from Jan Kundrát <jkt@kde.org> --- > (In reply to Pali Rohár from comment #13) > > Allow to (somehow) compose text/plain email without format=flowed. > > You're describing your expectation of a proper way towards achieving a certain > goal. Thank you for that, but I asked about the end goal. > 1) Allow to paste preformatted parts outside of composer. 2) Allow to write such text as in 1) directly in composer (e.g parts of code in some programming language, etc). 1) and 2) should be visible same in all email clients which support properly format=flowed and in email clients which do not support it but does not change structure of text/plain message (after decoding). 3) Allow to wrap text under quoted parts in same way how are wrapped quoted parts. If replaying to email which was without format=flowed, write reply without format=flowed too. 4) Allow to write full email as "verbatim" (no format=flowed) when I know that receiver does not support format=flowed (or when receiver has no-format=flowed policy).
(In reply to Pali Rohár from comment #15) > 1) Allow to paste preformatted parts outside of composer. This is what the solution suggested in comment #9 supports. > 2) Allow to write such text as in 1) directly in composer (e.g parts of > code in some programming language, etc). Also supported by the plan given in comment #9. > 1) and 2) should be visible same in all email clients which support > properly format=flowed and in email clients which do not support it but > does not change structure of text/plain message (after decoding). Sure thing. > 3) Allow to wrap text under quoted parts in same way how are wrapped > quoted parts. If replaying to email which was without format=flowed, > write reply without format=flowed too. I find this actively harmful. I will reject patches which disable format=flowed when responding to non-flowed e-mails for reasons stated in earlier comments and during our private conversation ("it takes just one inferior client to disable format=flowed in an entire thread"). > 4) Allow to write full email as "verbatim" (no format=flowed) when I > know that receiver does not support format=flowed (or when receiver > has no-format=flowed policy). What do you plan to use this for? Anyway, I think this is also something that is covered by the solution proposed in comment #9. Now that we have a reasonable solution, do we also have volunteers willing to implement it?
On Monday 17 August 2015 12:45:29 Jan Kundrát wrote: > https://bugs.kde.org/show_bug.cgi?id=351354 > > --- Comment #16 from Jan Kundrát <jkt@kde.org> --- > (In reply to Pali Rohár from comment #15) > > 1) Allow to paste preformatted parts outside of composer. > > This is what the solution suggested in comment #9 supports. > > > 2) Allow to write such text as in 1) directly in composer (e.g parts of > > code in some programming language, etc). > > Also supported by the plan given in comment #9. > > > 1) and 2) should be visible same in all email clients which support > > properly format=flowed and in email clients which do not support it but > > does not change structure of text/plain message (after decoding). > > Sure thing. > > > 3) Allow to wrap text under quoted parts in same way how are wrapped > > quoted parts. If replaying to email which was without format=flowed, > > write reply without format=flowed too. > > I find this actively harmful. I will reject patches which disable format=flowed > when responding to non-flowed e-mails for reasons stated in earlier comments > and during our private conversation ("it takes just one inferior client to > disable format=flowed in an entire thread"). > In personal 1 vs 1 conversation I do not see any reason to send email which other side cannot decode and interpret fully. As I subjectively wrote such emails are ugly, for some receivers looks ugly too and I for me it is rude to send such ugly emails. > > 4) Allow to write full email as "verbatim" (no format=flowed) when I > > know that receiver does not support format=flowed (or when receiver > > has no-format=flowed policy). > > What do you plan to use this for? Send emails to mailing list where they do not accept flowed emails. Like LKML. > Anyway, I think this is also something that > is covered by the solution proposed in comment #9. > > Now that we have a reasonable solution, do we also have volunteers willing to > implement it? >
> In personal 1 vs 1 conversation I do not see any reason to send email > which other side cannot decode and interpret fully. As I subjectively > wrote such emails are ugly, for some receivers looks ugly too and I for > me it is rude to send such ugly emails. Fair enough, so press the Enter key when you want to hard-wrap your content. That's the price which a user is going to pay for not using a feature whose only downside is different width of paragraphs on long screens when replying to messages authored by ooooooold clients. I do not want to provide tools for, er, our valued users who have just taken the mental shortcut "flowed = evil" to make my life harder, sorry. I find that opinion uninformed to say the least. >>> 4) Allow to write full email as "verbatim" (no format=flowed) when I >>> know that receiver does not support format=flowed (or when receiver >>> has no-format=flowed policy). >> >> What do you plan to use this for? > > Send emails to mailing list where they do not accept flowed emails. > Like LKML. I don't see any relevant blacklist of format=flowed at http://vger.kernel.org/majordomo-taboos.txt . Sadly, I also don't see a LKML archive of raw data, so I cannot grep for that myself. We've already established that they reject *patches* pasted by clients which reflow them. That's very different from "not accepting flowed emails". Sure thing, patches should *not* be flowed, but please note that it's perfectly fine to have a single-MIME-part message using format=flowed which contains some flowed text and some non-flowed text (such as a pasted patch), which is obviously *not* subject to any flowing. Could you please confirm that you fully understand this point?
For example you have simple patch file which has line: "+word " or line " word ". Both has special meaning in format=flowed and both are differently formatted in text/plain and format=flowed.
> For example you have simple patch file which has line: "+word " or line > " word ". Both has special meaning in format=flowed and both are > differently formatted in text/plain and format=flowed. ...and hence a compliant client (which Trojita is not at this point, composer-wise, see comment #9 for a proposal to make it compliant) will use proper escaping when serializing such data. The generated content will be correct and safe, and no unicorns will be harmed in the process. Where is the problem? Or are you referring to a hypothetical MUA which manages to mangle RFC3676 *decoding* so that it preserves the extra spaces inserted by delsp=yes, yet is going to somehow be used for applying patches to git, possibly by a copy-paste? Like, seriously?
Problem is that flowed escaping is not same as clean text/plain. Also if you insert extra spaces at begining of line, these space is ignored in flowed format, but not in non flowed format. So all tools which do not understand flowed format (e.g. unix patch or git am) cannot parse that email.
> Problem is that flowed escaping is not same as clean text/plain. Also if you > insert extra spaces at begining of line, these space is ignored in flowed > format, but not in non flowed format. So all tools which do not understand > flowed format (e.g. unix patch or git am) cannot parse that email. Thanks for clarifying this. The problem is apparently that you want to pipe the e-mail as-is to `patch` or `git am`. You're right that the solution described in comment #9 only supports patch copy-pasting, not saving the entire mail body and using *that* as a patch body. On the other hand, how do you plan to, say, patch files with long lines where quoted-printable CTE typically kicks in due to ESMTP line length limits? Does git-am support that thing? My solution for this is using inline attachments, of course (Content-Disposition: inline). I suppose that extending git-am to accept format=flowed and especially to undo delsp=yes should be a no-brainer as well.
(In reply to Jan Kundrát from comment #22) > > Problem is that flowed escaping is not same as clean text/plain. Also if you > > insert extra spaces at begining of line, these space is ignored in flowed > > format, but not in non flowed format. So all tools which do not understand > > flowed format (e.g. unix patch or git am) cannot parse that email. > > Thanks for clarifying this. The problem is apparently that you want to pipe > the e-mail as-is to `patch` or `git am`. This is typical way how kernel developers work with patches (via mutt). > You're right that the solution > described in comment #9 only supports patch copy-pasting, not saving the > entire mail body and using *that* as a patch body. On the other hand, how > do you plan to, say, patch files with long lines where quoted-printable CTE > typically kicks in due to ESMTP line length limits? Does git-am support > that thing? > Problem is that if you use email client which supports quoted-printable or base64 but does not support format=flowed, then also copy+paste will not work. And yes, git-am cannot handle QP nor base64, nor multipart emails. > My solution for this is using inline attachments, of course > (Content-Disposition: inline). I suppose that extending git-am to accept > format=flowed and especially to undo delsp=yes should be a no-brainer as > well. This question is for git developers, not for me. Also there are machines and env where is older version of git, so even if there will be patch for git-am to support such operation it will take ages until everybody upgrade their git (I have only 1.7 in my distro).
You have yet to explain *why* you want to paste or otherwise insert your LKML patch through a graphical MUA. Why don't you use inline attachments, something which works well enough already? Alternatively, if your target audience has some MIME-triggered fobia and if you're happy with your CLI tools which you use for your workflow, why don't you just use them for that final step as well? DUmbing down the composer with a non-feature just to support an archaic workflow which is *not* the only LKML-favored workflow anyway doesn't make much sense to me. > This is typical way how kernel developers work with patches (via mutt). I have no idea how kernel developers work in real world, but I observe that an inline attachment solves each and every objection you raised so far. In Trojita, it's done by right-clicking in the context menu of a freshly added patch. It's also a method which is allowed in the LKML FAQ I read, so I don't really understand your resistance here. > Problem is that if you use email client which supports quoted-printable or > base64 but does not support format=flowed, then also copy+paste > will not work. Sure. Use an e-mail client which doesn't suck, then -- there's plenty of such stuff out there. Even Mutt qualifies, based on a random FAQ I checked. You found a corner case where things break for some users on ancient tooling which refuse to upgrade stuff. That's how the world works, now let's move on -- it won't really stop the progress anyway. > And yes, git-am cannot handle QP nor base64, nor multipart emails. Seems that one cannot use git-am in the way you describe it's allegedly used, then. > This question is for git developers, not for me. Also there are machines and > env where is older version of git, so even if there will be > patch for git-am to support such operation it will take ages until everybody > upgrade their git (I have only 1.7 in my distro). If it doesn't even support base64 or quoted-printable CTEs, then there's no point in adding format=flowed, either. If someone relies on piping raw data without CTEs being undone, they are counting on sheer luck, and they are also using square pegs to fit round holes. That's an abuse of text/plain which many people learned the hard way. To make this bikeshedding more productive -- are you going to submit a patch which implements stuff described in comment #9, and are you going to submit a patch which turns off wrapped rendering in the composer?
I want to use one email client for doing all operations with emails (receive, send). And I do not like idea to configure every one tool to work properly with email servers, etc... So instead using git send-email I would like to copy+paste content into email client and sent it. Why not to use inline attachments? Those are just parts of multipart with Content-Disposition: inline, right? Just because is is multipart. Maintainers of some kernel subsystem do not like those inlined attachments, so sometimes is good idea to avoid them. And currently I do not have time hack composer code to fix comment #9...
> I want to use one email client for doing all operations with > emails (receive, > send). And I do not like idea to configure every one tool to > work properly with > email servers, etc... So instead using git send-email I would like to > copy+paste content into email client and sent it. Fair enough. So please write a patch which accepts the ready-made e-mail body on stdin, and let Trojita handle the actual submission but *not* the preparation of the MIME structure. This will likely require some refactoring of the MessageComposer to make it an abstract class, with one implementation using the existing stuff for actual composition, and the other one for just a class which provides the raw MIME data. You might want to work with Karan because he's interested in message bouncing, which effectively leads to a very similar problem. > Why not to use inline attachments? Those are just parts of multipart with > Content-Disposition: inline, right? Right. > Just because is is multipart. Maintainers > of some kernel subsystem do not like those inlined attachments, > so sometimes is good idea to avoid them. I wonder what their technical reasons are, except for a knee-jerk "it's evil" which I've seen so far. Also, [citation needed].
Reason is just ability to pipe email into git am or git apply magic script. For some developers it takes lot of time if they need to manually inspect emails, decode MIME parts, quote-printable (or base64)...
(In reply to Jan Kundrát from comment #9) > The other bug with pasted text whose lines end up with a space being flowed together is a > real bug which should be fixed, too. I'm not even sure whether it's a bug per se - we don't know why there's a trailing space (most text editors offer to auto-remove them and reviewboard highlights them red...) We also cannot just strip the trailing spaces from the paste (in case they're there for a purpose), nor tag such textblock as non-flowed (what do we do if the user edits such block, what if he removes one of those trailing spaces but leaves the others) Pali has a point in that using regular input as control bytes was not necessarily an ideal approach in the format. At least it's prone to cause such ambiguity. > What I very strongly object to is calling format=flowed an evil thing The rule I created after hundreds of bug reports: "We deal the bug, not the user" Bugreports are valuable as problem indicators, but if you don't learn to completely ignore the particular reporter, his habits, mood, terms, ... you can easily get frustrated. > I also dislike the idea of a toggle for disabling format=flowed when replying to non-flowed > mails because the end result is going to be a universe where a single non-flowing client > effectively disables flowing in all replies. I completely agree that notably quitting format=flowed for one non-flowed reply is a bad idea. This may work in a bilateral communication, but even then - being forced to use a webmailer only once during a longer discussion breaks flowing for hardly a reason. Let alone the multilateral communication case. Neither do I frankly buy the "non-flowed short quotes in too long unflowed text is ugly" argument, as it's fixable in the renderer (by limiting the width and/or indenting/rightaligning quote blocks) I do however not fundamentally oppose the idea of a way to submit mails verbatim, ie. abuse the body as text attachment. It doesn't cost too much to bypass text processing and there's apparently a use case for it (no matter how stupid it is - so are tax declarations, but you don't get around them ;-) The question is, given one buys such feature, how to provide access to this. The rule of thumb is: "the more exotic, the more stashed the access", ie. context menu. > That said, I see the value of being able to paste large chunks of > preformatted stuff, such as code examples, into format=flowed e-mails. I can > see that this is useful, and format=flowed supports such a mode just fine. I fear Pali's problem is that the other side doesn't support format=flowed, so that's not a solution to his problem (if it would, we'd probably not be here) - the recipient fails on space stuffing as well as static wrapping (trailing space or not) > I think that a proper™ solution to this problem is teaching the composer to > keep track of flowed vs. unflowed text on a per-paragraph basis. IIRC > there's a QTextDocument underneath and it supports (some more or less > complicated) way of adding custom properties to text paragraphs. You can add random data by subclassing QTextBlockUserData and set that. I think the bigger problem will be to "keep track" - editing the block (or some lines) would implicitly change the nature of the lines - this is gone if the nature is stored explicitly. We'd have to add a GUI to select the type... and confront the user with the format internals :-\ Ultimately, with static wrapping gone from the editor everything should be fine in this area: The user will notice "true" newlines by the behavior on window resizes. One could in addition visualize either newlines or dynamic word wraps (like many code editors do) What should *not* happen is that an explicit newline gets flowed because there a trailing space in front of it. The user ("now") edits dynamically wrapped text, he can expect newlines to be handled as such. (This aside the issue that even a useful block tracking would not suit Pali's usecase which I believe mandates a verbatim mode - regardless of what one thinks about the workflow that triggered this. The linked lkml advises point towards "no flow, no whitespace manipulation, *no static wrap*, eg. by advising to set the max line length to 0)
(In reply to Thomas Lübking from comment #28) > We also cannot just strip the trailing spaces from the paste (in case > they're there for a purpose), nor tag such textblock as non-flowed (what do > we do if the user edits such block, what if he removes one of those trailing > spaces but leaves the others) Right now, the composer leaks an implementation detail ("line ending up with a space") with the decision on whether to flow or not. That's a bug because a space at the end of the line is a legitimate thing which a person might want to include for some mysterious reason. That's why I suggested to decouple the flowed-or-nonflowed state of a paragraph into a special QTextBlockWhatever property, and to properly escape these spaces in all cases. > Pali has a point in that using regular input as control bytes was not > necessarily an ideal approach in the format. At least it's prone to cause > such ambiguity. Let's distinguish "stuff that the user writes" and "serialization on the wire". I want to allow our user to write anything whatsoever into Trojita's composer without triggering any "magic" such as flowed lines or quotation markings. The idea is that the status bits ("is this a quotation, and how deep", "this is a flowed thing") are manipulated explicitly, perhaps by a tool button right next to the text field. These bits will get converted to spaces and ">"s only when producing the resulting message. > Neither do I frankly buy the "non-flowed short quotes in too long unflowed > text is ugly" argument, as it's fixable in the renderer (by limiting the > width Yes, we should probably do this, too. I understand that this only applies to people who use the classic screen layout (message pane at the bottom) because the three-column wide layout which I've been using for years makes it unlikely for me to use overly wide MessageView widgets. > and/or indenting/rightaligning quote blocks) ? > I do however not fundamentally oppose the idea of a way to submit mails > verbatim, ie. abuse the body as text attachment. It doesn't cost too much to > bypass text processing and there's apparently a use case for it (no matter > how stupid it is - so are tax declarations, but you don't get around them ;-) Nobody sends me tax declarations, though. I do not like the idea of letting confused people send me garbage through Trojita. That's actually the core of my resistance here; I see a workaround being proposed which hacks around a problem. What I would like to implement is something which solve the root cause of the problem while preserving all benefits of format=flowed. > I think the bigger problem will be to "keep track" - editing the block (or > some lines) would implicitly change the nature of the lines - this is gone > if the nature is stored explicitly. > We'd have to add a GUI to select the type... and confront the user with the > format internals :-\ I don't follow -- let's show all non-flowed text with a dark background, and all quotes in blue text, and we're set. Yup, with explicit buttons for manipulating the state. > One could in addition visualize either newlines or dynamic word wraps (like > many code editors do) As an optional feature, why not. > What should *not* happen is that an explicit newline gets flowed because > there a trailing space in front of it. The user ("now") edits dynamically > wrapped text, he can expect newlines to be handled as such. +1 > (This aside the issue that even a useful block tracking would not suit > Pali's usecase which I believe mandates a verbatim mode - regardless of what > one thinks about the workflow that triggered this. The linked lkml advises > point towards "no flow, no whitespace manipulation, *no static wrap*, eg. by > advising to set the max line length to 0) The suggestions given in the FAQ are instructions on how to configure legacy clients to do "The Perceived Right Thing". I haven't noticed any claim like "oh, but I'm using this specific sequence of commands foo and bar on distro baz from 1996 for these and these reasons, and baz breaks on format=flowed". There was just hand-waving about "some people dislike them" and "stuff might break", while I pointed out that stuff is broken *anyway* because of innocent stuff like the Content-Transfer-Encoding which any MTA is free to change on its whim, by the way. That's what I call that "being misinformed" :(.
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.
Trojitá is no longer maintained, please switch to a maintained alternative like https://apps.kde.org/kmail2/ Sorry for the inconveniences.