[Orgmode] Re: Gnus nnimap links

[Ross Patterson]

Bernt Hansen <address@hidden> writes:

> Ross Patterson <address@hidden> writes:
>
>> I find that my org-mode links to Gnus articles are very unstable, often
>> breaking.  Specifically, a link to an article will work when created and
>> later be broken.
>>
>> Almost all the links I make to Gnus articles are to articles in an
>> nnimap backend connecting to a local dovecot IMAP server that is synced
>> with the remote dovecot IMAP server using OfflineIMAP.  I don't know if
>> its at all specific to nnimap or OfflineIMAPI.  IOW, since the problem
>> is intermittent and I don't link to many articles with other backends,
>> the fact that I've only run into this problem with this stack doesn't
>> mean it doesn't occur for a different stack.
>>
>> Has anyone run into this or a related problem?  Does anyone have any
>> suggestions for where I might start looking.
>
> I use Gnus with a local cyrus imap server on my network.  Occasionally
> links to mail fails when they are in subfolders of my INBOX.  (i.e. a
> link to [[gnus:INBOX.SomeFolder#12345][email description]] will fail.  I
> usually have Gnus session permanently open in a second frame all day
> long and if I just open the SomeFolder group in Gnus then the link works
> again.  So far that's my workaround for this issue - it's not very
> elegant but it Works For Me(tm).

Thanks for the suggestion!

I tried that in a couple ways and couldn't get it to work.

On further inspection, I think maybe there may be something that is
removing the message number within the group used in the link.  For
example, one broken link is #4922.  When I look in the group, the
message that is supposed to be linked now has number #4923.  So I think
somehow there's something in my setup that is duplicating and removing
the original.

I found a case of duplicated messages and noted that the Message-ID
header *is* stable.  Might there be a way to get org-mode links to use
that header for lookup rather than Gnus' internal group message number?
It seems like that might be better data to store anyways in that it's
more portable.

Ross