This fixes a wrong merge that should not have happened:
commit 7e903a merges the master branch into the maint branch,
while we really want to keep the maint branch a bugfix-only
branch.
This commit reverts back the maint branch to its state before
merging the master branch. From there, we will fix remaining
problems with the maint branch (e.g. copyright issues) then
release this maint branch as Org-mode 7.8.05.
Also remove blank lines before the ";;; org*el ends here" declarations.
Having a "Version" header forced us to update every file when releasing a
new version of Org; it also forced us to update every file when merging Org
with Emacs trunk, thus cluttering the diffs between the previously merged
version and the new one with useless information.
Glenn Morris suggested this in emacs-devel:
http://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00322.html
Eden Cardim <edencardim@gmail.com> writes:
> Tassilo> No, I just wasn't really sure what that SCAN argument
> Tassilo> means, so I tried to be as safe as possible. If it's
> Tassilo> always safe to provide nil, let's change that.
>
> Well, right now all it does is to check split rules against incoming
> mail. But, if we have a link to a message in org, then that message
> already went through the split process, so re-splitting is
> unnecessary.
Ok, so here we go:
Bye,
Tassilo
>From 89fecc7b938385647618dc28c4df304df872e6eb Mon Sep 17 00:00:00 2001
From: Tassilo Horn <tassilo@member.fsf.org>
Date: Tue, 12 Apr 2011 20:27:54 +0200
Subject: [PATCH] Call gnus-activate-group without SCAN arg.
* org-gnus.el (org-gnus-follow-link): Don't request scan of
group when following link.
Carsten Dominik <carsten.dominik@gmail.com> writes:
Hi Carsten,
> is that patch on the patchwork server? If you find it, can you please
> send me the ID?
No, I cannot find it there. I'll attach it to this mail.
From 4a0fe0bfd4aafed16f658e963fc10e966601d651 Mon Sep 17 00:00:00 2001
From: Tassilo Horn <tassilo@member.fsf.org>
Date: Thu, 13 Jan 2011 19:25:04 +0100
Subject: [PATCH 3/3] * org-gnus.el (org-gnus-store-link): Don't error out if mail
has no or bogus Date: header.
* org-gnus.el (org-gnus-nnimap-query-article-no-from-file): Query
article number from file is nil by default.
The function function `nnimap-group-overview-filename' is gone in Gnus
devel. Subsequently enabling this feature by default will cause
org-gnus to fail on Emacs24.
Thanks for Matt Lundin for pointing this out.
* org-gnus.el (org-gnus-nnimap-query-article-no-from-file): New
customization variable.
(org-gnus-nnimap-cached-article-number): New function.
(org-gnus-follow-link): Try to fetch cached article number of
message-id.
Some IMAP servers (e.g. Courier) are slow when searching for a message
by its message id header field. Because article numbers in IMAP
mailboxes are persistent UIDs, we can try to look up the UID of a IMAP
message in Gnus' cache for the mailbox in question and skip the slow
search on the server.
The problem with slow server was reported by Sébastien Vauban and the
patch is based on the work of Tassilo Horn.
The attached patch suppresses a compiler warning in org-gnus.el
* lisp/org-gnus.el:
Suppress compiler warning by declaring outside function
nnimap-retrieve-headers-from-file.
David Maus <dmaus@ictsoc.de> writes:
Hi David,
>>I'm trying to add a workaround to org-gnus.el which should save the
>>slowness of querying the IMAP server by looking up the article number
>>in the group's .overview file. But since I don't have nnimap groups,
>>we have to play some question & answer game. ;-)
>
>>Please apply this patch and set
>>`org-gnus-nnimap-query-article-no-from-file' to t.
>
> The patch does not work: It calls `nnimap-retrieve-headers-from-file'
> without the required arguments (group server)
Argh, stupid me! Here's a corrected patch.
--8<---------------cut here---------------start------------->8---
--8<---------------cut here---------------end--------------->8---
> and the headers are not fetched because
> `nnimap-retrieve-headers-from-file' looks for a NOV cache file, not
> .overview.
Aren't overview file and NOV file synonyms?
Hm, anyway. In the Gnus docs I've found this paragraph:
,----[ (info "(gnus)IMAP") ]
| `nnimap-nov-is-evil'
| Never generate or use a local NOV database. Defaults to the value
| of `gnus-agent'.
|
| Using a NOV database usually makes header fetching much faster,
| but it uses the `UID SEARCH UID' command, which is very slow on
| some servers (notably some versions of Courier). Since the Gnus
| Agent caches the information in the NOV database without using the
| slow command, this variable defaults to true if the Agent is in
| use, and false otherwise.
`----
So maybe we're trying to replace one slow command with another slow
command. Especially, the fact that Courier is explicitly mentioned is a
bit frustrating. Well, let's try it out and see if it helps a bit.
> Alas: I couldn't figure out how to enable NOV cache for my nnimap
> group. Setting `nnimap-nov-is-evil' to nil didn't help.
This variable defaults to the value of `gnus-agent', so I assume the
agent has to be enabled (which is default), and most probably the IMAP
server has to be agentized as well. That can be done in the server
buffer (`^' in *Group*), and then:
,----[ (info "(gnus)Server Agent Commands") ]
| `J a'
| Add the current server to the list of servers covered by the Gnus
| Agent (`gnus-agent-add-server').
`----
Bye,
Tassilo
Bastien Guerry
emacs
Tassilo Horn
Ulf Stegemann
Carsten Dominik
Julien Danjou
David Maus
Noorul Islam