Re: [Orgmode] Integration of Org mode and mairix

2007-07-31 Thread Jason F. McBrayer
Bastien [EMAIL PROTECTED] 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[EMAIL PROTECTED]  |
| 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


Re: [Orgmode] Integration of Org mode and mairix

2007-07-31 Thread Xiao-Yong Jin
Hi, it seems I have almost missed the best thing in
this list.

Bastien [EMAIL PROTECTED] writes:

 Hi George,

 Georg C. F. Greve [EMAIL PROTECTED] 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/*
\ * (__
*/\  


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


Re: [Orgmode] Integration of Org mode and mairix

2007-07-31 Thread Georg C. F. Greve
On Tue, 31 Jul 2007 12:56:18 -0400
Xiao-Yong Jin [EMAIL PROTECTED] 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:
--- org.el.orig	2007-07-22 13:52:40.0 +0200
+++ org.el	2007-07-30 15:45:10.0 +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)

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:



binV0gzkkFMAK.bin
Description: application/emacs-lisp

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:
base=/home/greve
mbox=Archive/Mail/Auto/incoming/-??:Archive/Mail/Auto/outgoing/-??
database=/home/greve/Tools/Gnus/MairixDB
mformat=maildir
mfolder=.nnmaildir/mairix

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

Re: [Orgmode] Integration of Org mode and mairix

2007-07-31 Thread Bastien
Xiao-Yong Jin [EMAIL PROTECTED] 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


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


Re: [Orgmode] Interpretation of priorities in org-mode

2007-07-31 Thread Bastien
Hi Piotr,

Piotr Zielinski [EMAIL PROTECTED] writes:

 I've been recently experimenting with a different interpretation of
 priorities: #B = tasks to do today, #C = tasks to do this week, #D =
 all the rest, default. #A is reserved at the moment. One good thing
 about this system is a clearer interpretation of priorities.

When i first started using priorities, i was also leaned to misuse them
as you describe, and my file ended up with top priorities everywhere.

After a while, i discover it was better:

1. not to upgrade priorities too easily;
2. not trying to make them do an other job than their job.

Let me explain myself a bit.

The #1 advice seems obvious but it is hard to stick to it. One problem
comes from Org-mode itself, because it makes it s easy to upgrade a
priority that you often feel like upgrading one -- instead of completing
the task under it :)

Another problem comes from the fact that priority are dependant from
each others. I think it's better to have something around 10%-[#A],
20%-[#B], and 30%-[#C], and changing the priority of a few tasks might
disturb the balance. 

So here comes the #2 advice. Because i noticed that the reflex of
upgrading too many [#B] to [#A] was just a way to make my Org files
say something else (yes, my Org files *speak*), like Do it next!
(which should be said by a TODO keyword) or Do it today, you lazy 
bum! (which could be said by the agenda...)

So i try to keep a reasonable number of high-prioritized tasks and if i
feel like i start to upgrade indecently, then i think twice about why
i'm doing this.

The thing is that i mainly use the priority system to have a useful
display of the agenda view:


(setq org-agenda-sorting-strategy
  '((agenda time-up priority-down)
(todo priority-down)
(tags priority-down)))


(Okay, all of this is very nice but here is the truth: i got *tons* of
chaotic tasks under misused priorities... but at least you get the way 
i would like to use them :)

PS: just thinking: another way to use priorities could be to make lower
tasks *dependant* (in they order of execution) from higher tasks. But i
would prefer to make this dependance visible by using the display order,
i.e. one task after another.

Regards,

-- 
Bastien


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