Thanks for a bug report. I suppose this is covered by bug #481915, simply reply to the currently viewed format.

Sorry I missed the the previous bug(s). We all have different ways of phrasing things so they sometimes escape our notice. This case is simplier than the mixed format scenarios and might be handled by dealing with it. I suspect simply replying in the viewed format would address somewhere between 75-90% of the issue.

However, one might go further to allow users to set up a list of exceptions to the overall format that has been set. So, my business e-mails and most personal ones arrive in HTML -- and my outgoing messages in such cases, whether replies or new -- are in HTML. However, I am on serveral user lists and a couple of dev lists where plain text is the norm. If a user is originating a message (as opposed to replying), it would be great if Evo checked his/her "exceptions" list of addresses to see if the the "non-default" format should be used.

Not pretending to be a developer or programmer, I cannot say if this is the way to go -- or worth the processing power and time involved. Furthermore even I can anticipate certain problems. If one starts with the recipient first, under the scheme outlined, Evo would check the address and adjust the formatting accordingly (or present a dialog box). Even though starting there routinely, I also know that it is better NOT to start with the recipient to prevent inadvertently sending the message before complete or sending it to the wrong person. What if I add an address which would normally require the alternate format? What happens if there are multiple addresses, some HTML-associated, some plain? Does Evo default to plain or default -- or does it somehow split the message in two so that some get plain, some HTML? (Sorry if some of this is getting nightmarish, but I thought some thinking aloud might help.)

Yeah, that's the main thing. One can find just too many "corner" cases where the change  might not work as expected and cause disappointment and/or confusion to users. Thus better to keep things simple.

The currently implemented things:

a) Edit->Preferences->Composer Preferences->Format messages in HTML, this sets
   the default composer open mode (if checked then it's HTML, otherwise Plain)

b) if you autocomplete the contacts, then evolution checks whether the contact
   has set "Wants to receive HTML mail". It warns on send when you try to send
   an HTML mail to persons which do not want it. This doesn't work without
   the autocompletion (which is the case for replies too).

What might be done:

c) bug #481915

d) set preferred send format per folder, similar to Send Account Override,
   then starting a new message or reply in certain folder would compose
   the message in that overridden format; this way it'll make it free of
   the prerequisite of having filled the recipient first

The idea of asking to change the format after a recipient is filled, not talking about multiple recipients, doesn't look like a good idea to me - Evolution shouldn't bother users that much. Furthermore, the check is done on send, within the b) above, which is sufficient.

What do you think?

Sorry for not responding earlier as I first saw this when I was in "cleanup" mode after being off line for a couple of days.

I agree about Evo bugging to much. There are far too many programs asking "Really? Are you absolutely sure?", which not only annoy but produce counterproductive results as one learns to say "yes" automatically. Tying format to folders not only gets around the potential "desired format" conflicts between two recipients, it even provides another incentive to organize folders. 

However, one question: Why does Evo only check when doing the autocomplete -- and how does it deal with multiple recipients with different format preferences? Unless I misunderstand, this suggests that there is already a routine that could be generalized to check all messages.

(In reply to waterbearer54 from comment #4)
> However, one question: Why does Evo only check when doing the autocomplete
> -- and how does it deal with multiple recipients with different format
> preferences?

Autocompletion is a problem, a time-consuming task, which can take quite long with remote servers, which can have lag issues or similar. What I meant above was that the "Wants HTML" option is checked when sending the message, but only for those recipients, whom had been already autocompleted, thus those for which the information is available. For example when you reply, the recipients are not auto-completed.

> Unless I misunderstand, this suggests that there is already a
> routine that could be generalized to check all messages.

I suppose you mean "all recipients", not "all messages". Having a separate list of recipients for reply style format doesn't seem good to me. There are similar lists in evolution, that's true, still adding another one might not work well in this case.

The thing is that what you want is a three-state option on the recipient (existing contact), of values: "prefers HTML", "prefers Plain text", "doesn't care of the message format". Then what might be done is to try to autocomplete each recipient on reply first (count with the lag from the servers and so on), check whether all recipients are fine with the given format and if not then either ask of set the right one.

It doesn't sound only complicated, but also easy to break and cause delays on message reply.

My question arose from a misunderstanding of what you meant by autocomplete. Furthermore, I agree that anything that involves too many resources (much less being easy to break) should be avoided.

Isn't the folder-based approach you proposed a reasonable option? It accomplishes most of what I think I had in mind (and which grew out of an exchange on the users listserv).

(In reply to waterbearer54 from comment #6)
> Isn't the folder-based approach you proposed a reasonable option? It
> accomplishes most of what I think I had in mind (and which grew out of an
> exchange on the users listserv).

Possibly yes. Having the reply style/message format per folder is not that expensive to get as search all the configured address books for recipients and so on.