Re: [O] [solved] Re: Org-class: recurring appointments not being displayed
On 7.1.2012, at 02:59, knubee wrote: * Class 7:00pm-9:00pm %% (org-class 2011 1 10 2011 4 10 2 8) Just figured out the problem. I was using 2011 and looking for the results in agenda for 2012 (now). Classic start of a new year mistake. Doh! :) That is pretty funny! I missed it as well Happy new year!
Re: [O] org-jira.el updated
Richard Riley rile...@gmail.com writes: Ken Williams kena...@gmail.com writes: Bao Haojun baohaojun at gmail.com writes: I have updated the org-jira.el as suggested by Bastien and Richard Riley: Amazing. Just 120 seconds ago I got out of a meeting where we talked about using Jira more widely in our company, and I worried that I'd duplicate too much between my org-mode journals and the Jira tracker. Then I go look at the org-mode list and this is the first message I see. =) I'm going to need to upgrade to org-mode 7.8 and try this out. I would love to see a video of jira being used in conjunction with org-mode. Anyone have one? Good idea! I have recorded one and uploaded it to YouTube: http://youtu.be/6Sp3h1Qlf4w -- All the best Bao Haojun
[O] C-k in visual line mode
Hi, Org people. Let me suggest this tiny patch, so C-k does the proper thing in visual line mode. diff --git a/lisp/org.el b/lisp/org.el index a8ac17d..2d0db0c 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -20491,7 +20491,8 @@ depending on context. (if (or (eq org-ctrl-k-protect-subtree 'error) (not (y-or-n-p Kill hidden subtree along with headline? ))) (error C-k aborted - would kill hidden subtree))) -(call-interactively 'kill-line)) +(call-interactively + (if visual-line-mode 'kill-visual-line 'kill-line))) ((looking-at (org-re .*?\\S-\\([ \t]+\\(:[[:alnum:]_@#%:]+:\\)\\)[ \t]*$)) (kill-region (point) (match-beginning 1)) (org-set-tags nil t)) François
[O] Problem at capture time
Hi, Org people.
On 2011-12-11 23:24, I reported a problem met while using the Org
capture facility, and a patch working around the problem. David Maus
then requested for details, which I sent on 2011-12-19 00:59. David's
mailer rejected my reply as being likely SPAM, but it made it to the
emacs-orgmode@gnu.org mailing list, so I presume David got it. Here are
references I have for both messages:
- [[gnus:gmane.emacs.orgmode#8739cqo1s3@iro.umontreal.ca][Email from
François Pinard: Capture failure {7.7}]]
- [[gnus:gmane.emacs.orgmode#871us1f6fo@iro.umontreal.ca][Email from
François Pinard: Re: Capture failure {7.7}]]
This morning, I removed my patch locally. Using a fresh Git pull of Org
mode, the problem is still there, showing as:
Debugger entered--Lisp error: (error Capture template `d':
integer-or-marker-p)
signal(error (Capture template `d': integer-or-marker-p))
error(Capture template `%s': %s d integer-or-marker-p)
byte-code(\301p!\203. \302\303\304
\\203. \305p!\210\306\307\310!!\210\300\311\307\312!A@#\207 [error
buffer-base-buffer string-match \\`CAPTURE- buffer-name kill-buffer
set-window-configuration org-capture-get :return-to-wconf Capture template
`%s': %s :key] 4)
org-capture(nil)
call-interactively(org-capture nil nil)
The problem, which I described two months ago, is that some variables in
org-capture.el (org-capture-place-item) do not get properly initialized
depending on the flow within the function. The following patch solves
the problem for me:
diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 46202f8..508611d 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -913,7 +913,8 @@ it. When it is a variable, retrieve the value. Return
whatever we get.
beg end)
(cond
((org-capture-get :exact-position)
- (goto-char (org-capture-get :exact-position)))
+ (goto-char (org-capture-get :exact-position))
+ (setq beg (point) end (point)))
((not target-entry-p)
;; Insert as top-level entry, either at beginning or at end of file
(setq beg (point-min) end (point-max)))
Could it be integrated in the main stream? I'm not sure that (point)
is the best value to give for beg and end (I do not understand the
code enough), but surely, this is better than capture just crashing.
François
Re: [O] Problem at capture time
pin...@iro.umontreal.ca (François Pinard) writes: Hi, Org people. [...] The problem, which I described two months ago, Hmph! My math is clearly wrong! One month ago! :-) Sorry. François P.S. Who never had the the memory of times...
Re: [O] Agenda buffer and relative links
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi François, Hello, Sebastien! François Pinard wrote: Nick Dokos nicholas.do...@hp.com writes: François Pinard pin...@iro.umontreal.ca wrote: When Org mode defines a link for me, it sometimes changes it so it becomes relative. [...] This is OK in general, but not always. There is a virtue in relative links which I recognize. So having an option to force all links to be absolute might not be a solution. Would this help you? ┏ ┃ org-link-file-path-type is a variable defined in `org.el'. ┗ Maybe, I might even end up using it, who knows. It does not solve the problem I tried to describe. Relative links allow for moving whole hierarchies elsewhere, so the current default Org behaviour is good. But not good enough for the agenda buffer. Links do not always work in there, and this is the problem to solve. The problem has ramifications. François P.S. Nice way to quote, by the way! :-)
Re: [O] Emacs macros and capture
*Bump!* Anyone? Mueen Nawaz mailingli...@nawaz.org writes: Hi, I'm seeing some weird behavior with my capture template setup. I have the following in my capture templates: (r Reply entry (file+headline ~/org/gtd/gtd.org Reply) * TODO %:subject :@respond:@email: \n %u\n %i\n %a\nFrom: %:from\nID:%:message-id\n %? :immediate-finish t) What this template does is create a new headline under Reply in my gtd.org file with the subject as the title of the headline. It will then place a link to the email as well as some other metadata. Here's an example: *** TODO LibraryThing: State of the Thing - December 2011:@review:@email: [2011-12-28 Wed] [[notmuch:id:201112151815.pbfiflxh021...@athena.librarything.com][Email from jer...@librarything.com: LibraryThing: State of the Thi]] From: jer...@librarything.com ID:201112151815.pbfiflxh021...@athena.librarything.com end example That works fine. Now if I record the keystrokes as a macro, and then execute the macro, here is what I get (same email as above): *** TODO LibraryThing: State of the Thing - December 2011:@review:@email: [2011-12-28 Wed] From: jer...@librarything.com ID:201112151815.pbfiflxh021...@athena.librarything.com end example As you can see, it recorded everything _but_ the link (the most important part). Any idea why this happens? Thanks.
Re: [O] Agenda buffer and relative links
pin...@iro.umontreal.ca (François Pinard) writes: The following message is a courtesy copy of an article that has been posted to gmane.emacs.orgmode as well. Hmph, I now wonder if the link is bidirectional, and if messages posted to gmane.emacs.orgmode actually end up on emacs-orgmode@gnu.org. I'm repeating it all below, quoted. (Would someone be kind enough to tell me if it was seen on the mailing list?) A good solution imposed itself to my mind, a few minutes ago. I do not know how easy to implement it would be however. The real problem is that relative links within the agenda buffer are interpreted relative to the directory (M-x pwd) of the agenda buffer. Happily enough, each line of the agenda buffer is somehow associated with the buffer it comes from. Links within the agenda should be interpreted relative to the base directory of the buffer they come from, rather than from the agenda buffer itself. François Sebastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: Hi François, Hello, Sebastien! François Pinard wrote: Nick Dokos nicholas.dokos-vxdhtt5m...@public.gmane.org writes: François Pinard pinard-crdztm1onbswkkpyngo...@public.gmane.org wrote: When Org mode defines a link for me, it sometimes changes it so it becomes relative. [...] This is OK in general, but not always. There is a virtue in relative links which I recognize. So having an option to force all links to be absolute might not be a solution. Would this help you? ┏ ┃ org-link-file-path-type is a variable defined in `org.el'. ┗ Maybe, I might even end up using it, who knows. It does not solve the problem I tried to describe. Relative links allow for moving whole hierarchies elsewhere, so the current default Org behaviour is good. But not good enough for the agenda buffer. Links do not always work in there, and this is the problem to solve. The problem has ramifications. François P.S. Nice way to quote, by the way! :-)
[O] Manual -- updating the Customization node
Hi, Org people. This is half a tease, half a report :-) Section 15.5 Customization in the Org manual says: There are more than 180 variables that can be used to customize Org. In a recent message to the mailing list, someone said 580 or so variables. Another gave a number over one thousand. Maybe that 180 is too low an estimate, at least from now on, and should be amended! François
Re: [O] Agenda buffer and relative links
Hi François, François Pinard wrote: pin...@iro.umontreal.ca (François Pinard) writes: The following message is a courtesy copy of an article that has been posted to gmane.emacs.orgmode as well. Hmph, I now wonder if the link is bidirectional, and if messages posted to gmane.emacs.orgmode actually end up on emacs-orgmode@gnu.org. I'm repeating it all below, quoted. (Would someone be kind enough to tell me if it was seen on the mailing list?) I saw your posting of 18:39... Reading this ML through Gmane, though. A good solution imposed itself to my mind, a few minutes ago. I do not know how easy to implement it would be however. The real problem is that relative links within the agenda buffer are interpreted relative to the directory (M-x pwd) of the agenda buffer. Happily enough, each line of the agenda buffer is somehow associated with the buffer it comes from. Links within the agenda should be interpreted relative to the base directory of the buffer they come from, rather than from the agenda buffer itself. I must admit I'm not hit -- yet? -- by your problem, as I never (I should never say that) have links in my headings. So, what I would do, is jump to the referenced heading (using RET or SPC) and activate it from there. BTW, just to confirm, is it the same is the link is in the very first line under a heading, and made visible from the agenda through `E': ┏ ┃ E runs the command org-agenda-entry-text-mode, which is an interactive Lisp ┃ function in `org-agenda.el'. ┃ ┃ It is bound to E, menu-bar Agenda View Show some entry text. ┃ ┃ (org-agenda-entry-text-mode optional ARG) ┃ ┃ Toggle entry text mode in an agenda buffer. ┗ Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi François, Hello, Sebastien! François Pinard wrote: Nick Dokos nicholas.do...@hp.com writes: François Pinard pin...@iro.umontreal.ca wrote: When Org mode defines a link for me, it sometimes changes it so it becomes relative. [...] This is OK in general, but not always. There is a virtue in relative links which I recognize. So having an option to force all links to be absolute might not be a solution. Would this help you? ┏ ┃ org-link-file-path-type is a variable defined in `org.el'. ┗ Maybe, I might even end up using it, who knows. It does not solve the problem I tried to describe. Relative links allow for moving whole hierarchies elsewhere, so the current default Org behaviour is good. But not good enough for the agenda buffer. Links do not always work in there, and this is the problem to solve. The problem has ramifications. François P.S. Nice way to quote, by the way! :-) M-x boxquote, with custom settings. Best regards, Seb -- Sebastien Vauban
[O] [PATCH] Documentation of :results wrap
Aloha all,
The attached patch to the Org mode manual describes the current behavior
of :results wrap.
All the best,
Tom
From bc7b5fe2cc52de4468cf847e72cb0a507ebb1626 Mon Sep 17 00:00:00 2001
From: Thomas Dye dk@poto.local
Date: Sat, 7 Jan 2012 20:38:53 -1000
Subject: [PATCH] * doc/org.texi: :results wrap produces a drawer instead of a
begin_results block
---
doc/org.texi |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index bc82e0b..c4031d7 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -13351,9 +13351,9 @@ The result is converted to pretty-printed code and is enclosed in a code
block. This option currently supports Emacs Lisp, Python, and Ruby. E.g.,
@code{:results value pp}.
@item @code{wrap}
-The result is wrapped in a @code{begin_result} block. This can be useful for
+The result is wrapped in a RESULTS drawer. This can be useful for
inserting @code{raw} or @code{org} syntax results in such a way that their
-extend is known and they can be automatically removed or replaced.
+extent is known and they can be automatically removed or replaced.
@end itemize
@subsubheading Handling
--
1.7.5.4
--
T.S. Dye Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com
