Re: [MlMt] I don't expect support soon, but, heads up. (Yosemite)
On 6 Jun 2014, at 18:08, Benny Kjær Nielsen wrote: On 6 Jun 2014, at 18:07, Sherif Soliman wrote: On 6 Jun 2014, at 9:32, Benny Kjær Nielsen wrote: defaults write com.freron.MailMate MmAutomaticUnwrapEnabled -bool YES I downloaded the latest test version and set the preference using the command you included above. As far as I can tell, the behaviour is still the same as before. Just to make sure, did you relaunch MailMate after changing the preference? (I forgot to note that.) Yes, several times. I quit MailMate, changed the preference, then relaunched. Sherif ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] I don't expect support soon, but, heads up. (Yosemite)
On 6 Jun 2014, at 18:07, Sherif Soliman wrote: On 6 Jun 2014, at 9:32, Benny Kjær Nielsen wrote: defaults write com.freron.MailMate MmAutomaticUnwrapEnabled -bool YES I downloaded the latest test version and set the preference using the command you included above. As far as I can tell, the behaviour is still the same as before. Just to make sure, did you relaunch MailMate after changing the preference? (I forgot to note that.) -- Benny ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
[MlMt] gmail folder's names
i use two gmail accounts with mailmate (and a real IMAP account). i noticed one of the google accounts have folders names as "usual", say [Gmail]/Archive, [Gmail]/Trash etc, but the other account (several years older) have folders like [Google Mail]/Archive, [Google Mail]/Trash etc. anyone knows why? it doesn't bother me, but i'm curious how it came to be like this, [Gmail] vs [Google Mail] folder names... paula ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] I don't expect support soon, but, heads up. (Yosemite)
On 6 Jun 2014, at 9:32, Benny Kjær Nielsen wrote: On 6 Jun 2014, at 13:40, Benny Kjær Nielsen wrote: * Heuristically unwrap the plain text body part. Problem: Some times MailMate is going to unwrap something which shouldn't have been unwrapped. To learn more I've implemented this variant in the latest test version. Enable it like this: defaults write com.freron.MailMate MmAutomaticUnwrapEnabled -bool YES The current strategy is as follows: * Only merge non-empty unquoted lines. * Only merge two lines if the first line is at least 60 bytes long. * Only merge lines if the last character of the previous line is whitespace, letter/number or a comma. I'm probably most interested in knowing if it fails so often that it's useless. Hi Benny, I downloaded the latest test version and set the preference using the command you included above. As far as I can tell, the behaviour is still the same as before. Hitting Command + R on a long message from a Gmail account opens the quoted text in the composer hard-wrapped to a line-width shorter than the width of the window, and not changing with window resizing. I really do appreciate you trying to find a workaround for this. Even if it's eventually not perfect, I'll take it. Sherif ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] I don't expect support soon, but, heads up. (Yosemite)
On 6 Jun 2014, at 13:40, Benny Kjær Nielsen wrote: * Heuristically unwrap the plain text body part. Problem: Some times MailMate is going to unwrap something which shouldn't have been unwrapped. To learn more I've implemented this variant in the latest test version. Enable it like this: defaults write com.freron.MailMate MmAutomaticUnwrapEnabled -bool YES The current strategy is as follows: * Only merge non-empty unquoted lines. * Only merge two lines if the first line is at least 60 bytes long. * Only merge lines if the last character of the previous line is whitespace, letter/number or a comma. I'm probably most interested in knowing if it fails so often that it's useless. -- Benny ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] I don't expect support soon, but, heads up. (Yosemite)
On 5 Jun 2014, at 16:47, Sherif Soliman wrote: I had to pull the test version. The fix has broken the display of plain text messages on Mavericks for several users. It works for me though and I haven't yet figured out what makes it fail for other users, but I'm looking into it. If this is going to prompt a rewriting of the decoding and re/deflowing scripts, It didn't :-) I'd like to bring up something I think I did once in the past. Replying to some emails (I think mostly ones sent from Gmail accounts) always changes the text from flowing until it finds a newline character to being hard wrapped to a certain line width. As in, it introduces newline chars to make lines and paragraphs a lot shorter than what the window width would make them, and they do not wrap around as I resize the window. This also remains the case after the reply is sent and I look at the reply message in browser. (I wanted to attach a screenshot, but Distortion mode doesn't distort email body content apparently). I think Benny said that it was specific to replies to messages from a Gmail account. A proposed workaround was to select all the text and then reply, which for some reason did reflow the text as one would want/expect. However, that workaround is a hassle, and it introduces strange added empty lines/newline characters. That strangeness is exactly why it's not the default behavior. The problem is that Gmail messages hard-wrap the plain text body part of a message. Every HTML message must have an equivalent plain text body part. This is what is used by MailMate when replying, because handling HTML is, in general, an error-prone heuristic game which is hard to win. Note that when a user tells Gmail to send plain text only then the message is still hard-wrapped. This is, in my opinion, horribly primitive. Is there any chance that this is going to fixed in the near future? I never promise anything, but it would be nice to improve because Gmail is ubiquitous (and I really dislike hard-wrapping). The best/proper fix would be if Gmail started to support `format=flowed`, but I asked them to do that years ago and I guess it's unlikely to happen. MailMate can work around the issue in three bad ways: * Heuristically unwrap the plain text body part. Problem: Some times MailMate is going to unwrap something which shouldn't have been unwrapped. * If present, convert the HTML body part to plain text. Problem: There is really no way to be sure how Gmail uses HTML and it could change at any time. * A combination of the above. Base it on plain text and use the HTML text as a hint with respect to line wrapping. Problem: Non-trivial but probably the best approach. If no HTML body part is present in the message then only the first option is viable. Option 1 would require some way to disable this behavior. Option 3 would probably be quite safe. None of the options are specific to Gmail, but could work for emails generated by other hard-wrapping email clients as well. That's my thoughts on the issue. New ideas are welcome, especially if I've overlooked the obvious perfect solution. For the record, that problem did not happen in the reply to this message. That's because you replied to a message written in a proper email client which does not hard-wrap plain text ;-) -- Benny ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] Feature request - highlighting related messages in a thread.
On 5 Jun 2014, at 4:29, Gary Hull wrote: Thread Arcs still leave my threads gathered together, so I have to click-click-click tiny little expansion arrows over and over again, Note that holding down ⌥ expands the entire thread. Also when using right arrow to expand a thread. which in the end are not in reverse chronological order with my other mail in the mailbox, but rather gathered together in threads. This is because strict threading does not work well with reversed date sorting. To work well, this would require what I call “group” threading (single-level threading). This is still on the todo. I don't know how others use e-mail, but if I want threads, I go to USENET. I just want my mail in the order received, in reverse. If you don't want threads at all then I recommend disabling “View ▸ Organize by Thread”. This setting, by the way, is saved together with columns when using “View ▸ Columns ▸ Use as Default Columns” (a bit illogical, I know). -- Benny ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] Resetting the database.
On 6 Jun 2014, at 4:04, Scott A. McIntyre wrote: I don't know if it's Yosemite, or the "closing the search box opens a new window" bug, but, MailMate has crashed, hard, for me today -- for the very first time. The 2 crash reports I have received related to this appear to show that this started with a problem loading part of the database (the values related to a specific header). In theory, such crashes (or any other non-hardware-crashes) should never lead to database corruption since MailMate is able to roll back to a safe state, but obviously this doesn't seem to work in this case :-( The only known issue in relation to this is that crashes in the composer can lead to database corruption when MailMate tries to restore an autosaved draft. I'm still having trouble reproducing and fixing this, but it appears to be unrelated to your issue. Upon restart I was asked how to rebuild, and now it's stuck in a loop of rebuilding from cache, crashing, and restarting. I'd like to get more information about this, but that's probably best off list. Does anyone know what the Right Way is to, as a last resort, start up and nuke all known cached data and re-download everything, painfully, from IMAP? It can be done as follows: 1. Rename (or move) `~/Library/Application Support/MailMate`. 2. Create a new `~/Library/Application Support/MailMate`. 3. Copy some or all of the `*.plist` files from the old folder to the new folder (if they are not suspected of causing the issue). This includes account settings, signatures, tags, and smart mailboxes. Note that the account-related files `Sources.plist`, `Submission.plist`, and `Identities.plist` must be copied as a group. The simple approach is to just do step 1. Non-account related `plist`-files can be copied later (when MailMate is **not** running). Note that the old folder would still allow you to switch back to reproduce the crash-loop if you have time to help me investigate the issue. Sorry about whatever caused this problem in the first place. -- Benny ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
