mutt-users@mutt.org

[Alexandre]

Le jeudi 18 juin de l'année 2009, vers 08 heures et 15 minutes, Alexandre 
Delanoë écrivait:
> Hello,
> 
> I tag a mail with "t" and attach it to a thread with "&". After that
> i quit mutt saving changes. I open my mail box with mutt again but my
> thread is not saved. How to save this ?

I noticed that it only happen when I attach mails that are not supposed
to be in the thread. In fact I make groupe of discussions.

Is there any means with mutt for such issue ?

Cheers.
-- 
Alexandre Delanoë

Re: gives "cannot write to temporary folder"

[Rocco Rutte]

Hi,

* Marianne wrote:

> When I try to use the  command on a message mutt tells me:
> "could not create temporary folder: No such file or directory"

> Writing new messages works just fine.

> In my muttrc, I have:
> set tmpdir="/home/mpromber/.mutt/tmp"

> Mutt does put the files for messages I'm currently writing there, with
> filenames like "mutt-lauren-1000-22804-0". Fine. When I try to edit a
> message (hitting "e" in the index) and get the above error, mutt also
> creates a file with a name like this in that folder, but they all have
> size "0", like this:

> -rw--- 1 mpromber mpromber   0 2009-06-16 13:10 mutt-lauren-1000-22110-0

> Possibly related:

> My "~/.mutt" dir is in fact a symlink to a dir inside a dir that I encrypt
> and decrypt using ENCFS:

> lauren:~$ l .mutt
> lrwxrwxrwx 1 mpromber mpromber 26 2009-06-16 12:40 .mutt -> 
> /home/mpromber/stuff/.mutt

> (But that folder is decrypted when I run into the problem, and the
> problem arises at the same time when I can write new messages, which
> writes to the same folder).

> In muttrc: set editor="emacs -nw"

> Does anyone have an idea what would be causing this? Is mutt trying to
> create a different temporary folder, and if so, where? If it is, why
> is it putting these empty files into $HOME/.mutt/tmp/ ?

When editing messages, mutt tries to create an empty mbox file in
$tmpdir. At the moment I have no real idea why this would fail if it
otherwise can create tempfiles (i.e. permission problems can be excluded
here). Maybe the symlink is the trouble, I don't know. Can you try with
a $tmpdir that is not a symlink?

Rocco

Re: [mutt] Re: [ANNOUNCE] 1.5.20 released

[Rocco Rutte]

Hi,

* Jan-Herbert Damm wrote:

> I am glad i followed this advice. Thanks Rocco! It turns out i have to resolve
> some issues. Encoding and gpg don't work as expected. I will do some
> investigation.

At first it can be tricky to get all the configure flags right. You can
compare the output of mutt -v of both installed versions, check for
differences and ask here again if you can't figure out where a
flag/option comes from.

Rocco

Re: mutt removing stuff in brackets from subject

[Rocco Rutte]

Hi,

* Rejo Zenger wrote:

> I see. I expected mutt to use this regular expression to determine 
> whether it should prepand the current subject with "Re: " or that it 
> should leave it intact (if there is a match) - instead of removing 
> whatever is matched and replacing it. 

That has the potential to produce a horrible mess like:

  Re: Aw: Re: ...

that is unreadable.

Rocco

Re: mutt removing stuff in brackets from subject

[Rejo Zenger]

++ 18/06/09 14:23 +0200 - Rocco Rutte:
>> I see. I expected mutt to use this regular expression to determine 
>> whether it should prepand the current subject with "Re: " or that it 
>> should leave it intact (if there is a match) - instead of removing 
>> whatever is matched and replacing it. 
>
>That has the potential to produce a horrible mess like:
>
>  Re: Aw: Re: ...
>
>that is unreadable.

It's not really relevant, but I disagree. If the behaviour would be like 
I said above, mutt won't make things worse. If the regular expression 
matched both "Re:" and "Aw:" and otehr variations, then mutt would 
recognize the subject is already prepended and would not touch the 
subject to do it again. 

