Integration of Org mode and Gnus

Integration of Org mode and Gnus

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 1079 bytes --]

Hi all,

I've recently discovered Org mode and have to say that I find it
extremely useful, so I'm switching my personal coordination to it right
now. One of my main applications is Gnus for mail reading, so quite
often I'd like to have links to emails that were either sent or
received.

Ideally, I'd like to make a decision on email when I find them in the
inboxes, and either archive them without a link, or archive them with a
link for my Org mode files. The same goes for mail I send.

So for sending mail and for moving mail to archive folders, I would like
to be able to memorise a link for the email in its *final storage*
location.

Did anyone solve this problem before me?

Does anyone have an idea of the "right" solution to this?

Regards,
Georg

-- 
Georg C. F. Greve                                 <greve@fsfeurope.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Join the Fellowship and protect your freedom!     (http://www.fsfe.org)
What everyone should know about DRM                   (http://DRM.info)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 306 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Integration of Org mode and Gnus

[Jason F. McBrayer]

"Georg C. F. Greve" <greve@fsfeurope.org> writes:

> Ideally, I'd like to make a decision on email when I find them in the
> inboxes, and either archive them without a link, or archive them with a
> link for my Org mode files. The same goes for mail I send.
>
> So for sending mail and for moving mail to archive folders, I would like
> to be able to memorise a link for the email in its *final storage*
> location.

I don't have a solution to this, but I'd like to note that I have the
same problem.

One possible way of approaching it might be with nnir (see
http://www.emacswiki.org/cgi-bin/wiki/IndexMail and
http://www.emacswiki.org/cgi-bin/wiki/nnir.el) so that the link you
save in org is a link to a search that will find the message, not a
link to the message itself.  But nnir is currently not working very
reliably for me (trying to use the IMAP backend).

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray@carcosa.net  |
| If someone conquers a thousand times a thousand others in |
| battle, and someone else conquers himself, the latter one |
| is the greatest of all conquerors.  --- The Dhammapada    |

Re: Integration of Org mode and Gnus

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 2443 bytes --]

On Tue, 17 Jul 2007 20:22:50 -0400
jmcbray@carcosa.net (Jason F. McBrayer) wrote: 

 jfm> I don't have a solution to this, but I'd like to note that I have
 jfm> the same problem.

Interesting. I was pretty sure that I was not alone with this. ;)


 jfm> One possible way of approaching it might be with nnir (see
 jfm> http://www.emacswiki.org/cgi-bin/wiki/IndexMail and
 jfm> http://www.emacswiki.org/cgi-bin/wiki/nnir.el) so that the link
 jfm> you save in org is a link to a search that will find the message,
 jfm> not a link to the message itself.  But nnir is currently not
 jfm> working very reliably for me (trying to use the IMAP backend).

Yeah, this seems suboptimal.

Moving email is trivial -- you just need to call

 gnus-summary-move-article

to move things to the place you want to archive them. But that function
does not return the URL of the moved article (as one might hope).

So I see two possibilities, essentially:

 a) pull it out of the function and subfunctions

 b) (when moving to a backend that uses NOV databases, like nnfolder)
    pull it out of the NOV file, the last moved message is the last one
    on the list

Of the two, method a) seems cleaner in principle, but it requires a fair
amount of knowledge of the gnus internals -- and the change would have
to make it back into gnus, otherwise the method could break
inconveniently timed in the future.

Method b) is easier and does not require changing the main body of gnus
code, but is somewhat messy and inelegant.

So in effect I was wondering whether I missed a method c) -- and whether
anyone had already thought about either a) or b).

This could then be followed by calling the integration outlined in

  http://article.gmane.org/gmane.emacs.orgmode/1771

to make Gnus+Org fully GTD integrating, allowing us to decide in the
inbox whether to archive, archive+file next action, forward, or discard
an email.

My knowledge and time available would probably allow me to put together
something based on b), but I wonder whether anyone here might be
motivated to try solution a).

Regards,
Georg

