[O] Global TODO: display more than the TODO heading line?
I use orgmode as a to do tracker rather than a scheduler, so C-cat is my main command. I have a bunch of files with TODO items in various states including WAITING and HOLD. When I change something to the WAITING or HOLD state, the C-c C-t command is set to ask why so a line of information is in the org file after the TODO line. (setq org-todo-keywords (quote ((sequence TODO(t) NEXT(n) SCHEDULED(s) | DONE(d)) (sequence WAITING(w@/!) HOLD(h@/!) | CANCELLED(c@/!) PHONE MEETING I'd love to see that line of information in the TODO list so I know why something is waiting or on hold without having to visit it. So and org file entry that looks like this: * HOLD make staffauth group and upload keys - State HOLD from TODO [2013-12-16 Mon 11:54] \\ Hold till we can work out a group to create (or a current one to use?) Now appears in the global todo list as: 56726-user-keys-ovl01.syd:HOLD make staffauth group and upload keys and I'd like to see something like 56726-user-keys-ovl01.syd:HOLD make staffauth group and upload keys Hold till we can work out a group to create (or a current one to use?) Can the todo list be tweaked in this way? Can some other agenda view be created so that the comments made when the item is set to WAITING or HOLD show up? With or without the date the comment was made? Zebee
[O] Missing patch from Eric Schulte from 2013-10-09
Hi, I noticed that I miss the following patch from Eric Schulte (from 2 months ago): http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=15847336c39e7219e1c51c55d487f99956a06e34 I have Org-mode version 8.2.4 (8.2.4-8-gf1b933-elpaplus @ c:/Users/fpz/Documents/home/.emacs.d/elpa/org-plus-contrib-20131216/) taken from elpa. When I download the current stable release of Org-mode (version 8.2.4 from http://orgmode.org/) I see that this patch is missing too (the org-babel-tangle-use-relative-file-links variable is missing). Any chance to get this patch in elpa (without having to clone the git master branch)? Thanks a lot for your help, Francesco
[O] Missing contrib packages
Hi, I have Org-mode version 8.2.4 (8.2.4-8-gf1b933-elpaplus @ c:/Users/fpz/Documents/home/.emacs.d/elpa/org-plus-contrib-20131216/). I notice that I miss several packages like htmlize (important) and org-effectiveness. My questions are: - why, in the org-plus-contrib from elpa, I miss these packages (present in the master branch)? - why, in the release version 8.2.4 downloaded from http://orgmode.org/, I have htmlize but not org-effectiveness? Thanks a lot, Francesco
Re: [O] Bug: Bad ODT files when including multiple images [7.9.3f (release_7.9.3f-17-g7524ef @ /usr/share/emacs/24.3/lisp/org/)]
At Tue, 03 Dec 2013 21:17:06 +0530, Jambunathan K wrote: Let me upgrade my LibreOffice and report back. Jambunathan, was wondering if you had a chance to look at this error ? I can confirm it is an issue on my Ubuntu 13.10 system with : - emacs 24.3.1 - org-mode 8.2.4 (org-plus-contrib elpa package 20131216) - libreoffice 4.1.3.2 I use the odt export to create student handouts and *really* don't want to go back through 200+ documents to add captions to all of the images ! Thanks -Tim
Re: [O] Bug: Bad ODT files when including multiple images [7.9.3f (release_7.9.3f-17-g7524ef at /usr/share/emacs/24.3/lisp/org/)]
Let me upgrade my LibreOffice and report back. Jambunathan, was wondering if you had a chance to look at this error ? I can confirm it is an issue on my Ubuntu 13.10 system with : - emacs 24.3.1 - org-mode 8.2.4 (org-plus-contrib elpa package 20131216) - libreoffice 4.1.3.2 I use the odt export to create student handouts and *really* don't want to go back through 200+ documents to add captions to all of the images ! Thanks -Tim
[O] #+TEXT: disappeared
Hi there, I just found that #+TEXT: from pre 8 org-mode has disappeared. Does anybody know how this is done with org-mode 8? -- Thanks, Manfred
Re: [O] #+TEXT: disappeared
Manfred Lotz wrote: I just found that #+TEXT: from pre 8 org-mode has disappeared. Does anybody know how this is done with org-mode 8? IIUC, it became `#+ascii:'. Best regards, Seb -- Sebastien Vauban
[O] one step ahead
Hi, after my first prob (with TODO), now, I've my second one :-( the Agenda. Following the guide: http://orgmode.org/worg/org-tutorials/org4beginners.html#sec-5 I've: - opened the 1.org - press the Cca (So, again, visit 1.org. Next press *C-c a*, which calls the agenda. It looks like this:) But, nothing appens... I mean, I don' t see that: Press key for an agenda command --- a Agenda for the current week or day t List of all TODO entries Can someone help me? TIA Renato
Re: [O] one step ahead
Renato Pontefice renato.pontef...@gmail.com writes: Hi, after my first prob (with TODO), now, I've my second one :-( the Agenda. Following the guide: http://orgmode.org/worg/org-tutorials/org4beginners.html#sec-5 I've: - opened the 1.org - press the Cca (So, again, visit 1.org. Next press C-c a, which calls the agenda. It looks like this:) But, nothing appens... I mean, I don' t see that: Press key for an agenda command --- a Agenda for the current week or day t List of all TODO entries Can someone help me? The tutorial makes certain assumptions that you probably have not satisfied. In particular, it assumes that you have done the setup described in section 1.3, Activation, of the Org manual, available through Info or on the web at: http://orgmode.org/manual/Activation.html# The keybindings described there should be placed in your .emacs initialization file. Nick
Re: [O] [parser] subscripts and underlines interacting badly
Hello, Aaron Ecay aarone...@gmail.com writes: Since the present syntax is inadequate for representating these sequences, the new syntax will have to break backwards compatibility somehow in order to fix the problem. So there’s no long-term harm in having a short-term kludge that will eventually disappear. OK. Thanks for the patch. Though, I think you are patching the wrong location. Modifying `org-element--get-next-object-candidates' is expensive. It would be better to patch `org-element-sub/superscript-successor' and make it ignore underline matches with brackets followed by an underscore character and resume searching. But eventually it will (assuming the cache implementation proves robust enough), right? So, changes in org-element.el will eventually percolate to the rest of org, whereas changes elsewhere will wither and dry up. But it will be a slow process, and, meanwhile both org-element and the rest of Org must be handled. I don’t think escaped characters help with the problem that it is presently impossible to represent the following (pseudo)-element sequence in org syntax: [...] You are right, escaped characters cannot help us here. Anyway, what do escaped characters do that entities cannot? Not much. But they could be used in verbatim context. Also, they are somehow inconvenient to use, as you noticed. This can be troublesome in an environment also meant for note-taking. Regards, -- Nicolas Goaziou
Re: [O] [export] org-export-with-* bugs
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Aaron Ecay aarone...@gmail.com writes: 1) In exporting the following org buffer to latex, I get the following stack trace (at end of email because of length): = #+options: |:nil | foo | bar | = The more I look at it, the more I'm inclined to think that it's totally useless. I don't think anyone wants tables removed from Org syntax. Though, occasionally some line starting with | can be interpreted as a table. In this case, it's possible to use \vert entity anyway. I'm not sure it is worth fixing. I think we really should remove it, or change its meaning, like |:nil means that all tables are ignored in export process (which is probably almost as useless). The same goes for ::nil. I personally agree with this. I can think of no cases where it's useful /and/ =·= isn't a solution /for my use-cases/. –Rasmus -- Got mashed potatoes. Ain't got no T-Bone. No T-Bone
Re: [O] PNG R plots size
Vicente Vera vichovp at gmail.com writes: How can I control the size of a PNG graphic? Do I need to tweak something inside Org or specify something in R? I use a line like this: #+HEADER: :res 300 :units cm :width 15 :height 15 to create a 15cm square PNG at 300 dpi.
[O] PNG R plots size
Hello. I have a source code block for an R plot with the following header: #+BEGIN_SRC R :results output graphics :file figure1.png :exports results It works, but the default size is too small. When I change the extension to SVG or PDF (i.e. when exporting to LaTeX, but is not what i need right now) the dimensions are fine. How can I control the size of a PNG graphic? Do I need to tweak something inside Org or specify something in R? Thanks.
Re: [O] Bug: Bad ODT files when including multiple images [7.9.3f (release_7.9.3f-17-g7524ef @ /usr/share/emacs/24.3/lisp/org/)]
At Wed, 18 Dec 2013 00:16:25 +0530, Jambunathan K wrote: Tim wiskey5al...@gmail.com writes: Jambunathan, was wondering if you had a chance to look at this error ? I can confirm it is an issue on my Ubuntu 13.10 system with : - emacs 24.3.1 - org-mode 8.2.4 (org-plus-contrib elpa package 20131216) - libreoffice 4.1.3.2 I can see the problem on my side. I use the odt export to create student handouts and *really* don't want to go back through 200+ documents to add captions to all of the images ! This issue is a bit unfortunate. Please don't modify your Org files. I will circulate a fix - if not a fix, atleast a workaround - in another day. Thank you ! -Tim
Re: [O] Bug: Bad ODT files when including multiple images [7.9.3f (release_7.9.3f-17-g7524ef @ /usr/share/emacs/24.3/lisp/org/)]
Tim wiskey5al...@gmail.com writes: Jambunathan, was wondering if you had a chance to look at this error ? I can confirm it is an issue on my Ubuntu 13.10 system with : - emacs 24.3.1 - org-mode 8.2.4 (org-plus-contrib elpa package 20131216) - libreoffice 4.1.3.2 I can see the problem on my side. I use the odt export to create student handouts and *really* don't want to go back through 200+ documents to add captions to all of the images ! This issue is a bit unfortunate. Please don't modify your Org files. I will circulate a fix - if not a fix, atleast a workaround - in another day. Jambunathan K.
Re: [O] preview beamer frame in org/beamer
Hi Mirko,
2013ko abenudak 14an, Mirko Vukovic-ek idatzi zuen:
Is there a command to generate a pdf output of a single beamer frame?
The command would generate the latex file with the correct header, and a
single frame, and process it into a pdf file.
You could do this partially with the \includeonlyframes command
(Sec. 4.3.3 of the Beamer manual). This will cut down on the Latex
compilation time needed, but not the time used by org to export the
document to Latex, so if the bottleneck is expensive babel computations
(for example) this won’t help – but other things (e.g. babel’s cache)
might.
Such a command isn’t currently implemented; what would be needed would
be to:
1) find out the label of the \frame corresponding to the current
headline
2) perform the usual export
3) insert \includeonlyframes{the-label-from-step-1} into the generated
latex (just above the \begin{document} line should be fine)
4) compile as usual
--
Aaron Ecay
Re: [O] [RFC] [patch] open/delete attachment with inherited directory
Hi Nicolas, 2013ko abenudak 17an, Nicolas Goaziou-ek idatzi zuen: Thanks for the patch. I see one major problem, though. Org attach doesn't require to list files attached to the entry (see `org-attach-file-list-property'). Therefore, `org-entry-get-multivalued-property' could return nil even though there are attached files. Hmm, good catch. Perhaps then we should read the property if it exists, but fall back to querying the filesystem in case it does not. WDYT? Thanks, -- Aaron Ecay
Re: [O] [export] org-export-with-* bugs
2013ko abenudak 17an, Nicolas Goaziou-ek idatzi zuen: The more I look at it, the more I'm inclined to think that it's totally useless. I don't think anyone wants tables removed from Org syntax. Though, occasionally some line starting with | can be interpreted as a table. In this case, it's possible to use \vert entity anyway. I'm not sure it is worth fixing. I think we really should remove it, or change its meaning, like |:nil means that all tables are ignored in export process (which is probably almost as useless). The same goes for ::nil. I think either suggestion (total removal or changing semantics) is a reasonable option. I attach a patch that should solve this (but doesn't handle tables or fixed-width areas). (fixed-width is one of the branches in the ‘case’ form in the new code...?) I can confirm the fix. It looks like the new mechanism is equivalent to a parse tree filter. (Also, reading the patch I feel like I finally understand what a parse tree filter can/should look like.) Should org-export--remove-uninterpreted be added to the default value of org-export-filter-parse-tree-functions, rather than hard-coding it into org-export-as? Thanks for the quick patch, -- Aaron Ecay
Re: [O] org-mode habits graph dissapears
Hi Javier, Thank you for your response. Here it is what I do: Thanks for the more detailed information. This is helpful. Please continue to cc the org-mode list your responses. I open one of my agenda files, write the new habit, schedule it with C-s, then add a repeat interval, and then I do C-c C-x p, write =STYLE=, and then habit. The result, is like this: * new habit SCHEDULED: 2013-12-17 Tue .+2d/4d :PROPERTIES: :STYLE:habit :END: I notice that I don't have the line: :LAST_REPEAT: then, I check my agenda, with C-a a, and I see the habit, with a color bar on the right, and the symbol !. = personal: new habit ! = Then I mark the new habit as DONE, C-c C-t DONE, now I update the agenda view with r. The new habit is gone, and It won't appear, again, If I check the agenda file, it says: * DONE new habit CLOSED: [2013-12-17 Tue 07:55] SCHEDULED: 2013-12-17 Tue .+2d/4d - State DONE from STARTED[2013-12-17 Tue 07:55] :PROPERTIES: :STYLE: habit :END: And It won't appear again, I noticed that it doesn't say: :LAST_REPEAT: Am I missing something? If I follow your example, I observe the same behavior. Though I dispute that the habit won't appear again: I think it will, just in 2 days, when it is time for you to do that habit again. So as I understand it, you are observing the expected behavior. If this is not what you want, you may want to look at the ways to customize org-habit, in particular , | (defcustom org-habit-show-all-today nil | If non-nil, will show the consistency graph of all habits on | today's agenda, even if they are not scheduled. | :group 'org-habit | :type 'boolean) ` If I (setq org-habit-show-all-today t) then all habits are shown, even ones which I don't need to do today. At least to me, this sounds like the behavior you are seeking. Hope that helps, Josiah
Re: [O] [parser] subscripts and underlines interacting badly
2013ko abenudak 17an, Nicolas Goaziou-ek idatzi zuen:
Hello,
Aaron Ecay aarone...@gmail.com writes:
Since the present syntax is inadequate for representating these
sequences, the new syntax will have to break backwards compatibility
somehow in order to fix the problem. So there’s no long-term harm in
having a short-term kludge that will eventually disappear.
OK. Thanks for the patch.
Though, I think you are patching the wrong location. Modifying
`org-element--get-next-object-candidates' is expensive. It would be
better to patch `org-element-sub/superscript-successor' and make it
ignore underline matches with brackets followed by an underscore
character and resume searching.
We (perhaps) have to worry about cases like: '_foo bar_ . Here it’s not
enough to look at the character immediately following the (possible)
subscript, but rather to take into account the full logic of
org-emph-re.
But now that I think about it, this is the only correct way, since what
org-element--get-next-object-candidates sees is limited by the
restriction.
The attached patch implements this. It also updates the fontification
to match (by calling out to the parser, so there are potential
performance issues although with the cache it will hopefully not be an
issue in practice), and notes the new heuristic in the manual. The test
suite passes.
From e2044312b95f8b427ddc662cd1abf10bf4d87b2d Mon Sep 17 00:00:00 2001
From: Aaron Ecay aarone...@gmail.com
Date: Sun, 15 Dec 2013 21:30:27 -0500
Subject: [PATCH] org-element: use brackets to disambiguate subscript/underline
* lisp/org-element.el (org-element-sub/superscript-successor): use
brackets to disambiguate subscript/underline
* lisp/org.el (org-do-emphasis-faces): incorporate the above
disambiguation
* doc/org.texi: reflect these changes in the manual
In an org-syntax string like 1 or 2 below, both subscript and
underline are possible interpretations. This patch uses the presence
of brackets to disambiguate these cases, that is, 1 is interpreted as
an underlined foo whereas 2 is subscript foo followed by
plain-text _
1: '_foo_
2: '_{foo}_
This the in-buffer highlighting is updated to match.
---
doc/org.texi| 14 ++
lisp/org-element.el | 22 +++---
lisp/org.el | 36 ++--
3 files changed, 55 insertions(+), 17 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index b4c4078..3eefe9a 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -9739,6 +9739,17 @@ can tweak @code{org-emphasis-regexp-components}. Beware that changing one of
the above variables will no take effect until you reload Org, for which you
may need to restart Emacs.
+When it follows an alphanumeric character, the underscore is always
+interpreted as a subscript (@pxref{Subscripts and superscripts}), and when it
+follows whitespace it is always the start of an underline (assuming a
+matching underscore is found in a proper position further along). However,
+after a punctuation character (for example the apostrophe), the underscore
+character can be ambiguous between these two interpretations. Org uses a
+simple heuristic for these cases: if the character following the underscore
+is an opening brace @samp{@{} or if no matching underscore is seen in the
+following text, the underscore is considered to be the start of a subscript.
+Otherwise, it is the start of underlining.
+
@node Horizontal rules
@subheading Horizontal rules
@cindex horizontal rules, markup rules
@@ -10123,6 +10134,9 @@ In addition to showing entities as UTF-8 characters, this command will also
format sub- and superscripts in a WYSIWYM way.
@end table
+For discussion of the resolution of ambiguities between the underscore as the
+introducer of a subscript vs.@ underline, see @ref{Emphasis and monospace}.
+
@node @LaTeX{} fragments
@subsection @LaTeX{} fragments
@cindex @LaTeX{} fragments
diff --git a/lisp/org-element.el b/lisp/org-element.el
index 089ecfb..faa1e44 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -3408,9 +3408,25 @@ Return value is a cons cell whose CAR is either `subscript' or
`superscript' and CDR is beginning position.
(save-excursion
(unless (bolp) (backward-char))
-(when (re-search-forward org-match-substring-regexp nil t)
- (cons (if (string= (match-string 2) _) 'subscript 'superscript)
- (match-beginning 2)
+(let (res)
+ (while (and (not res)
+ (re-search-forward org-match-substring-regexp nil t))
+ (goto-char (match-beginning 0))
+ (when (or
+ ;; this subscript uses brackets - handle as subscript
+ ;; unconditionally
+ (eq (aref (match-string 3) 0) ?{)
+ ;; it is not ambiguous with an underline - handle as
+ ;; subscript
+ (not (looking-at-p org-emph-re)))
+ (setq res (cons (if (string= (match-string 2) _)
+ 'subscript
+ 'superscript)
+ (match-beginning 2
+ ;; otherwise - keep going, and let