So, if subject is "Example", it would be prepended with "Re:" and if the 
subject is something like "Re: Example" or even "Re: Aw: Re: Example" 
(which both would match the given regular expression) it would leave the 
subject alone. As a result, mutt would never create a mess like "Re: Aw: 
Re:" - but it would leave it that way if it's there already.


-- 
Rejo Zenger .  . 0x75FC50F3 . 
GPG encrypted e-mail prefered. 


signature.asc
Description: Digital signature

Re: Monitoring new mail in mbox mailboxes

[Rocco Rutte]

Hi,

* Andrey Zhidenkov wrote:
> Hello. I want to configure my Conky to display a count of a new
> mail messages in mbox folders, like in sidebar-panel in mutt.

You have to use the sidebar patch for this.

Rocco

mutt-users@mutt.org

[Rocco Rutte]

Hi,

* Alexandre wrote:

> I tag a mail with "t" and attach it to a thread with "&". After that
> i quit mutt saving changes. I open my mail box with mutt again but my
> thread is not saved. How to save this ?

With what type of folder? Header caching enabled?

Rocco

Re: Monitoring new mail in mbox mailboxes

[Andrey Zhidenkov]

On Thu, Jun 18, 2009 at 02:50:50PM +0200, Rocco Rutte wrote:
> Hi,
> 
> * Andrey Zhidenkov wrote:
> > Hello. I want to configure my Conky to display a count of a new
> > mail messages in mbox folders, like in sidebar-panel in mutt.
> 
> You have to use the sidebar patch for this.
> 
> Rocco

I'm already using a sidebar patch. But I can't understand how a can output
a new mail notifications to console, for example? Cpnky needs a plain text 
output (from some script).

How to implement save_empty on maildir?

[Wu, Yue]

I want to let mutt deletes empty maildirs automatically, but 'save_empty' only
works for mbox, why? How to achieve it for maildir?

-- 
Hi,
Wu, Yue

Re: gives "cannot write to temporary folder"

[Marianne]

Rocco Rutte  18-Jun-09 13:17:
> * Marianne wrote:
> > When I try to use the  command on a message mutt tells me:
> > "could not create temporary folder: No such file or directory"
> 
> > Writing new messages works just fine.
> 
> > In my muttrc, I have:
> > set tmpdir="/home/mpromber/.mutt/tmp"
> > [...]
> 
> > My "~/.mutt" dir is in fact a symlink to a dir inside a dir that I encrypt
> > and decrypt using ENCFS:
> > [...]
>
> When editing messages, mutt tries to create an empty mbox file in
> $tmpdir. At the moment I have no real idea why this would fail if it
> otherwise can create tempfiles (i.e. permission problems can be excluded
> here). Maybe the symlink is the trouble, I don't know. Can you try with
> a $tmpdir that is not a symlink?

Yes, sorry, I should have thought of that.

set tmpdir="/home/mpromber/tmp"

And mutt edits away happily. So I assume it's something with
encfs. I've since posted to encfs-users and will report here in case I
hear anything intresting.

In the meantime, this tmpdir is just fine for me, at least for
editing, which I usually only use to create X-Label headers, so if I'm
really paranoid I'll keep the encrypted tmpdir and switch back and
forth with a macro.

Thanks!

Marianne

Re: [mutt] Re: [ANNOUNCE] 1.5.20 released

[Jan-Herbert Damm]

Hi,

Rocco Rutte wrote on 18.06.09:
> 
> * Jan-Herbert Damm wrote:
> At first it can be tricky to get all the configure flags right. You can
> compare the output of mutt -v of both installed versions, check for
> differences and ask here again if you can't figure out where a
> flag/option comes from.

I found quite a few discrepancies comparing mutt -v output. 

These are the compiler-flags used in Mutt-1.18.-ubuntu-build but not used in
my Mutt-1.20.-home-build and of which i don't know what configure-option they
are triggered by:

+HAVE_GETADDRINFO 
+COMPRESSED 
+HAVE_LANGINFO_CODESET

jan

Re: [mutt] Re: [ANNOUNCE] 1.5.20 released

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thursday, June 18 at 05:38 PM, quoth Jan-Herbert Damm:
>I found quite a few discrepancies comparing mutt -v output.
>
>These are the compiler-flags used in Mutt-1.18.-ubuntu-build but not used in
>my Mutt-1.20.-home-build and of which i don't know what configure-option they
>are triggered by:
>
>+HAVE_GETADDRINFO