-- 
Georg C. F. Greve                                 <greve@fsfeurope.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Join the Fellowship and protect your freedom!     (http://www.fsfe.org)
What everyone should know about DRM                   (http://DRM.info)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 306 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Integration of Org mode and Gnus

[Bastien]

"Georg C. F. Greve" <greve@fsfeurope.org> writes:

> Moving email is trivial -- you just need to call
>
>  gnus-summary-move-article
>
> to move things to the place you want to archive them. But that function
> does not return the URL of the moved article (as one might hope).

I think there is another solution:

1. Make C-c l (org-store-link) store message-id so that org-insert-link
   will insert something like:

  [[gnus:nnml:mail.compas#<8c930aea07071...@server>][Message description]

  intead of the current format:

  [[gnus:nnml:mail.compas#2306][Message description]]

2. If `gnus-registry.el' is in use, rely on it to double-check in which
   group the message is. If it's not in use, rely on the link infos.

   It's straightforward to get the group from a message-id with
   gnus-registry.el: 
 
     (cddr (assoc "message-id" gnus-registry-alist)) 

   Then with the group and the message-id you'll find the email.

I don't go further because this method relies on org-store-link being
aware of message-id, but that should not be hard to turn this on, maybe
as an option.

Anyway, i think gnus-registry comes in handy here.

Cheers,

-- 
Bastien

Re: Integration of Org mode and Gnus

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 1263 bytes --]

On Wed, 18 Jul 2007 12:04:52 +0200
Bastien <bzg@altern.org> wrote: 

 b> I think there is another solution:

 b> 1. Make C-c l (org-store-link) store message-id so that
 b> org-insert-link will insert something like:

 b>   [[gnus:nnml:mail.compas#<8c930aea07071...@server>][Message
 b>   description]

 b>   intead of the current format:

 b>   [[gnus:nnml:mail.compas#2306][Message description]]

Yes, this would also solve the problem.

I guess that this will also require an update of the follow link
function in Org?

If I try to add a link with message ID such as the one above by hand, I
cannot follow it (it seems to try to interpret the message ID as article
number in the group).

Since I know which group I am asking to move things to, being able to
link to the message ID directly would definitely solve the problem, and
maybe even more elegantly, as it should be robust against resorting the
mail group.

Regards,
Georg

-- 
Georg C. F. Greve                                 <greve@fsfeurope.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Join the Fellowship and protect your freedom!     (http://www.fsfe.org)
What everyone should know about DRM                   (http://DRM.info)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 306 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Integration of Org mode and mairix (was: ... and Gnus)

[Adam Spiers]

[-- Attachment #1: Type: text/plain, Size: 2765 bytes --]

On Wed, Jul 18, 2007 at 12:29:08PM +0200, Georg C. F. Greve wrote:
> Since I know which group I am asking to move things to, being able to
> link to the message ID directly would definitely solve the problem, and
> maybe even more elegantly, as it should be robust against resorting the
> mail group.

Funnily enough, I implemented exactly this idea about 15 months ago,
except that my implementation uses mairix (the mail indexer), and is
mode-agnostic.  I use mutt as my mail reader, so the usage workflow is
this:

  1. Read a mail which requires a TODO action

  2. Hit a keypress combo which triggers a Perl script acting on the
     mail to extract the Message-ID and dump it to a predictably-named
     temporary file, which can be considered as a dedicated clipboard.

  3. In emacs, hit another keypress combo to yank the contents of the
     clipboard into a new item in my TODO.org file as a link, e.g.:

       * NEXTACTION [#B] read this email about blah blah
         <mairix://m:4679BAC0.4057103@spiers.net>

  4. Archive the mail anywhere, safe in the knowledge that later on,
     moving the point over this mairix:// link within emacs and
     pressing another keypress combo will perform a mairix search for
     this Message-ID, and launch a mutt window displaying the mail,
     regardless of wherever it's been archived.

At first I thought that this was just a cute little trick, but it's
proved itself to be an absolute god-send:

  - emails can be converted into TODO items and cleared out of my
    inbox within seconds.  Anyone trying to follow GTD already knows
    the huge value of being able to quickly process an inbox.

  - Having mail linked to like this (and in general having it indexed
    and instantly searchable) means that I no longer have to make sure
    mails are carefully archived in the right folder according to
    topic.  This used to be very time-consuming, and didn't always
    work, e.g. when a single mail covered more than one topic.  These
    days, I simply have one archive folder per month to keep folder
    sizes manageable.

  - The URL-like syntax allows me to store hyperlinks which trigger
    more complex queries rather than just searching for a single
    message id, e.g.

       <mairix://s:orgmode>

    would find all mails with 'orgmode' in the subject.

I made it mode-agnostic because I also wanted to be able to link to
mails from within source code comments, log files, muse-mode, etc.
Having said that, if there is a generic mode-agnostic hyperlinking
framework in emacs, I really should have my wrist slapped for
reinventing the wheel.  In particular, I do wish that org-mode and
muse-mode had the same hyperlinking syntax ...

Anyway, source code for my hacks attached.

Cheers,
Adam

[-- Attachment #2: as-gtd.el --]
[-- Type: text/plain, Size: 2258 bytes --]

;; Things to help me with Getting Things Done.

(defvar as-mairix-links-clipboard "~/.clip-mairix"
  "Pseudo-clipboard file where mairix URLs get copied to.")

(defvar as-mairix-results-folder "~/mail/mairix"
  "Folder where mairix writes results.")

(defvar as-mairix-link-viewer-command "mairix '%search%' && xterm -title 'mairix search: %search%' -e 'unset COLUMNS; mutt -F ~/.mutt/work -f %folder% -e \"push <display-message>\"' &"
  "Command to view messages linked to by 'mairix://...' links.")

(defun as-mairix-yank-links ()
  "Yank from file defined by `as-mairix-links-clipboard'."
  (interactive)
  (let ((bytes (cadr (insert-file-contents
                      (expand-file-name as-mairix-links-clipboard)))))
    (forward-char bytes)
    (save-excursion
      (forward-char -1)
      (if (looking-at "\n")
          (delete-char 1)))))

(defun as-mairix-search-at-point ()
  "Return the start and end points of a mairix link at the current
point.  The result is a paired list of character positions for a
mairix link located at the current point in the current buffer."
  (save-excursion
    (if (looking-at "<mairix://")
        (forward-char 1)
      (skip-chars-backward "^<"))
    (if (looking-at "mairix://\\([^>]+?\\)>")
        (match-string 1)
      nil)))

(defun as-mairix-view-link-at-point (show-async-buf)
  "View the 'mairix://...' link at the point using the shell command
defined by `as-mairix-link-viewer-command'."
  (interactive "P")
  (let ((message-id (as-mairix-search-at-point)))
    (or message-id (error "No mairix URL found at point"))
    (let ((cmd as-mairix-link-viewer-command))
      (while (string-match "%search%" cmd)
        (setq cmd (replace-match message-id 'fixedcase 'literal cmd)))
      (while (string-match "%folder%" cmd)
        (setq cmd (replace-match as-mairix-results-folder 'fixedcase 'literal cmd)))
      ;; By default, async shell-command invocations display the temp
      ;; buffer, which is annoying here.  We choose a deterministic
      ;; buffer name so we can hide it again immediately.,
      (let ((tmpbufname (generate-new-buffer-name " *mairix-view*")))
        (shell-command cmd tmpbufname)
        (or show-async-buf
            (delete-windows-on (get-buffer tmpbufname)))))))

[-- Attachment #3: mairix-copy-message --]
[-- Type: text/plain, Size: 1741 bytes --]

#!/usr/bin/perl
#
# extract headers from mail stream on STDIN.
# For use with mutt, .e.g
#
#    macro index "\em"  ":set pipe_decode=no\n<pipe-message>mairix-copy-message ids\n:set pipe_decode\n"

use strict;
use warnings;
use Getopt::Long;
use Mairix;

my %opts;
GetOptions(
  \%opts,
  'help',
  'ids', 'threads',
) or usage();
usage() if @ARGV or $opts{help};

sub usage {
  warn @_, "\n" if @_;

  (my $me = $0) =~ s,.*/,,;

  die <<EOUSAGE;
Usage: cat mail1 [mail2 ...] | $me [--ids] [--threads]
Options:
  -h, --help     Show this help
      --ids      Extract Message-ID header(s)
      --threads  Extract thread subject(s)
EOUSAGE
}

my @found;

my $subject;
while (<STDIN>) {
  chomp;

  if ($opts{ids} && /^message-id:\s+(.+)\s*$/i) {
    my $value = $1;
    if ($value =~ /^<(.+)>$/) {
      push @found, "m:$1";
    }
    else {
      warn "WARNING: Message-ID '$value' violates RFC.\n";
      push @found, "m:$value";
    }
    next;
  }

  if ($opts{threads}) {
    if ($subject) {
      if (/^\s+(.+)/) {
        # continuation line
        $subject .= " " . $1;
        next;
      }

      # next header
      push @found, join ' ', Mairix::subject_query($subject);
      undef $subject;
      next;
    }
    elsif (/^Subject:\s+(.+)\s*$/i) {
      $subject = $1;
    }
  }
}

# xclip doesn't work :-(

if (! @found) {
  warn "No Message-ID header found!  Press a key...\n";
  my $read_key = <STDIN>;
  exit 1;
}

open(FAKECLIP, ">$ENV{HOME}/.clip-mairix")
  or die "Couldn't open($ENV): $!\n";

foreach (@found) {
  my $URL = "<mairix://$_>";
  print FAKECLIP "$URL\n";
  print          "$URL\n";
}

close(FAKECLIP);

# print "Press enter to continue ... ";
# my $read_key = <STDIN>;
sleep 1;

exit 0; # for mutt wait_key

[-- Attachment #4: Mairix.pm --]
[-- Type: text/plain, Size: 1289 bytes --]

package Mairix;

=head1 NAME

Mairix - helpers for mairix CLI utilities

=head1 SYNOPSIS

TODO

=head1 DESCRIPTION

TODO

=cut

use strict;
use warnings;

=head2 subject_query

Turn a subject into a mairix query to retrieve mail's with related
subjects.

=cut

sub subject_query {
  my ($subject) = @_;
  my $query = normalize_subject($subject);
  $query =~ s/^\s+//g;
  $query =~ s/\s+$//g;

  my @tokens = split /\s+|[^\w]+/, $query;

#  return map "s:$_", grep { length($_) && /\w/ } @tokens;
  return 's:' . join ",", grep { length($_) && /\w/ } @tokens;
}

=head2 normalize_subject

Trim a subject of cruft accumulated as a result of replying
to/forwarding the message etc.

=cut

sub normalize_subject {
  my ($original) = @_;

  my $new = $original;
  1 while $new =~ s/^\s+//
       or $new =~ s/\s+$//
       or $new =~ s/^((Re|Fwd|Aw|Antw|Svar):|\(Fwd\))\s*//i
       or $new =~ s/^\[Fwd:\s*(.+)\s*\]$/$1/i
       or $new =~ s/\(Fwd\)$//i
       or $new =~ s/^(FYI|FYEO|FCP|AHOD|F)(:|\b)//i
       or $new =~ s/^\s*\[[\w -]+\]\s+//i
       or $new =~ s/\bv\d+(\.\d+)*(\b|$)//i;
  if ($new ne $original) {
    warn "Normalized '$original' to '$new'\n";
  }
  return $new;
}

=head1 BUGS

None, zero, nada etc.

=head1 SEE ALSO

L<mairix-wrapper>, L<mairix-copy-message>

=cut

1;

[-- Attachment #5: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Integration of Org mode and mairix

[Georg C. F. Greve]

[-- Attachment #1.1.1: Type: text/plain, Size: 658 bytes --]

On Fri, 20 Jul 2007 17:08:33 +0100
Adam Spiers <orgmode@adamspiers.org> wrote: 

 as> Funnily enough, I implemented exactly this idea about 15 months
 as> ago, except that my implementation uses mairix (the mail indexer),
 as> and is mode-agnostic.

Thanks a lot, this is most interesting and put me on the right track.

Combining your work with that of Guy Hillenius, which he blogged at
http://www.hillenius.net/node/44 I integrated Gnus, Mairix & Org now.

The core is a patch for org.el -- this patch is still somewhat
primitive, but should not break anything and unless the new variables
are changed will not change standard behaviour:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1.2: org.mairix.patch --]
[-- Type: text/x-diff, Size: 3529 bytes --]

--- org.el.orig	2007-07-22 13:52:40.000000000 +0200
+++ org.el	2007-07-22 17:44:51.000000000 +0200
@@ -1100,6 +1100,18 @@ negates this setting for the duration of
   :group 'org-link-store
   :type 'boolean)
 
+(defcustom org-gnus-links-prefer-mairix nil
+  "Non-nil means, `org-store-link' will create links to Mairix searches for gnus.
+When nil, traditional Gnus links (group & article) will be used for such links."
+  :group 'org-link-store
+  :type 'boolean)
+
+(defcustom org-mairix-links-prefer-threaded nil
+  "Non-nil means, that links to Mairix searches will be stored as thread searches.
+   When nil, the links to Mairix searches will be stored as single message searches."
+  :group 'org-link-store
+  :type 'boolean)
+
 (defgroup org-link-follow nil
   "Options concerning following links in Org-mode"
   :tag "Org Follow Link"
@@ -4141,7 +4153,7 @@ that will be added to PLIST.  Returns th
 
 (defconst org-non-link-chars "]\t\n\r<>")
 (defconst org-link-types '("http" "https" "ftp" "mailto" "file" "news" "bbdb" "vm"
-			   "wl" "mhe" "rmail" "gnus" "shell" "info" "elisp"))
+			   "wl" "mhe" "rmail" "mairix" "mairixt" "gnus" "shell" "info" "elisp"))
 (defconst org-link-re-with-space
   (concat
    "<?\\(" (mapconcat 'identity org-link-types "\\|") "\\):"
@@ -10537,14 +10549,18 @@ For file links, arg negates `org-context
 	(org-store-link-props :type "gnus" :from from :subject subject
 			      :message-id message-id :group group)
 	(setq cpltxt (org-email-link-description))
-	(if (org-xor arg org-usenet-links-prefer-google)
-	    (setq link
-		  (concat
-		   cpltxt "\n  "
-		   (format "http://groups.google.com/groups?as_umsgid=%s"
-			   (org-fixup-message-id-for-http message-id))))
-	  (setq link (org-make-link "gnus:" group
-				    "#" (number-to-string article))))))
+	(if org-gnus-links-prefer-mairix
+	    (if org-mairix-links-prefer-threaded
+		(setq link (org-make-link "mairixt:m:" (substring message-id 1 -1)))
+	      (setq link (org-make-link "mairix:m:" (substring message-id 1 -1))))
+	  (if (org-xor arg org-usenet-links-prefer-google)
+	      (setq link
+		    (concat
+		     cpltxt "\n  "
+		     (format "http://groups.google.com/groups?as_umsgid=%s"
+			     (org-fixup-message-id-for-http message-id))))
+	    (setq link (org-make-link "gnus:" group
+				    "#" (number-to-string article)))))))
 
      ((eq major-mode 'w3-mode)
       (setq cpltxt (url-view-url t)
@@ -11105,6 +11121,12 @@ optional argument IN-EMACS is non-nil, E
        ((string= type "news")
 	(org-follow-gnus-link path))
 
+       ((string= type "mairix")
+	(org-follow-mairix-link path))
+
+       ((string= type "mairixt")
+	(org-follow-mairix-link-thread path))
+
        ((string= type "bbdb")
 	(org-follow-bbdb-link path))
 
@@ -11473,6 +11495,17 @@ onto the ring."
           (Info-find-node (match-string 1 name) "Top")))
     (message (concat "Could not open: " name))))
 
+; the following two org-follow-mairix functions should be generalised 
+; to deal with the different mail readers, right now they simply hook
+; into some primitive gnus glue
+(defun org-follow-mairix-link (string)
+  "Follow a Mairix link to its string."
+  (mairix-search string))
+
+(defun org-follow-mairix-link-thread (string)
+  "Follow a Mairix link to its string."
+  (mairix-search-thread string))
+
 (defun org-follow-gnus-link (&optional group article)
   "Follow a Gnus link to GROUP and ARTICLE."
   (require 'gnus)

[-- Attachment #1.1.3: Type: text/plain, Size: 148 bytes --]


But if someone feels like improving this so it can go into mainstream
org.el, that would be great.

Right now it needs some glue in your .gnus.el


[-- Attachment #1.1.4: Type: application/emacs-lisp, Size: 1684 bytes --]

[-- Attachment #1.1.5: Type: text/plain, Size: 125 bytes --]


and you should configure .mairixrc to store its search results where
Gnus stores its nnmaildir data. Mine looks like this:


[-- Attachment #1.1.6: Type: text/plain, Size: 175 bytes --]

base=/home/greve
mbox=Archive/Mail/Auto/incoming/????-??:Archive/Mail/Auto/outgoing/????-??
mformat=maildir
mfolder=.nnmaildir/mairix
database=/home/greve/Tools/Gnus/MairixDB

[-- Attachment #1.1.7: Type: text/plain, Size: 1208 bytes --]


With this you can store Org links as mairix links, including the
possibility to store links to emails that will pull the entire thread
that contains this message into the temporary buffer -- so you'll only
need to link to one and always get the entire thread.

For convenience it also makes sense to define some key bindings.

This gives as much functionality as "normal" Gnus integration otherwise,
although now it is no longer needed to know WHERE things are stored, as
mairix will find it regardless of final location.

So this solves the most urgent problem for me with the old Gnus links
and will hopefully be useful for some others, too.

On top of this some more sophisticated integration might be set up,
although http://thread.gmane.org/gmane.emacs.orgmode/1771 does not
really help me too much, as I have multiple agenda files in which I like
to store things.

Regards,
Georg

-- 
Georg C. F. Greve                                 <greve@fsfeurope.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Join the Fellowship and protect your freedom!     (http://www.fsfe.org)
What everyone should know about DRM                   (http://DRM.info)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 306 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Is it any function similar to appoinment alert in the planner mode?

[brianjiang]

 
I have just switched from Planner to Org recent and I find the Org mode
fit my need more.  But I failed to find a function that I used a lot in
the Planner mode. The function is that a alert window is pop up (with a
beep as well) when an appointment time is coming with in a few minutes.
Is it such a function in current Org mode. If no, can we implement it?
Thanks.

Regards,
Brian

Re: Is it any function similar to appoinment alert in the planner mode?

[Bernt Hansen]

<brianjiang@gdnt.com.cn> writes:

> I have just switched from Planner to Org recent and I find the Org mode
> fit my need more.  But I failed to find a function that I used a lot in
> the Planner mode. The function is that a alert window is pop up (with a
> beep as well) when an appointment time is coming with in a few minutes.
> Is it such a function in current Org mode. If no, can we implement it?
> Thanks.

I don't believe that exists.  I'm sure it can be added - it just hasn't
been done yet.  As a workaround I just schedule reminders in the diary -
luckily I don't have too many to deal with.

Bernt

Re: Is it any function similar to appoinment alert in the planner mode?

[Bastien Guerry]

<brianjiang@gdnt.com.cn> writes:

> I have just switched from Planner to Org recent and I find the Org mode
> fit my need more.  But I failed to find a function that I used a lot in
> the Planner mode. The function is that a alert window is pop up (with a
> beep as well) when an appointment time is coming with in a few minutes.
> Is it such a function in current Org mode. If no, can we implement it?

Here is a solution that works for me.  

(defun bzg-org-agenda-to-appt ()
  "Activate appointments found in `org-agenda-files'."
  (interactive)
  (require 'org)
  (let* ((today (org-date-to-gregorian 
		 (time-to-days (current-time))))
	 (files org-agenda-files)
	 entries file)
    (while (setq file (pop files))
      (setq entries (append entries (org-agenda-get-day-entries 
				     file today :timestamp))))
    (mapc (lambda(x) 
	    (let* ((event (org-trim (get-text-property 1 'txt x)))
		   (time (number-to-string
			  (get-text-property 1 'time-of-day x)))
		   (time-st (concat (substring time 0 2) ":" 
				    (substring time 2 4))))
	      (appt-add time-st event))) entries)))

Of course you should have initialized appt and this could be hooked
somewhere. Let me know if it's okay for you.

Regards,

-- 
Bastien

Re: Is it any function similar to appoinment alert in the planner mode?

[Bastien]

[-- Attachment #1: Type: text/plain, Size: 533 bytes --]

Bastien Guerry <Bastien.Guerry@ens.fr> writes:

> <brianjiang@gdnt.com.cn> writes:
>
>> I have just switched from Planner to Org recent and I find the Org mode
>> fit my need more.  But I failed to find a function that I used a lot in
>> the Planner mode. The function is that a alert window is pop up (with a
>> beep as well) when an appointment time is coming with in a few minutes.
>> Is it such a function in current Org mode. If no, can we implement it?
>
> Here is a solution that works for me.  

Er.. this one works better:


[-- Attachment #2: bzg-org-agenda-to-appt --]
[-- Type: application/emacs-lisp, Size: 722 bytes --]

[-- Attachment #3: Type: text/plain, Size: 13 bytes --]


-- 
Bastien

[-- Attachment #4: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

RE: Is it any function similar to appoinment alert in the planner mode?

[brianjiang]

It is great! Thanks a lot :)

Regards,
Brian 

-----Original Message-----
From: Bastien Guerry [mailto:bastienguerry@googlemail.com] On Behalf Of Bastien
Sent: 2007年7月26日 15:24
To: emacs-orgmode@gnu.org
Cc: Brian Jiang
Subject: Re: [Orgmode] Is it any function similar to appoinment alert in the planner mode?

Bastien Guerry <Bastien.Guerry@ens.fr> writes:

> <brianjiang@gdnt.com.cn> writes:
>
>> I have just switched from Planner to Org recent and I find the Org 
>> mode fit my need more.  But I failed to find a function that I used a 
>> lot in the Planner mode. The function is that a alert window is pop 
>> up (with a beep as well) when an appointment time is coming with in a few minutes.
>> Is it such a function in current Org mode. If no, can we implement it?
>
> Here is a solution that works for me.  

Er.. this one works better:

Re: Is it any function similar to appoinment alert in the planner mode?

[Bastien]

[-- Attachment #1: Type: text/plain, Size: 152 bytes --]

Bastien <bzg@altern.org> writes:

>> Here is a solution that works for me.  
>
> Er.. this one works better:

Still another slightly improved version:


[-- Attachment #2: bzg-org-agenda-to-appt.el --]
[-- Type: application/emacs-lisp, Size: 872 bytes --]

[-- Attachment #3: Type: text/plain, Size: 13 bytes --]


-- 
Bastien

[-- Attachment #4: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Is it any function similar to appoinment alert in the planner mode?

[Bastien]

Bastien <bzg@altern.org> writes:

>> Er.. this one works better:
>
> Still another slightly improved version:

I'm maintaining a few Org functions here:

  http://www.cognition.ens.fr/~guerry/u/bzg-org.el
  http://www.cognition.ens.fr/~guerry/bastien-org-mode.html

-- 
Bastien

Re: Is it any function similar to appoinment alert in the planner mode?

[william]

Bastien <bzg <at> altern.org> writes:

> 
> Bastien <bzg <at> altern.org> writes:
> 
> >> Here is a solution that works for me.  
> >


This is really good! I am looking for it for a long time.

Thanks 

Re: Integration of Org mode and mairix

[Bastien]

Hi Georg and list,

"Georg C. F. Greve" <greve@fsfeurope.org> writes:

> On Fri, 20 Jul 2007 17:08:33 +0100
> Adam Spiers <orgmode@adamspiers.org> wrote: 
>
>  as> Funnily enough, I implemented exactly this idea about 15 months
>  as> ago, except that my implementation uses mairix (the mail indexer),
>  as> and is mode-agnostic.
>
> Thanks a lot, this is most interesting and put me on the right track.
>
> Combining your work with that of Guy Hillenius, which he blogged at
> http://www.hillenius.net/node/44 I integrated Gnus, Mairix & Org now.

Thanks for pointing on mairix and providing an integrated solution for
org/Gnus/mairix. I tried your patch and the mairix-related elisp code,
it works fine here.

One little fix though: if Gnus is not loaded when following a mairix
link, it returns an error. Please make `org-follow-mairix-link' and
`org-follow-mairix-link-thread' (re)loading Gnus with something like:

  (require 'gnus)
  (funcall (cdr (assq 'gnus org-link-frame-setup)))
  (if gnus-other-frame-object (select-frame gnus-other-frame-object))


The "mairix" solution is especially elegant because it does not only
handle the case where you need to find a particular email, but it also
comes with lots of useful search options.

For example, if you need to check all message explicitely sent to you in
the last three days, just add a link like:

  [[mairix:d:3d- t:me]]

If you need to find mails from Carsten with "Org" in their subjects:

  [[mairix:s:Org f:Carsten]]

Caveat: for those who want to use mairix with the `nnml' Gnus backend,
install mairix >0.17.1. Debian(-based) systems will only install 0.17
and your `nnml' folders won't be indexed.

-- 
Bastien

Re: Integration of Org mode and mairix

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 1260 bytes --]

Hi Bastien,

On Tue, 24 Jul 2007 16:38:22 +0200
Bastien <bzg@altern.org> wrote: 

 b> Thanks for pointing on mairix and providing an integrated solution
 b> for org/Gnus/mairix. I tried your patch and the mairix-related elisp
 b> code, it works fine here.

Good to know.

Do you think there is any chance it would make it into the Org package?
I would greatly prefer not having to maintain a patch for a longer
period of time.


 b> One little fix though: [...]

Ah, true. Thanks for that.


 b> The "mairix" solution is especially elegant because it does not only
 b> handle the case where you need to find a particular email, but it
 b> also comes with lots of useful search options.

I am especially happy that it allows to pull out entire threads.

So if you do [[mairixt:m:xyz]] it will pull out the entire thread in
which that message id is present, so you have the full context, which I
find very useful.

Regards,
Georg

-- 
Georg C. F. Greve                                 <greve@fsfeurope.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Join the Fellowship and protect your freedom!     (http://www.fsfe.org)
What everyone should know about DRM                   (http://DRM.info)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 306 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Integration of Org mode and mairix

[Bastien]

Hi George,

"Georg C. F. Greve" <greve@fsfeurope.org> writes:

> Do you think there is any chance it would make it into the Org
> package? I would greatly prefer not having to maintain a patch for a
> longer period of time.

I can understand that.  Carsten, what do you think?

On the one hand, mairix is unlikely to be heavily in use among Org users
(unless we continue praising it!), so there is no *strong* necessity of
making Org natively interact with it. On the other hand, you cannot
maintain mairix integration through an external library since it depends
on `org-link-types', `org-store-link' and `org-open-at-point'.

I would say it worth keeping it into Org. One request though: could we
spare the cost of a new specific type for threaded searches? For example
we could have `org-gnus-links-prefer-mairix' being either nil, 'threaded
or t, so that you can handle the thread option as an argument, even in
mairix-search.

> So if you do [[mairixt:m:xyz]] it will pull out the entire thread in
> which that message id is present, so you have the full context, which I
> find very useful.

Yes, i also like the fast intexing. Other people playing with it around?

-- 
Bastien

Re: Integration of Org mode and mairix

[Leo]

On 2007-07-30 17:02 +0100, Bastien wrote:
> "Georg C. F. Greve" <greve@fsfeurope.org> writes:
>
>> Do you think there is any chance it would make it into the Org
>> package? I would greatly prefer not having to maintain a patch for a
>> longer period of time.
>
> I can understand that.  Carsten, what do you think?

I'd prefer to use tracker¹, as it is one component of the GNU desktop --
Gnome. There are just so many random email indexing tools. If we want to
pick one, Tracker is a good choice.

Footnotes: 
¹  http://www.gnome.org/projects/tracker/
-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

Re: Re: Integration of Org mode and mairix

[Bastien]

Leo <sdl.web@gmail.com> writes:

> I'd prefer to use tracker¹, as it is one component of the GNU desktop
> -- Gnome. There are just so many random email indexing tools. If we
> want to pick one, Tracker is a good choice.

Okay. Now it seems better to me not to integrate any exotic external
tool directly within Org.

Maybe we could use something like `org-custom-link-types' to do the
trick: its need to know about new link-types, major modes where they
come into play and what function `org-open-at-point' calls for them.

For example :

(setq org-custom-link-types 
      '(("mairix" (gnus-summary-mode gnus-article-mode) 
	 'org-make-mairix-link 'org-follow-mairix-link)))

It will make Org knowing about a new "mairix" link type. When you're in
`gnus-summary-mode' or `gnus-article-mode' this type is used instead of
the default `gnus' type. `org-make-mairix-link' is used to build the
link, and `org-follow-mairix-link' is used to open link at point.  

Am not completely sure on how this could be achieved in details, but I
believe it's a better approach to the integration of tools like mairix,
tracker and the like.

What do you think?

-- 
Bastien

Re: Re: Integration of Org mode and mairix

[Xiao-Yong Jin]

Bastien <bzg@altern.org> writes:

> Maybe we could use something like `org-custom-link-types' to do the
> trick: its need to know about new link-types, major modes where they
> come into play and what function `org-open-at-point' calls for them.
>
> For example :
>
> (setq org-custom-link-types 
>       '(("mairix" (gnus-summary-mode gnus-article-mode) 
> 	 'org-make-mairix-link 'org-follow-mairix-link)))
>
> It will make Org knowing about a new "mairix" link type. When you're in
> `gnus-summary-mode' or `gnus-article-mode' this type is used instead of
> the default `gnus' type. `org-make-mairix-link' is used to build the
> link, and `org-follow-mairix-link' is used to open link at point.  
>
> Am not completely sure on how this could be achieved in details, but I
> believe it's a better approach to the integration of tools like mairix,
> tracker and the like.
>
> What do you think?

I think it's a very good idea.  And we don't even need to
restrict ourselves within index and search tools.  It could
be just an extension to `org-open-at-point'.  When the link
type is not one of the built-ins, the function uses a user
customizable `alist' of link type keywords and corresponding
user supplied functions.

However, some kind of community contributed code base must
be set up so that people like me who don't know much about
elisp can grab some code which works out of box.  And it
would be also much easier to track api changes in the main
org code.  Let's see what Carsten has to say about this,
when he comes back.

Xiao-Yong

> -- 
> Bastien
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>
>

-- 
    c/*    __o/*
    <\     * (__
    */\      <

Re: Integration of Org mode and mairix

[Jason F. McBrayer]

Bastien <bzg@altern.org> writes:

>> So if you do [[mairixt:m:xyz]] it will pull out the entire thread in
>> which that message id is present, so you have the full context, which I
>> find very useful.
>
> Yes, i also like the fast intexing. Other people playing with it around?

TBH, I haven't messed with mairix or the associated patches posted here,
even though I do need such a solution, because it doesn't look like any
of the posted solutions work with IMAP mailstores, only local mailstores
like nnml and nnmaildir.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray@carcosa.net  |
| If someone conquers a thousand times a thousand others in |
| battle, and someone else conquers himself, the latter one |
| is the greatest of all conquerors.  --- The Dhammapada    |

Re: Integration of Org mode and mairix

[Xiao-Yong Jin]

Hi, it seems I have almost missed the best thing in
this list.

Bastien <bzg@altern.org> writes:

> Hi George,
>
> "Georg C. F. Greve" <greve@fsfeurope.org> writes:
>
>> Do you think there is any chance it would make it into the Org
>> package? I would greatly prefer not having to maintain a patch for a
>> longer period of time.
>
> I can understand that.  Carsten, what do you think?

I would really appreciate it.

> On the one hand, mairix is unlikely to be heavily in use among Org users
> (unless we continue praising it!), so there is no *strong* necessity of
> making Org natively interact with it. On the other hand, you cannot
> maintain mairix integration through an external library since it depends
> on `org-link-types', `org-store-link' and `org-open-at-point'.
>
> I would say it worth keeping it into Org. One request though: could we
> spare the cost of a new specific type for threaded searches? For example
> we could have `org-gnus-links-prefer-mairix' being either nil, 'threaded
> or t, so that you can handle the thread option as an argument, even in
> mairix-search.

Probably it's the time for us to think of a universal way to
support system dependent 3rd party index tools.  Mairix may
not be the only search tool people want to use with
org-mode, though it is my favourite and only index tool I
use for now.

>> So if you do [[mairixt:m:xyz]] it will pull out the entire thread in
>> which that message id is present, so you have the full context, which I
>> find very useful.
>
> Yes, i also like the fast intexing. Other people playing with it around?

Sorry, but I missed the thread.  Where can I grab the code
for support in org-mode?

Xiao-Yong
-- 
    c/*    __o/*
    <\     * (__
    */\      <

Re: Integration of Org mode and mairix

[Georg C. F. Greve]

[-- Attachment #1.1.1: Type: text/plain, Size: 306 bytes --]

On Tue, 31 Jul 2007 12:56:18 -0400
Xiao-Yong Jin <xj2106@columbia.edu> wrote: 

 xj> Sorry, but I missed the thread.  Where can I grab the code for
 xj> support in org-mode?

Since there were small changes, allow me to repost.

This is a patch against org.el that incorporates mairix into org.el:

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1.2: org.el.mairix.patch --]
[-- Type: text/x-diff, Size: 3821 bytes --]

--- org.el.orig	2007-07-22 13:52:40.000000000 +0200
+++ org.el	2007-07-30 15:45:10.000000000 +0200
@@ -1100,6 +1100,18 @@ negates this setting for the duration of
   :group 'org-link-store
   :type 'boolean)
 
+(defcustom org-gnus-links-prefer-mairix nil
+  "Non-nil means, `org-store-link' will create links to Mairix searches for gnus.
+When nil, traditional Gnus links (group & article) will be used for such links."
+  :group 'org-link-store
+  :type 'boolean)
+
+(defcustom org-mairix-links-prefer-threaded nil
+  "Non-nil means, that links to Mairix searches will be stored as thread searches.
+   When nil, the links to Mairix searches will be stored as single message searches."
+  :group 'org-link-store
+  :type 'boolean)
+
 (defgroup org-link-follow nil
   "Options concerning following links in Org-mode"
   :tag "Org Follow Link"
@@ -4141,7 +4153,7 @@ that will be added to PLIST.  Returns th
 
 (defconst org-non-link-chars "]\t\n\r<>")
 (defconst org-link-types '("http" "https" "ftp" "mailto" "file" "news" "bbdb" "vm"
-			   "wl" "mhe" "rmail" "gnus" "shell" "info" "elisp"))
+			   "wl" "mhe" "rmail" "mairix" "mairixt" "gnus" "shell" "info" "elisp"))
 (defconst org-link-re-with-space
   (concat
    "<?\\(" (mapconcat 'identity org-link-types "\\|") "\\):"
@@ -10537,14 +10549,18 @@ For file links, arg negates `org-context
 	(org-store-link-props :type "gnus" :from from :subject subject
 			      :message-id message-id :group group)
 	(setq cpltxt (org-email-link-description))
-	(if (org-xor arg org-usenet-links-prefer-google)
-	    (setq link
-		  (concat
-		   cpltxt "\n  "
-		   (format "http://groups.google.com/groups?as_umsgid=%s"
-			   (org-fixup-message-id-for-http message-id))))
-	  (setq link (org-make-link "gnus:" group
-				    "#" (number-to-string article))))))
+	(if org-gnus-links-prefer-mairix
+	    (if org-mairix-links-prefer-threaded
+		(setq link (org-make-link "mairixt:m:" (substring message-id 1 -1)))
+	      (setq link (org-make-link "mairix:m:" (substring message-id 1 -1))))
+	  (if (org-xor arg org-usenet-links-prefer-google)
+	      (setq link
+		    (concat
+		     cpltxt "\n  "
+		     (format "http://groups.google.com/groups?as_umsgid=%s"
+			     (org-fixup-message-id-for-http message-id))))
+	    (setq link (org-make-link "gnus:" group
+				    "#" (number-to-string article)))))))
 
      ((eq major-mode 'w3-mode)
       (setq cpltxt (url-view-url t)
@@ -11105,6 +11121,12 @@ optional argument IN-EMACS is non-nil, E
        ((string= type "news")
 	(org-follow-gnus-link path))
 
+       ((string= type "mairix")
+	(org-follow-mairix-link path))
+
+       ((string= type "mairixt")
+	(org-follow-mairix-link-thread path))
+
        ((string= type "bbdb")
 	(org-follow-bbdb-link path))
 
@@ -11473,6 +11495,23 @@ onto the ring."
           (Info-find-node (match-string 1 name) "Top")))
     (message (concat "Could not open: " name))))
 
+; the following two org-follow-mairix functions should be generalised 
+; to deal with the different mail readers, right now they simply hook
+; into some primitive gnus glue
+(defun org-follow-mairix-link (string)
+  "Follow a Mairix link to its string."
+  (require 'gnus)
+  (funcall (cdr (assq 'gnus org-link-frame-setup)))
+  (if gnus-other-frame-object (select-frame gnus-other-frame-object))
+  (mairix-search string))
+
+(defun org-follow-mairix-link-thread (string)
+  "Follow a Mairix link to its string."
+  (require 'gnus)
+  (funcall (cdr (assq 'gnus org-link-frame-setup)))
+  (if gnus-other-frame-object (select-frame gnus-other-frame-object))
+  (mairix-search-thread string))
+
 (defun org-follow-gnus-link (&optional group article)
   "Follow a Gnus link to GROUP and ARTICLE."
   (require 'gnus)

[-- Attachment #1.1.3: Type: text/plain, Size: 175 bytes --]


The patch should be safe to apply in that it should not break anything.

For it to make sense you'll need to glue it into gnus with additional
code, here is the code I use:


[-- Attachment #1.1.4: Type: application/emacs-lisp, Size: 2429 bytes --]

[-- Attachment #1.1.5: Type: text/plain, Size: 565 bytes --]


Beware: This part is a cludge. It works for me, but YMMV.

It allows me to store links the normal way (C-c l) as mairix links and
insert them into my Org files normally (C-c C-l). I can also always
insert the latest SENT mail into my Org files by doing (C-c C-S-l).

Please consider all my stuff under GNU GPL v2 or later (v3 explicitly
allowed) so if someone wants to grab this and turn it into a "clean"
solution, that would be greatly appreciated.

Regards,
Georg


P.S. For completeness, and to make your life easier in trying this, this
is my .mairixrc file:

[-- Attachment #1.1.6: .mairixrc --]
[-- Type: text/plain, Size: 175 bytes --]

base=/home/greve
mbox=Archive/Mail/Auto/incoming/????-??:Archive/Mail/Auto/outgoing/????-??
database=/home/greve/Tools/Gnus/MairixDB
mformat=maildir
mfolder=.nnmaildir/mairix

[-- Attachment #1.1.7: Type: text/plain, Size: 433 bytes --]


P.P.S. In theory you can also use other backends to access mairix search
results, but I found nnmaildir to be the fastest by far.

-- 
Georg C. F. Greve                                 <greve@fsfeurope.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Join the Fellowship and protect your freedom!     (http://www.fsfe.org)
What everyone should know about DRM                   (http://DRM.info)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 306 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Integration of Org mode and mairix

[Xiao-Yong Jin]

"Georg C. F. Greve" <greve@fsfeurope.org> writes:

> On Tue, 31 Jul 2007 12:56:18 -0400
> Xiao-Yong Jin <xj2106@columbia.edu> wrote: 
>
>  xj> Sorry, but I missed the thread.  Where can I grab the code for
>  xj> support in org-mode?
>
> Since there were small changes, allow me to repost.
>
> This is a patch against org.el that incorporates mairix into org.el:
>
>
> The patch should be safe to apply in that it should not break anything.
>
> For it to make sense you'll need to glue it into gnus with additional
> code, here is the code I use:
>
>
>
> Beware: This part is a cludge. It works for me, but YMMV.
>
> It allows me to store links the normal way (C-c l) as mairix links and
> insert them into my Org files normally (C-c C-l). I can also always
> insert the latest SENT mail into my Org files by doing (C-c C-S-l).
>
> Please consider all my stuff under GNU GPL v2 or later (v3 explicitly
> allowed) so if someone wants to grab this and turn it into a "clean"
> solution, that would be greatly appreciated.
>
> Regards,
> Georg

Thanks, Georg.  It works quite well.

>
>
> P.S. For completeness, and to make your life easier in trying this, this
> is my .mairixrc file:
>
>
> P.P.S. In theory you can also use other backends to access mairix search
> results, but I found nnmaildir to be the fastest by far.

The maildir is quite cumbersome, as it makes useless
directories.  Nevertheless, I couldn't think of a way to use
other backends without letting gnus moving things around.

>
> -- 
> Georg C. F. Greve                                 <greve@fsfeurope.org>
> Free Software Foundation Europe	                 (http://fsfeurope.org)
> Join the Fellowship and protect your freedom!     (http://www.fsfe.org)
> What everyone should know about DRM                   (http://DRM.info)
> _______________________________________________
> Emacs-orgmode mailing list
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

-- 
    c/*    __o/*
    <\     * (__
    */\      <

Re: Integration of Org mode and mairix

[Bastien]

Xiao-Yong Jin <xj2106@columbia.edu> writes:

> Probably it's the time for us to think of a universal way to support
> system dependent 3rd party index tools. Mairix may not be the only
> search tool people want to use with org-mode, though it is my
> favourite and only index tool I use for now.

Please see (and comment) my suggestion here:

  http://article.gmane.org/gmane.emacs.orgmode/2563

-- 
Bastien

Re: Integration of Org mode and mairix

[Jason F. McBrayer]

Bastien <bzg@altern.org> writes:

> Xiao-Yong Jin <xj2106@columbia.edu> writes:
>
>> Probably it's the time for us to think of a universal way to support
>> system dependent 3rd party index tools. Mairix may not be the only
>> search tool people want to use with org-mode, though it is my
>> favourite and only index tool I use for now.
>
> Please see (and comment) my suggestion here:
>
>   http://article.gmane.org/gmane.emacs.orgmode/2563

I think that's basically right, though in the case of email search,
probably the best thing would be making nnir work right (and provide
nnir with a mairix backend).  nnir is supposed to provide a layer of
indirection between mail indexers and gnus, which should be enough for
org-mode needs.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray@carcosa.net  |
| If someone conquers a thousand times a thousand others in |
| battle, and someone else conquers himself, the latter one |
| is the greatest of all conquerors.  --- The Dhammapada    |

Re: Integration of Org mode and mairix

[Bastien]

jmcbray@carcosa.net (Jason F. McBrayer) writes:

>> Please see (and comment) my suggestion here:
>>
>>   http://article.gmane.org/gmane.emacs.orgmode/2563
>
> I think that's basically right, though in the case of email search,
> probably the best thing would be making nnir work right (and provide
> nnir with a mairix backend).  

Yes, that would be even better. Although I think we could have both: a
org-gnus-links-prefer-nnir option (and mairix or namazu or swish-e ...
being called by nnir.el) *and* a org-custom-link-types (if one want to
store links from within, say, a man page.)

-- 
Bastien

Re: Integration of Org mode and mairix

[Xiao-Yong Jin]

jmcbray@carcosa.net (Jason F. McBrayer) writes:

> Bastien <bzg@altern.org> writes:
>
>> Xiao-Yong Jin <xj2106@columbia.edu> writes:
>>
>>> Probably it's the time for us to think of a universal way to support
>>> system dependent 3rd party index tools. Mairix may not be the only
>>> search tool people want to use with org-mode, though it is my
>>> favourite and only index tool I use for now.
>>
>> Please see (and comment) my suggestion here:
>>
>>   http://article.gmane.org/gmane.emacs.orgmode/2563
>
> I think that's basically right, though in the case of email search,
> probably the best thing would be making nnir work right (and provide
> nnir with a mairix backend).  nnir is supposed to provide a layer of
> indirection between mail indexers and gnus, which should be enough for
> org-mode needs.
>

Perhaps we should actually suggest Carsten build nnir
support in org-mode and at the same time persuade the
maintainer of nnir.el to support mairix?  ;-)

> -- 
> +-----------------------------------------------------------+
> | Jason F. McBrayer                    jmcbray@carcosa.net  |
> | If someone conquers a thousand times a thousand others in |
> | battle, and someone else conquers himself, the latter one |
> | is the greatest of all conquerors.  --- The Dhammapada    |
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>
>

-- 
    c/*    __o/*
    <\     * (__
    */\      <

Re: Integration of Org mode and mairix

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 822 bytes --]

On Sat, 04 Aug 2007 21:44:48 -0400
Xiao-Yong Jin <xj2106@columbia.edu> wrote: 

 xj> Perhaps we should actually suggest Carsten build nnir support in
 xj> org-mode and at the same time persuade the maintainer of nnir.el to
 xj> support mairix?  ;-)

I think this could be a clean solution to the problem.

Unfortunately my time to spend on persuasion is extremely limited, but
if you CC me on the emails sent to the maintainers, I'll add my "I think
this would be a great idea" bit to it. ;)

Regards,
Georg

-- 
Georg C. F. Greve                                 <greve@fsfeurope.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Join the Fellowship and protect your freedom!     (http://www.fsfe.org)
What everyone should know about DRM                   (http://DRM.info)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 306 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Integration of Org mode and mairix

[Bastien]

[-- Attachment #1: Type: text/plain, Size: 507 bytes --]

"Georg C. F. Greve" <greve@fsfeurope.org> writes:

> On Sat, 04 Aug 2007 21:44:48 -0400
> Xiao-Yong Jin <xj2106@columbia.edu> wrote: 
>
>  xj> Perhaps we should actually suggest Carsten build nnir support in
>  xj> org-mode and at the same time persuade the maintainer of nnir.el to
>  xj> support mairix?  ;-)
>
> I think this could be a clean solution to the problem.

Here is a patch against latest org-mode 5.04 as a first attempt of
implementing custom link-types (stored in `org-link-custom-types'.)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: org.el_07082007.patch --]
[-- Type: text/x-diff, Size: 3144 bytes --]

diff --git a/org.el b/org.el
index 1fc081e..c139be1 100644
--- a/org.el
+++ b/org.el
@@ -968,6 +968,23 @@ Automatically means, when TAB or RET or C-c C-c are pressed in the line."
 The value of this is taken from the #+LINK lines.")
 (make-variable-buffer-local 'org-link-abbrev-alist-local)
 
+(defcustom org-link-custom-types nil
+  "Alist of recognized link types.  
+This types are appended to `org-link-types'.
+Each cell is of the form 
+
+  \(\"type\" \(follow-function store-function major-mode\)\)
+
+where \"type\" is the string defining the type, follow-function
+is the function that Org will call to follow these links,
+store-function the function that Org will use to store these link
+and major-mode the major mode where it's active."
+  :group 'org-link
+  :type '(repeat (list (string :tag "Type (string)       ")
+		       (function :tag "Follow function     ")
+		       (function :tag "Store function      ")
+		       (function :tag "Active in major mode"))))
+
 (defcustom org-link-abbrev-alist nil
   "Alist of link abbreviations.
 The car of each element is a string, to be replaced at the start of a link.
@@ -4140,8 +4157,11 @@ that will be added to PLIST.  Returns the string that was modified."
 (require 'font-lock)
 
 (defconst org-non-link-chars "]\t\n\r<>")
-(defconst org-link-types '("http" "https" "ftp" "mailto" "file" "news" "bbdb" "vm"
-			   "wl" "mhe" "rmail" "gnus" "shell" "info" "elisp"))
+(defconst org-link-types 
+  (append (list "http" "https" "ftp" "mailto" "file" "news" "bbdb" "vm"
+		"wl" "mhe" "rmail" "gnus" "shell" "info" "elisp")
+	  (delq nil (mapcar (lambda(x) (car x)) org-link-custom-types))))
+
 (defconst org-link-re-with-space
   (concat
    "<?\\(" (mapconcat 'identity org-link-types "\\|") "\\):"
@@ -10410,9 +10430,13 @@ For links to usenet articles, arg negates `org-usenet-links-prefer-google'.
 For file links, arg negates `org-context-in-file-links'."
   (interactive "P")
   (setq org-store-link-plist nil)  ; reset
-  (let (link cpltxt desc description search txt)
+  (let (link cpltxt desc description search txt cus)
     (cond
 
+     ((setq cus (assq major-mode (mapcar '(lambda(e) (reverse e)) 
+					 org-link-custom-types)))
+      (funcall (nth 1 cus)))
+
      ((eq major-mode 'bbdb-mode)
       (let ((name (bbdb-record-name (bbdb-current-record)))
 	    (company (bbdb-record-getprop (bbdb-current-record) 'company)))
@@ -11006,7 +11030,7 @@ optional argument IN-EMACS is non-nil, Emacs will visit the file."
   (org-remove-occur-highlights nil nil t)
   (if (org-at-timestamp-p t)
       (org-follow-timestamp-link)
-    (let (type path link line search (pos (point)))
+    (let (type path link line search (pos (point)) cus)
       (catch 'match
 	(save-excursion
 	  (skip-chars-forward "^]\n\r")
@@ -11177,7 +11201,10 @@ optional argument IN-EMACS is non-nil, Emacs will visit the file."
               (message "%s => %s" cmd (eval (read cmd)))
 	    (error "Abort"))))
 
-       (t
+       ((setq cus (assoc type org-link-custom-types))
+	(funcall (nth 1 cus) path))
+
+       (t 
 	(browse-url-at-point)))))
   (move-marker org-open-link-marker nil))
 

[-- Attachment #3: Type: text/plain, Size: 225 bytes --]


It lets you define an alist of custom link-types. See the docstring of
`org-link-custom-types'.

Then you need to define the follow/store functions by yourself. Here are
the defuns I use (in addition to Georg's mairix.el):


[-- Attachment #4: org-mairix.el --]
[-- Type: application/emacs-lisp, Size: 939 bytes --]

[-- Attachment #5: Type: text/plain, Size: 300 bytes --]


I think the nnir.el support could be provided via custom link types,
instead of being hardcoded within org.el.

Please test it and give me feedback! 

PS: i started to have a look at nnir.el to make it aware of mairix. But
i'm not sure i'll have time for this till the end of the week.

-- 
Bastien

[-- Attachment #6: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Integration of Org mode and mairix

[Carsten Dominik]

On Aug 7, 2007, at 19:54, Bastien wrote:
> Here is a patch against latest org-mode 5.04 as a first attempt of
> implementing custom link-types (stored in `org-link-custom-types'.)
>
> <org.el_07082007.patch>
> It lets you define an alist of custom link-types. See the docstring of
> `org-link-custom-types'.
>
> Then you need to define the follow/store functions by yourself. Here 
> are
> the defuns I use (in addition to Georg's mairix.el):

I have read the discussion about extending link capabilities with
great interrest, and I do like the code that has been written.
Thanks in particular to Adam Spiers and George Greve for their
inspiring mairix hack.

Here is my take on it.

First about the mairix integration.  If I understand correctly, mairix 
does
only the search, and you still do need to select a way how to display
the results.  In this case, wouldn't a syntax

   gnus:mairix:.....
   vm:mairix:.....

be better?

Then I understand that mairix is only one of many possible indexing 
tools,
so we probably should go for a general solution.  So far I have liked
the fact that many more common Emacs packages are integrated with
Org-mode right
out of the box, and that no setup steps are needed.  However, with
this indexing stuff, it seems that the time for a general extension
mechanism has come - this will also allow many other hacks.
Bastien, I looked at your code, and I want to propose to you to modify
it in the following way - making it closer to how John Wiegley has
implemented it for planner/wiki/muse.

The basic structure of an extension could look like this:

(require 'org)

(org-add-link-type "mairix" 'org-mairix-follow-link 
'org-mairix-publish-link)
(add-hook 'org-store-link-functions 'org-mairix-store-link)

(defun org-follow-mairix-link (path)
   "this will be called by org-open-at-point"
   ... )

(defun org-mairix-publish-link (path)
   "this returns something that can be used when publishing the file"
    ... )

(defun org-mairx-store-link ()
    "This function should test if it is relevant for the current buffer.
     If yes, return a link for org-store-link.  If not,
     return nil"
    )))

(provide 'org-mairix)

org-add-link-type needs to add "mairix" to the link types, and
it needs to re-make all regular expression constants that use
org-link-types, also indirectly.

org-store-link will try all functions in org-store-link-functions
in turn, maybe using run-hooks-with-args-until-success.
Only if all of them return nil, then org-mode will
check for the other, built-in link types.

So this is very similar to to what Bastien has already done, but
has the advantage the all a user needs to do is

     (require 'org-mairix)

- Carsten

Re: Integration of Org mode and mairix

[Adam Spiers]

Carsten Dominik (dominik@science.uva.nl) wrote:
> On Aug 7, 2007, at 19:54, Bastien wrote:
> >Here is a patch against latest org-mode 5.04 as a first attempt of
> >implementing custom link-types (stored in `org-link-custom-types'.)
> >
> ><org.el_07082007.patch>
> >It lets you define an alist of custom link-types. See the docstring of
> >`org-link-custom-types'.
> >
> >Then you need to define the follow/store functions by yourself. Here 
> >are the defuns I use (in addition to Georg's mairix.el):
> 
> I have read the discussion about extending link capabilities with
> great interrest, and I do like the code that has been written.
> Thanks in particular to Adam Spiers and George Greve for their
> inspiring mairix hack.

My pleasure :-)

> Here is my take on it.
> 
> First about the mairix integration.  If I understand correctly, mairix 
> does only the search, and you still do need to select a way how to display
> the results.  In this case, wouldn't a syntax
> 
>   gnus:mairix:.....
>   vm:mairix:.....
> 
> be better?

Possibly - that depends on whether any user would ever want to create
links which fired up more than one MUA; otherwise the choice of MUA
could be set with a defcustom.  I can't think of a use case for the
former, and the latter seems cleaner (and means that if you change MUA
you don't have to do a search/replace on all your links), but no doubt
someone will think of an opposing argument.

Personal plea: please bear in mind those of us who use MUAs not based
in emacs!  For example, my preferred action when following a mairix
link is to pop up a fresh xterm with `mutt -f $mairix_folder' running
inside it.

> Then I understand that mairix is only one of many possible indexing
> tools, so we probably should go for a general solution.

Agreed.

> So far I have liked the fact that many more common Emacs packages
> are integrated with Org-mode right out of the box, and that no setup
> steps are needed.  However, with this indexing stuff, it seems that
> the time for a general extension mechanism has come - this will also
> allow many other hacks.  Bastien, I looked at your code, and I want
> to propose to you to modify it in the following way - making it
> closer to how John Wiegley has implemented it for planner/wiki/muse.

This leads to the other point I wanted to make, although its scope is
possibly too great for this list: I would greatly prefer any such
solution to allow hyperlinking from within other modes - muse in
particular.  Perhaps this could be done via orgstruct, or maybe the
org and muse camps could get together and agree to standardize on a
single syntax for hyperlinking, e.g. implemented via a shared minor
mode.  Wishful thinking?  I don't know, but it does strike me that
there is some duplication of effort across not just org and muse,
but also browse-url.el and possibly others.  

Incidentally, I think it's great that org-mode already uses URL-like
locators for external links.  This would be a good foundation for a
unification project.

Re: Integration of Org mode and mairix

[Carsten Dominik]

On Aug 14, 2007, at 13:29, Adam Spiers wrote:
>> In this case, wouldn't a syntax
>>
>>   gnus:mairix:.....
>>   vm:mairix:.....
>>
>> be better?
>
> Possibly - that depends on whether any user would ever want to create
> links which fired up more than one MUA

With the possible exception that you'd like GNUS for usenet messages
and some mailing application for your mail?

> I can't think of a use case for the
> former, and the latter seems cleaner (and means that if you change MUA
> you don't have to do a search/replace on all your links),

This is a good point.

> Personal plea: please bear in mind those of us who use MUAs not based
> in emacs!  For example, my preferred action when following a mairix
> link is to pop up a fresh xterm with `mutt -f $mairix_folder' running
> inside it.

Yes, this should be made possible.

>> So far I have liked the fact that many more common Emacs packages
>> are integrated with Org-mode right out of the box, and that no setup
>> steps are needed.  However, with this indexing stuff, it seems that
>> the time for a general extension mechanism has come - this will also
>> allow many other hacks.  Bastien, I looked at your code, and I want
>> to propose to you to modify it in the following way - making it
>> closer to how John Wiegley has implemented it for planner/wiki/muse.
>
> This leads to the other point I wanted to make, although its scope is
> possibly too great for this list: I would greatly prefer any such
> solution to allow hyperlinking from within other modes - muse in
> particular.  Perhaps this could be done via orgstruct, or maybe the
> org and muse camps could get together and agree to standardize on a
> single syntax for hyperlinking, e.g. implemented via a shared minor
> mode.


What are the differences?  The basic structure

[[link][description]]

is already the same.  So I guess you are referring to things like
how the message-id is attached to the link, and how targets are 
specified?

It is certainly possible to write a command that would correctly open
an Org-mode style link in any buffer.  Could even be a separate minor
mode, just for this one command.  I'll take a look.


- Carsten

Re: Integration of Org mode and mairix

[Carsten Dominik]

On Aug 14, 2007, at 13:29, Adam Spiers wrote:

> This leads to the other point I wanted to make, although its scope is
> possibly too great for this list: I would greatly prefer any such
> solution to allow hyperlinking from within other modes - muse in
> particular.

It may not be feasible to convince the different authors to use a single
format for links.  However, what I can offer is commands that allow you 
to
use Org-mode-style links in any mode.  Mind - these links might not be
published correctly by muse - but maybe the Muse-maintainers can be
persuaded to handle Org-mode links as well.

Here are the commands, currently they will only work
if orgstruct-mode has been activated at least once during the
current Emacs session (because a special variable needs to be
initialized).  In 5.05, these commands will be part of org.el
and work independently of orgstruct-mode.

(defun org-open-at-point-global ()
   "Follow a link like Org-mode does.
This command can be called in any mode to follow a link that has
Org-mode syntax."
   (interactive)
   (org-run-like-in-org-mode 'org-open-at-point))

(defun org-insert-link-global ()
   "Insert a link like Org-mode does.
This command can be called in any mode to follow a link that has
Org-mode syntax."
   (interactive)
   (org-run-like-in-org-mode 'org-insert-link))

- Carsten

Re: Integration of Org mode and mairix

[Steven Lumos]

Carsten Dominik <dominik@science.uva.nl> writes:
> On Aug 7, 2007, at 19:54, Bastien wrote:
>> Here is a patch against latest org-mode 5.04 as a first attempt of
>> implementing custom link-types (stored in `org-link-custom-types'.)
>>
>> <org.el_07082007.patch>
>> It lets you define an alist of custom link-types. See the docstring of
>> `org-link-custom-types'.
>>
>> Then you need to define the follow/store functions by yourself. Here
>> are
>> the defuns I use (in addition to Georg's mairix.el):
>
> I have read the discussion about extending link capabilities with
> great interrest, and I do like the code that has been written.
> Thanks in particular to Adam Spiers and George Greve for their
> inspiring mairix hack.
>
> Here is my take on it.
>
> First about the mairix integration.  If I understand correctly, mairix
> does
> only the search, and you still do need to select a way how to display
> the results.  In this case, wouldn't a syntax
>
>   gnus:mairix:.....
>   vm:mairix:.....
>
> be better?

I have not been following very closely, so sorry if this is redundant.
I currently use mairix through org-follow-mhe-link, although I had to
do a little hacking to make MH-E do a search by message-id.

It all works great for me, but I think it would be nice if following a
link didn't depend on what MUA or search I happen to use.  Couldn't it
easily enough be mail:...? Then I could send an Org file to a friend
and the link will Just Work for them.

Steve

Re: Re: Integration of Org mode and mairix

[Carsten Dominik]

On Aug 15, 2007, at 0:54, Steven Lumos wrote:

> I have not been following very closely, so sorry if this is redundant.
> I currently use mairix through org-follow-mhe-link, although I had to
> do a little hacking to make MH-E do a search by message-id.

Interesting, maybe you would like to share your hack?

>
> It all works great for me, but I think it would be nice if following a
> link didn't depend on what MUA or search I happen to use.  Couldn't it
> easily enough be mail:...? Then I could send an Org file to a friend
> and the link will Just Work for them.

That would not work universally either, for example on a windows 
machine.

- Carsten

Re: Integration of Org mode and mairix

[Steven Lumos]

Carsten Dominik <dominik@science.uva.nl> writes:
> On Aug 15, 2007, at 0:54, Steven Lumos wrote:
>
>> I have not been following very closely, so sorry if this is redundant.
>> I currently use mairix through org-follow-mhe-link, although I had to
>> do a little hacking to make MH-E do a search by message-id.
>
> Interesting, maybe you would like to share your hack?

Well...  It's not really useful to add to org, and guaranteed to break
for anyone not using mairix for MH-E searching, but here it is.  The
only change is prefixing the message-id with m:.

(defun org-follow-mhe-link (folder article)
  "Follow an MHE link to FOLDER and ARTICLE.
If ARTICLE is nil FOLDER is shown.  If the configuration variable
`org-mhe-search-all-folders' is t and `mh-searcher' is pick,
ARTICLE is searched in all folders.  Indexed searches (swish++,
namazu, and others supported by MH-E) will always search in all
folders."
  (require 'mh-e)
  (require 'mh-search)
  (require 'mh-utils)
  (mh-find-path)
  (if (not article)
      (mh-visit-folder (mh-normalize-folder-name folder))
    (mh-search-choose)
    (if (equal mh-searcher 'pick)
        (progn
          (mh-search folder (list "--message-id" article))
          (when (and org-mhe-search-all-folders
                     (not (org-mhe-get-message-real-folder)))
            (kill-this-buffer)
            (mh-search "+" (list "--message-id" article))))
      (mh-search "+" (list (concat "m:" article)))
    (if (org-mhe-get-message-real-folder)
        (mh-show-msg 1)
      (kill-this-buffer)
      (error "Message not found")))))

>> It all works great for me, but I think it would be nice if following a
>> link didn't depend on what MUA or search I happen to use.  Couldn't it
>> easily enough be mail:...? Then I could send an Org file to a friend
>> and the link will Just Work for them.
>
> That would not work universally either, for example on a windows
> machine.
>
> - Carsten

I'm a non-Windows person, but in theory I think I could write a
program that would drive Outlook or whatever (even Google Desktop
Search?) through COM to bring up a message by message-id.

Likewise, you could probably snarf the message-id of the currently
displayed message from Outlook for org-store-outlook-link. :-)

Steve

Re: Integration of Org mode and mairix

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 2036 bytes --]

Hi all,

did this thread come to a conclusion? I just checked out 5.09 and could
not find any of the patches applied to it, so would assume that it is
still hanging in mid-air.

Based on a few months of experience with my patches, here is my take:

On Fri, 10 Aug 2007 08:56:45 +0200
Carsten Dominik <dominik@science.uva.nl> wrote: 

 cd> First about the mairix integration.  If I understand correctly,
 cd> mairix does only the search, and you still do need to select a way
 cd> how to display the results.  In this case, wouldn't a syntax

 cd>   gnus:mairix:.....
 cd>   vm:mairix:.....

 cd> be better?

Not necessarily, it would make the link dependent on the MUA, which
would otherwise not be the case. People probably don't switch back and
forth all the time, but still it might be better to not code this into
the system.

A kind of generic "org-visit-search-results" that can be set to whatever
method is being used with sane defaults might be a cleaner solution.

Having a generic link-creation and link-visiting structure into which
one can hook the different backends should be the way to go, I guess.

Initially I also had a "mairix with thread" and "mairix without thread"
link type, but now find myself thinking that it would be better to only
have a mairix link and decide during search whether or not to use
threads or influence other search parameters.


 cd> The basic structure of an extension could look like this:

Yeah, I think this would work.

Is there already a patch out there? Can someone supply a "clean" patch
for this that will make it into Org-Mode? I'm willing to have another
look at this, but would prefer to work against a proper target.

Regards,
Georg

-- 
Georg C. F. Greve                                 <greve@fsfeurope.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Join the Fellowship and protect your freedom!     (http://www.fsfe.org)
What everyone should know about DRM                   (http://DRM.info)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 306 bytes --]

[-- Attachment #2: Type: text/plain, Size: 204 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Integration of Org mode and mairix

[Carsten Dominik]

On Sep 23, 2007, at 10:44, Georg C. F. Greve wrote:

> Hi all,
>
> did this thread come to a conclusion? I just checked out 5.09 and could
> not find any of the patches applied to it, so would assume that it is
> still hanging in mid-air.

Well, there are now all the hooks in org-mode to introduce new link 
types.
So from my side, this have come to some kind of a conclusion - I just
hope that mairix and other link types will pop up eventually.

- Carsten


>
> Based on a few months of experience with my patches, here is my take:
>
> On Fri, 10 Aug 2007 08:56:45 +0200
> Carsten Dominik <dominik@science.uva.nl> wrote:
>
>  cd> First about the mairix integration.  If I understand correctly,
>  cd> mairix does only the search, and you still do need to select a way
>  cd> how to display the results.  In this case, wouldn't a syntax
>
>  cd>   gnus:mairix:.....
>  cd>   vm:mairix:.....
>
>  cd> be better?
>
> Not necessarily, it would make the link dependent on the MUA, which
> would otherwise not be the case. People probably don't switch back and
> forth all the time, but still it might be better to not code this into
> the system.
>
> A kind of generic "org-visit-search-results" that can be set to 
> whatever
> method is being used with sane defaults might be a cleaner solution.
>
> Having a generic link-creation and link-visiting structure into which
> one can hook the different backends should be the way to go, I guess.
>
> Initially I also had a "mairix with thread" and "mairix without thread"
> link type, but now find myself thinking that it would be better to only
> have a mairix link and decide during search whether or not to use
> threads or influence other search parameters.
>
>
>  cd> The basic structure of an extension could look like this:
>
> Yeah, I think this would work.
>
> Is there already a patch out there? Can someone supply a "clean" patch
> for this that will make it into Org-Mode? I'm willing to have another
> look at this, but would prefer to work against a proper target.
>
> Regards,
> Georg
>
> -- 
> Georg C. F. Greve                                 <greve@fsfeurope.org>
> Free Software Foundation Europe	                 (http://fsfeurope.org)
> Join the Fellowship and protect your freedom!     (http://www.fsfe.org)
> What everyone should know about DRM                   (http://DRM.info)
>

--
Carsten Dominik
Sterrenkundig Instituut "Anton Pannekoek"
Universiteit van Amsterdam
Kruislaan 403
NL-1098SJ Amsterdam
phone: +31 20 525 7477

Re: Integration of Org mode and mairix

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 866 bytes --]

On Sun, 23 Sep 2007 11:12:09 -0700
Carsten Dominik <carsten.dominik@gmail.com> wrote: 

 cd> Well, there are now all the hooks in org-mode to introduce new link
 cd> types.  So from my side, this have come to some kind of a
 cd> conclusion - I just hope that mairix and other link types will pop
 cd> up eventually.

I've looked for the function names that you suggested in your mails, but
did not see them. A quick glance also did not seem to make it obvious
where to hook this in.

Could you maybe give me a hint where to look?

Best regards,
Georg

-- 
Georg C. F. Greve                                 <greve@fsfeurope.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Join the Fellowship and protect your freedom!     (http://www.fsfe.org)
What everyone should know about DRM                   (http://DRM.info)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 306 bytes --]

[-- Attachment #2: Type: text/plain, Size: 204 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Integration of Org mode and mairix

[Carsten Dominik]

On Sep 23, 2007, at 14:50, Georg C. F. Greve wrote:

> On Sun, 23 Sep 2007 11:12:09 -0700
> Carsten Dominik <carsten.dominik@gmail.com> wrote:
>
>  cd> Well, there are now all the hooks in org-mode to introduce new 
> link
>  cd> types.  So from my side, this have come to some kind of a
>  cd> conclusion - I just hope that mairix and other link types will pop
>  cd> up eventually.
>
> I've looked for the function names that you suggested in your mails, 
> but
> did not see them. A quick glance also did not seem to make it obvious
> where to hook this in.
>
> Could you maybe give me a hint where to look?

http://orgmode.org/org.html#Adding-hyperlink-types


- Carsten

Re: Integration of Org mode and mairix

[Georg C. F. Greve]

[-- Attachment #1.1.1: Type: text/plain, Size: 955 bytes --]

On Sun, 23 Sep 2007 15:05:31 -0700
Carsten Dominik <carsten.dominik@gmail.com> wrote: 

 cd> http://orgmode.org/org.html#Adding-hyperlink-types

Thanks a lot.

I now created org-mairix-gnus.el to hook mairix into Org mode using Gnus
as the MUA. This is essentially the same functionality (minus threading
capabilities) so it can be used instead of the patch. A simple

(require 'org-mairix-gnus)

in your .gnus should do the job.

Prerequisites are that mairix is set up, and that the variable

              mairix-gnus-results-group

is set to whatever you're using to display mairix search results.

I'd still like to clean up the code, however, and am wondering about
potential threaded search. Would it be possible to

 a) give additional arguments to the function to open the link?

or

 b) have different functions to follow the link?

It strikes me that a might be much easier than b, though.

Regards,
Georg



[-- Attachment #1.1.2: org-mairix-gnus.el --]
[-- Type: application/emacs-lisp, Size: 1806 bytes --]

[-- Attachment #1.1.3: Type: text/plain, Size: 299 bytes --]


-- 
Georg C. F. Greve                                 <greve@fsfeurope.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Join the Fellowship and protect your freedom!     (http://www.fsfe.org)
What everyone should know about DRM                   (http://DRM.info)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 306 bytes --]

[-- Attachment #2: Type: text/plain, Size: 204 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Integration of Org mode and mairix

[Carsten Dominik]

On Sep 24, 2007, at 10:38, Georg C. F. Greve wrote:

> I now created org-mairix-gnus.el to hook mairix into Org mode using 
> Gnus
> as the MUA. This is essentially the same functionality (minus threading
> capabilities) so it can be used instead of the patch. A simple
>
> (require 'org-mairix-gnus)
>
> in your .gnus should do the job.
>
> Prerequisites are that mairix is set up, and that the variable
>
>               mairix-gnus-results-group
>
> is set to whatever you're using to display mairix search results.
>
> I'd still like to clean up the code, however, and am wondering about
> potential threaded search. Would it be possible to
>
>  a) give additional arguments to the function to open the link?
>
> or
>
>  b) have different functions to follow the link?
>
> It strikes me that a might be much easier than b, though.

It is entirely up to you to define the syntax for this and
process arguments.  The function org-mairix-gnus-open will
be called with whatever was after the "mairix:" tag in the
link.  Just define your own syntax for passing arguments, like

    [[mairix:<message-id> -thread -verbose -new-frame]]

and process it in org-mairix-gnus-open.

- Carsten

Re: Integration of Org mode and mairix

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 965 bytes --]

On Tue, 25 Sep 2007 07:41:13 -0700
Carsten Dominik <carsten.dominik@gmail.com> wrote: 

 cd> It is entirely up to you to define the syntax for this and process
 cd> arguments.  The function org-mairix-gnus-open will be called with
 cd> whatever was after the "mairix:" tag in the link.  Just define your
 cd> own syntax for passing arguments, like

 cd>    [[mairix:<message-id> -thread -verbose -new-frame]]

 cd> and process it in org-mairix-gnus-open.

Yes, but this would be link based, instead of "per search" which is what
I was considering. But maybe that is actually not necessary. I'll give
this one a little more thought.

Regards,
Georg

-- 
Georg C. F. Greve                                 <greve@fsfeurope.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Join the Fellowship and protect your freedom!     (http://www.fsfe.org)
What everyone should know about DRM                   (http://DRM.info)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 306 bytes --]

[-- Attachment #2: Type: text/plain, Size: 204 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Integration of Org mode and mairix

[Carsten Dominik]

On Sep 25, 2007, at 15:25, Georg C. F. Greve wrote:

> On Tue, 25 Sep 2007 07:41:13 -0700
> Carsten Dominik <carsten.dominik@gmail.com> wrote:
>
>  cd> It is entirely up to you to define the syntax for this and process
>  cd> arguments.  The function org-mairix-gnus-open will be called with
>  cd> whatever was after the "mairix:" tag in the link.  Just define 
> your
>  cd> own syntax for passing arguments, like
>
>  cd>    [[mairix:<message-id> -thread -verbose -new-frame]]
>
>  cd> and process it in org-mairix-gnus-open.
>
> Yes, but this would be link based, instead of "per search" which is 
> what
> I was considering. But maybe that is actually not necessary. I'll give
> this one a little more thought.


Ah, I misunderstood.  Right.

- Carsten

Re: Integration of Org mode and Gnus

[Jason F. McBrayer]

Bastien <bzg@altern.org> writes:

> Anyway, i think gnus-registry comes in handy here.

It looks like that may indeed be the way forward, if it will let you
follow a link by message-id rather than group.  I'm not clear on the
specifics of how you'd set it up, though.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray@carcosa.net  |
| If someone conquers a thousand times a thousand others in |
| battle, and someone else conquers himself, the latter one |
| is the greatest of all conquerors.  --- The Dhammapada    |

Re: Integration of Org mode and Gnus

[Bastien]

[-- Attachment #1: Type: text/plain, Size: 698 bytes --]

jmcbray@carcosa.net (Jason F. McBrayer) writes:

> Bastien <bzg@altern.org> writes:
>
>> Anyway, i think gnus-registry comes in handy here.
>
> It looks like that may indeed be the way forward, if it will let you
> follow a link by message-id rather than group.  I'm not clear on the
> specifics of how you'd set it up, though.

Not fully tested yet, but this patch is a first attempt to implement
this.

It uses message-id instead of message number to store Gnus links. If
gnus-registry is on, it fetches location of the article depending on
gnus-registry-alist.  It's compatible with old Gnus links.

The problem is gnus-registry-alist can be huge, and access to article
might be somewhat slow.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: org-gnus-links.patch --]
[-- Type: text/x-diff, Size: 1145 bytes --]

--- org.el.orig	2007-07-13 15:10:47.000000000 +0200
+++ org.el	2007-07-18 13:48:38.000000000 +0200
@@ -10509,7 +10509,7 @@
 		   (format "http://groups.google.com/groups?as_umsgid=%s"
 			   (org-fixup-message-id-for-http message-id))))
 	  (setq link (org-make-link "gnus:" group
-				    "#" (number-to-string article))))))
+				    "#" (org-remove-angle-brackets message-id))))))
 
      ((eq major-mode 'w3-mode)
       (setq cpltxt (url-view-url t)
@@ -11444,8 +11444,14 @@
   (funcall (cdr (assq 'gnus org-link-frame-setup)))
   (if gnus-other-frame-object (select-frame gnus-other-frame-object))
   (cond ((and group article)
+	 (if (string-match "@" article)
+	     (when (boundp 'gnus-registry-alist)
+	       (gnus-registry-initialize)
+	       (setq group (caddr (assoc (concat "<" article ">")
+					 gnus-registry-alist))))
+	   (setq article (string-to-number article)))
 	 (gnus-group-read-group 1 nil group)
-	 (gnus-summary-goto-article (string-to-number article) nil t))
+	 (gnus-summary-goto-article article nil t))
 	(group (gnus-group-jump-to-group group))))
 
 (defun org-follow-vm-link (&optional folder article readonly)

[-- Attachment #3: Type: text/plain, Size: 49 bytes --]


Let me know if this is convenient.

-- 
Bastien

[-- Attachment #4: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Integration of Org mode and Gnus

[Jason F. McBrayer]

Bastien <bzg@altern.org> writes:

> Not fully tested yet, but this patch is a first attempt to implement
> this.
>
> It uses message-id instead of message number to store Gnus links. If
> gnus-registry is on, it fetches location of the article depending on
> gnus-registry-alist.  It's compatible with old Gnus links.
>
> The problem is gnus-registry-alist can be huge, and access to article
> might be somewhat slow.

This looks good; I'll give it a test when I get the chance.  Not sure
"somewhat slow" will be a problem, since jumping to a specific article
in gnus is already somewhat inherently slow.

If it is a problem, maybe gnus-registry can be written to use hashtables
from hash.el (http://www.math.utah.edu/pub/emacs/hash-1.00.tar.gz)
instead of an alist?

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray@carcosa.net  |
| If someone conquers a thousand times a thousand others in |
| battle, and someone else conquers himself, the latter one |
| is the greatest of all conquerors.  --- The Dhammapada    |

Re: Integration of Org mode and Gnus

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 1384 bytes --]

On Wed, 18 Jul 2007 14:01:06 +0200
Bastien <bzg@altern.org> wrote: 

 b> Not fully tested yet, but this patch is a first attempt to implement
 b> this.

Just tried it.

The patch applies cleanly, and old links still work.

But when I try to follow a link to

  gnus:nnfolder+archive+incoming:2007-07#<20070718095834.109112202E9@quill.bollow.ch>

I see this in *Messages*:

  Retrieving newsgroup: nnml:gnu.ml.emacs.orgmode...
  Fetching headers for nnml:gnu.ml.emacs.orgmode...done
  Suppressing duplicates...done
  Scoring...done
  Generating summary...done
  No more unread articles
  Couldn't fetch article <20070718095834.109112202E9@quill.bollow.ch>

So it seems to look into the wrong group.


 b> It uses message-id instead of message number to store Gnus links. If
 b> gnus-registry is on, it fetches location of the article depending on
 b> gnus-registry-alist.

Considering that gnus-registry-alist can slow down Gnus considerably and
I normally don't use it, I'd ask to always ensure it does not depend on
it. Please. :)

Regards,
Georg

-- 
Georg C. F. Greve                                 <greve@fsfeurope.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Join the Fellowship and protect your freedom!     (http://www.fsfe.org)
What everyone should know about DRM                   (http://DRM.info)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 306 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Integration of Org mode and Gnus

[Bastien]

"Georg C. F. Greve" <greve@fsfeurope.org> writes:

> I see this in *Messages*:
>
>   Retrieving newsgroup: nnml:gnu.ml.emacs.orgmode...
>   Fetching headers for nnml:gnu.ml.emacs.orgmode...done
>   Suppressing duplicates...done
>   Scoring...done
>   Generating summary...done
>   No more unread articles
>   Couldn't fetch article <20070718095834.109112202E9@quill.bollow.ch>
>
> So it seems to look into the wrong group.

I found out that the registry is not up-to-date until you save the
~/gnus.registry.el.  

Replace `gnus-registry-initialize' by `gnus-registry-save' in the patch
before. It should be okay - unless there are special issues with virtual
groups.

> Considering that gnus-registry-alist can slow down Gnus considerably
> and I normally don't use it, I'd ask to always ensure it does not
> depend on it. Please. :)

I still think using gnus-registry might be a good solution, even if it
requires making access to `gnus-registry-alist' more efficient.

Best,

-- 
Bastien

Re: Integration of Org mode and Gnus

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 809 bytes --]

On Wed, 18 Jul 2007 17:39:54 +0200
Bastien <bzg@altern.org> wrote: 

 b> I found out that the registry is not up-to-date until you save the
 b> ~/gnus.registry.el.

 b> Replace `gnus-registry-initialize' by `gnus-registry-save' in the
 b> patch before. It should be okay - unless there are special issues
 b> with virtual groups.

I see.

But doesn't this require for the article to be in the registry, still?

What happens if the article has been pushed out of the registry?

Regards,
Georg

-- 
Georg C. F. Greve                                 <greve@fsfeurope.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Join the Fellowship and protect your freedom!     (http://www.fsfe.org)
What everyone should know about DRM                   (http://DRM.info)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 306 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Integration of Org mode and Gnus

[Bastien]

"Georg C. F. Greve" <greve@fsfeurope.org> writes:

> But doesn't this require for the article to be in the registry, still?

Yes it does. 

> What happens if the article has been pushed out of the registry?

If you set `gnus-registry-max-entries' to a reasonably large number (say
5000) the registry will keep track of these 5000 articles. Beyond this
number I suppose it makes more sense to use the nnir.el interface.

Yet another solution would be to have an Org registry.

All links in an Org project would be stored in this registry (so that
being on a mail, you can ask yourself "Is it somewhere in one of my org
file?") and moving articles in Gnus would help syncing the registry and
the org file.

But er.. that's more than a small patch :)

Best,

PS: i wrote a registry for planner, and already suggested it for org
here: http://article.gmane.org/gmane.emacs.orgmode/1534/match=registry

-- 
Bastien

Re: Integration of Org mode and Gnus

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 1903 bytes --]

On Thu, 19 Jul 2007 00:06:04 +0200
Bastien <bzg@altern.org> wrote: 

 >> But doesn't this require for the article to be in the registry, still?

 b> Yes it does. 

That means the registry would not solve my problem, really.

Sometimes I'll keep mails "task storage" for weeks, and also like to
refer to emails for archival purposes in some cases.


 b> Beyond this number I suppose it makes more sense to use the nnir.el
 b> interface.

It might make sense to have the chance to save searches as URLs in Org
for various things.

For the problem at hand it seems inelegant, though, as it is too reliant
on a rather complex and cpu hungry indexing system. I'd prefer things
leaner.


 b> Yet another solution would be to have an Org registry.

Yes. But there might be another solution, too.

Ultimately, the problem is caused by the Gnus backend not reporting
where it stored the article. So instead of doing a search every time one
tries to access the mail, one might do a search during storing time.

This could work by hooking a routine into

  gnus-summary-article-move-hook

that would record the message IDs of the articles moved into a temporary
list. After gnus-summary-move-article returns, the list is parsed for
the message IDs and the target group is searched for those IDs. The
resulting URLs are then saved into the Org link storage.

This would make up a "org-gnus-move-and-link-article" routine, which
could then be called directly or in the customisation that has been
posted to this list some time ago.

What do you think?

Regards,
Georg

-- 
Georg C. F. Greve                                 <greve@fsfeurope.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Join the Fellowship and protect your freedom!     (http://www.fsfe.org)
What everyone should know about DRM                   (http://DRM.info)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 306 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Integration of Org mode and Gnus

[Carsten Dominik]

Hi Bastien,

I'd like to accept a patch that does this and keeps the old links
working.  After this discussion has converged, could you send me the
final patch against a 5.xx version or org-mode?

Thanks a lot.

- Carsten

On Jul 18, 2007, at 17:39, Bastien wrote:

> "Georg C. F. Greve" <greve@fsfeurope.org> writes:
>
>> I see this in *Messages*:
>>
>>   Retrieving newsgroup: nnml:gnu.ml.emacs.orgmode...
>>   Fetching headers for nnml:gnu.ml.emacs.orgmode...done
>>   Suppressing duplicates...done
>>   Scoring...done
>>   Generating summary...done
>>   No more unread articles
>>   Couldn't fetch article <20070718095834.109112202E9@quill.bollow.ch>
>>
>> So it seems to look into the wrong group.
>
> I found out that the registry is not up-to-date until you save the
> ~/gnus.registry.el.
>
> Replace `gnus-registry-initialize' by `gnus-registry-save' in the patch
> before. It should be okay - unless there are special issues with 
> virtual
> groups.
>
>> Considering that gnus-registry-alist can slow down Gnus considerably
>> and I normally don't use it, I'd ask to always ensure it does not
>> depend on it. Please. :)
>
> I still think using gnus-registry might be a good solution, even if it
> requires making access to `gnus-registry-alist' more efficient.
>
> Best,
>
> -- 
> Bastien
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>
>

--
Carsten Dominik
Sterrenkundig Instituut "Anton Pannekoek"
Universiteit van Amsterdam
Kruislaan 403
NL-1098SJ Amsterdam
phone: +31 20 525 7477

Re: Integration of Org mode and Gnus

[Bastien]

[-- Attachment #1: Type: text/plain, Size: 298 bytes --]

Hi Carsten,

Carsten Dominik <dominik@science.uva.nl> writes:

> I'd like to accept a patch that does this and keeps the old links
> working.  After this discussion has converged, could you send me the
> final patch against a 5.xx version or org-mode?

Here it is. This patch is against Org 5.03.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: org-gnus-link.patch --]
[-- Type: text/x-diff, Size: 1139 bytes --]

--- org.el.orig	2007-07-13 15:10:47.000000000 +0200
+++ org.el	2007-07-18 17:33:21.000000000 +0200
@@ -10509,7 +10509,7 @@
 		   (format "http://groups.google.com/groups?as_umsgid=%s"
 			   (org-fixup-message-id-for-http message-id))))
 	  (setq link (org-make-link "gnus:" group
-				    "#" (number-to-string article))))))
+				    "#" (org-remove-angle-brackets message-id))))))
 
      ((eq major-mode 'w3-mode)
       (setq cpltxt (url-view-url t)
@@ -11444,8 +11444,14 @@
   (funcall (cdr (assq 'gnus org-link-frame-setup)))
   (if gnus-other-frame-object (select-frame gnus-other-frame-object))
   (cond ((and group article)
+	 (if (string-match "@" article)
+	     (when (boundp 'gnus-registry-alist)
+	       (gnus-registry-save)
+	       (setq group (caddr (assoc (concat "<" article ">")
+					 gnus-registry-alist))))
+	   (setq article (string-to-number article)))
 	 (gnus-group-read-group 1 nil group)
-	 (gnus-summary-goto-article (string-to-number article) nil t))
+	 (gnus-summary-goto-article article nil t))
 	(group (gnus-group-jump-to-group group))))
 
 (defun org-follow-vm-link (&optional folder article readonly)

[-- Attachment #3: Type: text/plain, Size: 23 bytes --]


Regards,

-- 
Bastien

[-- Attachment #4: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Integration of Org mode and Gnus

[Tassilo Horn]

"Georg C. F. Greve" <greve@fsfeurope.org> writes:

Hi Georg,

> Moving email is trivial -- you just need to call
>
>  gnus-summary-move-article
>
> to move things to the place you want to archive them. But that
> function does not return the URL of the moved article (as one might
> hope).

Would that help?

This could be implemented very easy. As far as I can see nothing depends
on the current return value of `gnus-summary-move-article'.

Bye,
Tassilo
-- 
A morning without coffee is like something without something else.

Re: Re: Integration of Org mode and Gnus

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 918 bytes --]

On Wed, 18 Jul 2007 12:20:06 +0200
Tassilo Horn <tassilo@member.fsf.org> wrote: 

 >> to move things to the place you want to archive them. But that
 >> function does not return the URL of the moved article (as one might
 >> hope).

 th> Would that help?

Yes, I think so.

Although I think the function supports moving several marked articles,
so the return value should technically be a list.

But otherwise yes: This would help me solve my immediate problem. :)


 th> This could be implemented very easy.

If you could do that and submit it back to Gnus, that would be great.

Regards,
Georg

-- 
Georg C. F. Greve                                 <greve@fsfeurope.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Join the Fellowship and protect your freedom!     (http://www.fsfe.org)
What everyone should know about DRM                   (http://DRM.info)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 306 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Integration of Org mode and Gnus

[Tassilo Horn]

"Georg C. F. Greve" <greve@fsfeurope.org> writes:

Hi Georg,

>  th> Would that help?
>
> Yes, I think so.
>
> Although I think the function supports moving several marked articles,
> so the return value should technically be a list.

As far as I can see it can only move several articles to exactly one
group.

>  th> This could be implemented very easy.
>
> If you could do that and submit it back to Gnus, that would be great.

I just found out that this is not needed. You can use the
`gnus-summary-article-move-hook'. Each function of that hook will be run
with the arguments

    - action: move/copy/respool/crosspost
    - Some data vector, dunno its use...
    - original group
    - destination group
    - select method

So you could write a delegate function that first add-hooks a function
that sets a custom variable to the destination group. Then it calls
`gnus-summary-move-article'. When that returns you can create the
org-link and remove the function from the hook again.

Bye,
Tassilo
-- 
No person,  no idea, and no  religion deserves to be  illegal to insult,
not even the Church of Emacs. (Richard M. Stallman)

Re: Re: Integration of Org mode and Gnus

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 1953 bytes --]

On Wed, 18 Jul 2007 13:55:30 +0200
Tassilo Horn <tassilo@member.fsf.org> wrote: 

 >> Although I think the function supports moving several marked
 >> articles, so the return value should technically be a list.

 th> As far as I can see it can only move several articles to exactly
 th> one group.

Yes, exactly.


 >> If you could do that and submit it back to Gnus, that would be
 >> great.

 th> I just found out that this is not needed. You can use the
 th> `gnus-summary-article-move-hook'. Each function of that hook will
 th> be run with the arguments

 th>     - action: move/copy/respool/crosspost
 th>     - Some data vector, dunno its use...
 th>     - original group
 th>     - destination group
 th>     - select method

 th> So you could write a delegate function that first add-hooks a
 th> function that sets a custom variable to the destination group. Then
 th> it calls `gnus-summary-move-article'. When that returns you can
 th> create the org-link and remove the function from the hook again.

I think I don't quite understand how this solves the problem.

This sounds like I should set the target group dynamically in the hook
when moving the article. But I can determine the group simply by calling

   (gnus-summary-move-article nil "<GROUP>")

So I know which group the articles end up in, but I don't know which
article number they got in that group -- but that is the basic
prerequisite to be able to link to them.

I'm sorry to ask a question that may be stupid, but how would I get the
article number(s) of the message(s) that have been moved by doing the
above?

Regards,
Georg

-- 
Georg C. F. Greve                                 <greve@fsfeurope.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Join the Fellowship and protect your freedom!     (http://www.fsfe.org)
What everyone should know about DRM                   (http://DRM.info)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 306 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Integration of Org mode and Gnus

[Tassilo Horn]

"Georg C. F. Greve" <greve@fsfeurope.org> writes:

>  >> If you could do that and submit it back to Gnus, that would be
>  >> great.
>
>  th> I just found out that this is not needed. You can use the
>  th> `gnus-summary-article-move-hook'. Each function of that hook will
>  th> be run with the arguments
>
>  th>     - action: move/copy/respool/crosspost
>  th>     - Some data vector, dunno its use...
>  th>     - original group
>  th>     - destination group
>  th>     - select method
>
>  th> So you could write a delegate function that first add-hooks a
>  th> function that sets a custom variable to the destination
>  th> group. Then it calls `gnus-summary-move-article'. When that
>  th> returns you can create the org-link and remove the function from
>  th> the hook again.
>
> I think I don't quite understand how this solves the problem.
>
> This sounds like I should set the target group dynamically in the hook
> when moving the article. But I can determine the group simply by
> calling
>
>    (gnus-summary-move-article nil "<GROUP>")

But `gnus-summary-move-article' is the one who asks you for the group
name when you do `B m' with some articles.

> So I know which group the articles end up in, but I don't know which
> article number they got in that group -- but that is the basic
> prerequisite to be able to link to them.

Uh, yes. I think I got you wrong. I thought you only needed the group
where the article was moved to.

Maybe you can use that and the message-id to link to the message without
requiring the registry. Have a look at Bastien's patch.

> I'm sorry to ask a question that may be stupid, but how would I get
> the article number(s) of the message(s) that have been moved by doing
> the above?

I don't have any clue. :-)

Bye,
Tassilo

Re: Re: Integration of Org mode and Gnus

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 975 bytes --]

On Wed, 18 Jul 2007 14:54:02 +0200
Tassilo Horn <tassilo@member.fsf.org> wrote: 

 th> Uh, yes. I think I got you wrong. I thought you only needed the
 th> group where the article was moved to.

Ah, okay. So it was a case of misunderstanding.

Thanks for the clarification.


 th> Maybe you can use that and the message-id to link to the message
 th> without requiring the registry. Have a look at Bastien's patch.

Yes, this seems like it might be the best way forward.


 th> I don't have any clue. :-)

I suspected something was wrong when you said "this should be easy"
because when I looked at the code, it didn't seem SO easy. ;)

Regards,
Georg

-- 
Georg C. F. Greve                                 <greve@fsfeurope.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Join the Fellowship and protect your freedom!     (http://www.fsfe.org)
What everyone should know about DRM                   (http://DRM.info)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 306 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Integration of Org mode and Gnus

[Tassilo Horn]

"Georg C. F. Greve" <greve@fsfeurope.org> writes:

>  th> I don't have any clue. :-)
>
> I suspected something was wrong when you said "this should be easy"
> because when I looked at the code, it didn't seem SO easy. ;)

I got you wrong. You said

    But that function does not return the URL of the moved article (as
    one might hope).

and I've read GROUP instead of URL. ;-)

Regards,
Tassilo
-- 
There is no chin behind Chuck Norris' beard. There is only another fist.

Re: Integration of Org mode and Gnus

[Bastien]

"Georg C. F. Greve" <greve@fsfeurope.org> writes:

> Ideally, I'd like to make a decision on email when I find them in the
> inboxes, and either archive them without a link, or archive them with a
> link for my Org mode files. The same goes for mail I send.

Alain Picard suggested something on this list earlier:
http://article.gmane.org/gmane.emacs.orgmode/1771

It allows you to quickly store Gnus mails in a section of your org file.
Just press ">" when on the mail you want to store.

------------------------------------------------------------------------
(setq *org-email-todo-tree-header* "* Email TODOS")
(setq *org-email-todo-list-buffer* "~/org/bzg.org")

(defun org-insert-email-as-current-todo (&optional kw)
  "Save a Gnus email into `*org-email-todo-list-buffer*' as a headline.
If prefix is non-nil, ask for a specific state."
  (interactive "P")
  (let ((link (org-store-link nil)))
    (save-window-excursion
      (find-file *org-email-todo-list-buffer*)
      (goto-char (point-min))
      (let ((state (if kw (completing-read "State: " 
					   (mapcar (lambda(x) (list x))
						   org-not-done-keywords)
					   nil t "TODO") "TODO"))
	    (point (re-search-forward *org-email-todo-tree-header* 
				      (point-max) nil)))
	(org-end-of-subtree t)
	(insert "\n** " state " " link))))
  (message "Email saved in %s" *org-email-todo-list-buffer*))

(define-key gnus-summary-mode-map ">" 'org-insert-email-as-current-todo)
------------------------------------------------------------------------

You might be also interested by the "bookmark" facility that comes with
Gnus:

,----[ gnus-bookmark.el ]
| Set a Gnus bookmark (from the summary buffer):
| M-x gnus-bookmark-set 
| 
| Jump to a Gnus bookmark:
| M-x gnus-bookmark-jump
| 
| Display a list of bookmarks:
| M-x gnus-bookmark-bmenu-list
`----

> So for sending mail and for moving mail to archive folders, I would
> like to be able to memorise a link for the email in its *final
> storage* location.

If you want the links to your mails being always up-to-date, either
create links when mails are at their final place or use nnir.el (as
proposed by Jason).  I'm afraid there is no easy way otherwise...

> Does anyone have an idea of the "right" solution to this?

I think the easiest solution is to use Gnus native bookmarks, except if
your emails are part of something you have to do.

Hope this helps!

-- 
Bastien

Re: Integration of Org mode and Gnus

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 1141 bytes --]

On Wed, 18 Jul 2007 02:55:01 +0200
Bastien <bzg@altern.org> wrote: 

 b> Alain Picard suggested something on this list earlier:
 b> http://article.gmane.org/gmane.emacs.orgmode/1771

 b> It allows you to quickly store Gnus mails in a section of your org
 b> file.  Just press ">" when on the mail you want to store.

Thanks for that.

This is quite useful for adding the link automatically to the right
place, but it doesn't solve the problem I have, because it leaves the
email in the inbox, which is what I don't want to do.


 b> If you want the links to your mails being always up-to-date, either
 b> create links when mails are at their final place

This means leaving the mailbox, going into the archive mailbox, creating
the link, going back to the inbox... too cumbersome for daily work, imho.

Regards,
Georg

-- 
Georg C. F. Greve                                 <greve@fsfeurope.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Join the Fellowship and protect your freedom!     (http://www.fsfe.org)
What everyone should know about DRM                   (http://DRM.info)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 306 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode