Re: [O] [PATCH] org-contacts: Update contacts cache if it contains markers with no buffer

2013-07-20 Thread Øyvind Stegard
Daimrod daim...@gmail.com writes:

[...]

 You're right, good catch!

 I've installed the patch and haven't felt any slowdown, but I've a small
 contacts file. If people complain about slowdown we could add a buffer
 local hook to ask before killing contacts files.

If speed turns out to be an issue, then simply caching references to the
contact buffers and validating those references with `buffer-live-p'
should be quicker and just as reliable.

(Checking markers was just a quick solution on my part that did not
require changes to any data structures.)


Øyvind
-- 
 Øyvind Stegard
  http://stegard.net/



Re: [O] [PATCH] org-contacts: Update contacts cache if it contains markers with no buffer

2013-07-17 Thread Øyvind Stegard
Daimrod daim...@gmail.com writes:

[...]

 Thanks for the bug report!

 Don't you think that checking if one of the buffer would be enough and
 faster?
 With something like (every #'get-file-buffer org-contacts-files)

Hi,

I thought about that, yes. But what about when an org-contacts buffer is
killed and subsequently re-opened (like using `find-alternate-file' with
same file name). Then the buffer will exist for the file, but it will be
a new instance, and the markers in org-contacts-db will still be dead.
That's why I decided to just check the markers instead.


Regards,

Øyvind
-- 
 Øyvind Stegard
  http://stegard.net/



[O] [PATCH] org-contacts: Update contacts cache if it contains markers with no buffer

2013-07-12 Thread Øyvind Stegard
Hi list,

In contrib/lisp/org-contacts.el:

The function `org-contacts-db-need-update-p' does two checks to
determine if the contacts cache should be updated:
1. If the variable `org-contacts-last-update' is nil.
2. If modification time of any file containing contacts is more recent than
   timestamp recorded in `org-contacts-last-update'.

There is another case where an update is required: when marker objects
contained in the contact cache `org-contacts-db' suddenly point to no
buffer. If a buffer containing contacts is killed, but underlying file
is not modified, org-contacts will not detect this, and cached markers
that pointed to the now killed buffer will become dead (have no buffer
associated with them). This seems to cause problems at least in
`org-contacts-anniversaries', which if used as diary sexp in an agenda
file, will cause Bad sexp errors.

I have not done any thorough analysis of `org-contacts-anniversaries'
itself, but it seems to work OK whenever the markers in
`org-contacts-db' are OK. And it looks like the markers are used in that
code.

To reproduce:
1. Load up org-contacts and do a query with M-x org-contacts.
2. Kill at least one org-buffer containing a contact with BIRTHDAY
   property set (but do not save underlying file).
3. Make sure to use %%(org-contacts-anniversaries) in some agenda file.
4. Opening agenda should produce a Bad sexp error.


I've attached a patch (against git master) which I am currently using.
It will cause org-contacts to re-load if a marker is found in cache that
points to no buffer. This looked to me like the quickest approach for
fixing it without getting to know org-contacts.el better.


Regards,

Øyvind
-- 
 Øyvind Stegard
  http://stegard.net/

From e8d5f9ab71f75e5f5087d47e2e86115584db4a03 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=C3=98yvind=20Stegard?= oyvind.steg...@ifi.uio.no
Date: Fri, 12 Jul 2013 12:17:12 +0200
Subject: [PATCH] org-contacts: Ensure contacts cache is updated if it contains
 markers with no buffer

* contrib/lisp/org-contacts.el (org-contacts-db-need-update-p):
Check if org-contacts-db cache contains markers with no buffer as well, when
determining if cache should be updated from files.

The function `org-contacts-db-need-update-p' does two checks to determine if the
contacts cache should be updated:
1. If the variable `org-contacts-last-update' is nil.
2. If modification time of any file containing contacts is more recent than
   timestamp recorded in `org-contacts-last-update'.

There is another case where an update is required: when marker objects contained
in the contact cache `org-contacts-db' suddenly point to no buffer. If a buffer
containing contacts is killed, but underlying file is not modified, org-contacts
will not detect this, and cached markers that pointed to the now killed buffer
will become dead (e.g. have no buffer associated with them). This seems to cause
problems for instance in `org-contacts-anniversaries', which if used as diary
sexp in agenda file, will cause Bad sexp errors.
---
 contrib/lisp/org-contacts.el | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/contrib/lisp/org-contacts.el b/contrib/lisp/org-contacts.el