This means that the system mutt was configured on (i.e. yours versus 
the Ubuntu build system) has the getaddrinfo() function available.

Generally, I believe this is used primarily by mutt to decide whether 
it can support IPv6 (the getaddrinfo function is more flexible than 
other methods, and so can be used with IPv6).

I don't believe that there is a configure argument you can use that 
forces this to be used or not.

>+COMPRESSED

This is a reference to the Ubuntu/Debian compressed-mbox patch. In 
essence, they use a patch that allows mutt to read a gzip'd mbox file.

>+HAVE_LANGINFO_CODESET

Literally, this means that your system has the langinfo.h header and 
the nl_langinfo(CODESET) function is available as well. This allows 
mutt to automatically detect the default charset the system wants to 
use---without this ability, mutt is forced to assume some default 
charset (namely ISO-8859-1). Again, there's no way to force mutt to 
use or not use this by passing arguments to configure; it relies 
entirely upon the localization features your computer supports.

HTH,
~Kyle
- -- 
Formal symbolic representation of qualitative entities is doomed to 
its rightful place of minor significance in a world where flowers and 
beautiful women abound.
 -- Albert Einstein
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKOmOlAAoJECuveozR/AWef3QQAIB4b54At7dkIDlp4G3xUlIo
tD1jY9GSaKBzsS/xJUfBUMZNUsLv6Zb1CzTQWVM29XwttTvBWkvwGkb1v5m7k3ZR
ihD3U9sG9Y378wCIxSvZevMfpO/pb8KuTLhS89uaP3drEQz/TqmHkuLSr+E95Dgn
1uH0GR8SbaTAp7Qf63SZr198Szw1w5iIgE2bkaBs9sqo8JXS8L++ox6s8Aje4e3m
Rm7JwIy6atlGM8n6zb8X+wIfCQBT5Rtr8iB1lQPozA3QtbeVqnKwqBguHGcE4MIB
rtd7F1thkcxFeTjVyTvU8n2LTGfly39M60fKHYO3q4Oo2X3A9xxd7ECh0w/c3ju/
Jing/mS8uXqIWiLLqR23qgT1YOqwghaGaocxcaUxoyz/i/2/LJCEmgFQE4Ea3yxG
UlDFZenEpqAwzTvaA5o9eej93JRU7ms5P+dd971PgAT+gBsQNMtFDOohlOitckNC
Pl7R4d83y4o8lCawJUUVVDEVSqQRyxsMLnklz+yHATlRiUVzMp0we7a0Zlk32bAx
BbhYbDr24skPi4k28r1IQ1YKg9kMLx2hHV8Scg8GnsVvzRNRWcH3a4NrBBhkbU/V
B2iLFcAGURz5SNLZS1RmUtKl0yoECOXxJ0UjVtUzMwZOyeALoHNVO4RTK8JiN29Z
mcpPeQkeUaZs5QXQOsVc
=3Dtk
-END PGP SIGNATURE-

mutt-users@mutt.org

[Marianne]

Alexandre  18-Jun-09 12:18:
> Le jeudi 18 juin de l'année 2009, vers 08 heures et 15 minutes, Alexandre 
> Delanoë écrivait:
> > Hello,
> > 
> > I tag a mail with "t" and attach it to a thread with "&". After that
> > i quit mutt saving changes. I open my mail box with mutt again but my
> > thread is not saved. How to save this ?
> 
> I noticed that it only happen when I attach mails that are not supposed
> to be in the thread. In fact I make groupe of discussions.

Are you doing this on a Gmail IMAP folder?

I had issues using mutt to link threads in Gmail as well, as described
here:

http://does-not-exist.org/mail-archives/mutt-users/msg17790.html

I received no replies about this, and for all I know the problem still
exists, but I've stayed away from linking threads in Gmail folders
ever since, so I don't know.
 
Marianne

mutt-users@mutt.org

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thursday, June 18 at 05:13 PM, quoth Marianne:
>>> I tag a mail with "t" and attach it to a thread with "&". After 
>>> that i quit mutt saving changes. I open my mail box with mutt 
>>> again but my thread is not saved. How to save this ?
>>
>> I noticed that it only happen when I attach mails that are not supposed 
>> to be in the thread. In fact I make groupe of discussions.

I've had a similar problem before, only not with unrelated messages 
but rather with messages that don't contain certain headers (e.g. 
Message-ID). I think the reason is because mutt uses Message-ID to 
link threads---if a message doesn't HAVE an ID, mutt simply fails to 
link the messages, rather than attempt to give the message a 
Message-ID header.

There might be good reasons for this, but I don't know what they are. 
I think it's probably more complicated to add a header to both 
messages than it is to modify an existing header in a single message, 
but I don't know the details.

> Are you doing this on a Gmail IMAP folder?
>
> I had issues using mutt to link threads in Gmail as well, as described 
> here:
>
> http://does-not-exist.org/mail-archives/mutt-users/msg17790.html
>
> I received no replies about this, and for all I know the problem still 
> exists, but I've stayed away from linking threads in Gmail folders 
> ever since, so I don't know.

My guess here is that it's either related to the problem I mentioned 
above OR it's related to the fact that Gmail doesn't implement IMAP 
correctly.

That's right, I said it. Gmail's IMAP implementation is *awful*, and 
broken in lots of important ways. Some of these are at least somewhat 
understandable, because Gmail is attempting to change the way email 
storage works while still supporting a "good enough" version of IMAP. 
But "good enough" isn't always "good enough" to allow everything mutt 
wants to do. For example, Gmail doesn't like "deleting" messages (even 
though they claim to technically allow it, as of somewhat recently). 
Unfortunately, many of the more creative and powerful tricks mutt can 
perform with messages (e.g. connecting threads) rely on being able to 
modify messages on the IMAP server---which (because IMAP provides no 
method for modifying a message directly (for very good reasons)) 
involves copying messages and DELETING the old ones. It is no surprise 
to me that this can be a problem, given how loathe Gmail is to grant 
users the power of deletion.

Of course, some of the Gmail IMAP bugs are just flat out wrong and 
Google should be embarrassed about them (see all the various encoding 
bugs).

I recommend that if you have a problem using mutt with Gmail, try 
doing the same thing with some other IMAP client (ANY other IMAP 
client). If it doesn't work there either, chances are it's a Gmail 
problem, not a mutt problem!

And putting a filter, like offlineimap, between mutt and gmail means 
it's even harder for mutt to perform creative message modification 
correctly, because mutt cannot detect when something doesn't work and  
thus cannot attempt a second way of doing it. When you run into 
trouble while using something like offlineimap, my first suggestion 
would be: try doing it without offlineimap. If it works, then you have 
isolated the problem: it's an offlineimap problem. If it still doesn't 
work, then you have eliminated a potential cause, and you've made 
progress toward figuring out what the real problem is.

~Kyle
- -- 
Hanging on to resentment is letting someone you despise live rent-free 
in your head.
 -- Ann Landers
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKOnncAAoJECuveozR/AWewFsQAI8e6liOvzJZdI3zdUfpOS47
D2MZ7QKgG/XRgaMcIfA2I785mS4Zf5035n+kFyK0GgtD60zXunP8/8VvuVb5/FZU
zz8vcCptfjjCr1H6uCya4UXjMY7h3g/KpRBpss2ZkiMAeDk05cqrpwMmX54UG4Em
SzcZ7tCaW6rCD6BwmOb3Yxtc/421XzEazAoUnntuy+31KYLu9ePdOv2vCW+AwKWf
je7Wl91e1qQMZrtXr9rIDr9j47eULpG5qYtAqcId2gJNJA0tmN9rNddtk3ITOWBY
LDsITswUZuglpqOZaxjWQ0QWEC7nP0I8yKdWky6BWjPu/hEBR5VbdTtc0PlBs9Hr
T8m+ek8D6TJ8gc0qu0N2BEUj8n++bi798/myv/zRE7/Pb//f8WR+06fj0QoIKIGr
VJUqQQUDe19VMMkWJ8o3/6cm2xsMcA8QH67kWnKdFyMyqQ0U9/RzDJL0VOi9MsvW
d/7duHPKBalAy6traPfXbnwPmeRhXl9ufkr4rYjLbwdwa+sJb0F9DlnzO6+iNv7/
+qXtgbOPE+/jKcHmLztZCz1N+e6EW9gG3uqIAQMdCRJIiwjIpHq2sQGrdVgdAScL
0fffFqnO7y77vuJMACCl9BNYtvtW5C0ezHdLvJCGa9yxF/omMpLd7oL8lyfgpb00
zz+k1fdqedO4mQWKuEPu
=Tnsk
-END PGP SIGNATURE-

mutt-users@mutt.org

[Christian Brabandt]

Hi Kyle!

On Do, 18 Jun 2009, Kyle Wheeler wrote:

> On Thursday, June 18 at 05:13 PM, quoth Marianne:
> >>> I tag a mail with "t" and attach it to a thread with "&". After 
> >>> that i quit mutt saving changes. I open my mail box with mutt 
> >>> again but my thread is not saved. How to save this ?
> >>
> I've had a similar problem before, only not with unrelated messages 
> but rather with messages that don't contain certain headers (e.g.  
> Message-ID). I think the reason is because mutt uses Message-ID to 
> link threads---if a message doesn't HAVE an ID, mutt simply fails to 
> link the messages, rather than attempt to give the message a 
> Message-ID header.

I have noticed that behaviour, too. Was a little bit surprising and 
disturbing not to be able to link messages, that belong to the same 
thread.

regards,
Christian
-- 
:wq!

mutt-users@mutt.org

[Marianne]

Kyle Wheeler  18-Jun-09 18:31:
> On Thursday, June 18 at 05:13 PM, quoth Marianne:
> > Are you doing this on a Gmail IMAP folder?
> >
> > I had issues using mutt to link threads in Gmail as well, as described 
> > here:
> >
> > http://does-not-exist.org/mail-archives/mutt-users/msg17790.html
> >
> 
> My guess here is that it's either related to the problem I mentioned 
> above OR it's related to the fact that Gmail doesn't implement IMAP 
> correctly.
> [...]
> Unfortunately, many of the more creative and powerful tricks mutt can 
> perform with messages (e.g. connecting threads) rely on being able to 
> modify messages on the IMAP server---which (because IMAP provides no 
> method for modifying a message directly (for very good reasons)) 
> involves copying messages and DELETING the old ones. 

Thanks! That's the explanation that must underlie this problem.  It
explains both that when I directly access Gmail via IMAP it removes
the label, and that offlineimap deletes the mail.  I didn't know that
mutt does delete + copy instead of modifying the message in place.

> I recommend that if you have a problem using mutt with Gmail, try 
> doing the same thing with some other IMAP client (ANY other IMAP 
> client). If it doesn't work there either, chances are it's a Gmail 
> problem, not a mutt problem!

