[O] Re: [Bug] [Version 7.5] org-capture : the clock doesn't resume on the original clocking task
Bernt == Bernt Hansen be...@norang.ca writes: Bernt Hi Frederic, Bernt So does this mean it's fixed in origin/master but broken in Bernt release_7.5? Is your original task in the same file as the Bernt target of your capture? Yes, it is. Bernt There were a few fixes to the codebase for clocking after the Bernt 7.5 release. Ok. That works with the git version, that is the main thing. Here is the diff between the 7.5 version and git version. --- org-7.5/lisp/org-capture.el 2011-03-07 15:29:01.0 +0100 +++ org-7.5-git/lisp/org-capture.el 2011-03-30 16:46:41.0 +0200 @@ -54,7 +54,7 @@ (require 'org-mks) (declare-function org-datetree-find-date-create org-datetree - (DATE optional KEEP-RESTRICTION)) + (date optional keep-restriction)) (declare-function org-table-get-specials org-table ()) (declare-function org-table-goto-line org-table (N)) (defvar org-remember-default-headline) @@ -460,7 +460,7 @@ (org-capture-get :key) (nth 1 error (if (org-capture-get :immediate-finish) - (org-capture-finalize nil (not (org-capture-get :clock-keep))) + (org-capture-finalize nil (org-capture-get :clock-keep)) (if (and (org-mode-p) (org-capture-get :clock-in)) (condition-case nil @@ -491,12 +491,12 @@ (t (setq txt * Invalid capture template))) (org-capture-put :template txt))) -(defun org-capture-finalize (optional stay-with-capture clock-out) +(defun org-capture-finalize (optional stay-with-capture clock-keep) Finalize the capture process. With prefix argument STAY-WITH-CAPTURE, jump to the location of the captured item after finalizing. A second optional argument tells whether finalizing the capture -process should clock-out the captured entry. +process should keep the clock running in the filed entry. (interactive P) (unless (and org-capture-mode (buffer-base-buffer (current-buffer))) @@ -509,8 +509,8 @@ ( org-clock-marker (point-min)) ( org-clock-marker (point-max))) ;; Looks like the clock we started is still running. Clock out. -(when clock-out (let (org-log-note-clock-out) (org-clock-out))) -(when (and clock-out +(when (not clock-keep) (let (org-log-note-clock-out) (org-clock-out))) +(when (and (not clock-keep) (org-capture-get :clock-resume 'local) (markerp (org-capture-get :interrupted-clock 'local)) (buffer-live-p (marker-buffer Librement, Fred.
[O] Re: unnumbered subsections in latex export
Eric S Fraga e.fr...@ucl.ac.uk writes:
Jambunathan K kjambunat...@gmail.com writes:
[...]
I think one of the reasons Org is so popular it is that it is a
common-man's swiss army knife and not a elitist samurai sword.
And I think this is a very important analogy. Org does a good job for
many (very different) tasks. The price is that it does not necessarily
do some of those tasks as well as could be.
I am happy to put with the rough edges exposed by the exporters because
of what the whole package provides. Case in point: I submitted a paper
yesterday which I wrote in org. However, for the submission, once I was
happy with all the content, I had to tweak the latex to meet the
journal's format because they provide a style file which requires title,
author, etc. to come *after* the \begin{document}.
I agree that the org-exporter currently does its job very well. The
astounding utility of org-mode is ample proof of the value of releasing
early; even if the exporter is not as elegant as a modern compiler, it
works. :)
That said, I very much support Nicolas' proposal. Right now, the issue
is not so much the end user's experience as it is the ease of
maintaining and developing the backends. We obviously don't want org to
be as strict as xml --- i.e., the a new export parser should be somewhat
forgiving. But a more abstract approach would make it easier to build
new backends or fix bugs that effect all of the backends. One might even
develop an org backend -- i.e., export functions that take the data
produced by the parser and spit out an Org-mode syntax. One might then
write importers that parse other types of files (mediawiki, markdown,
latex, etc.) and return the data structure expected by org-exp.el. Of
course, this latter possibility may not be necessary, given that pandoc
can already convert to org files. :)
Best,
Matt
[O] Re: unnumbered subsections in latex export
Matt Lundin m...@imapmail.org writes:
Eric S Fraga e.fr...@ucl.ac.uk writes:
Jambunathan K kjambunat...@gmail.com writes:
[...]
I think one of the reasons Org is so popular it is that it is a
common-man's swiss army knife and not a elitist samurai sword.
And I think this is a very important analogy. Org does a good job for
many (very different) tasks. The price is that it does not necessarily
do some of those tasks as well as could be.
I am happy to put with the rough edges exposed by the exporters because
of what the whole package provides. Case in point: I submitted a paper
yesterday which I wrote in org. However, for the submission, once I was
happy with all the content, I had to tweak the latex to meet the
journal's format because they provide a style file which requires title,
author, etc. to come *after* the \begin{document}.
I agree that the org-exporter currently does its job very well. The
astounding utility of org-mode is ample proof of the value of releasing
early; even if the exporter is not as elegant as a modern compiler, it
works. :)
That said, I very much support Nicolas' proposal.
A quick (prototype) exporter demoing Nicolas's proposal could be
developed by using my new org-html.el in under few hours.
Think of it this way: If something could be XML-ified it could be
lispified. My exporter already has a common core that emits html and odt
and it is a matter of altering few callbacks so that it generates a
lispy list instead of XML.
Best,
Matt
[O] what happened to the #+OPTIONS: \n:t ?
what happen to the #+OPTIONS: \n:t ? we need it back please!!! why it does not work By the way nobody responded to my message!!! http://www.mail-archive.com/emacs-orgmode@gnu.org/msg40104.html why? is it a stupid question or it can't be implemented? Regards katepano
[O] Re: unnumbered subsections in latex export
Hi Nick and al., Nick Dokos wrote: This will at least help with the first difficulty -- and motivate all people working on the exporters to address the second one. The third one can be turned into a *chance*: that of having several people working in the same direction. Excellent plan! If nobody beats me to it, I'll send out an initial draft of such a table to the list for comment over the weekend: not a complete thing, mind you - just something partially covering one or two exporters. We can modify it as necessary and then proceed to populate it over the next few weeks. When discussing exporters and features, two things that come up to my mind as missing as a general Org feature: - bibliography :: works for LaTeX[1], not for HTML export. - acronyms :: idem. Maybe those should be made available for general Org usage by making them somehow part of the preprocessing? Best regards, Seb Footnotes: [1] ... but uglyfies a bit (too much) the *visible* text. Ideally, such features should be hidden behind things like links or so. -- Sébastien Vauban
Re: [O] Re: org-add-note not working with winner-mode
* http://www.emacswiki.org/emacs/WinnerMode gives: The problem with (windmove-default-keybindings) is that they clash with the more common use on modern systems of S-right etc for selecting text. In Emacs this is turned on by CuaMode for example. Therefore it might be better to go with the alternative (windmove-default-keybindings 'meta) --ie suggest trying: (windmove-default-keybindings 'meta) rather than (windmove-default-keybindings) (I don't believe this will help; maybe though)
Re: [O] Re: org-add-note not working with winner-mode
Hi Brian, On Mon, 4 Apr 2011 11:57:30 -0400 brian powell briangpowel...@gmail.com wrote: * http://www.emacswiki.org/emacs/WinnerMode gives: I am a little confused, aren't windmove and winner mode different packages? I use both, but I narrowed down the problem to just winner-mode. The problem with (windmove-default-keybindings) is that they clash with the more common use on modern systems of S-right etc for selecting text. In Emacs this is turned on by CuaMode for example. Therefore it might be better to go with the alternative (windmove-default-keybindings 'meta) --ie suggest trying: (windmove-default-keybindings 'meta) rather than (windmove-default-keybindings) (I don't believe this will help; maybe though) I actually use windmove with meta, so no that doesn't help. I will follow Nick's advice of using edebug on org-add-note when I can find the time. -- Suvayu Open source is the future. It sets us free.
[O] [Bug][BABEL][R] Headers of the tables are not recognized during the export.
Hello everyone!
Have a file like this:
#+OPTIONS:H:3 num:nil toc:2 \n:nil @:t ::t |:t ^:{} -:t f:t *:t TeX:t
LaTeX:t skip:t d:(HIDE) tags:not-in-toc
#+BABEL: :exports both :session *R* :cache no
#+TBLNAME: Chuah07
| condition | Mean.offer |
|---+|
| 1.MMM | 48.49 |
| 2.MMU | 42.59 |
| 3.MUM | 44.87 |
| 4.UMU | 46.43 |
| 5.UUM | 44.15 |
| 6.UUU | 43.80 |
| MAL | 46.28 |
| UK| 44.1 |
| All | 45.29 |
#+begin_src R :var data=Chuah07 :results output
str(data)
#+end_src
If I run html export C-c C-e b, the output like this:
'data.frame': 9 obs. of 2 variables:
$ V1: chr 1.MMM 2.MMU 3.MUM 4.UMU ...
$ V2: num 48.5 42.6 44.9 46.4 44.1 ...
which means the header is not recognized.
In contrast if I run C-c C-c on the block everything is fine:
#+results
: 'data.frame': 9 obs. of 2 variables:
: $ condition : chr 1.MMM 2.MMU 3.MUM 4.UMU ...
: $ Mean.offer: num 48.5 42.6 44.9 46.4 44.1 ...
Also if I use :cache yes header. The html export recomputes the block.
Wouldn't it be reasonable to have the exporter take into account the :cache
header?
Thanks,
Vitalie.
[O] Re: unnumbered subsections in latex export
Hi Jambunathan, Jambunathan K kjambunat...@gmail.com writes: Matt Lundin m...@imapmail.org writes: I agree that the org-exporter currently does its job very well. The astounding utility of org-mode is ample proof of the value of releasing early; even if the exporter is not as elegant as a modern compiler, it works. :) That said, I very much support Nicolas' proposal. A quick (prototype) exporter demoing Nicolas's proposal could be developed by using my new org-html.el in under few hours. Think of it this way: If something could be XML-ified it could be lispified. My exporter already has a common core that emits html and odt and it is a matter of altering few callbacks so that it generates a lispy list instead of XML. Thanks for all the hard work on your exporter and the rewrite! I look forward to looking at it more closely very soon. In the meantime, does anyone have advice on how to start creating a formal syntax definition for org-mode? Any good links or resources we might check out? I'm guessing that writing a formal definition is more complex than simply defining org-mode syntax in prose---that we are after something a little more formal and symbolic than a headline is demarcated by one or more asterisks beginning at column 0 of a new line Is that correct? Best, Matt
Re: [O] Re: org-add-note not working with winner-mode
IIRC org-add-note works in a way that is unexpected. I think it makes its actions happen after the command itself. I got bitten by that for something else; maybe it is related here. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com/2010/12/welcome-to-kafka-pandemic-two-forces_9182.html I support the Whittemore-Peterson Institute (WPI) === I want to see the original (pre-hold) Lo et al. 2010 NIH/FDA/Harvard MRV paper.
Re: [O] Re: unnumbered subsections in latex export
Sébastien Vauban wxhgmqzgw...@spammotel.com wrote: Hi Nick and al., Nick Dokos wrote: This will at least help with the first difficulty -- and motivate all people working on the exporters to address the second one. The third one can be turned into a *chance*: that of having several people working in the same direction. Excellent plan! If nobody beats me to it, I'll send out an initial draft of such a table to the list for comment over the weekend: not a complete thing, mind you - just something partially covering one or two exporters. We can modify it as necessary and then proceed to populate it over the next few weeks. BTW, I got buried last week and at least through this one, so not much progress. It might go faster if somebody does beat me to it. Thanks, Nick When discussing exporters and features, two things that come up to my mind as missing as a general Org feature: - bibliography :: works for LaTeX[1], not for HTML export. - acronyms :: idem. Maybe those should be made available for general Org usage by making them somehow part of the preprocessing? Best regards, Seb Footnotes: [1] ... but uglyfies a bit (too much) the *visible* text. Ideally, such features should be hidden behind things like links or so. -- Sébastien Vauban
Re: [O] Re: unnumbered subsections in latex export
Matt Lundin m...@imapmail.org wrote: Hi Jambunathan, Jambunathan K kjambunat...@gmail.com writes: Matt Lundin m...@imapmail.org writes: I agree that the org-exporter currently does its job very well. The astounding utility of org-mode is ample proof of the value of releasing early; even if the exporter is not as elegant as a modern compiler, it works. :) That said, I very much support Nicolas' proposal. A quick (prototype) exporter demoing Nicolas's proposal could be developed by using my new org-html.el in under few hours. Think of it this way: If something could be XML-ified it could be lispified. My exporter already has a common core that emits html and odt and it is a matter of altering few callbacks so that it generates a lispy list instead of XML. Thanks for all the hard work on your exporter and the rewrite! I look forward to looking at it more closely very soon. In the meantime, does anyone have advice on how to start creating a formal syntax definition for org-mode? Any good links or resources we might check out? EBNF is pretty much the standard metasyntax for context-free grammars (check Wikipedia). However, I doubt org is context-free, so EBNF might need extensions to deal with it. Or it can do the context-free part and any context-dependent stuff is superimposed on that. Nick I'm guessing that writing a formal definition is more complex than simply defining org-mode syntax in prose---that we are after something a little more formal and symbolic than a headline is demarcated by one or more asterisks beginning at column 0 of a new line Is that correct? Best, Matt
Re: [O] [Bug][BABEL][R] Headers of the tables are not recognized during the export.
Vitalie Spinu spinuvit.l...@gmail.com writes:
Hello everyone!
Have a file like this:
#+OPTIONS:H:3 num:nil toc:2 \n:nil @:t ::t |:t ^:{} -:t f:t *:t TeX:t
LaTeX:t skip:t d:(HIDE) tags:not-in-toc
#+BABEL: :exports both :session *R* :cache no
#+TBLNAME: Chuah07
| condition | Mean.offer |
|---+|
| 1.MMM | 48.49 |
| 2.MMU | 42.59 |
| 3.MUM | 44.87 |
| 4.UMU | 46.43 |
| 5.UUM | 44.15 |
| 6.UUU | 43.80 |
| MAL | 46.28 |
| UK| 44.1 |
| All | 45.29 |
#+begin_src R :var data=Chuah07 :results output
str(data)
#+end_src
If I run html export C-c C-e b, the output like this:
'data.frame': 9 obs. of 2 variables:
$ V1: chr 1.MMM 2.MMU 3.MUM 4.UMU ...
$ V2: num 48.5 42.6 44.9 46.4 44.1 ...
which means the header is not recognized.
In contrast if I run C-c C-c on the block everything is fine:
#+results
: 'data.frame': 9 obs. of 2 variables:
: $ condition : chr 1.MMM 2.MMU 3.MUM 4.UMU ...
: $ Mean.offer: num 48.5 42.6 44.9 46.4 44.1 ...
Thanks for catching this, I've just pushed up a fix for this issue. The
column headers were being lost during the export processing.
Also if I use :cache yes header. The html export recomputes the block.
Wouldn't it be reasonable to have the exporter take into account the :cache
header?
The exporter *does* take into account the :cache header, however, due to
the error above, the values of the inputs to the block of R code were
different on export than on interactive evaluation, so the cache was
invalidated as if the contents of the table had changed.
Cheers -- Eric
Thanks,
Vitalie.
Re: [O] what happened to the #+OPTIONS: \n:t ?
katepano katep...@gmail.com wrote: what happen to the #+OPTIONS: \n:t ? we need it back please!!! Why? what's the use case? why it does not work By the way nobody responded to my message!!! http://www.mail-archive.com/emacs-orgmode@gnu.org/msg40104.html why? is it a stupid question or it can't be implemented? [the question in that message is about exporting to a file with a different file name than the default, in particular consisting partly of a datestamp] Neither - but it is not the way it works currently. Again, if you can present a compelling use case, maybe somebody will implement it (but maybe not). You are always free to implement it yourself. Nick
[O] Re: what happened to the #+OPTIONS: \n:t ?
katepano katep...@gmail.com writes: what happen to the #+OPTIONS: \n:t ? we need it back please!!! why it does not work Something happened to it? This feature was not removed intentionally. I don't use this feature so I can't verify if it works or not without more information. Please provide an example org source file for export and instructions with sample output from a previous release where it did work and what you get now so we can understand the problem. Please also provide the version of org-mode and Emacs that you are using. It is possible there's a bug that needs to be fixed. By the way nobody responded to my message!!! http://www.mail-archive.com/emacs-orgmode@gnu.org/msg40104.html why? is it a stupid question or it can't be implemented? No it's not a stupid question. I don't think the functionality to export documents with a date in the filename currently exists. We all deal with the org-mode mailing list in our spare time. I expect lots of people (including me) saw your original post but nobody had anything constructive to add. Regards, Bernt
Re: [O] Re: what happened to the #+OPTIONS: \n:t ?
Bernt Hansen be...@norang.ca wrote:
katepano katep...@gmail.com writes:
what happen to the #+OPTIONS: \n:t ? we need it back please!!! why it
does not work
Something happened to it? This feature was not removed intentionally.
I don't use this feature so I can't verify if it works or not without
more information.
It's marked DOES NOT WORK in the manual. And git blame found this.
Nick
,
| commit 0776eab890a7352144dd6c56523dbf3ab3f1b71d
| Author: Carsten Dominik carsten.domi...@gmail.com
| Date: Wed Dec 9 22:27:38 2009 +0100
|
| Preserving line breaks for export no longer works
|
| ASCII export always preserves them - no other export format does.
|
| diff --git a/doc/org.texi b/doc/org.texi
| index 1ba4352..8866704 100644
| --- a/doc/org.texi
| +++ b/doc/org.texi
| @@ -8926,7 +8926,7 @@ you can:
| H: @r{set the number of headline levels for export}
| num: @r{turn on/off section-numbers}
| toc: @r{turn on/off table of contents, or set level limit (integer)}
| -\n:@r{turn on/off line-break-preservation}
| +\n:@r{turn on/off line-break-preservation (DOES NOT WORK)}
| @@: @r{turn on/off quoted HTML tags}
| :: @r{turn on/off fixed-width sections}
| |: @r{turn on/off tables}
| diff --git a/lisp/ChangeLog b/lisp/ChangeLog
| index 025079e..0f23b9a 100755
| --- a/lisp/ChangeLog
| +++ b/lisp/ChangeLog
| @@ -1,5 +1,7 @@
| 2009-12-09 Carsten Dominik carsten.domi...@gmail.com
|
| + * org-latex.el (org-export-latex-make-header): Remove \obeylines.
| +
| * org.el (org-make-link-regexps): Use John Gruber's regexp for
| urls.
|
| diff --git a/lisp/org-latex.el b/lisp/org-latex.el
| index ce697a3..62f9a80 100644
| --- a/lisp/org-latex.el
| +++ b/lisp/org-latex.el
| @@ -1027,9 +1027,7 @@ OPT-PLIST is the options plist for current buffer.
| (format
\\setcounter{tocdepth}{%s}\n\\tableofcontents\n\\vspace*{1cm}\n
| (min toc (plist-get opt-plist :headline-levels
|(toc (format
\\setcounter{tocdepth}{%s}\n\\tableofcontents\n\\vspace*{1cm}\n
| - (plist-get opt-plist :headline-levels)
| - (when (plist-get opt-plist :preserve-breaks)
| - \\obeylines\n
| + (plist-get opt-plist :headline-levels
|
| (defun org-export-latex-first-lines (opt-plist optional beg end)
|Export the first lines before first headline.
`
[O] Re: what happened to the #+OPTIONS: \n:t ?
Bernt Hansen be...@norang.ca writes:
katepano katep...@gmail.com writes:
what happen to the #+OPTIONS: \n:t ? we need it back please!!! why it
does not work
Something happened to it? This feature was not removed intentionally.
Actually I stand corrected. Carsten added the DOES NOT WORK text to
the info manual for this feature.
-\n:@r{turn on/off line-break-preservation}
+\n:@r{turn on/off line-break-preservation (DOES NOT WORK)}
so it seems this functionality has been orphaned (over a year ago)
--8---cut here---start-8---
commit 0776eab890a7352144dd6c56523dbf3ab3f1b71d
Author: Carsten Dominik carsten.domi...@gmail.com
Date: Wed Dec 9 22:27:38 2009 +0100
Preserving line breaks for export no longer works
ASCII export always preserves them - no other export format does.
--8---cut here---end---8---
Regards,
Bernt
Re: [O] Re: what happened to the #+OPTIONS: \n:t ?
On 4.4.2011, at 19:57, Nick Dokos wrote:
Bernt Hansen be...@norang.ca wrote:
katepano katep...@gmail.com writes:
what happen to the #+OPTIONS: \n:t ? we need it back please!!! why it
does not work
Something happened to it? This feature was not removed intentionally.
I don't use this feature so I can't verify if it works or not without
more information.
It's marked DOES NOT WORK in the manual. And git blame found this.
Also, some information about the reasoning behind this decision is
in this thread:
http://thread.gmane.org/gmane.emacs.orgmode/20636
- Carsten
Nick
,
| commit 0776eab890a7352144dd6c56523dbf3ab3f1b71d
| Author: Carsten Dominik carsten.domi...@gmail.com
| Date: Wed Dec 9 22:27:38 2009 +0100
|
| Preserving line breaks for export no longer works
|
| ASCII export always preserves them - no other export format does.
|
| diff --git a/doc/org.texi b/doc/org.texi
| index 1ba4352..8866704 100644
| --- a/doc/org.texi
| +++ b/doc/org.texi
| @@ -8926,7 +8926,7 @@ you can:
| H: @r{set the number of headline levels for export}
| num: @r{turn on/off section-numbers}
| toc: @r{turn on/off table of contents, or set level limit (integer)}
| -\n:@r{turn on/off line-break-preservation}
| +\n:@r{turn on/off line-break-preservation (DOES NOT WORK)}
| @@: @r{turn on/off quoted HTML tags}
| :: @r{turn on/off fixed-width sections}
| |: @r{turn on/off tables}
| diff --git a/lisp/ChangeLog b/lisp/ChangeLog
| index 025079e..0f23b9a 100755
| --- a/lisp/ChangeLog
| +++ b/lisp/ChangeLog
| @@ -1,5 +1,7 @@
| 2009-12-09 Carsten Dominik carsten.domi...@gmail.com
|
| + * org-latex.el (org-export-latex-make-header): Remove \obeylines.
| +
| * org.el (org-make-link-regexps): Use John Gruber's regexp for
| urls.
|
| diff --git a/lisp/org-latex.el b/lisp/org-latex.el
| index ce697a3..62f9a80 100644
| --- a/lisp/org-latex.el
| +++ b/lisp/org-latex.el
| @@ -1027,9 +1027,7 @@ OPT-PLIST is the options plist for current buffer.
| (format
\\setcounter{tocdepth}{%s}\n\\tableofcontents\n\\vspace*{1cm}\n
| (min toc (plist-get opt-plist :headline-levels
| (toc (format
\\setcounter{tocdepth}{%s}\n\\tableofcontents\n\\vspace*{1cm}\n
| - (plist-get opt-plist :headline-levels)
| - (when (plist-get opt-plist :preserve-breaks)
| - \\obeylines\n
| + (plist-get opt-plist :headline-levels
|
| (defun org-export-latex-first-lines (opt-plist optional beg end)
|Export the first lines before first headline.
`
Re: [O] create new files from capture
At Fri, 1 Apr 2011 13:43:06 -0400, Buck Brody wrote: Is there a way to use capture to create new files? Can I fill out the name of the file, and add a date stamp, from within the capture template? Prompting in the templates happens after the template is placed in the target buffer. So AFAIK there is no way to achive this without a little bit hacking: You could specify a target function target Specification of where the captured item should be placed. In Org-mode files, targets usually define a node. Entries will become children of this node, other types will be added to the table or list in the body of this node. Most target specifications contain a file name. If that file name is the empty string, it defaults to `org-default-notes-file'. A file can also be given as a variable, function, or Emacs Lisp form. ... (function function-finding-location) Most general way, write your own function to find both file and location That could read the target file name with a prompt. I also considered creating a new headline and then exporting the subtree. The problem is that I need to have the title of the new file automatically created based upon the headline, and I can't figure out how to do this. Same here. The function `org-heading-components' (C-h f org-heading-components RET) will get you the title of the headline which you would have to transform to a valid file name (i.e. `replace-regexp-in-string'). Best, -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de pgpYa2kBMhaPv.pgp Description: PGP signature
Re: [O] Bug: org-export-html-protect-char-alist type def [7.5]
At Thu, 31 Mar 2011 00:06:52 +0200, Michael Heerdegen wrote: Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See http://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org-mode mailing list. Hello, I use the ELPA built of orgmode. M-x customize-variable org-export-html-protect-char-alist RET gives an error. I guess its custom type definition is illegal: :type '((repeat (cons (string :tag Character) (string :tag HTML equivalent Emacs : GNU Emacs 23.2.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2010-12-11 on raven, modified by Debian Package: Org-mode version 7.5 Thanks for reporting. This one was fixed by commit 2ff34a5fac5039ff192964d1c0e5fd33097dbe77 Author: Bastien Guerry b...@altern.org Date: Tue Mar 15 14:13:25 2011 +0100 * org-html.el (org-export-html-protect-char-alist): Fix typo in custom type definition. Best, -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de pgpSCyMHH9VFC.pgp Description: PGP signature
Re: [O] create new files from capture
Could one not have it go into a temporary file and then have an exit hook attatched to a particular template that if a particular property had been filled in that it would create a new file with that name and either refile to or cut to and then paste from the kill ring? Matthew obviously would require some modification/hacking On Mon, Apr 4, 2011 at 2:12 PM, David Maus dm...@ictsoc.de wrote: At Fri, 1 Apr 2011 13:43:06 -0400, Buck Brody wrote: Is there a way to use capture to create new files? Can I fill out the name of the file, and add a date stamp, from within the capture template? Prompting in the templates happens after the template is placed in the target buffer. So AFAIK there is no way to achive this without a little bit hacking: You could specify a target function target Specification of where the captured item should be placed. In Org-mode files, targets usually define a node. Entries will become children of this node, other types will be added to the table or list in the body of this node. Most target specifications contain a file name. If that file name is the empty string, it defaults to `org-default-notes-file'. A file can also be given as a variable, function, or Emacs Lisp form. ... (function function-finding-location) Most general way, write your own function to find both file and location That could read the target file name with a prompt. I also considered creating a new headline and then exporting the subtree. The problem is that I need to have the title of the new file automatically created based upon the headline, and I can't figure out how to do this. Same here. The function `org-heading-components' (C-h f org-heading-components RET) will get you the title of the headline which you would have to transform to a valid file name (i.e. `replace-regexp-in-string'). Best, -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de
[O] [taskjuggler] small edits to org-taskjuggler.el for tj3
Appended is a patch with a couple of small changes to org-taskjuggler.el,
addressing the following issues:
General:
* in org-taskjuggler-open-project, the duration is never calculated (default is
always used).
Specific to tj3:
* the reports need a formats attribute
* tj3 does not support the utilization and freeload columns in reports.
* the sorttasks startup attribute in the default resourcereport does not make
sense anymore.
Not addressed in the patch:
* I wasn't sure about how best to maintain backwards compatibility with the
default report strings, as I override the taskjuggler version in the .org file
(not in my .emacs file).
* for tj3, I found that I needed to put a scheduling property in the top
level task, with value asap.
Org-mode version 7.5 (release_7.5.134.gb869b.dirty)
TaskJuggler III v0.0.11
-- Greg
--
Greg Sullivan gregory.sulli...@baesystems.com
(781)262-4553 (office) (978)430-3461 (cell)
--- ../../../git-org-mode-new/org-mode/lisp/org-taskjuggler.el 2011-04-04
13:12:56.758073400 -0400
+++ ./org-taskjuggler.el2011-04-04 15:32:33.789346200 -0400
@@ -204,13 +204,14 @@
columns hierarchindex, name, start, end, effort, duration, completed, chart
timeformat \%Y-%m-%d\
hideresource 1
+ formats html
loadunit shortauto
}
resourcereport \Resource Graph\ {
headline \Resource Allocation Graph\
- columns no, name, utilization, freeload, chart
+ columns no, name, effortleft, freetime, chart
loadunit shortauto
- sorttasks startup
+ formats html
hidetask ~isleaf()
})
Default reports for the project.
@@ -553,11 +554,16 @@
(headline (cdr (assoc headline project)))
(version (cdr (assoc version project)))
(start (cdr (assoc start project)))
- (end (cdr (assoc end project
+ (end (cdr (assoc end project)))
+ (duration (if (and start end)
+ (- (time-to-days
+ (date-to-time (format %s 00:01:00 end)))
+(time-to-days
+ (date-to-time (format %s 00:01:00 start
+ org-export-taskjuggler-default-project-duration)))
(insert
(format project %s \%s\ \%s\ %s +%sd {\n }\n
-unique-id headline version start
-org-export-taskjuggler-default-project-duration
+unique-id headline version start duration
(defun org-taskjuggler-filter-and-join (items)
Filter all nil elements from ITEMS and join the remaining ones
[O] [PATCH] Remove obsolete functionality to add todo list in front of agenda
* lisp/org-agenda.el: Remove obsolete code for adding todo list in front of the agenda Todo lists should be built with the TODO list or a block agenda instead. This code was triggered for C-u R in block agendas which is used to limit the clock report to the current tags filter applied to the agenda. --- This patch seems to fix the problem for me but I'm not sure if it has any other ill side-effects. I initially just did a (setq include-all nil) but that clobbered the prefix if any for the agenda call. Please review this before applying. This commit is available at git://git.norang.ca/org-mode.git fix-agenda-clock-report-with-prefix Thanks, Bernt lisp/org-agenda.el | 23 --- 1 files changed, 0 insertions(+), 23 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 1f046f2..d7c35d1 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -3457,11 +3457,6 @@ the daily/weekly agenda, see `org-agenda-skip-function'.) The view will be for the current day or week, but from the overview buffer you will be able to go to other days/weeks. -With one \\[universal-argument] prefix argument INCLUDE-ALL, -all unfinished TODO items will also be shown, before the agenda. -This feature is considered obsolete, please use the TODO list or a block -agenda instead. - With a numeric prefix argument in an interactive call, the agenda will span INCLUDE-ALL days. Lisp programs should instead specify SPAN to change the number of days. SPAN defaults to `org-agenda-span'. @@ -3516,24 +3511,6 @@ given in `org-agenda-start-on-weekday'. (org-set-local 'org-starting-day (car day-numbers)) (org-set-local 'org-include-all-loc include-all) (org-set-local 'org-agenda-current-span (org-agenda-ndays-to-span span)) -(when (and (or include-all org-agenda-include-all-todo) - (member today day-numbers)) - (setq files thefiles - rtnall nil) - (while (setq file (pop files)) - (catch 'nextfile - (org-check-agenda-file file) - (setq date (calendar-gregorian-from-absolute today) - rtn (org-agenda-get-day-entries -file date :todo)) - (setq rtnall (append rtnall rtn - (when rtnall - (insert All currently open TODO items:\n) - (add-text-properties (point-min) (1- (point)) -(list 'face 'org-agenda-structure - 'short-heading All TODO items)) - (org-agenda-mark-header-line (point-min)) - (insert (org-finalize-agenda-entries rtnall) \n))) (unless org-agenda-compact-blocks (let* ((d1 (car day-numbers)) (d2 (org-last day-numbers)) -- 1.7.5.rc0.100.gcb35c0
[O] Re: [BUG] Changing TODO states sometimes modifies the schedulingof the next heading
Tom adatgyujto at gmail.com writes: Bottom line: the problem does not occur in the English locale, because there all day abbreviations are 3 chars long, so the above described simple way of restoring the cursor position always works. But this is not true for all locales, so org shouldn't rely on that. I created a temporary fix for the problem with advice until it is fixed in the code properly. Here it is if someone needs it: (defadvice org-todo (around my-org-todo activate) (save-restriction (narrow-to-region (save-excursion (org-back-to-heading t) (point)) (save-excursion (outline-next-heading) (point))) ad-do-it))
Re: [O] Re: unnumbered subsections in latex export
Hullo, 2011/4/4 Sébastien Vauban wxhgmqzgw...@spammotel.com: [snip] When discussing exporters and features, two things that come up to my mind as missing as a general Org feature: - bibliography :: works for LaTeX[1], not for HTML export. - acronyms :: idem. Maybe those should be made available for general Org usage by making them somehow part of the preprocessing? FWIW, acronyms wouldn’t need any preprocessing for HTML export. Or maybe they would: HTML has both ‘acronym’ and ‘abbr’ (abbreviation) elements, the distinction between them being a little hard to make. Could go the other way and provide both in Org and combine them where there’s no distinction, I suppose. Uhm, anyway. Acronyms are natively supported in HTML. That is all. Aankhen
[O] orgmode manual improvement suggestion.
Reading the manual, I found myself needing a single page version which I found after a quick search, I noticed that org mode manual is offered in several formats but not as much as emacs'[1]., which made me wonder if there is a org manual plain text version that can be downloaded somewhere. I also want to report noticed a broken link, the first link in this section [2] to this directory leads to a 404. And that the single page version of the compact Org-mode Guide is missing. Iz. [1] http://www.gnu.org/software/emacs/manual/emacs.html [2] http://orgmode.org/index.html#sec-4_1
Re: [O] orgmode manual improvement suggestion.
[forgot to cc: the list] Izzie ml_orgmode.kap...@antichef.net wrote: Reading the manual, I found myself needing a single page version which I found after a quick search, I noticed that org mode manual is offered in several formats but not as much as emacs'[1]., which made me wonder if there is a org manual plain text version that can be downloaded somewhere. If you download an org distribution (through git or a tar file or what have you), you should be able to find the doc/org.texi file which is used to generate the manual. The following page http://www.gnu.org/software/texinfo/manual/texinfo/html_node/Output-Formats.html#Output-Formats describes briefly how to produce each output format from the texi file. I also want to report noticed a broken link, the first link in this section [2] to this directory leads to a 404. Somebody reported that a few days ago: I guess it has not been fixed yet. And that the single page version of the compact Org-mode Guide is missing. Follow the link called Generating HTML in the above page to find out how to generate HTML output in a single page (the input file is doc/orgguide.texi). But I don't know whether the single page document ever was (or should be) available from the orgmode site, so I'm not sure I'd characterize is as missing: Matt and/or Jason would know better. Nick
Re: [O] what happened to the #+OPTIONS: \n:t ?
Hi Katepano, katepano katep...@gmail.com writes: By the way nobody responded to my message!!! http://www.mail-archive.com/emacs-orgmode@gnu.org/msg40104.html Please be patient -- I have been busier than expected lately and I could not read/reply all emails. If nobody else replied to it, it doesn't mean it's stupid or irrelevant, it just means this is not a question that someone on this list can answer in less than 5 minutes -- but it's surely on someone's TODO list. Thanks, -- Bastien