index 71f7bf4..a220993 100644
--- a/contrib/lisp/org-contacts.el
+++ b/contrib/lisp/org-contacts.el
@@ -224,7 +224,20 @@ A regexp matching strings of whitespace, `,' and `;'.)
   (org-find-if (lambda (file)
 		 (or (time-less-p org-contacts-last-update
   (elt (file-attributes file) 5
-		   (org-contacts-files
+		   (org-contacts-files))
+  (org-contacts-db-has-dead-markers-p org-contacts-db)))
+
+(defun org-contacts-db-has-dead-markers-p (org-contacts-db)
+  Returns t if at least one dead marker is found in
+ORG-CONTACTS-DB. A dead marker in this case is a marker pointing
+to dead or no buffer.
+;; Scan contacts list looking for dead markers, and return t at first found.
+(catch 'dead-marker-found
+  (while org-contacts-db
+(unless (marker-buffer (nth 1 (car org-contacts-db)))
+  (throw 'dead-marker-found t))
+(setq org-contacts-db (cdr org-contacts-db)))
+  nil))
 
 (defun org-contacts-db ()
   Return the latest Org Contacts Database.
-- 
1.8.1.2



[O] [PATCH] org-contacts: Provide ordering when using cycle completion

2013-06-10 Thread Øyvind Stegard
Hello list,

I have recently switched to using org-contacts, after several years of
BBDB usage. When completing contacts in message-mode, I prefer cycling
the completion alternatives, for instance when a single contact has
multiple email addresses. So I set `completion-cycle-threshold' to some
value other than nil.

However, the cycle ordering was not consistent with the order in which
email addresses appeared in the contact (actually, cycle order was
shortest candidate first, which I understand is a default). So the
preferred email address (or the first one defined in :EMAIL: property
of contact node) was typically not always chosen as first completion
suggestion in the cycle.

I attach a patch here (against current org-mode git) which also provides
the display sort function for cycle completions in metadata. That seems
to resolve the problem for me.


Regards,

Øyvind Stegard
-- 
 Øyvind Stegard
  http://stegard.net/

From 64623274f0a040c452df43b2a3f7b23b0af8fd57 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=C3=98yvind=20Stegard?= oyvind.steg...@ifi.uio.no
Date: Mon, 10 Jun 2013 11:08:56 +0200
Subject: [PATCH] org-contacts: Provide ordering when using cycle completion

* contrib/lisp/org-contacts.el (org-contacts-metadata-prefix):
Provide same function for cycle ordering as is used for display ordering
in completion metadata.

When using cycle completion style for contacts, by setting
`completion-cycle-threshold' to some value, the ordering was not consistent
with order of email addresses in contact definition, nor the order
which was used for regular display completion. Fix that by also
supplying sort function for cycle completion in metadata.
---
 contrib/lisp/org-contacts.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/contrib/lisp/org-contacts.el b/contrib/lisp/org-contacts.el
index 5d63fcc..71f7bf4 100644
--- a/contrib/lisp/org-contacts.el
+++ b/contrib/lisp/org-contacts.el
@@ -452,7 +452,8 @@ prefixes rather than just the beginning of the string.
 
 (defun org-contacts-metadata-prefix (string collection predicate)
   '(metadata .
-	 ((display-sort-function . org-contacts-display-sort-function
+	 ((cycle-sort-function . org-contacts-display-sort-function)
+	  (display-sort-function . org-contacts-display-sort-function
 
 (defun org-contacts-complete-group (start end string)
   Complete text at START from a group.
-- 
1.8.1.2



[Orgmode] XHTML export - Upper case COL tag is invalid XHTML

2007-10-30 Thread Øyvind Stegard
Hi,

XML and therefore XHTML is case sensitive with regard to tag names.
Org-mode version 5.13h generates upper-case COL tags in XHTML-export,
which is invalid. The tag should be in lowercase. The patch below should
fix it.

--- org.el.orig 2007-10-30 13:34:18.0 +0100
+++ org.el  2007-10-30 13:30:40.0 +0100
@@ -24127,11 +24127,11 @@
 (unless splice (push /table\n html))
 (setq html (nreverse html))
 (unless splice
-  ;; Put in COL tags with the alignment (unfortuntely often ignored...)
+  ;; Put in col tags with the alignment (unfortuntely often ignored...)
   (push (mapconcat
 (lambda (x)
   (setq gr (pop org-table-colgroup-info))
-  (format %sCOL align=\%s\/COL%s
+  (format %scol align=\%s\/col%s
   (if (memq gr '(:start :startend))
   (prog1
   (if colgropen /colgroup\ncolgroup 
colgroup)


Regards,
Øyvind Stegard

PS. I'm not a list subscriber, and only a light-weight org-mode user.
-- 
 Øyvind Stegard  oyvinst at ifi uio no 
  http://www.oyvind.nu/



___
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