Well, yes, if you look at my original post that's pretty much the
conclusion I came to. I still use Gmail for mailing lists that have
lots of messages that I want to keep (maybe not a sensible thing, but
I've to some degree fallen for the Gmail "I'll just have to use lots
of space now that I have it" trick), but I've stopped cleaning up
threads.

> When you run into trouble while using something like offlineimap, my
> first suggestion would be: try doing it without offlineimap. If it
> works, then you have isolated the problem: it's an offlineimap
> problem. If it still doesn't work, then you have eliminated a
> potential cause, and you've made progress toward figuring out what
> the real problem is.

Fully aggree, and again, if you look at my initial post from December
2008 you'll find that that's what I did.

Thanks again for your explanations about Gmail & IMAP and what mutt
does when it links threads, that really cleared things up for me.

Marianne

Re: [mutt] Re: [ANNOUNCE] 1.5.20 released

[Jan-Herbert Damm]

Hello,

Thanks for explanations!

I tried another build and found that my switches revealed more problems that i
want to gnaw on for a while. 

 
> >+HAVE_LANGINFO_CODESET
> 
> Literally, this means that your system has the langinfo.h header and 
> the nl_langinfo(CODESET) function is available as well. This allows 
> mutt to automatically detect the default charset the system wants to 
> use---without this ability, mutt is forced to assume some default 
> charset (namely ISO-8859-1).

This is particularly disturbing because my Mutt-1.20. hat great problems
displaying numerous characters (such as the lines showing the threads and
german umlauts etc.) But ":set ?charset" renders "utf-8". 

Since i also have strange encoding behaviour in Mutt-1.18. (i may not use
german umlauts in muttrc else running into trouble) i hope to find a common
root to these issues.

I will report back when/if i find out more.

greetings 

jan

mutt-users@mutt.org

[Alexandre]

Le jeudi 18 juin de l'année 2009, vers 14 heures et 53 minutes, Rocco Rutte 
écrivait:
> Hi,
> 
> * Alexandre wrote:
> 
> > I tag a mail with "t" and attach it to a thread with "&". After that
> > i quit mutt saving changes. I open my mail box with mutt again but my
> > thread is not saved. How to save this ?
> 
> With what type of folder? Header caching enabled?

It is maildir folder.
I have this mutt version 1.5.18-6+b1 on Debian (testing) system.

I do not know if Header caching is enabled on this version.

-- 
Alexandre Delanoë

Re: [mutt] Re: [ANNOUNCE] 1.5.20 released

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thursday, June 18 at 11:28 PM, quoth Jan-Herbert Damm:
> This is particularly disturbing because my Mutt-1.20. hat great 
> problems displaying numerous characters (such as the lines showing 
> the threads and german umlauts etc.) But ":set ?charset" renders 
> "utf-8".
>
> Since i also have strange encoding behaviour in Mutt-1.18. (i may not use 
> german umlauts in muttrc else running into trouble) i hope to find a common 
> root to these issues.

Ahh - in that case, I think you probably want to read 
http://wiki.mutt.org/?MuttFaq/Charset. It explains things reasonably 
well, and contains a great test (see "How can I check if locales work 
before I blame Mutt for it?").

I bet that solves your problem for you.

~Kyle
- -- 
Blessed are they who can laugh at themselves for they shall never 
cease to be amused.
 -- Unknown
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKOrslAAoJECuveozR/AWeZHYP/jYMCC6y9bx2moRboWsHy8N9
fPqgl0VYpXO00dT7ePziib3d/KFJ5ijwuHzabFz3ereojpe6z+aGYYPDEuBJwmRx
hWvCpb6QjNEE/JC5K3+ppFoU8QgQtjW8Y/6AicCQlYaXrosnQM2OiAxpQGoaFx10
XrBJvKs0GkeJnlxggXWLIo7jdLxJOge3K0tOwYSgUrAHuTSJxURlNg2bYN0Zq7KR
G279msfW35CxPLOP6LRJG69R5I4vL7slLAImKoSg2/Q2ZROiacG2PYw4SCPP9WPS
UgBeg/+6CqinZ62j4jksLqrAiJC7yCR/gBsARmLl72pACQk7bhNw4gS50zgv2oCq
l/v7iTWL5wpZNvGayHjM7Omsfqg5nvilBhEV4wUZ8QdLqsCqRUtguuWTmF116m4d
CxmVr1bMHhFZwZqio9v2WNFVekcmTuxfJqg6hmisLvbbSRwxdCwxFKM+KkRY4aAh
9IKMx70FXqkhSiQ4R0FvFc6ABUkb9ifKu9jeUVedflTc9PoIZoLcUN9fRIP37yiL
6+5ijl4sxd8GGuP0uIejhcPY81dBofW6NCAl4eROuLeGEkD1t+UThTLlTajZ4t3E
1DgoZ98Ff+ZMAJOk52dmCcGjL0qv1haTMKZVaD7E0NbQWi1nRHE5yr0oFRjHxtWF
EGFY8JZrqReZu6vP8Erh
=qfj4
-END PGP SIGNATURE-

mutt-users@mutt.org

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thursday, June 18 at 10:08 PM, quoth Marianne:
>> Unfortunately, many of the more creative and powerful tricks mutt 
>> can perform with messages (e.g. connecting threads) rely on being 
>> able to modify messages on the IMAP server---which (because IMAP 
>> provides no method for modifying a message directly (for very good 
>> reasons)) involves copying messages and DELETING the old ones.
>
> Thanks! That's the explanation that must underlie this problem.  It 
> explains both that when I directly access Gmail via IMAP it removes 
> the label, and that offlineimap deletes the mail.  I didn't know that 
> mutt does delete + copy instead of modifying the message in place.

The reason for it is actually somewhat interesting. Essentially, IMAP 
provides two important message-related guarantees: that every message 
has a unique identifier (UID number) and that every unique identifier 
applies to exactly one message. The idea is to facilitate client-side  
message caching. For example, clients can ask the server "what 
messages are in this mailbox?", receive back a list of UIDs, compare 
that to its own list of cached message UIDs, and know which ones (if 
any) are new. If a message could be modified, it would have to receive 
a new UID so that any other clients would know that their cached copy 
of that message is no longer valid. Keep in mind that an IMAP server 
has to handle lots of annoying situations, such as when one client 
wants to update a message and another client wants to delete that same 
message at the same time. Similarly, there would be safety issues with 
multiple clients trying to modify the same message at the same time. 
Which change wins? How do you inform the others that the message has 
changed out from underneath them? That sort of thing.

Because of that, IMAP doesn't have a "modify message" command (okay, 
if we spent enough time on it, we can probably work out some 
complicated new semantics for how such a thing might work... but 
that's the basic reason IMAP doesn't have one, as I understand it). On 
the other hand, IMAP *does* have a command for adding a whole new 
message to a folder ("APPEND"), and has a command for removing a 
message from a folder ("DELETE"). So mutt does what it needs to do in 
order to accomplish what it wants done.

>> When you run into trouble while using something like offlineimap, 
>> my first suggestion would be: try doing it without offlineimap. If 
>> it works, then you have isolated the problem: it's an offlineimap 
>> problem. If it still doesn't work, then you have eliminated a 
>> potential cause, and you've made progress toward figuring out what 
>> the real problem is.
>
> Fully aggree, and again, if you look at my initial post from December 
> 2008 you'll find that that's what I did.

Ahh, I missed that part.

> Thanks again for your explanations about Gmail & IMAP and what mutt 
> does when it links threads, that really cleared things up for me.

Glad to help!

~Kyle
- -- 
It is only possible to live happily ever after on a day-to-day basis.
-- Margaret Bonnano
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKOr1eAAoJECuveozR/AWenigQAIsLRHSa2cuQoq63hgIxI6vL
5EeBO+ZQ1cnbk5KuXEZB0IoBMqqoWpVvmQJkf3LjUDfPqhViSLKDJlDe0KuITK9b
METEpys18nA/3elc6LlcgKhaTff8DRzxVve0WHsciFyiP8SR4fj/Gfvc5dnZMRq2
v3bGXwFKn+gxMszQ4k2O+bnpnEnAGoPqLgR6Y54ZxTHCiAxE+zGJVxgw3dgYxstx
5dJeEVbg8skWVOVESrkBl6IFQ5gxFII6hPzVo4SwPQEzD4oA8xCSbfJCKJUkxw72
+f6T3ssoX1zYf7NiIJOz6k0OAIqBenipOq9jNGS1uYsjrvDVgu8DvLWBgE+hkXDv
3U0+eGxy5HR2jN1WTGXld6QN7HfhK7+ISX3fyzub9LfoGEbNO5195TqS0/aZ2b5o
NBctPafhUautHJNVMGfiCGTUvKwck914iP2Q7JRgN14t128+pq1YlXYMezOGa/aR
ozUNq78nG4QNYEQIkaWx87LoYpJOcFzKOckVNPH98twWrRx2ig807r7JlGmh7T6Z
ECA5UZAvx0Q5U5n3yWqAaKzIS7Q8l2UmqSQYW8tr5w//nBz5RrHgkngHpR9Wce6x
/5yTN92ViPfVXDFRy7+W+9ZXvjQOg/UnWBWPmaABUHjiTcKTC93cl6Tmk1GYmZCv
Waezg/BqQ9BSo7ntJww1
=XNv6
-END PGP SIGNATURE-