Re: [O] bug in orgmode parsing of results
On 12/27/16 19:11, Charles C. Berry wrote: > On Tue, 27 Dec 2016, daimrod wrote: > >> Hi, >> >> I've found what I think is a bug in orgmode parsing. >> When the following file is parsed : >> >> * Test >> #+BEGIN_SRC emacs-lisp :exports results :results raw drawer >> (format "- Test2") >> #+END_SRC >> >> #+RESULTS: >> :RESULTS: >> - Test2 >> :END: >> > > [snip] > >> >> That is, it generates a DRAWER, which seems correct. >> >> However, when the following file is parsed : >> >> * Test >> #+BEGIN_SRC emacs-lisp :exports results :results raw drawer >> (format "* Test2") >> #+END_SRC >> >> #+RESULTS: >> :RESULTS: >> * Test2 >> :END: >> > > [deleted] > >> That is, it generates a PARAGRAPH which seems incorrect. >> >> WDYT? >> > > What I think is that you should run org-lint on your document. It will > say something like this (but with different line numbers): > > Line Trust Warning > 2 low Forbidden combination in header ":results": raw, drawer > 12 low Forbidden combination in header ":results": raw, drawer > 17 low Possible incomplete drawer ":RESULTS:" > > The last one should catch your eye. Didn't know about org-lint. Thanks. > If you want to generate results that have lines that start with `*' you > need to protect them. A good way to do this is to wrap them in a src > block or export block like this: > > #+BEGIN_SRC emacs-lisp :exports results :wrap export latex > (format "* Test2") > #+END_SRC The thing about :wrap export html is that I've to generate the HTML myself, whereas when I export the :RESULTS: drawer, org-mode generates the HTML. AFAIK there is no export block for org (no begin_export org). As a workaround I can always use `:results raw` but then it can not replace the result automatically. However, that's not a problem for my use case I think... Thanks for your help. Best, signature.asc Description: OpenPGP digital signature
Re: [O] bug in orgmode parsing of results
On 12/27/16 19:09, Nicolas Goaziou wrote: > Hello, > > daimrod <daim...@gmail.com> writes: > >> #+RESULTS: >> :RESULTS: >> * Test2 >> :END: >> > [...] > >> (paragraph >> (:begin 98 :end 119 :contents-begin 109 :contents-end 119 :post-blank 0 >> :post-affiliated 109 :results >> (\"\") >> :parent #2) >> #(\":RESULTS:\\n\" 0 10 >>(:parent #3))) >> >> That is, it generates a PARAGRAPH which seems incorrect. > > The parser is correct. A drawer cannot contain a headline. Hmm, OK. > Regards, > > signature.asc Description: OpenPGP digital signature
[O] bug in orgmode parsing of results
Hi, I've found what I think is a bug in orgmode parsing. When the following file is parsed : * Test #+BEGIN_SRC emacs-lisp :exports results :results raw drawer (format "- Test2") #+END_SRC #+RESULTS: :RESULTS: - Test2 :END: The truncated result of `org-element-parse-buffer' is : (src-block (:language \"emacs-lisp\" :switches nil :parameters \":exports results :results raw drawer\" :begin 8 :end 98 :number-lines nil :preserve-indent nil :retain-labels t :use-labels t :label-fmt nil :value \"(format \\\"- Test2\\\")\\n\" :post-blank 1 :post-affiliated 8 :parent #2)) (drawer (:begin 98 :end 133 :drawer-name \"RESULTS\" :contents-begin 119 :contents-end 127 :post-blank 0 :post-affiliated 109 :results (\"\") :parent #2)) That is, it generates a DRAWER, which seems correct. However, when the following file is parsed : * Test #+BEGIN_SRC emacs-lisp :exports results :results raw drawer (format "* Test2") #+END_SRC #+RESULTS: :RESULTS: * Test2 :END: The (truncated) result of `org-element-parse-buffer' is : (src-block (:language \"emacs-lisp\" :switches nil :parameters \":exports results :results raw drawer\" :begin 8 :end 98 :number-lines nil :preserve-indent nil :retain-labels t :use-labels t :label-fmt nil :value \"(format \\\"* Test2\\\")\\n\" :post-blank 1 :post-affiliated 8 :parent #2)) (paragraph (:begin 98 :end 119 :contents-begin 109 :contents-end 119 :post-blank 0 :post-affiliated 109 :results (\"\") :parent #2) #(\":RESULTS:\\n\" 0 10 (:parent #3))) That is, it generates a PARAGRAPH which seems incorrect. WDYT? signature.asc Description: OpenPGP digital signature
Re: [O] Obsolete org contrib package
On 11/10/16 10:50, Joost Kremers wrote: > > On Tue, Nov 08 2016, Joost Kremers wrote: >> Hi, >> >> On Tue, Nov 08 2016, Nicolas Goaziou wrote: >>> So you mean there is no equivalent to both >>> >>> (ebib-cur-entry-key) >> >> This one was what I was worried about, but on second thought, it >> should be possible to simply use: >> >> (ebib--get-key-at-point) >> >>> and >>> >>> (ebib-db-get-field-value 'title key ebib-cur-db) >> >> That one's easier: >>(ebib-db-get-field-value "title" key ebib--cur-db) >> >>> "org-ebib.el" is already compatible with Org 9.0. >> >> Ah, good, I didn't realise that. >> >>> I'm Cc'ing the author. Ideally this library should be updated to new >>> Ebib and moved to some ELPA. >>> >>> If Grégoire doesn't want to take care of it and no one volunteers to >>> maintain that file, we can remove it. >> >> I was actually planning to add this functionality to Ebib itself. So >> if Grégoire isn't interested in it anymore, I could put it in the Ebib >> repo, or create a separate repo for it, either on Github or somewhere >> else, wherever you prefer. > > I received the following reply from Grégoire (which, although it was > sent to the mailing list as well, apparently didn't show up there): > > > == > > On 11/08/16 13:23, Nicolas Goaziou wrote: >> I'm Cc'ing the author. Ideally this library should be updated to new >> Ebib and moved to some ELPA. >> >> If Grégoire doesn't want to take care of it and no one volunteers to >> maintain that file, we can remove it. > > I don't use this package anymore. > If anyone uses it, s/he take over it, otherwise we can just remove it > from org-contrib. > > == > > Like I said, I'd be happy to take over maintainance. Just let me know > how to go about making it available to org-contrib. (If there is a way > to keep the file in the main Ebib repository, that would be my preference.) IMHO it's best if you can maintain org-ebib as part of ebib itself. We can remove org-ebib from contrib and you can add it to ebib. Best, > Best, > > Joost > > > >
Re: [O] Obsolete org contrib package
On 11/08/16 13:23, Nicolas Goaziou wrote: > Hello, > > Joost Kremerswrites: > >> I just ran into org-ebib.el, a file that's part of org-contrib. >> I noticed that it uses functions from Ebib that were renamed pretty >> much exactly two years ago. (They're internal functions and thus got >> an extra dash.) This could in principle be fixed by changing the >> relevant function calls in org-ebib.el, but as it happens I'm about to >> push some changes to Ebib that will make it less straightorward to fix >> org-ebib.el. > > OK. > > So you mean there is no equivalent to both > > (ebib-cur-entry-key) > > and > > (ebib-db-get-field-value 'title key ebib-cur-db) > > ? > >> So perhaps it would be best to simply remove org-ebib.el from >> org-contrib? It doesn't seem to have been used by anyone the past two >> years and all it does is define a function to store an org link to an >> Ebib entry, which, IIUC, is done in a completely different way in Org >> 9.0. > > "org-ebib.el" is already compatible with Org 9.0. > > I'm Cc'ing the author. Ideally this library should be updated to new > Ebib and moved to some ELPA. > > If Grégoire doesn't want to take care of it and no one volunteers to > maintain that file, we can remove it. I don't use this package anymore. If anyone uses it, s/he take over it, otherwise we can just remove it from org-contrib. Best, > > We should at least wait for a week in any case. > > Regards, > signature.asc Description: OpenPGP digital signature
Re: [O] match on any TODO state
Xebar Saram zelt...@gmail.com writes: Hi I created this function which works well. (defun z/org-sparse-todo () (interactive) (org-match-sparse-tree t +TODO=\TODO\)) my question is how can i match on ANY todo state and not just literaly TODO ie if i have this in my org file #+TODO: TODO(t) EXP(e) | SUBMITTED(s) K_TRACK(k) PAUSED(p) DONE(d) how can i match it by all the todos like TODO and EXP In the agenda match, I use TODO. That is, all TODO keywords that aren't empty. Best, -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] [PATCH] org-contacts.el: Catch 'nextfile in org-contacts-db
phcrama.e...@gmx.com writes: Hi Nicolas and Greg, Hi Philippe, sorry for the late reply :( Thank you for applying my initial patch. Inspired by Greg's improvements to my patch, I'd like to propose the attached (presumptuously named) better-patch that I believe fixes the TODO of my initial patch. Sorry it isn't quite in the format of the previous one/recommended by the project but I'm not on my main machine now. --- org.elFri Jun 19 12:07:26 2015 +++ org-modif.el Wed Jun 24 09:13:10 2015 @@ -18097,17 +18097,28 @@ (defun org-file-menu-entry (file) (vector file (list 'find-file file) t)) -(defun org-check-agenda-file (file) - Make sure FILE exists. If not, ask user what to do. +(defun org-check-agenda-file-1 (file) + Make sure FILE exists. If not, ask user what to do. + +Possible outcomes: +1. File exists - return NIL. +2. File doesn't exist and user requests to remove it - throws 'nextfile. +3. File doesn't exist and user requests to remove it - raise error \Abort\. + +You probably want `org-check-agenda-file'. (when (not (file-exists-p file)) (message Non-existent agenda file %s. [R]emove from list or [A]bort? (abbreviate-file-name file)) (let ((r (downcase (read-char-exclusive (cond ((equal r ?r) - (org-remove-file file) (throw 'nextfile t)) (t (error Abort)) The 3. item looks wrong to me. I think it should be: 3. File doesn't exist and user requests to abort - raise error \Abort\. +(defun org-check-agenda-file (file) + Make sure FILE exists, else if user agrees, remove FILE from `org-agenda-files'. + (when (catch 'nextfile (org-check-agenda-file-1 file)) +(org-remove-file file))) (defun org-get-agenda-file-buffer (file) Get a buffer visiting FILE. If the buffer needs to be created, add --- org-contacts.el Fri Jun 19 12:07:20 2015 Moreover, I'm not sure about changing the behaviour of an existing function. Though the change looks good to me, it is very likely users (or maybe even other parts of org-mode, I'haven't check) rely on it, and expect to catch exceptions. +++ org-contacts-modif.el Wed Jun 24 09:13:56 2015 [snip] I agree with the modifications of org-contacts.el. Maybe org-contacts.el should have its own version of `org-check-agenda-file' (e.g. named `org-contacts-check-contacts-file') until we find a better solution... WDYT? Best, -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] org-log-reschedule: inactive time-stamp instead
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, M elwood...@web.de writes: I wonder if I get something wrong, but in the variable org-log-note-headings I see Heading when rescheduling String: Rescheduled from %S on %t Shouldn't the %S represent a TODO state (which makes no sense)? %S represents the last state. If you change a TODO keyword, is also a TODO keyword (or lack thereof). If you alter a timestamp, it is that timestamp. Can I replace it by an inactive timestamp? Is there any use case for an active timestamp at this location anyway? If there is not, we could automatically convert it to an inactive timestamp. WDYT? I don't have any use for an active location here. IMO it clutters the agenda with senseless entries. Best, -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] org-log-reschedule: inactive time-stamp instead
M elwood...@web.de writes: Karl Voit devnull at Karl-Voit.at writes: Those active time-stamps clutter my daily agenda a bit. Therefore: ,[ what I would like to get ] | :LOGBOOK: | - Rescheduled from [2014-12-17 Mi] on [2014-12-16 Di 17:01] | :END: ` So can someone please add an option for this variable to get inactive time-stamps? Hi Karl, did you find a solution in the meantime? I'm having the same problem and the active timestamps are also bothering me as rescheduled tasks which originally were scheduled for today stay in my daily agenda and clutter it. I wonder if I get something wrong, but in the variable org-log-note-headings I see Heading when rescheduling String: Rescheduled from %S on %t Shouldn't the %S represent a TODO state (which makes no sense)? Can I replace it by an inactive timestamp? Hi, I had the same problem and implemented a quick'n dirty solution : (defun dmd-org-active-timestamp-to-inactive-when-rescheduled () Convert some variable with active timestamp to inactive one. (when (eq org-log-note-purpose 'reschedule) (setq org-log-note-previous-state (substitute ?\] ?\ (substitute ?\[ ?\ org-log-note-previous-state :test #'char-equal) :test #'char-equal (add-hook 'org-log-buffer-setup-hook 'dmd-org-active-timestamp-to-inactive-when-rescheduled) It works for me but it should probably be fixed in org-mode itself. Best, -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] Filters lost after reviving buried, sticky agenda
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Daimrod daim...@gmail.com writes: Here is an updated version of the second patch : Both look good. Could you can push them. Thank you. Done, thank you. Regards, -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] Filters lost after reviving buried, sticky agenda
Err, I should have tested it before sending the patch, sorry. Here is an updated version of the second patch : From 11ef3cc8dd804a9498edc856350d5e57d9ce3fff Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Gr=C3=A9goire=20Jadi?= gregoire.j...@univ-nantes.fr Date: Tue, 23 Jun 2015 10:42:25 +0200 Subject: [PATCH 2/2] lisp/org-agenda.el: Fix non-persistent category filters in sticky agenda * lisp/org-agenda.el (org-agenda-prepare): Use the correct key for category filter. `org-agenda-prepare-window' uses 'cat whereas `org-agenda-prepare' used 'car. --- lisp/org-agenda.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index a07eead..32509a5 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -3647,7 +3647,7 @@ FILTER-ALIST is an alist of filters we need to apply when (list `(tag . ,org-agenda-tag-filter) `(re . ,org-agenda-regexp-filter) `(effort . ,org-agenda-effort-filter) - `(car . ,org-agenda-category-filter)) + `(cat . ,org-agenda-category-filter)) (if (org-agenda-use-sticky-p) (progn (put 'org-agenda-tag-filter :preset-filter nil) -- 1.9.1 Best, -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] Filters lost after reviving buried, sticky agenda
Nick Dokos ndo...@gmail.com writes: What happened to the effort filter? Good catch! Thanks. Here is an updated patch plus another one to fix the regexp and category filters. From 59cd3eb256d9473db42f9a1629755140c0d648cb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Gr=C3=A9goire=20Jadi?= gregoire.j...@univ-nantes.fr Date: Fri, 12 Jun 2015 17:35:30 +0200 Subject: [PATCH 1/2] lisp/org-agenda.el : Fix non-persistent filters when refreshing sticky agenda * lisp/org-agenda.el (org-agenda-prepare): Fix non-persistent filters when refreshing sticky agenda When a sticky agenda is buried, then reviving and refreshing, existing filters are ignored even when org-agenda-persistent-filter is `t'. Reported and fixed by Daniel Borchmann --- lisp/org-agenda.el | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index f5d1022..a07eead 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -3642,10 +3642,12 @@ FILTER-ALIST is an alist of filters we need to apply when (defun org-agenda-prepare (optional name) (let ((filter-alist (if org-agenda-persistent-filter - (list `(tag . ,org-agenda-tag-filter) -`(re . ,org-agenda-regexp-filter) -`(effort . ,org-agenda-effort-filter) -`(car . ,org-agenda-category-filter) + (with-current-buffer + (get-buffer-create org-agenda-buffer-name) + (list `(tag . ,org-agenda-tag-filter) + `(re . ,org-agenda-regexp-filter) + `(effort . ,org-agenda-effort-filter) + `(car . ,org-agenda-category-filter)) (if (org-agenda-use-sticky-p) (progn (put 'org-agenda-tag-filter :preset-filter nil) -- 1.9.1 From 3dc0e17b0887b182309696b2f790dac9ad3ca018 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Gr=C3=A9goire=20Jadi?= gregoire.j...@univ-nantes.fr Date: Tue, 23 Jun 2015 10:42:25 +0200 Subject: [PATCH 2/2] lisp/org-agenda.el: Fix non-persistent regexp and category filters in sticky agenda * lisp/org-agenda.el (org-agenda-prepare): Use the correct key for category and regexp filters. `org-agenda-finalize' uses 'regexp and 'category whereas `org-agenda-prepare' used 're and 'car. --- lisp/org-agenda.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index a07eead..8efc037 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -3645,9 +3645,9 @@ FILTER-ALIST is an alist of filters we need to apply when (with-current-buffer (get-buffer-create org-agenda-buffer-name) (list `(tag . ,org-agenda-tag-filter) - `(re . ,org-agenda-regexp-filter) + `(regexp . ,org-agenda-regexp-filter) `(effort . ,org-agenda-effort-filter) - `(car . ,org-agenda-category-filter)) + `(category . ,org-agenda-category-filter)) (if (org-agenda-use-sticky-p) (progn (put 'org-agenda-tag-filter :preset-filter nil) -- 1.9.1 -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] Filters lost after reviving buried, sticky agenda
Daniel Borchmann daniel.borchm...@tu-dresden.de writes: Dear all, I regularly lose all my filters when I bury a sticky agenda and revive it later. In that case, the variable `org-agenda-tag-filter' is set to nil, although it was non-nil before burying. I played around a bit, and found out that `org-agenda-tag-filter' is buffer-local (which is not a surprise). When the agenda buffer is revived, the function `org-agenda-prepare' is called, which, among others, should reset the filters (provided that `org-agenda-persistent-filter' is set). The beginning of the function is ---8--- (defun org-agenda-prepare (optional name) (let ((filter-alist (if org-agenda-persistent-filter (list `(tag . ,org-agenda-tag-filter) `(re . ,org-agenda-regexp-filter) `(car . ,org-agenda-category-filter) ...)) ---8--- It seems to me that `org-agenda-tag-filter' is read *before* the old agenda buffer is poped up (i.e., made current), and thus results in a `nil' value. Indeed, if I replace the definition of `filter-alist' by ---8--- (let ((filter-alist (if org-agenda-persistent-filter (with-current-buffer (get-buffer org-agenda-buffer-name) (list `(tag . ,org-agenda-tag-filter) `(re . ,org-agenda-regexp-filter) `(car . ,org-agenda-category-filter)) ...) ---8--- then the bug (seems to) disappear. My question is now: is this correct, or did I understand something wrong? If my understanding is correct, how this bug be fixed more elegantly? It doesn't work at startup when agenda hasn't been built yet. The following patch does seem to fix that. If it's ok, I can push it. From d2e8fef81585c249f33fa37260f6228709a67017 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Gr=C3=A9goire=20Jadi?= gregoire.j...@univ-nantes.fr Date: Fri, 12 Jun 2015 17:35:30 +0200 Subject: [PATCH] lisp/org-agenda.el : Fix non-persistent filters when refreshing sticky agenda * lisp/org-agenda.el (org-agenda-prepare): Fix non-persistent filters when refreshing sticky agenda When a sticky agenda is buried, then reviving and refreshing, existing filters are ignored even when org-agenda-persistent-filter is `t'. Reported and fixed by Daniel Borchmann --- lisp/org-agenda.el | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index f5d1022..3a1f5bc 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -3642,10 +3642,11 @@ FILTER-ALIST is an alist of filters we need to apply when (defun org-agenda-prepare (optional name) (let ((filter-alist (if org-agenda-persistent-filter - (list `(tag . ,org-agenda-tag-filter) -`(re . ,org-agenda-regexp-filter) -`(effort . ,org-agenda-effort-filter) -`(car . ,org-agenda-category-filter) + (with-current-buffer + (get-buffer-create org-agenda-buffer-name) + (list `(tag . ,org-agenda-tag-filter) + `(re . ,org-agenda-regexp-filter) + `(car . ,org-agenda-category-filter)) (if (org-agenda-use-sticky-p) (progn (put 'org-agenda-tag-filter :preset-filter nil) -- 1.9.1 Best, -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] [PATCH] org-contacts.el: Catch 'nextfile in org-contacts-db
Philippe Crama phcrama.e...@gmx.com writes: Hi, Hello Philippe, This is a small patch to catch the 'nextfile thrown by `org-check-agenda-file' in `org-contacts-db'. I don't know how to fix the TODO in the comment myself, sorry. At least, with the patch, the execution doesn't abort anymore. Thanks for the report and the patch. I've attached a patch inspired by yours. WDYT? From b3bb252c6e2138fa65b7c960060d68ea8c260873 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Gr=C3=A9goire=20Jadi?= gregoire.j...@univ-nantes.fr Date: Mon, 15 Jun 2015 09:36:36 +0200 Subject: [PATCH] org-contacts.el: Handle missing files in `org-contacts-files' gracefully * contrib/lisp/org-contacts.el (org-contacts-files): Catch 'nextfile From `org-check-agenda-file' and update `org-contacts-files' if modified. (org-contacts-db): Don't call `org-check-agenda-file' now called in `org-contacts-files'. When `org-agenda-files' contains non-existent files, remove them if the user asks for it instead of failing. Modified from a patch proposal by Philippe Crama --- contrib/lisp/org-contacts.el | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/contrib/lisp/org-contacts.el b/contrib/lisp/org-contacts.el index bc07fc1..3e14c7e 100644 --- a/contrib/lisp/org-contacts.el +++ b/contrib/lisp/org-contacts.el @@ -227,7 +227,12 @@ A regexp matching strings of whitespace, `,' and `;'.) (defun org-contacts-files () Return list of Org files to use for contact management. - (or org-contacts-files (org-agenda-files t 'ifmode))) + (org-remove-if (lambda (file) + (when (catch 'nextfile + (org-check-agenda-file file)) + (customize-save-variable 'org-contacts-files + (delete file org-contacts-files + (or org-contacts-files (org-agenda-files t 'ifmode (defun org-contacts-db-need-update-p () Determine whether `org-contacts-db' needs to be refreshed. @@ -261,7 +266,6 @@ to dead or no buffer. (make-progress-reporter Updating Org Contacts Database... 0 (length org-contacts-files))) (i 0)) (dolist (file (org-contacts-files)) - (org-check-agenda-file file) (with-current-buffer (org-get-agenda-file-buffer file) (unless (eq major-mode 'org-mode) (error File %s is not in `org-mode' file)) -- 1.9.1 Regards, -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] Filters lost after reviving buried, sticky agenda
Daniel Borchmann daniel.borchm...@tu-dresden.de writes: ghItlhpu' Daimrod daim...@gmail.com: My question is now: is this correct, or did I understand something wrong? If my understanding is correct, how this bug be fixed more elegantly? It doesn't work at startup when agenda hasn't been built yet. The following patch does seem to fix that. If it's ok, I can push it. It works for me. Great! If nobody complains in the next days, I'll push it. Best, -- Daimrod/Greg signature.asc Description: PGP signature
[O] [BUG] Bad escape with Babel + org-mode
Hi, I've encountered a bug when using org-mode in source blocks. I'm using the latest version of org-mode from git: Org-mode version 8.3beta (release_8.3beta-1195-g1a7364 [...]) I have no problem with the following snippet: #+BEGIN_SRC org ,* test 1 ,* test 2 ,* test 3 ,* test 4 ,* test 5 ,* test 6 ,* test 7 ,* test 8 ,* test 9 ,* test 10 #+END_SRC But I have an error with this one when I hit C-' to go back to my org file: error in `org-escape-code-in-region' while: Invalid search bound (wrong side of point) #+BEGIN_SRC org ,* test 1 ,* test 2 ,* test 3 ,* test 4 ,* test 5 ,* test 6 ,* test 7 ,* test 8 ,* test 9 ,* test 10 ,* test 11 #+END_SRC And with the following snippet: #+BEGIN_SRC org ,* test 1 ,* test 2 ,* test 3 ,* test 4 ,* test 5 ,* test 6 ,* test 7 ,* test 8 ,* test 9 ,* test 10 ,* test 11 ,* test 12 #+END_SRC When I hit C-' to go back to the org file the block isn't properly escaped, it becomes: #+BEGIN_SRC org ,* test 1 ,* test 2 ,* test 3 ,* test 4 ,* test 5 ,* test 6 ,* test 7 ,* test 8 ,* test 9 ,* test 10 ,* test 11 * test 12 #+END_SRC I've tried to understand what's the problem and it looks like the position returned by `re-search-forward' in `org-escape-code-in-region' is wrong, but I don't know why. By wrong, I mean that the position returned isn't immediately after the expression found but slightly after, and the error increases which is why it doesn't fail with 10 items or less. e.g. * test 1 ^ point * test 2 ^ point * test 3 ^ point ... Best, -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] [BUG] Bad escape with Babel + org-mode
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Daimrod daim...@gmail.com writes: I've encountered a bug when using org-mode in source blocks. I'm using the latest version of org-mode from git: Org-mode version 8.3beta (release_8.3beta-1195-g1a7364 [...]) I have no problem with the following snippet: #+BEGIN_SRC org ,* test 1 ,* test 2 ,* test 3 ,* test 4 ,* test 5 ,* test 6 ,* test 7 ,* test 8 ,* test 9 ,* test 10 #+END_SRC But I have an error with this one when I hit C-' to go back to my org file: error in `org-escape-code-in-region' while: Invalid search bound (wrong side of point) #+BEGIN_SRC org ,* test 1 ,* test 2 ,* test 3 ,* test 4 ,* test 5 ,* test 6 ,* test 7 ,* test 8 ,* test 9 ,* test 10 ,* test 11 #+END_SRC And with the following snippet: #+BEGIN_SRC org ,* test 1 ,* test 2 ,* test 3 ,* test 4 ,* test 5 ,* test 6 ,* test 7 ,* test 8 ,* test 9 ,* test 10 ,* test 11 ,* test 12 #+END_SRC When I hit C-' to go back to the org file the block isn't properly escaped, it becomes: #+BEGIN_SRC org ,* test 1 ,* test 2 ,* test 3 ,* test 4 ,* test 5 ,* test 6 ,* test 7 ,* test 8 ,* test 9 ,* test 10 ,* test 11 * test 12 #+END_SRC Fixed in f91d194d4fe4644de9cac94a807a08c220ab521d. Thank you. Confirmed. Thanks ! Regards, -- Daimrod/Greg signature.asc Description: PGP signature
[O] ':post' Direct execution via Emacs Lisp
Hi, We can read in the manual: 14.8.2.25 ‘:post’ The ‘:post’ header argument is used to post-process the results of a code block execution. When a post argument is given, the results of the code block will temporarily be bound to the ‘*this*’ variable. This variable may then be included in header argument forms such as those used in *note var:: header argument specifications allowing passing of results to other code blocks, or direct execution via Emacs Lisp. ^^^ IIUC, it means that we can post process the data in Emacs Lisp, that is, by calling an Emacs Lisp function, not another source block. However, the example only shows how to do it with another source block. Is my understanding correct or not? If so, how can I post process the result with an Emacs Lisp function? Cheers, -- Daimrod/Greg
Re: [O] Extra empty line at the top of the page when tangling.
Ivanov Dmitry usr...@gmail.com writes: Hi, Code: #+BABEL: :cache yes :tangle yes :noweb yes #+NAME: top_block #+begin_src perl :tangle test.pl :noweb tangle From (info (org) padline): 14.8.2.10 ‘:padline’ Control in insertion of padding lines around code block bodies in tangled code files. The default value is ‘yes’ which results in insertion of newlines before and after each tangled code block. The following arguments are accepted. • ‘yes’ Insert newlines before and after each code block body in tangled code files. • ‘no’ Do not insert any newline padding in tangled output. You can use the following block declaration: #+begin_src perl :tangle test.pl :noweb tangle :padline no #!/usr/bin/perl use strict; use warnings; open(my $fh, , test.txt) or die cannot open file name: $!; output-all close($fh); #+end_src #+NAME: output-all #+begin_src perl while (my $line = $fh) { print $line; } #+end_src Outputs a perl file, where the 1-st line is blank. What should I do to remove it? -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] Link to named block
Bastien b...@gnu.org writes: Hi Greg, Hi Bastien, Daimrod daim...@gmail.com writes: I've made a small function to link to a named block in org files. #+BEGIN_SRC emacs-lisp (defun dmd--org-link-to-named-block () Create an org-link to the named block at point. Blocks are named with #+NAME. (when (eq major-mode 'org-mode) (let* ((el (org-element-at-point)) (name (org-element-property :name el))) (when name (org-store-link-props :link name) #+END_SRC Do you think it should be added to org? I find it useful to add a link to a figure when I'm exporting to latex. I'm not sure how to use the function above -- how do you set the link itself, not just its properties? I don't. The link name is enough because named block usually have nice name. For example, given the following named block: #+NAME: fig:my-fig [[file:my-fig.png]] Then link will be [[fig:my-fig]]. I tried to add it to `org-store-link` but it's a big function and I wonder why it's not splitted in smaller functions. (e.g. org-help-store-link, org-w3-store-link, org-image-store-link, ...). If you agree, I could split it. Yes, please go ahead. noted. -- Daimrod/Greg signature.asc Description: PGP signature
[O] Link to named block
Hi, I've made a small function to link to a named block in org files. #+BEGIN_SRC emacs-lisp (defun dmd--org-link-to-named-block () Create an org-link to the named block at point. Blocks are named with #+NAME. (when (eq major-mode 'org-mode) (let* ((el (org-element-at-point)) (name (org-element-property :name el))) (when name (org-store-link-props :link name) #+END_SRC Do you think it should be added to org? I find it useful to add a link to a figure when I'm exporting to latex. I tried to add it to `org-store-link` but it's a big function and I wonder why it's not splitted in smaller functions. (e.g. org-help-store-link, org-w3-store-link, org-image-store-link, ...). If you agree, I could split it. WDYT? Best, -- Daimrod/Greg signature.asc Description: PGP signature
[O] Help on org-export-filter-link-functions
Hi, I've wrote a simple filter to customize how links are exported in latex: #+BEGIN_SRC (defun dmd--latex-bib-link-filter (data backend info) Convert a bib link to a citation (e.g. bib:foo93 - \cite{foo93}). (let* ((beg (next-property-change 0 data)) (link (if beg (get-text-property beg :parent data (cond ((and link (org-export-derived-backend-p backend 'latex) (string= (org-element-property :type link) bib)) (format \\cite{%s} (org-element-property :path link))) ((and link (org-export-derived-backend-p backend 'latex) (string= (org-element-property :type link) file) (string= (org-element-property :path link) ~/.bib.bib)) (format \\cite{%s} (org-element-property :search-option link))) (t data #+END_SRC And I was wondering whether there is an easier way to retrieve the org properties stored in the text properties of DATA. Best, -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] doing a capture and jumping to the file
Alan Schmitt alan.schm...@polytechnique.org writes: Hello, Hello Alan, I often find myself doing the following: use a capture template to nicely setup an entry (often a date tree entry with a link to the current document), then jump to the newly created headline to start adding notes. I typically do this during meetings, as I do not want to stay in the capture buffer all the time. Is there a way to setup a capture template such that it directly opens the target file and set-up entry, instead of the capture buffer? I tried a universal argument before calling org-capture, but it only jumps to the capture destination and does not set up the entry. You can customize your capture templates with `M-x org-capture RET C'. Look especially at the plist keywords `:immediate-finish` and `:jump-to-captured`. Best, -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] org-elements-parse-buffer and weird property drawers
Eike e...@eknet.org writes: Hello, Nicolas Goaziou writes: Eike n...@eknet.org writes: I'm playing with the functions in org-elements.el and the following effect seems strange to me: I have a few propery drawers with empty propertys, like #+BEGIN_EXAMPLE :PROPERTIES: :date: [2014-08-29 Fr] :chf: 21.76 :eur: :END: #+END_EXAMPLE If I do org-elements-parse-buffer, the empty one is not there, but the first one is duplicated. At least, there are two node-property elements in the tree like that: #+BEGIN_EXAMPLE (node-property (:key chf :value 21.76 :begin 38 :end 58 :post-blank 0 :post-affiliated 38 :parent #4)) (node-property (:key chf :value 21.76 :begin 58 :end 67 :post-blank 0 :post-affiliated 58 :parent #4)) #+END_EXAMPLE The function call was this: #+begin_src emacs-lisp (with-current-buffer test-exp.org (org-element-parse-buffer)) #+end_src And here is the test-exp.org org file: #+BEGIN_EXAMPLE * Sonstiges ** Pizza :PROPERTIES: :chf: 21.76 :eur: :END: #+END_EXAMPLE This should be fixed. Thank you for reporting it. Many thanks! It works here now. Hi, Since the change to `org-re-property' I have problems to display org files. My *Message* buffer is spammed with the following error: Error during redisplay: (jit-lock-function 1119) signaled (error No match 3 in highlight (3 (quote org-property-value) t)) this number changes I know the problem lies in org-re-property because if I revert the change, it works as it did before. Test file: * TODO Test :PROPERTIES: :TEST: test :END: Best, -- Daimrod/Greg
Re: [O] org-elements-parse-buffer and weird property drawers
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Daimrod daim...@gmail.com writes: Since the change to `org-re-property' I have problems to display org files. My *Message* buffer is spammed with the following error: Error during redisplay: (jit-lock-function 1119) signaled (error No match 3 in highlight (3 (quote org-property-value) t)) this number changes Fixed. Thank you. It works, thanks. Regards, -- Daimrod/Greg
Re: [O] [PATCH] docstring improvement of org-agenda-refile
Charles Millar mill...@verizon.net writes: Charles Millar wrote: Daimrod wrote: +When GOTO is '(14) or \\[universal-argument] \\[universal-argument], go to the location of the last refiled item. ^^ '(16) Just opened my own reply and the '(16) may be misaligned. Good catch. I've applied the patch with the correction. -- Daimrod/Greg
Re: [O] Tab completion for link to file
Chris Henderson henders...@gmail.com writes: Hi Chris, How can I get auto tab completion for links to files? Is C-u C-c C-l what you're looking for? From the *Help* of `org-insert-link': With a C-u prefix, prompts for a file to link to. The file name can be selected using completion. e.g. [[file+sys:///Users/chris/projects/marketing 2014]] Thanks. -- Daimrod/Greg
[O] [PATCH] docstring improvement of org-agenda-refile
Hi, Here is a small patch to improve the docstring of `org-agenda-refile'. Can I apply it? From acd2830755849a055ce46a34b65af89b9547fcb2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Gr=C3=A9goire=20Jadi?= gregoire.j...@gmail.com Date: Sun, 10 Aug 2014 01:41:16 +0200 Subject: [PATCH] lisp/org-agenda.el (org-agenda-refile): Documentation improvement * lisp/org-agenda.el (org-agenda-refile): State explicitly that '(16) = C-u C-u and that '(64) = C-u C-u C-u. --- lisp/org-agenda.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 3919328..8244eeb 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -8475,8 +8475,8 @@ If this information is not given, the function uses the tree at point. (defun org-agenda-refile (optional goto rfloc no-update) Refile the item at point. -When GOTO is 0 or '(64), clear the refile cache. -When GOTO is '(16), go to the location of the last refiled item. +When GOTO is 0 or '(64) or \\[universal-argument] \\[universal-argument] \\[universal-argument], clear the refile cache. +When GOTO is '(14) or \\[universal-argument] \\[universal-argument], go to the location of the last refiled item. RFLOC can be a refile location obtained in a different way. When NO-UPDATE is non-nil, don't redo the agenda buffer. (interactive P) -- 1.8.0.2722.gc0242e5 -- Daimrod/Greg
[O] [PATCH] docstring improvement of org-agenda-refile
Hi, Here is a small patch to improve the docstring of `org-agenda-refile'. Can I apply it? From acd2830755849a055ce46a34b65af89b9547fcb2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Gr=C3=A9goire=20Jadi?= gregoire.j...@gmail.com Date: Sun, 10 Aug 2014 01:41:16 +0200 Subject: [PATCH] lisp/org-agenda.el (org-agenda-refile): Documentation improvement * lisp/org-agenda.el (org-agenda-refile): State explicitly that '(16) = C-u C-u and that '(64) = C-u C-u C-u. --- lisp/org-agenda.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 3919328..8244eeb 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -8475,8 +8475,8 @@ If this information is not given, the function uses the tree at point. (defun org-agenda-refile (optional goto rfloc no-update) Refile the item at point. -When GOTO is 0 or '(64), clear the refile cache. -When GOTO is '(16), go to the location of the last refiled item. +When GOTO is 0 or '(64) or \\[universal-argument] \\[universal-argument] \\[universal-argument], clear the refile cache. +When GOTO is '(14) or \\[universal-argument] \\[universal-argument], go to the location of the last refiled item. RFLOC can be a refile location obtained in a different way. When NO-UPDATE is non-nil, don't redo the agenda buffer. (interactive P) -- 1.8.0.2722.gc0242e5 -- Daimrod/Greg
[O] [feature request] Matching tags and properties
Hi all, ATM, it is possible to look for date in properties using special keywords such as now, today and tomorrow. Unfortunately, the last two keywords doesn't match on timestamps that include time information. e.g. [2014-08-04 Mon] can be matched, but not [2014-08-04 Mon 21:20]. I think it would make sense to allow the later to be matched with today, that is, to ignore time information. WDYT? -- Daimrod/Greg
Re: [O] per file org-todo-keywords?
Xebar Saram zelt...@gmail.com writes: Hi all Hi, i would like to know if its possible to have per file org-todo-keywords? i know you can have custom TODO states in the top of the file/buffer but then you loose the fast access to TODO states tight? No, it still works. currently i have something like this: (setq org-todo-keywords (quote ((sequence TODO(t) NEXT(n) | DONE(d)) (sequence WAITING(w@/!) HOLD(h@/!) | CANCELLED(c@/!) but i woud like different TODO keywords for specific file that i can use fast access for any ideas? It's all in the documentation. see (info (org) Tracking TODO state changes) You can use the exact same syntax for setting logging preferences local to a buffer: #+TODO: TODO(t) WAIT(w@/!) | DONE(d!) CANCELED(c@) -- Daimrod/Greg
Re: [O] org-contact Export
Esben Stien b...@esben-stien.name writes: Daimrod daim...@gmail.com writes: It wasn't possible, but it is now. I've slightly modified `org-contacts-export-as-vcard' so that it will prompt for a user name when called with a prefix argument. This is in git? Yes. The new function's behovior when called interactively is the following: 1. no prefix : do as before, export all contacts to `org-contacts-vcard-file'. 2. C-u : prompt for a contact name and use the contact at point if it exists, then export the matching contacts to `org-contacts-vcard-file'. 3. C-u C-u : same as 2. but prompt for a file name where to export instead of `org-contacts-vcard-file'. 4. C-u C-u C-u : same as 3. but prompt for a buffer name instead of a file name. How about export to kill-ring? Do you mean in the kill-ring instead of the buffer? or with another prefix level (C-u C-u C-u C-u)? -- Daimrod/Greg
Re: [O] org-contact Export
Esben Stien b...@esben-stien.name writes: Hello Esben, Is there any way to retrieve a single org-contact as CSV or maybe a VCF file? I know I can export all of them, but is there a function to get just the one under point? It wasn't possible, but it is now. I've slightly modified `org-contacts-export-as-vcard' so that it will prompt for a user name when called with a prefix argument. The new function's behovior when called interactively is the following: 1. no prefix : do as before, export all contacts to `org-contacts-vcard-file'. 2. C-u : prompt for a contact name and use the contact at point if it exists, then export the matching contacts to `org-contacts-vcard-file'. 3. C-u C-u : same as 2. but prompt for a file name where to export instead of `org-contacts-vcard-file'. 4. C-u C-u C-u : same as 3. but prompt for a buffer name instead of a file name. When the function isn't called interactively it behaves as it did before. WDYT? Best, -- Daimrod/Greg
Re: [O] Bug: org-contacts show Non-existent agenda file ~/org/* virexit. [R]emove from list or [A]bort? when trying to find contacts with M-x org-contactsRET [8.2.7b (8.2.7b-dist @ c:/Users/Seam/A
seamw...@gmail.com writes: I put my captured contacts to ~/.orgmode/data/contact.org and I can successfully capture the contacts, however, when I eval the function org-contacts in org mode, it just shows the message in the title. if the contact file is empty, it does not show the message, but org-contacts show an empty match. -- org-contacts show Non-existent agenda file ~/org/* virexit. [R]emove from list or [A]bort? when trying to find contacts with M-x org-contactsRET [8.2.7b (8.2.7b-dist @ c:/Users/Seam/AppData/Roaming/.emacs.d/orgmode/lisp/)] -- It looks like you had added a file named '* virexit' to the agenda list, but that file doesn't exist anymore. `org-contacts' uses the agenda views to display contacts. I don't know the internals of `org-agenda' very well but I guess that it checks for agenda files even if the caller doesn't need them, hence the error. I don't know (yet) if it's possible to disable this behavior, but in the meantime you can remove the file from the agenda list. Best, -- Daimrod/Greg
Re: [O] how to hide titles marked with DONE
bofe hust.hu...@gmail.com writes: Hi, I use org to manage my projects. When some works are finished ,I marked the titles “DONE”,but as time goes by ,there are too many of them, that I can’t focus on the rest of unfinished works. Is there a way to hide the “DONE titles,rather than delete them? You can toggle the archive tag (C-c C-x a) or archive the tasks (C-c C-x C-a). -- Daimrod/Greg
Re: [O] org-contacts email completion by tags
Daimrod daim...@gmail.com writes: Thanks, but I'm refactoring org-contacts a bit, and I think I have found a slightly better way to do that, but in the meantime you can use the aforementioned hook for your function. It turns out that my idea was wrong, so I have used a version very similar to yours. The function is triggered by the prefix '#' (customizable) and can be used to match tags and properties. e.g. the following expression: #work-phdBIRTHDAY will look for contacts with the tag 'work' but not the tag 'phd' and for which there is a BIRTHDAY properties. Best, -- Daimrod/Greg
Re: [O] still seeing semi-regular lockups
Matt Lundin m...@imapmail.org writes: Eric Abrahamsen e...@ericabrahamsen.net writes: Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Eric Abrahamsen e...@ericabrahamsen.net writes: None of those three, I'm afraid! It was hanging on a variety of editing operations that, as far as I can tell, had little in common. There's a possibility that they were list-item-related, but really there wasn't much commonality. FYI, I recently fixed a bug[fn:1] that could introduce uncommon random lockups. Hopefully, it may be related to your problem (which is different from Daimrod's). Thanks for the followup! I was watching Daimrod's thread, and also Matt's most recent posting -- that also seemed more relevant to my problems, which were almost solely confined to log/state notes. I've pulled the fix, and will let you know if I see any more problems. With the latest git, I've experienced three lock-ups/freezes this evening when a) archiving a subtree to a file, b) changing a todo state with repeating timestamp, and 3) calling C-c C-c in an org-capture buffer. (I don't think this is due to a recent change - I've been running into these lockups sporadically for several months.) The freezes are very difficult to replicate reliably. When they happen, emacs is unresponsive and can only be killed from the outside. Any tips on how to debug this would be greatly appreciated. See my previous post: http://thread.gmane.org/gmane.emacs.orgmode/86255/focus=86263 You can wrap `jit-lock--debug-fontify' with: (advice-add 'jit-lock--debug-fontify :around (lambda (fun rest args) (with-local-quit (apply fun args and then force emacs to break and display a backtrace by sending the SIGUSR2 to the emacs process. Best, -- Daimrod/Greg
Re: [O] org-contacts email completion by tags
John Kitchin jkitc...@andrew.cmu.edu writes: Hi, First, sorry for the late reply. Here is what I finally ended up with to allow completion with tag expressions. I did not figure out how to avoid overwriting an org-contacts function. I thought I could find the right hooks to use, but I could not figure it out. It is only a one line modification to the org-contacts function. I've added a new hook `org-contacts-complete-functions' that you can use to plug your function. This works for tag expressions, but I have not gotten it to work with properties. (defun org-contacts-complete-tags (start end tag-expression) insert emails from org-contacts that match the tags expression. For example: group-phd will match entries tagged with group but not with phd. (let* ((completion-ignore-case org-contacts-completion-ignore-case) (group-completion-p t)) (let ((result (mapconcat 'identity (loop for contact in (org-contacts-db) for contact-name = (car contact) for email = (org-contacts-strip-link (car (org-contacts-split-property (or (cdr (assoc-string org-contacts-email-property (caddr contact))) for tags = (cdr (assoc TAGS (nth 2 contact))) for tags-list = (if tags (split-string (substring (cdr (assoc TAGS (nth 2 contact))) 1 -1) :) '()) if (let ((todo-only nil)) (eval (cdr (org-make-tags-matcher tag-expression collect (org-contacts-format-email contact-name email)) ,))) (when (not (string= result)) ;; return (start end function) (lexical-let* ((to-return result)) (list start end (lambda (string pred optional to-ignore) to-return))) Thanks, but I'm refactoring org-contacts a bit, and I think I have found a slightly better way to do that, but in the meantime you can use the aforementioned hook for your function. Best, -- Daimrod/Greg
Re: [O] still seeing semi-regular lockups
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Daimrod daim...@gmail.com writes: My guess is that the lockup happens in `org-element--cache-key-less-p', called by `org-element--cache-process-request'. Probably, but it doesn't mean that this particular function is buggy. The lockup happens there because the cache gets corrupted at some point. I see. After investigating a little while, it appears that switching input-method to latin-postfix alone is sufficient to corrupt it. Though, setting `org-element-cache-sync-idle-time' to a high value prevents the problem, which means that the corruption happens only when cache is synchronized during idle time. Ok. That's where I am for the time being. I don't know much about input methods, so I have no clue about the reasons behind this. I'm still investigating. I would help if I knew about input-methods or the caching mechanism, but I do not. :-( Thanks for investigating. Best, -- Daimrod/Greg
[O] bug#17746: bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message
Bastien b...@gnu.org writes: Nicolas Richard theonewiththeevill...@yahoo.fr writes: Perhaps this isn't the right place to ask, but I wonder how (save-excursion (set-window-start (selected-window) (window-start))) isn't a noop. Perhaps it is a noop -- The purpose of `org-fix-ellipsis-at-bol' is to remove the ellipsis overlay that outline-mode may leave when navigating through folded regions. At least this was the purpose of the original version, and using recenter did the job. I'll try to reproduce the original bug, see if the new version of `org-fix-ellipsis-at-bol' does the job and if not, why. In `org-fix-ellipsis-at-bol', the change wasn't : (save-excursion (set-window-start (selected-window) (window-start))) but : (save-excursion (set-window-start (selected-window) (point-min))) which is not a noop. But it does the wrong thing with isearch. When isearch is done, that is, when it has found a match and we leave isearch with RET for example. Then it calls `isearch-done' which runs `org-fix-ellipsis-at-bol' because it is in `isearch-mode-end-hook' (I didn't look to find why). Because of this, if the pattern found isn't at the top of the buffer, then the point won't be at the pattern, but at the top of the buffer. Best, -- Daimrod/Greg
[O] bug#17746: bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message
Nicolas Richard theonewiththeevill...@yahoo.fr writes: Daimrod daim...@gmail.com writes: PS: The change about throwing an error when recentering a window that does not display the current buffer breaks ~37 tests in Org master branch, even with this fix. I need to digg this further. Err, what's the rational behind this change? It is meant to catch cases where recenter acts on the wrong window. Think of the cases where (recenter) is called from within a timer or a process filter function. See the discussion entitled comint-preoutput-filter-functions and flickering redisplay in TTY on emacs devel. Thanks! -- Daimrod/Greg
[O] bug#17746: bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message
Daimrod daim...@gmail.com writes: Nicolas Richard theonewiththeevill...@yahoo.fr writes: Daimrod daim...@gmail.com writes: PS: The change about throwing an error when recentering a window that does not display the current buffer breaks ~37 tests in Org master branch, even with this fix. I need to digg this further. Err, what's the rational behind this change? It is meant to catch cases where recenter acts on the wrong window. Think of the cases where (recenter) is called from within a timer or a process filter function. See the discussion entitled comint-preoutput-filter-functions and flickering redisplay in TTY on emacs devel. Thanks! Okay, so is there another fix than `(when (eq (current-buffer) (window-buffer)))' or removing the call? If not, why does it raise an error instead of doing nothing silently? Best, -- Daimrod/Greg
[O] bug#17746: bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message
Daimrod daim...@gmail.com writes: Daimrod daim...@gmail.com writes: Nicolas Richard theonewiththeevill...@yahoo.fr writes: Daimrod daim...@gmail.com writes: PS: The change about throwing an error when recentering a window that does not display the current buffer breaks ~37 tests in Org master branch, even with this fix. I need to digg this further. Err, what's the rational behind this change? It is meant to catch cases where recenter acts on the wrong window. Think of the cases where (recenter) is called from within a timer or a process filter function. See the discussion entitled comint-preoutput-filter-functions and flickering redisplay in TTY on emacs devel. Thanks! Okay, so is there another fix than `(when (eq (current-buffer) (window-buffer)))' or removing the call? If not, why does it raise an error instead of doing nothing silently? I've read the fix in org-mode and I understand that it was a silly question. Please ignore it. Best, -- Daimrod/Greg
Re: [O] can show inline images anymore in orgmode
Xebar Saram zelt...@gmail.com writes: Hi all Hi, i have a weird problem. in the last few weeks i cant get orgmode to show inline images anymore. when i use org-toggle-inline-images i get the following error: progn: Wrong type argument: stringp, nil [2 times] can anyone help me to debug this? 1. M-x toggle-debug-on-error RET 2. report the backtrace FWIW, I don't have this error using the latest version (HEAD) of org-mode. Regards, -- Daimrod/Greg
Re: [O] still seeing semi-regular lockups
Daimrod daim...@gmail.com writes: Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Daimrod daim...@gmail.com writes: I've attached part of the traces (the whole traces are way too big) and the backtraces. Thanks for looking into this. However, you are running a compiled Org, which renders backtraces less useful. Ok, I was wondering why the backtraces was so ugly, I didn't think about byte-compilation... Thanks for the tip. Also, you may want to disable cache refresh on idle time with, e.g., (setq org-element-cache-sync-idle-time 3600) It could make the bug easier to reproduce. Thanks, I'll try again this w.e. Okay, so I've found a more or less reliable way to reproduce this bug (on my machine at least). 1. $ emacs -Q -l debug.el test.org 2. Expand headline (S-TAB) 3. go below the first headline (C-n) 4. press `i' a couple of seconds ~10 chars 5. delete the line (C-a C-k) 6. goto 4 until if locks up As I said, it's not completely reliable but so far the lockup always happens. Sometimes it happens after the third iteration, sometimes after the tenth iteration, but it always happen. I've attached `debug.el' and `test.org'. `debug.el' setup the environment to reproduce the bug, you may need to change the path to your orgmode source base and you'll need `adaptive-wrap-prefix-mode' (available on ELPA). I've been able to reproduce the bug without `adaptive-wrap-prefix-mode' though other people have reported the same symptoms without using it. `test.org' is a simple org file with two headlines. It seems that two headlines are required to trigger the cache mechanism (with `org-element-cache--sync'). Do you confirm the lockup with this setting? Best, * i * i i debug.el Description: application/emacs-lisp -- Daimrod/Greg
Re: [O] still seeing semi-regular lockups
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Daimrod daim...@gmail.com writes: Okay, so I've found a more or less reliable way to reproduce this bug (on my machine at least). 1. $ emacs -Q -l debug.el test.org 2. Expand headline (S-TAB) 3. go below the first headline (C-n) 4. press `i' a couple of seconds ~10 chars 5. delete the line (C-a C-k) 6. goto 4 until if locks up As I said, it's not completely reliable but so far the lockup always happens. Sometimes it happens after the third iteration, sometimes after the tenth iteration, but it always happen. I've attached `debug.el' and `test.org'. [...] Do you confirm the lockup with this setting? Yes, I do. I will investigate on this soon. Thank you for providing this recipe. Cool! Also, I should have mentioned that I didn't trace the function `org-element--cache-key-less-p' because when I do so, Emacs stays locked even when I send it the signal SIGUSR2. However, this function appears in the backtrace produced by `xbacktrace' in a gdb session if I call it during a lockup. My guess is that the lockup happens in `org-element--cache-key-less-p', called by `org-element--cache-process-request'. Best, -- Daimrod/Greg
[O] bug#17746: bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message
@@ package ox-bibtex by Taru Karttunen. (call-interactively 'reftex-citation))) Functions extending outline functionality +(defun org-recenter (optional arg) + Like `recenter' but ensure that the `current-buffer' is +properly set. + (with-current-buffer (window-buffer) +(recenter arg))) (defun org-beginning-of-line (optional arg) Go to the beginning of the current line. If that is invisible, continue -- 1.8.0.2722.gc0242e5 -- Daimrod/Greg
[O] bug#17746: bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message
Stefan Monnier monn...@iro.umontreal.ca writes: +(defun org-recenter (optional arg) + Like `recenter' but ensure that the `current-buffer' is +properly set. + (with-current-buffer (window-buffer) +(recenter arg))) This doesn't make much sense: in many case (window-buffer) can be a buffer completely unrelated to Org. Hmm, what was the previous behaviour of `recenter'? (i.e. before it reports an error) Did it just do nothing? Best, -- Daimrod/Greg
Re: [O] still seeing semi-regular lockups
Eric Abrahamsen e...@ericabrahamsen.net writes: Daimrod daim...@gmail.com writes: Bastien b...@gnu.org writes: Hi Eric, Eric Abrahamsen e...@ericabrahamsen.net writes: After Nicolas made the last round of improvements to the caching mechanism I got far fewer hangs with Org, but they are still happening. Maybe once a day or so, on average, editing something in an Org buffer causes emacs to hang, and my fans to spin up, and there we are until I kill emacs. [...] By the way, if you want to see in which part the infloop occurs, you can attach a gdb debugger to the running emacs, source the path-to-emacs-source/src/.gdbinit file and use the `xbacktrace' command. $ gdb path-to-emacs-executable emacs-pid gdb) source path-to-emacs-source/src/.gdbinit ... gdb) xbacktrace You can also use the `bt' command but it contains much more noise. I got another one just now (while moving from one org table cell to the next), and that was the gdb backtrace: avl-tree--do-delete (0xbfffe858) avl-tree-delete (0xbfffe998) byte-code (0xbfffeaa0) byte-code (0xbfffec30) org-element--cache-process-request (0xbfffedd8) byte-code (0xbfffeef0) org-element--cache-sync (0xb0a8) org-element-at-point (0xb1e8) org-mode-flyspell-verify (0xb338) flyspell-word (0xb478) byte-code (0xb580) flyspell-post-command-hook (0xb784) It seems the lockup also happens in `org-element--cache-...'. Not much, and probably not that useful. I'll start running org uncompiled, and try the debug-on-event trick. Thanks for you time! FWIW, this was the first lockup that *didn't* occur in a logbook drawer -- that's where I usually get them. Either a full lockup, or else the cache goes wonky so that adding log notes (or even just navigating in the drawer) gives me that bound on wrong side of point you get when you try to search forwards, backwards. That's weird (in my cases it usually mess up with the input-method). -- Daimrod/Greg
Re: [O] still seeing semi-regular lockups
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Daimrod daim...@gmail.com writes: I've attached part of the traces (the whole traces are way too big) and the backtraces. Thanks for looking into this. However, you are running a compiled Org, which renders backtraces less useful. Ok, I was wondering why the backtraces was so ugly, I didn't think about byte-compilation... Thanks for the tip. Also, you may want to disable cache refresh on idle time with, e.g., (setq org-element-cache-sync-idle-time 3600) It could make the bug easier to reproduce. Thanks, I'll try again this w.e. Best, -- Daimrod/Greg
[O] bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
We can probably close this bug. I haven't been able to reproduce it with the org-mode bundled with the pretest version. Sorry for the noise. Regards, -- Daimrod/Greg
Re: [O] org-contacts development
Michael Strey mst...@strey.biz writes: Hi Michael, Reading http://orgmode.org/worg/dev/org-syntax.html#Node_Properties I just realised that my clumsy property keys are against the rules since they are containing whitespace characters. Nevertheless I still like the idea of having a Type, a number and a Value for every property that can occur multiple. Thus the properties can be easily mapped to the VCard scheme as well as to any other scheme. Thus, what I would like to propose is the following scheme: #+BEGIN_SRC org :PROPERTIES: :Contact_Type: individual or organisation :Organization_1_Type: company :Organization_1_Name: The company name :Organization_1_Department: department, business unit, division :Organization_1_Title: job title of an individual :FN: The full name :GivenName: :FamilyName: :Name_Prefix: :Name_Suffix: :Nickname: :Email_1_Type: Work :Email_1_Value: n...@company.fr :Address_1_Type: Work :Address_1_Street: The street can contain multiple lines \\ second line :Address_1_Box: Postal box :Address_1_Extension: other extensions that can occur in addresses :Address_1_City: The city :Address_1_Region: Region, federal state etc. :Address_1_Code: 12100 :Address_1_Country: France :Phone_1_Type: Work :Phone_1_Value: +33 565 623740 :Phone_2_Type: Fax :Phone_2_Value: +33 565 623070 :Website_1_Type: Work :Website_1_Value: http://www.domain.fr :Birthday: :Language: en :Salutation: :END: #+END_SRC Hmm, I kinda like this. It seems a bit verbose but it's better than having multiple values per properties (IMHO). Though, if we adopt this scheme, we would need to add some helper bindings/functions so that we don't have to fill this by hands. Other user defined properties can be added and mapped to the appropriate user defined keys during export. I'm not sure to understand what you mean. Could you give more details and maybe an example? [snip] Please note that org-collector tries to convert property values from strings into numbers if possible. For postal codes with leading Zeros this can lead to unexpected results. I did not find any other way to solve this problem than to add a national code like in the following example :Address_1_Code: 01169 would lead to 1169 in the propview table. so I replaced it with :Address_1_Code: DE-01169 What is `org-collector' and when does it happen? I've done a quick test and the 0 appears in `org-contacts-db'. Best, -- Daimrod/Greg
Re: [O] org-contacts development
Alexis flexibe...@gmail.com writes: Daimrod daim...@gmail.com writes: So, as you said, we would need to define and document a specification for org-contacts. And we need to be clear from the beginning about what it can do and what it can not do. For example, it is unlikely that org-contacts will be a 1:1 mapping with the vCard format in its current form because vCard properties can have values. e.g. PROP1;PROP2=VAL:FOO BAR ^ Agreed. But it seem to me we could at least map e.g. TEL;CELL: (which is how my Android phone vCard-exports a mobile number) to e.g. :MOBILE: or :PHONE_CELL:. And we could map things like e.g. EMAIL;TYPE=work: to e.g. :EMAIL_WORK:. This is just brainstorming, however. :-) Sure, but then how would we define the map? with a fixed set of rules? with a user customizable map (e.g. '((MOBILE - TELL;CELL) (EMAIL_WORK - EMAIL;TYPE=work)))? I'm not saying that it's impossible nor that we shouldn't do it but that we need to think about it first. :) An approach would be to keep using properties whenever it's possible to keep the format simple when possible and use subtree instead of properties when necessary. e.g. #+BEGIN_SRC org ,* Contact Name ,** PHONE :PROPERTIES: :TYPE: WORK :END: - num1 - num2 #+END_SRC But then we would need a special property to indicate that a subtree is a contact and ignore subtree without this property (just like it does with the EMAIL property ATM). #+BEGIN_SRC org ,* Contact Name :PROPERTIES: :TYPE: org-contacts :END: ,** PHONE :PROPERTIES: :TYPE: WORK :END: - num1 - num2 #+END_SRC And of course it would be nice if we could keep as much compatibility with the current format :) Well, to me this looks broadly similar to what Esben has proposed: https://lists.gnu.org/archive/html/emacs-orgmode/2014-05/msg01055.html Although i like the idea of such a format in principle, my concern (as i noted in my reply to Esben) is that this might require a substantial modification of org-contacts.el, both to accommodate this format and to ensure backwards-compatibility. If this is indeed the case, and someone else is willing to commit to being the lead on undertaking that work, then i'll certainly support that work and write relevant MobileOrg code to work with both the new and old formats. Otherwise, from my perspective of wanting to simply add some more fields and be able to transfer contact details between MobileOrg and my phone's Contacts system, it's more than i'm willing to take on at this point. Well, if people are willing to help, I'll see if I can come up with a proposal. -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] org-contacts development
Alexis flexibe...@gmail.com writes: Hi all, Hi, [snip...] Fleshing out an extended spec for org-contacts data could be part of the process of making org-contacts a first-class citizen of org-mode, and provide a more solid foundation on which people can build (and share) the org-contacts functionality they're after. And in my own particular case, it would greatly facilitate my work in org-contacts / Android Contacts integration. :-) What do people think? IMHO, the problem with org-contacts isn't that it isn't part of org-mode, but that its format isn't well defined enough. Some fields accept only one value, some multiple values, with different separators, etc... And on top of that, there is no easy way to access the database (`car', `cadr', `caddr', ...) which makes it difficult to read and write code. So, as you said, we would need to define and document a specification for org-contacts. And we need to be clear from the beginning about what it can do and what it can not do. For example, it is unlikely that org-contacts will be a 1:1 mapping with the vCard format in its current form because vCard properties can have values. e.g. PROP1;PROP2=VAL:FOO BAR ^ And AFAIK we can't do that with org-mode properties. An approach would be to keep using properties whenever it's possible to keep the format simple when possible and use subtree instead of properties when necessary. e.g. #+BEGIN_SRC org ,* Contact Name ,** PHONE :PROPERTIES: :TYPE: WORK :END: - num1 - num2 #+END_SRC But then we would need a special property to indicate that a subtree is a contact and ignore subtree without this property (just like it does with the EMAIL property ATM). #+BEGIN_SRC org ,* Contact Name :PROPERTIES: :TYPE: org-contacts :END: ,** PHONE :PROPERTIES: :TYPE: WORK :END: - num1 - num2 #+END_SRC And of course it would be nice if we could keep as much compatibility with the current format :) -- Daimrod/Greg
Re: [O] still seeing semi-regular lockups
Eric Abrahamsen e...@ericabrahamsen.net writes: On 05/19/14 23:21 PM, Daimrod wrote: Daimrod daim...@gmail.com writes: I have also semi-regular lockup with org-mode. I have opened a bug on debbugs and here is what Stefan told me to try to debug this: You can try `debug-on-event'. There's jit-lock-debug-mode but it doesn't disable inhibit-quit. So you'll need to additionally use (advice-add 'jit-lock--debug-fontify :around (lambda (fun rest args) (with-local-quit (apply fun args Of course sometimes this doesn't work because jit-lock-debug-mode changes the way things are executed and the bug may not manifest itself any more, but it's worth a try. Another source of info is to M-x trace-function RET org-adaptive-fill-function RET M-x trace-function RET org-element-at-point RET M-x trace-function RET org-element--cache-sync RET M-x trace-function RET org-element--cache-process-request RET Then reproduce the hang, then break the hang somehow (maybe with the jit-lock-debug hack above, or maybe with debug-on-event, or with C-g C-g C-g, ...), then look at the *trace..* buffer. I'll try to see what I can find this week end and report back. Ok, so the good news is the `debug-on-event' trick works. If you got a lockup, you can get a classic elisp backtrace by sending the SIGUSR2 to the Emacs process. The bad news is that I don't know yet how to reproduce the lockup. It seems to happen mostly (if not only) when I use org-mode + visual-line-mode + adaptive-wrap-prefix-mode + an input-method like latin-postfix. And it probably has to do with the cache mechanism. I'll try to reproduce it with the cache disabled but it hard to test because, as I said, I don't know how to reproduce it yet. I'll keep testing and see if I can reproduce it reliably. Stay tuned! Of course I haven't gotten a single lock-up since reporting in last time... :D Do you have a similar setup? That is visual-line-mode, adaptive-wrap-prefix-mode, input-method? -- Daimrod/Greg
Re: [O] still seeing semi-regular lockups
Daimrod daim...@gmail.com writes: I have also semi-regular lockup with org-mode. I have opened a bug on debbugs and here is what Stefan told me to try to debug this: You can try `debug-on-event'. There's jit-lock-debug-mode but it doesn't disable inhibit-quit. So you'll need to additionally use (advice-add 'jit-lock--debug-fontify :around (lambda (fun rest args) (with-local-quit (apply fun args Of course sometimes this doesn't work because jit-lock-debug-mode changes the way things are executed and the bug may not manifest itself any more, but it's worth a try. Another source of info is to M-x trace-function RET org-adaptive-fill-function RET M-x trace-function RET org-element-at-point RET M-x trace-function RET org-element--cache-sync RET M-x trace-function RET org-element--cache-process-request RET Then reproduce the hang, then break the hang somehow (maybe with the jit-lock-debug hack above, or maybe with debug-on-event, or with C-g C-g C-g, ...), then look at the *trace..* buffer. I'll try to see what I can find this week end and report back. Ok, so the good news is the `debug-on-event' trick works. If you got a lockup, you can get a classic elisp backtrace by sending the SIGUSR2 to the Emacs process. The bad news is that I don't know yet how to reproduce the lockup. It seems to happen mostly (if not only) when I use org-mode + visual-line-mode + adaptive-wrap-prefix-mode + an input-method like latin-postfix. And it probably has to do with the cache mechanism. I'll try to reproduce it with the cache disabled but it hard to test because, as I said, I don't know how to reproduce it yet. I'll keep testing and see if I can reproduce it reliably. Stay tuned! -- Daimrod/Greg
Re: [O] still seeing semi-regular lockups
Bastien b...@gnu.org writes: Hi Eric, Eric Abrahamsen e...@ericabrahamsen.net writes: After Nicolas made the last round of improvements to the caching mechanism I got far fewer hangs with Org, but they are still happening. Maybe once a day or so, on average, editing something in an Org buffer causes emacs to hang, and my fans to spin up, and there we are until I kill emacs. I've seen hiccups here and there, but generally, what happens is an error, not an infinite hanging. It happens often enough that I guess it's worth running emacs under some kind of debugger -- at least, I assume that's the best way of catching the bug. I'm not really sure how to go hunting, though, so if anyone had any advice in this direction, that would be great. I'd hunt for some infloop in parsing -- but cannot detail more than that, problably Nicolas could. In the meantime, is there any way of interrupting emacs so it quits whatever its doing, without having to kill it? I've played around with sending different signals using kill, just for fun, but everything I've tried either does nothing, or kills emacs altogether. I have no suggestion here either, sorry :/ I have also semi-regular lockup with org-mode. I have opened a bug on debbugs and here is what Stefan told me to try to debug this: You can try `debug-on-event'. There's jit-lock-debug-mode but it doesn't disable inhibit-quit. So you'll need to additionally use (advice-add 'jit-lock--debug-fontify :around (lambda (fun rest args) (with-local-quit (apply fun args Of course sometimes this doesn't work because jit-lock-debug-mode changes the way things are executed and the bug may not manifest itself any more, but it's worth a try. Another source of info is to M-x trace-function RET org-adaptive-fill-function RET M-x trace-function RET org-element-at-point RET M-x trace-function RET org-element--cache-sync RET M-x trace-function RET org-element--cache-process-request RET Then reproduce the hang, then break the hang somehow (maybe with the jit-lock-debug hack above, or maybe with debug-on-event, or with C-g C-g C-g, ...), then look at the *trace..* buffer. I'll try to see what I can find this week end and report back. By the way, if you want to see in which part the infloop occurs, you can attach a gdb debugger to the running emacs, source the path-to-emacs-source/src/.gdbinit file and use the `xbacktrace' command. $ gdb path-to-emacs-executable emacs-pid gdb) source path-to-emacs-source/src/.gdbinit ... gdb) xbacktrace You can also use the `bt' command but it contains much more noise. -- Daimrod/Greg signature.asc Description: PGP signature
[O] bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
Bastien b...@gnu.org writes: Daimrod daim...@gmail.com writes: I wonder if it is because `org-adaptive-fill-function' doesn't mix well with `adaptive-wrap-prefix-mode'... (Nicolas has been doing some rewrite for filling functions in the master branch, maybe it's worth checking whether this bug affects the master branch too, not just the Emacs-24 version of Org.) I am using the master branch, I didn't check if it also happens in the Emacs-24 version of Org. Sorry, I should have mentioned that in my initial report. :( -- Daimrod/Greg
Re: [O] still seeing semi-regular lockups
Eric Abrahamsen e...@ericabrahamsen.net writes: Daimrod daim...@gmail.com writes: Bastien b...@gnu.org writes: Hi Eric, Eric Abrahamsen e...@ericabrahamsen.net writes: After Nicolas made the last round of improvements to the caching mechanism I got far fewer hangs with Org, but they are still happening. Maybe once a day or so, on average, editing something in an Org buffer causes emacs to hang, and my fans to spin up, and there we are until I kill emacs. [...] I have also semi-regular lockup with org-mode. I have opened a bug on debbugs and here is what Stefan told me to try to debug this: You can try `debug-on-event'. There's jit-lock-debug-mode but it doesn't disable inhibit-quit. So you'll need to additionally use (advice-add 'jit-lock--debug-fontify :around (lambda (fun rest args) (with-local-quit (apply fun args Of course sometimes this doesn't work because jit-lock-debug-mode changes the way things are executed and the bug may not manifest itself any more, but it's worth a try. Another source of info is to M-x trace-function RET org-adaptive-fill-function RET M-x trace-function RET org-element-at-point RET M-x trace-function RET org-element--cache-sync RET M-x trace-function RET org-element--cache-process-request RET Then reproduce the hang, then break the hang somehow (maybe with the jit-lock-debug hack above, or maybe with debug-on-event, or with C-g C-g C-g, ...), then look at the *trace..* buffer. I'll try to see what I can find this week end and report back. By the way, if you want to see in which part the infloop occurs, you can attach a gdb debugger to the running emacs, source the path-to-emacs-source/src/.gdbinit file and use the `xbacktrace' command. $ gdb path-to-emacs-executable emacs-pid gdb) source path-to-emacs-source/src/.gdbinit ... gdb) xbacktrace You can also use the `bt' command but it contains much more noise. Thanks! This is the sort of thing I assumed I'd have to do, and it's good to have an actual recipe. If you're on it, I might take the lazy option and spectate for now... :) No problem, but could you attach gdb during a lockup, source .gdbitinit and use the `xbacktrace' command to see if the lockup happens at the same place? -- Daimrod/Greg
[O] bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
Bastien b...@altern.org writes: Daimrod daim...@gmail.com writes: Bastien b...@gnu.org writes: Daimrod daim...@gmail.com writes: I wonder if it is because `org-adaptive-fill-function' doesn't mix well with `adaptive-wrap-prefix-mode'... (Nicolas has been doing some rewrite for filling functions in the master branch, maybe it's worth checking whether this bug affects the master branch too, not just the Emacs-24 version of Org.) I am using the master branch, I didn't check if it also happens in the Emacs-24 version of Org. Okay, then it would be good to know if it happens in the Org version included in the Emacs pretest, as this is the one that needs heavy testing right now :) So far I haven't manage to reproduce it with the Org bundled with the Emacs pretest. I'll continue to use it for a while and see what happens. Best, -- Daimrod/Greg
[O] bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
Stefan Monnier monn...@iro.umontreal.ca writes: gdb) xbacktrace avl-tree-delete (0x54b0) byte-code (0x55a0) byte-code (0x5760) org-element--cache-process-request (0x5990) byte-code (0x5aa0) org-element--cache-sync (0x5ce0) org-element-at-point (0x5e00) byte-code (0x60d0) org-adaptive-fill-function (0x6300) fill-match-adaptive-prefix (0x6480) fill-context-prefix (0x6620) adaptive-wrap-fill-context-prefix (0x67d0) adaptive-wrap-prefix-function (0x6a18) run-hook-with-args (0x6a10) 0x4d89f80 PVEC_COMPILED funcall (0x6b30) jit-lock-fontify-now (0x6e38) jit-lock-function (0x6fc8) vertical-motion (0xdca8) end-of-visual-line (0xde08) call-interactively (0xdfc0) org-end-of-line (0xe198) call-interactively (0xe350) command-execute (0xe478) I wonder if it is because `org-adaptive-fill-function' doesn't mix well with `adaptive-wrap-prefix-mode'... As mentioned earlier, the immediate problem is that org-adaptive-fill-function does not terminate (or at least takes too long to terminate). Ok. Now, one reason why this might happen here is that adaptive-wrap-prefix-mode calls org-adaptive-fill-function everywhere, so it might be called in places where it usually (i.e. when adaptive-wrap-prefix-mode isn't in use) isn't triggered. Is there a way to disable the effect of `inhibit-quit' in `jit-lock' so C-g interrupt again in order to get an elisp-backtrace with `debug-on-quit'. Otherwise, what's the best way to debug this? Looking closer at `org-adaptive-fill-function'? -- Daimrod/Greg
[O] bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
Stefan Monnier monn...@iro.umontreal.ca writes: So, that's an org-mode bug, I'll try to see if I can reproduce it Right: org-adaptive-fill-function should finish fairly promptly. (though I wonder why it uses `inhibit-quit' in the first place). It's not org-mode which binds inhibit-quit but the C code that runs jit-lock. The C code binds inhibit-quit basically any time we run asynchronous code (i.e. code run from redisplay, timers, process-filters, ...) since the user usually doesn't really know that such is running, so if she hits C-g she doesn't mean for it to interrupt that code, but instead to do something else (e.g. get out of the minibuffer). Well, `org-mks' (in `org-capture.el') sets `inhibit-quit' to T and is called by `org-capture'. I have found 7 places were `inhibit-quit' was set to T in org-mode. The flip side is that all code run from jit/font-lock, process filters and timers should be super extra careful to finish promptly and never ever get into an inf-loop. I can see why. :) -- Daimrod/Greg
[O] bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
Daimrod daim...@gmail.com writes: Stefan Monnier monn...@iro.umontreal.ca writes: So, that's an org-mode bug, I'll try to see if I can reproduce it Right: org-adaptive-fill-function should finish fairly promptly. (though I wonder why it uses `inhibit-quit' in the first place). It's not org-mode which binds inhibit-quit but the C code that runs jit-lock. The C code binds inhibit-quit basically any time we run asynchronous code (i.e. code run from redisplay, timers, process-filters, ...) since the user usually doesn't really know that such is running, so if she hits C-g she doesn't mean for it to interrupt that code, but instead to do something else (e.g. get out of the minibuffer). Well, `org-mks' (in `org-capture.el') sets `inhibit-quit' to T and is called by `org-capture'. You were right, it's not a problem with `org-capture', I had a another freeze without using it. Here is the xbacktraces: gdb) xbacktrace avl-tree-delete (0x54b0) byte-code (0x55a0) byte-code (0x5760) org-element--cache-process-request (0x5990) byte-code (0x5aa0) org-element--cache-sync (0x5ce0) org-element-at-point (0x5e00) byte-code (0x60d0) org-adaptive-fill-function (0x6300) fill-match-adaptive-prefix (0x6480) fill-context-prefix (0x6620) adaptive-wrap-fill-context-prefix (0x67d0) adaptive-wrap-prefix-function (0x6a18) run-hook-with-args (0x6a10) 0x4d89f80 PVEC_COMPILED funcall (0x6b30) jit-lock-fontify-now (0x6e38) jit-lock-function (0x6fc8) vertical-motion (0xdca8) end-of-visual-line (0xde08) call-interactively (0xdfc0) org-end-of-line (0xe198) call-interactively (0xe350) command-execute (0xe478) I wonder if it is because `org-adaptive-fill-function' doesn't mix well with `adaptive-wrap-prefix-mode'... -- Daimrod/Greg
[O] [PATH] Customize org-annotate-file
Hi, Here is a small patch for contrib/lisp/org-annotate-file.el. This patch creates a customization group for org-annotate-file (child of the org group) and convert defvars to defcustoms. Okay to push? From ea5be445776f7d139f52b38306552e0012b47d0a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Gr=C3=A9goire=20Jadi?= gregoire.j...@gmail.com Date: Fri, 9 May 2014 14:58:59 +0900 Subject: [PATCH] contrib/lisp/org-annotate-file.el: Create a customization group and convert `defvar' customization variables to `defcustom' * contrib/lisp/org-annotate-file.el (org-annotate-file): New customization group. (org-annotate-file-storage-file org-annotate-file-add-search org-annotate-file-always-open): Convert `defvar' symbols to `defcustom' using the new group. --- contrib/lisp/org-annotate-file.el | 26 ++ 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/contrib/lisp/org-annotate-file.el b/contrib/lisp/org-annotate-file.el index 8fbb590..b8e8bd9 100644 --- a/contrib/lisp/org-annotate-file.el +++ b/contrib/lisp/org-annotate-file.el @@ -59,14 +59,24 @@ (require 'org) -(defvar org-annotate-file-storage-file ~/.org-annotate-file.org - File in which to keep annotations.) - -(defvar org-annotate-file-add-search nil - If non-nil, add a link as a second level to the actual file location.) - -(defvar org-annotate-file-always-open t - If non-nil, always expand the full tree when visiting the annotation file.) +(defgroup org-annotate-file nil + Org Annotate + :group 'org) + +(defcustom org-annotate-file-storage-file ~/.org-annotate-file.org + File in which to keep annotations. + :group 'org-annotate-file + :type 'file) + +(defcustom org-annotate-file-add-search nil + If non-nil, add a link as a second level to the actual file location. + :group 'org-annotate-file + :type 'boolean) + +(defcustom org-annotate-file-always-open t + If non-nil, always expand the full tree when visiting the annotation file. + :group 'org-annotate-file + :type 'boolean) (defun org-annotate-file-ellipsify-desc (string optional after) Return shortened STRING with appended ellipsis. -- 1.8.0.2722.gc0242e5 -- Daimrod/Greg
Re: [O] [PATH] Customize org-annotate-file
Bastien b...@gnu.org writes: Daimrod daim...@gmail.com writes: Okay to push? Please go ahead, thanks, done. -- Daimrod/Greg
Re: [O] loading all agenda files at startup
Eric Abrahamsen e...@ericabrahamsen.net writes: Hi Eric, I've got a few top-level user commands, related to org, that load at startup. Specifically org-agenda and org-ido-switchb are bound to keys that are available after emacs starts up. Before Org loads properly, however, things like the agenda file list and the list of valid tags and TODO keywords are unavailable. That makes it hard to boot emacs and go directly into a call to `org-todo-list': the TODO keywords aren't loaded yet. I've looked into this before but couldn't find a single function that would boot my local data. `org-agenda-files' reads the file list, but it doesn't actually parse the files and do all the setup routines. Is there a single-function entry point that I could put in my init files, that would get me where I want to be? ie, in a state as though `org-agenda' had already been called, though it hasn't yet? I call `org-agenda-list' in my `after-init-hook' but it is not silent, that is, it displays the agenda list. Best, -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] How to write a org babel hook, which can manupulate result
Feng Shu tuma...@gmail.com writes: Hi: Hi Feng, Look at the :post header argument. (info (org) post) I want to write a hook to menupulate org babel output, The problem is: How can I get two points info: [pointA] and [pointB] in my hook function? #+begin_src R :results output raw drawer tbl - data.frame(a=c(1,2,3),b=c(3,2,1)) print(ascii(tbl),type=org) #+END_SRC #+RESULTS: :RESULTS: [pointA] | |a |b | |---+--+--| | 1 | 1.00 | 3.00 | | 2 | 2.00 | 2.00 | | 3 | 3.00 | 1.00 | [pointB] :END: -- Daimrod/Greg
Re: [O] How to write a org babel hook, which can manupulate result
Feng Shu tuma...@gmail.com writes: Daimrod daim...@gmail.com writes: Feng Shu tuma...@gmail.com writes: Hi: Hi Feng, Look at the :post header argument. (info (org) post) How to use elisp in :post directly, I don't think you can. You have to use it this way (not tested): #+NAME: align-multi-table #+BEGIN_SRC emacs-lisp :var content=nil :results raw (align-multi-table content) #+END_SRC #+begin_src R :results output raw drawer :post align-multi-table(content=*this*) content #+end_src for example: #+begin_src R :results output raw drawer :post (align-multi-table) content #+end_src #+begin_comment (defun align-multi-table (optional content) (interactive) (let ((content (or content *this*))) (with-temp-buffer (insert content) (goto-char (point-min)) (while (not (eobp)) (when (org-at-table-p) (org-table-align)) (forward-line)) (buffer-string #+end_comment I want to write a hook to menupulate org babel output, The problem is: How can I get two points info: [pointA] and [pointB] in my hook function? #+begin_src R :results output raw drawer tbl - data.frame(a=c(1,2,3),b=c(3,2,1)) print(ascii(tbl),type=org) #+END_SRC #+RESULTS: :RESULTS: [pointA] | |a |b | |---+--+--| | 1 | 1.00 | 3.00 | | 2 | 2.00 | 2.00 | | 3 | 3.00 | 1.00 | [pointB] :END: -- Daimrod/Greg
Re: [O] [PATCH] Support for links to Ebib's entries
Bastien b...@gnu.org writes: Hi Greg, Daimrod daim...@gmail.com writes: I've attached a small patch to support links (opening and storing) to Ebib's[1] entries. Can I integrate it? Sure, please go ahead, thanks! Done. Best, -- Daimrod/Greg
[O] [PATCH] Support for links to Ebib's entries
Hi, I've attached a small patch to support links (opening and storing) to Ebib's[1] entries. Can I integrate it? 1: http://joostkremers.github.io/ebib/ From acd007302d56d40189659853ef146407bb64ba20 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Gr=C3=A9goire=20Jadi?= gregoire.j...@gmail.com Date: Wed, 12 Mar 2014 08:06:13 +0900 Subject: [PATCH] contrib/lisp/org-ebib.el: Support for links to Ebib's entries * contrib/lisp/org-ebib.el: Support for links to Ebib's entries. (org-ebib-open): Open an Ebib's entry. (org-ebib-store-link): Store a link to an Ebib's entry. --- contrib/lisp/org-ebib.el | 47 +++ 1 file changed, 47 insertions(+) create mode 100644 contrib/lisp/org-ebib.el diff --git a/contrib/lisp/org-ebib.el b/contrib/lisp/org-ebib.el new file mode 100644 index 000..2136a13 --- /dev/null +++ b/contrib/lisp/org-ebib.el @@ -0,0 +1,47 @@ +;;; org-ebib.el - Support for links to Ebib's entries in Org +;; +;; Author: Grégoire Jadi daim...@gmail.com +;; +;; This file is not yet part of GNU Emacs. +;; +;; This program is free software; you can redistribute it and/or modify +;; it under the terms of the GNU General Public License as published by +;; the Free Software Foundation; either version 3, or (at your option) +;; any later version. + +;; This program is distributed in the hope that it will be useful, +;; but WITHOUT ANY WARRANTY; without even the implied warranty of +;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +;; GNU General Public License for more details. + +;; You should have received a copy of the GNU General Public License +;; along with GNU Emacs. If not, see http://www.gnu.org/licenses/. +; +;; +;;; Commentary: + +(require 'org) + +(org-add-link-type ebib 'org-ebib-open) + +(add-hook 'org-store-link-functions 'org-ebib-store-link) + +(defun org-ebib-open (key) + Open Ebib and jump to KEY. + (ebib nil key)) + +(defun org-ebib-store-link () + Store a key to an Ebib entry. + (when (memq major-mode '(ebib-index-mode ebib-entry-mode)) +;; This is an Ebib entry +(let* ((key (ebib-cur-entry-key)) + (link (concat ebib: key)) + (description (ignore-errors (ebib-db-get-field-value 'title key ebib-cur-db + (org-store-link-props + :type ebib + :link link + :description description + +(provide 'org-ebib) + +;;; org-ebib.el ends here -- 1.8.0.2722.gc0242e5 -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] Some links not working anymore for me
François Pinard pin...@iro.umontreal.ca writes: Hi, Org people. Hello, For a little while, I've not been able to follow links to Org files, when the link contains a search to some header, and the searched header itself contains white space or non-ASCII characters. I just made this patch that apparently helps me out of this new little misery :-). The patch is only indicative: I'm not sure it is the proper way to solve the difficulty, as I do not really understand all the code surrounding it! See this commit 8 days ago: 567ec87 * | Unescape links before opening them diff --git a/lisp/org.el b/lisp/org.el index a0ed137..5c41b52 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -10555,7 +10555,8 @@ is used internally by `org-open-link-from-string'. (cond ((not option) nil) ((org-string-match-p \\`[0-9]+\\' option) (list (string-to-number option))) -(t (list nil option +(t (list nil + (org-link-unescape option) ((assoc type org-link-protocols) (funcall (nth 1 (assoc type org-link-protocols)) path)) ((equal type help) François -- Daimrod/Greg
Re: [O] can org-mode file export to markdown file
jenenliu jenen...@gmail.com writes: Hello, Can I write a org file and then export it as a markdown file ? Sure, just load the library `ox-md' then you can export to a markdown file with C-c C-e m m -- Daimrod/Greg
Re: [O] analog of org-element-at-point for objects?
John Kitchin jkitc...@andrew.cmu.edu writes: Hi John, Is there an easy way to to get the object at point? I found org-element-at-point, but what I need is to determine if point is on a link of a particular type, and links appear to be objects rather than elements. I think that `org-element-context' is what you're looking for. an alternative solution for me would be how do you move point to the beginning of a link (if it is on a link)? I found org-next-link and org-previous-link, but neither of these move you to the beginning of the current link. Then, I could use org-element-link-parser, but that only works with point at the beginning of a link. The reason I was looking into this is here: http://kitchingroup.cheme.cmu.edu/blog/2014/03/07/Storing-label-links-in-org-mode/ It just seems there must be a better way than I implemented. thanks! Best, -- Daimrod/Greg
Re: [O] [Bug] org-open-at-point adds file+
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Daimrod daim...@gmail.com writes: I think that since its recent rewrite, `org-open-at-point' adds 'file+' before the name of the application before trying to find the correct application. For example the following link: #+BEGIN_EXAMPLE [[docview:foo.pdf]] #+END_EXAMPLE won't trigger the `org-docview-open' handler This should be fixed. Thank you for reporting it. Thanks for the fast reply. Regards, -- Daimrod/Greg
Re: [O] org-element-context doesn't parse consistently link with spaces
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Daimrod daim...@gmail.com writes: I think that there is a bug in `org-element-context' because it doesn't seem to parse link with spaces consistently. For example: #+BEGIN_EXAMPLE v [[file:test 1 2 3]] ^ #+END_EXAMPLE If the cursor is before the '1', then `org-element-context' will return: #+BEGIN_EXAMPLE (link (:type file :path test :raw-link file:test :application nil :search-option nil :begin 26 ...)) #+END_EXAMPLE if the cursor is one or after the '1', then `org-element-context' will return: #+BEGIN_EXAMPLE (link (:type file :path test%201%202%203 :raw-link file:test%201%202%203 :application nil :search-option nil :begin 1 ...)) #+END_EXAMPLE I cannot reproduce it. What Org version do you use? Did you try to disable `org-element-use-cache'? Sorry, it happens with: #+BEGIN_EXAMPLE [[file:test%201%202%203][file:test 1 2 3]] #+END_EXAMPLE I use org-mode version release_8.0.2-101-gce5988 (I follow the git upstream) and I tried it with `org-element-use-cache' set to nil. It doesn't happen with: #+BEGIN_EXAMPLE [[file:test 1 2 3]] #+END_EXAMPLE but as soon as the cursor leaves the link, org-mode rewrite the link to: #+BEGIN_EXAMPLE [[file:test%201%202%203][file:test 1 2 3]] #+END_EXAMPLE Best, -- Daimrod/Greg
Re: [O] org-element-context doesn't parse consistently link with spaces
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Daimrod daim...@gmail.com writes: I use org-mode version release_8.0.2-101-gce5988 (I follow the git upstream) and I tried it with `org-element-use-cache' set to nil. There was no `org-element-use-cache' in Org 8.0. Could you update Org and try again? I had forgotten to rerun make after I pulled the latest version. `org-version' now returns 8.2.5h. And you're right, it doesn't happen when `org-element-use-cache' is set to nil. However, when `org-element-use-cache' is set to t, then it looks like `org-element-context' uses the link's title instead of the link's value. e.g. #+BEGIN_EXAMPLE v-- with the cursor here, it returns (link (:type file :path foo ...)) [[file:foo][file:test 1 2 3]] ^-^ when the cursor is in this zone, it returns (link (:type file :path test ...)) ^-- when the cursor is after this point (after the first space) it returns (link (:type file :path test 1 2 3 ...)) #+END_EXAMPLE Best, -- Daimrod/Greg
Re: [O] org-element-context doesn't parse consistently link with spaces
Nicolas Goaziou n.goaz...@gmail.com writes: Daimrod daim...@gmail.com writes: I had forgotten to rerun make after I pulled the latest version. `org-version' now returns 8.2.5h. This is still not right. 8.2.5h refers to maint branch, where cache doesn't exist. When I compile the latest release on master, I get: Org-mode version 8.2.5e (release_8.2.5e-231-g51718d) So, I'm confused. On what branch are you? I really don't understand. I am on the master branch, the latest commit I see is yours (51718d9 Fix last commit). I'm trying with a fresh clone. Regards, -- Daimrod/Greg
Re: [O] org-element-context doesn't parse consistently link with spaces
Bastien b...@gnu.org writes: Hi Nicolas and Greg, Nicolas Goaziou n.goaz...@gmail.com writes: Daimrod daim...@gmail.com writes: I had forgotten to rerun make after I pulled the latest version. `org-version' now returns 8.2.5h. This is still not right. 8.2.5h refers to maint branch, where cache doesn't exist. I think Greg did C-h v org-version RET, which returns 8.2.5h both from the maint and the master branch. Greg: M-x org-version RET gives all the information we need. Awww that's tricky, M-x org-version doesn't have the same behavior than M-: (org-version) M-x org-version returns: Org-mode version 8.2.5h (release_8.2.5h-678-gd8c717 @ ...) -- Daimrod/Greg
Re: [O] org-element-context doesn't parse consistently link with spaces
Daimrod daim...@gmail.com writes: Nicolas Goaziou n.goaz...@gmail.com writes: Daimrod daim...@gmail.com writes: I had forgotten to rerun make after I pulled the latest version. `org-version' now returns 8.2.5h. This is still not right. 8.2.5h refers to maint branch, where cache doesn't exist. When I compile the latest release on master, I get: Org-mode version 8.2.5e (release_8.2.5e-231-g51718d) So, I'm confused. On what branch are you? I really don't understand. I am on the master branch, the latest commit I see is yours (51718d9 Fix last commit). I'm trying with a fresh clone. Still the same with a fresh clone. Regards, -- Daimrod/Greg
[O] [Bug] org-open-at-point adds file+
Hello, I think that since its recent rewrite, `org-open-at-point' adds 'file+' before the name of the application before trying to find the correct application. For example the following link: #+BEGIN_EXAMPLE [[docview:foo.pdf]] #+END_EXAMPLE won't trigger the `org-docview-open' handler because the following code: #+BEGIN_SRC emacs-lisp (or (let ((app (org-element-property :application context))) (nth 1 (assoc (concat file (and app (concat + app))) org-link-protocols))) #'org-open-file) #+END_SRC adds `file+' and then search in `org-link-protocols'. -- Daimrod/Greg signature.asc Description: PGP signature
[O] org-element-context doesn't parse consistently link with spaces
Hello, I think that there is a bug in `org-element-context' because it doesn't seem to parse link with spaces consistently. For example: #+BEGIN_EXAMPLE v [[file:test 1 2 3]] ^ #+END_EXAMPLE If the cursor is before the '1', then `org-element-context' will return: #+BEGIN_EXAMPLE (link (:type file :path test :raw-link file:test :application nil :search-option nil :begin 26 ...)) #+END_EXAMPLE if the cursor is one or after the '1', then `org-element-context' will return: #+BEGIN_EXAMPLE (link (:type file :path test%201%202%203 :raw-link file:test%201%202%203 :application nil :search-option nil :begin 1 ...)) #+END_EXAMPLE Best, -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] http link character mistranslated
Daimrod daim...@gmail.com writes: Fixed by ngz in commit 567ec87 mirko mirko.vuko...@gmail.com writes: Hi, Hello, (Org-mode version 8.2.5h (release_8.2.5h-651-g897b60) I have an https address with an equal sign `=': https://forums.virtualbox.org/viewforum.php?f=3 When I try to access the link, the `=' is translated as `%D': https://forums.virtualbox.org/viewforum.php?f%3D3 I have the same problem here. It causes problem with docview and gnus links. I looked in org-open-at-point, and the translation appears somewhere in org-element-property. I did not look deeper. IIUC, since I don't know when, org-mode encode links with percent encoding (you can check it by turning off org-mode (e.g. M-x fundamental-mode)). My guess is that it is now the job of the link handler (FOLLOW arg in org-add-link-type) to unescape the path if necessary, but I'm not sure of it. I tested this in an Emacs session with only org mode loaded (no user init) Thanks, Mirko -- Daimrod/Greg
Re: [O] http link character mistranslated
mirko mirko.vuko...@gmail.com writes: Hi, Hello, (Org-mode version 8.2.5h (release_8.2.5h-651-g897b60) I have an https address with an equal sign `=': https://forums.virtualbox.org/viewforum.php?f=3 When I try to access the link, the `=' is translated as `%D': https://forums.virtualbox.org/viewforum.php?f%3D3 I have the same problem here. It causes problem with docview and gnus links. I looked in org-open-at-point, and the translation appears somewhere in org-element-property. I did not look deeper. IIUC, since I don't know when, org-mode encode links with percent encoding (you can check it by turning off org-mode (e.g. M-x fundamental-mode)). My guess is that it is now the job of the link handler (FOLLOW arg in org-add-link-type) to unescape the path if necessary, but I'm not sure of it. I tested this in an Emacs session with only org mode loaded (no user init) Thanks, Mirko -- Daimrod/Greg
Re: [O] orc-contacts contacting ww.gravatar.com! -- How to switch off?
AW alexander.will...@t-online.de writes: Hi, I'm exploring the org-contacts. When I do M-x org-contacts, Emacs tries to contact www.gravatar.com:80 How can I switch that off? You can set `org-contacts-icon-use-gravatar' to nil. Besides that, what I really miss is a comprehensive manual on org-contact. OK, I can search for a name as described above, I can add a new contact with M-x org-capture, but what else? Thank you, Regards, Alexander -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] [PATCH] org-contacts: Update contacts cache if it contains markers with no buffer
Øyvind Stegard oyvi...@ifi.uio.no writes: 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. 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. Regards, Øyvind -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] [PATCH] org-contacts: Update contacts cache if it contains markers with no buffer
Øyvind Stegard oyvi...@ifi.uio.no writes: Hi list, Hello, 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. 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) Regards, Øyvind -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] Circular lists/shared structures in org-element parse-tree
Thorsten Jolitz tjol...@gmail.com writes: Hi List, I wonder how I can find out in a (elisp) program the points in the parse tree (returned by org-element-parse-buffer) where shared structures are used. In the read-syntax, its easy to see (especially with `print-circle' set to non-nil): #+begin_src emacs-lisp #2=(org-data nil #1=(headline (:raw-value header 1 [...] :parent #2#) [...] #+end_src but when processing the parse tree as a list in elisp, how can I detect the fact that , | :parent #2# ` refers to ,- | #2=(org-data nil `- i.e. points back to an already existing structure? AFAIK you have to track all pointers inspected to see if one has already be seen. For example, I've implemented a version of equal[1] to compare this kind of lists (to add tests to org-sync). [1] https://github.com/daimrod/Emacs-config/blob/master/elisp/dmd-utils.el#L25 -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] [PATCH] org-contacts: Provide ordering when using cycle completion
Øyvind Stegard oyvi...@ifi.uio.no writes: Hello list, Hello, Merged into master, thanks for patch! 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. -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] [patch] Add a complex org-contacts template to the file header
Feng Shu tuma...@gmail.com writes: Thanks for the patch! It's merged, I've taken the liberty to fix some typos. Regards, -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] Handling outdated contact information
Karl Voit devn...@karl-voit.at writes: * Daimrod daim...@gmail.com wrote: Hi Karl, Hi Daimrod! This is a very good patch, fixing an issue I also do have currently. I am curious, what was the issue? Sure: I do use contacts.org by myself and I tend to collect data about people and never delete any. For example, previously used phone numbers are quite handy in order to get a connection between old text messages or phone call logs and a person. However, I do not want to mess up current phone numbers with old ones. With this ignore feature, I am able to address this issue (in the future). For now, I do not export contact information from Org-mode to somewhere else (except: lbdb - mutt). In the future, I plan to add a workflow that gets contact information form Org-mode (my central point of information) to my phone and so forth. I see, thanks for the explanation. -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] [PATCH] org-contacts.el: add expire feature
Feng Shu tuma...@gmail.com writes: Daimrod daim...@gmail.com writes: This is not very idiomatic elisp, I would write something more like: #+BEGIN_SRC emacs-lisp (remove-if (lambda (el) (member el expire-list)) list) #+END_SRC Thanks! Is this possible? test1@g = te...@gmail.com Yes, you could do it like this: #+BEGIN_SRC emacs-lisp (remove-if (lambda (el) (find-if (lambda (x) (string-match-p x el)) expire-list)) list) #+END_SRC This way you can use regular expressions in the ignore list. -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] [PATCH] org-contacts.el: add expire feature
Feng Shu tuma...@gmail.com writes: Hi Daimrod! This is the 3 updated patch, if possible, please include it to master. It's merged and pushed. I've also pushed another commit to fix the formatting in some parts of the code and I've found a bug in `org-contacts-split-property', but it should be fixed now. Thanks for your help! -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] [Patch] phone links...
Michael Strey mst...@strey.biz writes: Hello Michael, While merging a patch (from Feng Shu) I have found a bug in `org-contacts-split-property'. Though the docstring says that OMIT-NULLS is forced to t when SEPARATORS is nil (just like `split-string'), it wasn't the case. I've pushed a fix; could you check on your side that it doesn't break anything in your workflow? Thanks, -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] [PATCH] org-contacts.el: add expire feature
Karl Voit devn...@karl-voit.at writes: Hi Karl, This is a very good patch, fixing an issue I also do have currently. I am curious, what was the issue? Regards, -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] [PATCH] org-contacts.el: add expire feature
-property properties (head (format BEGIN:VCARD\nVERSION:3.0\nN:%s\nFN:%s\n n name)) + (expire-list (when expire (setq expire-list (org-contacts-split-property expire emails-list result phones-list) (concat head (when email (progn - (setq emails-list (org-contacts-split-property email)) + (setq emails-list (org-contacts-remove-expired-property expire-list (org-contacts-split-property email))) ; There is a leading semi-colon. (setq result ) (while emails-list (setq result (concat result EMAIL: (org-contacts-strip-link (car emails-list)) \n)) @@ -886,7 +908,7 @@ to do our best. (when addr (format ADR:;;%s\n (replace-regexp-in-string \\, ? ; addr))) (when tel (progn - (setq phones-list (org-contacts-split-property tel)) + (setq phones-list (org-contacts-remove-expired-property expire-list (org-contacts-split-property tel))) (setq result ) (while phones-list (setq result (concat result TEL: (org-contacts-strip-link (car phones-list)) \n)) -- 1.7.10.4 [1] http://orgmode.org/worg/org-contribute.html#sec-5 -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] [PATCH] org-contacts.el: add expire feature
Feng Shu tuma...@gmail.com writes: (defun org-contacts-complete-name (start end string) Complete text at START with a user name and email. (let* ((completion-ignore-case org-contacts-completion-ignore-case) @@ -484,10 +497,17 @@ A group FOO is composed of contacts with the tag FOO. ;; The contact name is always the car of the assoc-list ;; returned by `org-contacts-filter'. for contact-name = (car contact) + + ;; Build the list of the email addresses which has + ;; been expired + for expire-list = (org-contacts-split-property (or + (cdr (assoc-string org-contacts-expire-property + (caddr contact))) )) ;; Build the list of the user email addresses. - for email-list = (org-contacts-split-property (or - (cdr (assoc-string org-contacts-email-property -(caddr contact))) )) + for email-list = (org-contacts-remove-expired-property expire-list + (org-contacts-split-property (or + (cdr (assoc-string org-contacts-email-property + (caddr contact))) ))) I forgot to ask, why do you also modify org-contacts-complete-name? This function isn't used to export to VCARD, but to complete the email in Gnus. -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] org-element
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Hello Nicolas, Daimrod daim...@gmail.com writes: I'm playing a bit with org-element for org-contacts and I wanted to know what is the prefered way to change an element. For example, ATM, when I want to change an element property to add a new value, I do: #+BEGIN_SRC emacs-lisp (org-entry-put nil property (concat (org-entry-get nil property) new-value)) #+END_SRC See `org-element-put-property' and friends. I've tried to use `org-element-put-property' but it only modifies the object in memory, not the element in the file. Is there a way to write the object into a file? Regards, -- Daimrod/Greg pgpx5qxLaG4B3.pgp Description: PGP signature
[O] org-element
Hi, I'm playing a bit with org-element for org-contacts and I wanted to know what is the prefered way to change an element. For example, ATM, when I want to change an element property to add a new value, I do: #+BEGIN_SRC emacs-lisp (org-entry-put nil property (concat (org-entry-get nil property) new-value)) #+END_SRC Is it the correct way? IMHO it would be nicer if we could modify an object created by the new parser and write it back but I don't think it is possible (yet?). Regards, -- Daimrod/Greg pgpZ70aTA0Nyn.pgp Description: PGP signature
Re: [O] require a feature: merge many contacts which have the same name.
Feng Shu tuma...@gmail.com writes: I think org-contacts.el shoule have the feature which can merge many contacts which have the same name into one, for example: #+begin_example * name :PROPERTIES: :EMAIL: [[mailto:a...@a.com]] [[mailto:b...@b.com]] :PHONE: [[tel:123456789]] :ALIAS:a :END: * name :PROPERTIES: :EMAIL: [[mailto:c...@a.com]] [[mailto:d...@b.com]] :PHONE: [[tel:987654321]] :ALIAS:b :END: * name :PROPERTIES: :EMAIL: [[mailto:e...@a.com]] [[mailto:f...@b.com]] :PHONE: [[tel:111]] :ALIAS:c :END: #+end_example how can I get the result: #+begin_example * name :PROPERTIES: :EMAIL: [[mailto:a...@a.com]] [[mailto:b...@b.com]] [[mailto:c...@a.com]] [[mailto:d...@b.com]] [[mailto:e...@a.com]] [[mailto:f...@b.com]] :PHONE: [[tel:123456789]] [[tel:987654321]] [[tel:]] :ALIAS:a b c :END: #+end_example Hi Feng, It's noted, I'll see what I can do this week-end. -- Daimrod/Greg pgpgoAyLvZ17T.pgp Description: PGP signature
[O] bug#14374: bug#14374: Possibly incorrect custom :types
Glenn Morris r...@gnu.org writes: Hi Glenn, Thanks for this detailled report. May I ask how you did you tests? I can't find cus-test.el in my Emacs. I've attached a diff patch where I fix some of this. Package: org-mode cus-test.el suggests the following variables may have incorrect custom :types. (There may be some false positives.) This refers to Org mode in current Emacs trunk. Eg, org-footnote-auto-adjust does not have nil as an option. org-refile-target-verify-function It's a function with no function by default and I don't know how to fix it. Should we use '(choice function nil)? org-icalendar-combined-description Seems fine to me. org-link-frame-setup Patched (I've only interferred the functions name could VM users confirmed that they are correct). org-export-with-archived-trees Patched. org-bibtex-prefix It's suppose to be a string and after a quick look at the code I think it's safe to set it to nil but I'm not sure. org-log-note-headings Patched. org-structure-template-alist Patched. org-export-html-postamble-format I think it's named `org-html-postamble-format' in master. The docstring and the type talks about an alist but the default value is not. I don't know which one is correct (the default value or the description). org-get-priority-function Same problem than `org-refile-target-verify-function'. org-export-odt-content-template-file Now `org-odt-content-template-file', the type is a file but the default value is nil. Should we use '(choice file nil)? org-export-latex-quotes I couldn't find this variable in master. org-export-html-toplevel-hlevel Now `org-html-toplevel-hlevel' and it doesn't seem to be wrong. org-agenda-ndays The type is an integer but the default value is nil. Should we use '(choice integer nil)? I've just seen Carsten's mail so I'll stop here. org-export-initial-scope org-plantuml-jar-path org-export-blocks-witheld org-make-link-description-function org-export-html-postamble org-babel-lob-files org-agenda-export-html-style org-clock-heading-function org-show-notification-handler org-agenda-custom-commands org-beamer-outline-frame-options org-agenda-day-face-function org-use-fast-tag-selection org-export-docbook-xsl-fo-proc-command org-link-translation-function org-export-docbook-xslt-stylesheet org-export-docbook-xslt-proc-command org-columns-modify-value-for-display-function org-export-html-preamble-format org-agenda-auto-exclude-function org-export-docbook-doctype org-wl-namazu-default-index org-agenda-inactive-leader org-export-ascii-underline org-sparse-tree-default-date-type org-footnote-auto-adjust org-protocol-default-template-key defcustom-fixes.path Description: Binary data -- Daimrod/Greg pgp38ECem9JSK.pgp Description: PGP signature