Re: [O] Fix broken URL in org-bibtex.el
Hello, Rafael Laboissiere raf...@laboissiere.net writes: The patch attached below fixes a very minor problem in org-bibtex.el. Applied. Thank you. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
Hello, Toby Cubitt ts...@cantab.net writes: Personally, I find the time duration 123:15 much harder to parse mentally than 5d 3:15. The attached patch adds a new customization option `org-time-clocksum-days-format'. When non-nil, this is used instead of `org-time-clocksum-format' for clocksum durations longer than 1 day. It gets passed three values: # days, # hours, # mins. (Note that you don't have to use all three in the format if, say, you don't feel the need to display the minutes for such long durations.) In the patch, I've set the default value for this new customization option to a non-nil value. If you prefer to keep the current behaviour as the default, just make the default value nil. Toby PS: I guess the logical extrapolation of this is to add even more `org-time-clocksum-[months|years|decades]-format' options. (Or, probably better, abandon printf formats for long durations and just add an `org-time-clocksum-format-function' option, leaving it up users to define a function to format the time as they wish.) I haven't done this in the patch, because I think 64d 3:15 is no harder to parse than 2m 4d 3:15 (plus there's the thorny issue of how many days should be in a month). And by the time you get to 535d 3:15 vs. 2y 5d 3:15, the duration is so long that you probably don't care much about the exact value, except that it's a very long-running task indeed! Thanks for your patch. I like the idea, but it would be better to avoid introducing yet another defcustom for this. There is already: - org-time-clocksum-format - org-time-clocksum-use-fractional - org-time-clocksum-fractional-format As you suggest, I think a better plan is to replace all of them with a single `org-time-clocksum-display-function'. Its expected value would be a function accepting 2 arguments: hours and minutes, as numbers and it should return a string. We can also provide default functions for current behaviour (i.e. fractional time and Hs:MM) and for the one you suggest. It's more work, but it simplifies the whole thing in the end. What do you think? Do you want to give it a try? Regards, -- Nicolas Goaziou
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
On Mon, Nov 05, 2012 at 10:14:27AM +0100, Nicolas Goaziou wrote: Toby Cubitt ts...@cantab.net writes: Personally, I find the time duration 123:15 much harder to parse mentally than 5d 3:15. The attached patch adds a new customization option `org-time-clocksum-days-format'. When non-nil, this is used instead of `org-time-clocksum-format' for clocksum durations longer than 1 day. It gets passed three values: # days, # hours, # mins. (Note that you don't have to use all three in the format if, say, you don't feel the need to display the minutes for such long durations.) In the patch, I've set the default value for this new customization option to a non-nil value. If you prefer to keep the current behaviour as the default, just make the default value nil. Toby PS: I guess the logical extrapolation of this is to add even more `org-time-clocksum-[months|years|decades]-format' options. (Or, probably better, abandon printf formats for long durations and just add an `org-time-clocksum-format-function' option, leaving it up users to define a function to format the time as they wish.) I haven't done this in the patch, because I think 64d 3:15 is no harder to parse than 2m 4d 3:15 (plus there's the thorny issue of how many days should be in a month). And by the time you get to 535d 3:15 vs. 2y 5d 3:15, the duration is so long that you probably don't care much about the exact value, except that it's a very long-running task indeed! Thanks for your patch. I like the idea, but it would be better to avoid introducing yet another defcustom for this. There is already: - org-time-clocksum-format - org-time-clocksum-use-fractional - org-time-clocksum-fractional-format As you suggest, I think a better plan is to replace all of them with a single `org-time-clocksum-display-function'. Its expected value would be a function accepting 2 arguments: hours and minutes, as numbers and it should return a string. We can also provide default functions for current behaviour (i.e. fractional time and Hs:MM) and for the one you suggest. It's more work, but it simplifies the whole thing in the end. What do you think? Do you want to give it a try? Sounds like a good plan, and it won't be very difficult to implement. I'm happy to have a go, but I'm somewhat short on spare time just at the moment, so it might take me a few weeks to get around to it. Best, Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
Nicolas Goaziou writes: As you suggest, I think a better plan is to replace all of them with a single `org-time-clocksum-display-function'. Its expected value would be a function accepting 2 arguments: hours and minutes, as numbers and it should return a string. Actually, it seems an even better plan IMHO to just have one single function that takes a format string and the total time in minutes or seconds and allow customization of the format string. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
On Mon, Nov 05, 2012 at 11:47:12AM +0100, Achim Gratz wrote: Nicolas Goaziou writes: As you suggest, I think a better plan is to replace all of them with a single `org-time-clocksum-display-function'. Its expected value would be a function accepting 2 arguments: hours and minutes, as numbers and it should return a string. Actually, it seems an even better plan IMHO to just have one single function that takes a format string and the total time in minutes or seconds and allow customization of the format string. A format string isn't sufficient. It requires the number of time components (days, hours, minutes, etc.) to be fixed in advance. Whereas a function can decide whether to display e.g. days+hours or hours+minutes depending on whether the time is longer or shorter than 24h. A defcustom that can either be a format string *or* a function might be an option. Or maybe I've misunderstood what you're proposing? Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
Toby Cubitt writes: A format string isn't sufficient. It requires the number of time components (days, hours, minutes, etc.) to be fixed in advance. Whereas a function can decide whether to display e.g. days+hours or hours+minutes depending on whether the time is longer or shorter than 24h. You can define the format specification with any semantics you want, including alternatives like those suggested above. A defcustom that can either be a format string *or* a function might be an option. What I'm saying is that this whole business of exposing formatting functions to the user is somewhat superfluous. Whether different formats dispatch their work to different (internal) functions is another matter — if it makes implementation easier, just do it. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
[O] Can not get keybinding to work in org-agenda-mode
Hi, I use org-mime to mail subtrees from org-mode and have bound this to 'C-c m' I would like to be able to do the same thing from my agenda views, but somehow I can't get the keybinding to work. This is what I have: (defun m/ms-org-agenda () (interactive) (org-agenda-goto) (org-mime-subtree)) ;; This works (define-key org-mode-map [(control c) m] 'org-mime-subtree) ;; This does not (define-key org-agenda-mode-map [(control c) m] 'm/ms-org-agenda) When asking help about modes (C-h m) I see the keybinding listed: key binding --- --- ... C-c m m/ms-org-agenda ... I don't get any errors, other than 'C-c m is undefined' What am I missing here? Thx, marcel -- Marcel van der Boom -- http://hsdev.com/mvdb.vcf HS-Development BV-- http://www.hsdev.com We use bitcoin! -- http://bitcoin.org
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
On Mon, Nov 05, 2012 at 12:13:25PM +0100, Achim Gratz wrote: Toby Cubitt writes: A format string isn't sufficient. It requires the number of time components (days, hours, minutes, etc.) to be fixed in advance. Whereas a function can decide whether to display e.g. days+hours or hours+minutes depending on whether the time is longer or shorter than 24h. You can define the format specification with any semantics you want, including alternatives like those suggested above. OK, I get it now. I was interpreting format specification to mean format string, but that's not what you meant. A defcustom that can either be a format string *or* a function might be an option. What I'm saying is that this whole business of exposing formatting functions to the user is somewhat superfluous. But defining a custom format semantics just for this one rather simple case also seems somewhat superfluous. We already have a clean, well-known, well-understood semantics for expressing conditionals: Elisp. I'm not sure we've hit upon the clean solution yet... Looking through the code, it seems the clocksum format options are used in two places: org-colview.el and org-clock.el. For some reason, only the latter honours `org-time-clocksum-use-fractional'. In my patch, only the former honoured the new `org-time-clocksum-days-format'. Some rationalisation of all these options is clearly needed. Most users are probably happy with the defaults. So the question is how best to allow the small minority who want to tweak the clocksum format to do so. A couple of questions: 1. Is there any real need to allow the org-colview and org-clock formats to be customized independently? Making them the same would simplify things and probably be clearer for users. 2. What are the different formats that users are likely to want? The list can't be very long. I can think of: hh:mm, hh.mm (fractional), dd hh:mm (separate days), dd hh.mm, and possibly MM dd hh:mm and YY MM dd hh:mm. If the above covers everything we want, then what about getting rid of every customization option except `org-time-clocksum-format', and parsing the format string itself to decide how many and what arguments to pass to it? More precisely, if the format string contains :, . or , then the smallest time component is minutes; otherwise it's hours. Pass as many time components as necessary to fill all the % expandos in the format string, from largest to smallest, with either hours or minutes as the smallest. If the format string contains . or , then pass the number of minutes as a fraction (, is used as the decimal separator in many European languages). This would simplify things, and make the format string just do the right thing in all the cases I listed above. On the other hand, it won't allow unusual formats that don't fit the above scheme (but they're not possible now, anyway). Thoughts? Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
Hello, Toby Cubitt ts...@cantab.net writes: Looking through the code, it seems the clocksum format options are used in two places: org-colview.el and org-clock.el. For some reason, only the latter honours `org-time-clocksum-use-fractional'. In my patch, only the former honoured the new `org-time-clocksum-days-format'. Some rationalisation of all these options is clearly needed. That's the purpose of the patch: only one function to rule them all. Most users are probably happy with the defaults. So the question is how best to allow the small minority who want to tweak the clocksum format to do so. Allow a free function and provide default ones. A couple of questions: 1. Is there any real need to allow the org-colview and org-clock formats to be customized independently? Making them the same would simplify things and probably be clearer for users. I think they should be formatted the same way. It's important to have a consistent format for such things. 2. What are the different formats that users are likely to want? The list can't be very long. I can think of: hh:mm, hh.mm (fractional), dd hh:mm (separate days), dd hh.mm, and possibly MM dd hh:mm and YY MM dd hh:mm. Just provide what is actually possible to have along with your day count. It will make a good enough default offer. If the above covers everything we want, then what about getting rid of every customization option except `org-time-clocksum-format', and parsing the format string itself to decide how many and what arguments to pass to it? More precisely, if the format string contains :, . or , then the smallest time component is minutes; otherwise it's hours. Pass as many time components as necessary to fill all the % expandos in the format string, from largest to smallest, with either hours or minutes as the smallest. If the format string contains . or , then pass the number of minutes as a fraction (, is used as the decimal separator in many European languages). That would be over-engineering it. This would simplify things, and make the format string just do the right thing in all the cases I listed above. On the other hand, it won't allow unusual formats that don't fit the above scheme (but they're not possible now, anyway). Thoughts? I think it's too much complicated: it requires to know about strange formatting rules. I suggest to keep it simple: just specify a function with fixed arguments to do the job and provide default functions to handle most common cases. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] Capture: Expand keyword within %(SEXP) in template
Hello, Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Ryo TAKAISHI ryo.takaish...@gmail.com writes: I create a complete patch for current commit. I've pushed your patch on master (with some documentation tweaks). Thank you for your work. Thank you very much. But, I had forgot to escape double quote in docstring, so attach patch fixing it. Also, please consider signing FSF papers if you want to make other contributions to Org. OK, I want to consider when I send a patch next time. Regards, Ryo From dacf4ef0677f80cfc589bf5014ca71dfdd2dc3d4 Mon Sep 17 00:00:00 2001 From: Ryo TAKAISHI ryo.takaish...@gmail.com Date: Mon, 5 Nov 2012 21:20:14 +0900 Subject: [PATCH] org-capture: Fix a docstring * lisp/org-capture.el: Fix a docstring. TINYCHANGE --- lisp/org-capture.el |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-capture.el b/lisp/org-capture.el index 695c5eb..ccdb0c1 100644 --- a/lisp/org-capture.el +++ b/lisp/org-capture.el @@ -1631,7 +1631,7 @@ The template may still contain \%?\ for cursor positioning. (defun org-capture--expand-keyword-in-embedded-elisp (attr) Recursively replace capture link keywords in ATTR sexp. -Such keywords are prefixed with %:. See `org-capture-template' +Such keywords are prefixed with '%:'. See `org-capture-template' for more information. (cond ((consp attr) (mapcar 'org-capture--expand-keyword-in-embedded-elisp attr)) -- 1.7.9.5
Re: [O] [ANN] e-icalendar back-end
Hi, I tried it, nothing gets exported at all ... Is there anything I'm missing ? /v -- Vincent Beffara On Saturday, November 3, 2012 at 24:48 , Nicolas Goaziou wrote: Hello, I've just pushed a new (and probably very buggy) iCalendar back-end for org-export.el. To install it: (require 'org-e-icalendar) It should then be available under `org-export-dispatch' menu. There's also a function to write current agenda view to a calendar, but it isn't hooked into `org-agenda-write' yet. For now, you can test it, from an agenda buffer, with: M-: (org-e-icalendar-export-current-agenda) Feedback is welcome. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] Capture: Expand keyword within %(SEXP) in template
Hello, Ryo TAKAISHI ryo.takaish...@gmail.com writes: But, I had forgot to escape double quote in docstring, so attach patch fixing it. Fixed. Thank you. Regards, -- Nicolas Goaziou
Re: [O] Can not get keybinding to work in org-agenda-mode
Hi Marcel, Marcel van der Boom wrote: I use org-mime to mail subtrees from org-mode and have bound this to 'C-c m' I would like to be able to do the same thing from my agenda views, but somehow I can't get the keybinding to work. This is what I have: (defun m/ms-org-agenda () (interactive) (org-agenda-goto) (org-mime-subtree)) ;; This works (define-key org-mode-map [(control c) m] 'org-mime-subtree) ;; This does not (define-key org-agenda-mode-map [(control c) m] 'm/ms-org-agenda) When asking help about modes (C-h m) I see the keybinding listed: key binding --- --- ... C-c m m/ms-org-agenda ... I don't get any errors, other than 'C-c m is undefined' What am I missing here? I don't know, but the following does work for me: #+begin_src emacs-lisp (add-hook 'org-mode-hook (lambda () (local-set-key (kbd C-c m) 'org-mime-subtree))) (defun my/mail-subtree () (interactive) (org-agenda-goto) (org-mime-subtree)) (add-hook 'org-agenda-mode-hook (lambda () (local-set-key (kbd C-c m) 'my/mail-subtree))) #+end_src Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
On Mon, Nov 05, 2012 at 01:20:48PM +0100, Nicolas Goaziou wrote: Toby Cubitt ts...@cantab.net writes: [snip] [...] what about getting rid of every customization option except `org-time-clocksum-format', and parsing the format string itself to decide how many and what arguments to pass to it? More precisely, if the format string contains :, . or , then the smallest time component is minutes; otherwise it's hours. Pass as many time components as necessary to fill all the % expandos in the format string, from largest to smallest, with either hours or minutes as the smallest. If the format string contains . or , then pass the number of minutes as a fraction (, is used as the decimal separator in many European languages). That would be over-engineering it. This would simplify things, and make the format string just do the right thing in all the cases I listed above. On the other hand, it won't allow unusual formats that don't fit the above scheme (but they're not possible now, anyway). Thoughts? I think it's too much complicated: it requires to know about strange formatting rules. I suggest to keep it simple: just specify a function with fixed arguments to do the job and provide default functions to handle most common cases. I'm fine with a function + sensible defaults, but Achim didn't like it and proposed a custom format syntax instead. org-time-clocksum-format is used all over the place in org-clock.el, often concatenated with other bits of format string. So the changes needed to change it into one function to rule them all are more extensive, though fairly trivial. I'd prefer to see some agreement before I waste time coding something that won't get accepted. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [ANN] e-icalendar back-end
Hello, Vincent Beffara vbeff...@gmail.com writes: I tried it, Thank you. nothing gets exported at all ... Is there anything I'm missing ? I don't know. What did you try exactly? On which kind of data? If your file/agenda only contains TODO entries, you may want to try again, as I have push a fix for it. Regards, -- Nicolas Goaziou
[O] [PATCH] Escape slashes in ARCHIVE_OLPATH
Currently information about tree structure is lost if you have a slash in node headings. This patch fixes the problem by escaping slashes in headings before concatenating them. Takafumi archive_olpath.patch Description: Binary data
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
Hello, Toby Cubitt ts...@cantab.net writes: I'd prefer to see some agreement before I waste time coding something that won't get accepted. Then let's wait for Achim (Cc'ed) to illustrate what he has in mind, because his proposal is too vague yet to permit discussion about it. Regards, -- Nicolas Goaziou
Re: [O] Can not get keybinding to work in org-agenda-mode
On ma 05-nov-2012 13:43 Sebastien Vauban wxhgmqzgw...@spammotel.com wrote: I don't get any errors, other than 'C-c m is undefined' What am I missing here? I experimented a bit and (define-key org-agenda-mode-map \C-cm 'm/ms-org-agenda) also seems to work. I don't understand what the difference is, if any. Marcel -- Marcel van der Boom -- http://hsdev.com/mvdb.vcf HS-Development BV-- http://www.hsdev.com We use bitcoin! -- http://bitcoin.org
Re: [O] end-of-line test fails
When compiling the latest git version with make up2, the end-of-line test fails, giving the following output: This should be fixed on master (and even maint). Could you confirm this? Confirmed. Thanks.
[O] [PATCH] org-edit-special too much space if starting with empty block
Some tests: Case 1: Start with emacs -Q I insert #+begin_src javascript #+end_src with point before #+end_src, I press C-c ' to start editing the source I enter foobar into the source buffer and immediately exit with C-c ' Case 2: restart with #+begin_src javascript #+end_src I've included a patch that fixes both issues. -- Le org-src.el.3.diff Description: Binary data
Re: [O] OSX to PDF: Minimal Install
On Fri, Nov 2, 2012 at 2:41 PM, Jambunathan K kjambunat...@gmail.com wrote: Nathan Neff nathan.n...@gmail.com writes: Hello, I'd like to convert org-mode documents to PDF using the exporter, on OSX, but it appears that I'd have to download MacTex which is a 2GB download. Is there anything smaller that I could download in order to be able to export org documents to PDF? Install LibreOffice and follow instructions in this thread: http://lists.gnu.org/archive/html/emacs-orgmode/2012-09/msg00027.html Hello Jambunathan, I like this solution the best, as I already have LibreOffice installed. However, I am having trouble following the instructions in that thread. I cannot even get a simple .org file to export using the C-c C-e o command -- I get the error message Symbol's value as variable is void: err. I have LibreOffice installed (on OSX) in /Applications/LibreOffice. Some additional information from Emacs/org-mode/org-odt is here: OVERVIEW [2 times] Export buffer: Debug (org-odt): Searching for OpenDocument schema files... Debug (org-odt): Trying /usr/share/emacs/etc/org/schema/... Debug (org-odt): Using schema files under /usr/share/emacs/etc/org/schema/ Debug (org-odt): Searching for OpenDocument styles files... Debug (org-odt): Trying /usr/share/emacs/etc/org/styles/... Debug (org-odt): Using styles under /usr/share/emacs/etc/org/styles/ call-interactively: Symbol's value as variable is void: err Export buffer: call-interactively: Symbol's value as variable is void: err I am using org-odt.el version 24.1 and org-mode version 7.8.11 (release_7.8.11-723-g0f3b6 I suspected that soffice was not in Emacs' path, so I added /Applications/LibreOffice/Contents/MacOS to the path, but to no avail. Any help would be appreciated! Thanks, --Nate Thanks, --Nate --
[O] org-beginning-of-line, org-end-of-line, and visual line mode
Hello, I'm using a very recent version of org-mode (compiled earlier today from git), and I see that using visual-line-mode, the org-beginning-of-line goes to the beginning of the visual line (it does not ignore soft line breaks), whereas org-end-of-line goes to the end of the real line (it ignores soft line breaks). The FAQ says that this used to be broken back in 2009, but does not mention this asymmetry. Is this a bug? Thanks, Alan
Re: [O] org-beginning-of-line, org-end-of-line, and visual line mode
Hello, Alan Schmitt alan.schm...@polytechnique.org writes: I'm using a very recent version of org-mode (compiled earlier today from git), and I see that using visual-line-mode, the org-beginning-of-line goes to the beginning of the visual line (it does not ignore soft line breaks), whereas org-end-of-line goes to the end of the real line (it ignores soft line breaks). The FAQ says that this used to be broken back in 2009, but does not mention this asymmetry. Is this a bug? This is a bug, which should be fixed now. Could you confirm it? Thanks for reporting this. Regards, -- Nicolas Goaziou
[O] Source block processing changes
Hi all, I've been silently suffering since the changes to source block processing announced at the end of September[1]. I had been using (abusing?) ':results org' to write results that would be processed as orgmode syntax and exported to both latex and html. For example, this #+name: tst #+begin_src R :results output org :exports results library(ascii) cat(* First ten\n) print(ascii(head(mtcars)), type=org) cat(\n* Last ten\n) print(ascii(tail(mtcars)), type=org) #+end_src used to give me heading First ten followed by a table nicely formatted in html or latex depending on the export target, followed by a heading Last ten, again followed by a nicely formatted table. Changing the data or the code in the block would update the contents. This was very convenient, and I relied heavily on this to generate reports. Now it seems that this very useful feature no longer exists, and try as I might I cannot find a way to duplicate it. Using ':results drawer' or ':results org' gives me verbatim export (i.e., * First ten is not converted to a headline, but displayed in highlighted syntax similar to the way it appears in the buffer. The only way I can get the headlines and tables to be exported properly is to set ':results raw', but then I get duplicate results every time I evaluate the R source block. I understand from the original announcement that #+begin org / #+end org blocks don't really make sense because these kind of blocks correspond to backends, and there is no org backend, but it was very useful. Is there any way to produce the old behavior in the current development version of org? If not, what are the chances of this very useful functionality being re-implemented? Thanks, Ista [1] http://lists.gnu.org/archive/html/emacs-orgmode/2012-09/msg01230.html
Re: [O] Source block processing changes
Hello, Ista Zahn istaz...@gmail.com writes: The only way I can get the headlines and tables to be exported properly is to set ':results raw', but then I get duplicate results every time I evaluate the R source block. You can use :cache yes in order to avoid duplicating results. Is there any way to produce the old behavior in the current development version of org? Besides using :results raw? You may also generate a file containing your results and include it in the buffer. If not, what are the chances of this very useful functionality being re-implemented? I'd like to avoid re-implementing this hack, if possible. But if it had to be done, I think it would require to treat specially begin_org blocks during export by replacing them with their contents just before parsing (i.e. just after included files have been expanded). Hence, #+begin_src org ,* Headline #+end_src would become * Headline just before parser kicks in. But, again, let's see first if no solution can be found without creating yet another special case. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
Nicolas Goaziou writes: Then let's wait for Achim (Cc'ed) to illustrate what he has in mind, because his proposal is too vague yet to permit discussion about it. What I had in mind was to remove org-time-clocksum-format and replace the associated format calls with a formatting function that has customizable behaviour (how customizable is t.b.d.). (format org-time-clocksum-format h m) = (org--format-time n fmt) Even if nothing else changes, that removes a lot of unnecessary code duplication, like the seven or so different ways to split the hours from the minutes that may or may not agree on their results. This is not far from your own suggestion to provide different functions depending on which output is desired, I just happen to think that these functions would all be so similar that they should be rolled into a single function that can produce different outputs. I think there'd only be a handful of possible values for fmt based on the current usage and that suggests just another cond form would be needed in implementing this function rather than a full-blown format string interpreter. The fmt argument might even be optional (use the custom value if nil) or dynamically bound instead of being a function argument. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Waldorf MIDI Implementation additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
On Mon, Nov 05, 2012 at 06:40:20PM +0100, Achim Gratz wrote: Nicolas Goaziou writes: Then let's wait for Achim (Cc'ed) to illustrate what he has in mind, because his proposal is too vague yet to permit discussion about it. What I had in mind was to remove org-time-clocksum-format and replace the associated format calls with a formatting function that has customizable behaviour (how customizable is t.b.d.). (format org-time-clocksum-format h m) = (org--format-time n fmt) Even if nothing else changes, that removes a lot of unnecessary code duplication, like the seven or so different ways to split the hours from the minutes that may or may not agree on their results. I think whatever we end up doing, it's going simply things and remove duplicate code. Which I agree is definitely a good thing. This is not far from your own suggestion to provide different functions depending on which output is desired, I just happen to think that these functions would all be so similar that they should be rolled into a single function that can produce different outputs. I think there'd only be a handful of possible values for fmt based on the current usage and that suggests just another cond form would be needed in implementing this function rather than a full-blown format string interpreter. It seems to me your `org--format-time' function would end up looking very like what I sketched. A cond to switch between hh:mm, hh.mm, dd hh:mm or dd hh.mm based only on the contents of the fmt argument would have to check whether fmt contains 2 or 3 %-sequences, then check if it contains . or : If these 4 options are the only ones that are ever going to be useful, we could instead just have a single defcustom with a 4-way choice (between 4 different descriptive symbols). This would remove some flexibility from the existing version (as well as adding some), but it's simpler than partially parsing the fmt string. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] Source block processing changes
Thank you Nicolas for your quick response! On Mon, Nov 5, 2012 at 12:25 PM, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, Ista Zahn istaz...@gmail.com writes: The only way I can get the headlines and tables to be exported properly is to set ':results raw', but then I get duplicate results every time I evaluate the R source block. You can use :cache yes in order to avoid duplicating results. I gave up on using ':cache yes' a long time ago -- the problem is that results don't update when the input data changes, as I describe here: http://lists.gnu.org/archive/html/emacs-orgmode/2010-09/msg01152.html Is there any way to produce the old behavior in the current development version of org? Besides using :results raw? Yes, so that evaluating the result multiple times does not produce duplicate output, while re-evaluating if the input data changes. You may also generate a file containing your results and include it in the buffer. This does work, but has the drawback that I can't see the output in my main org buffer. This is one of the things that drew me away from Sweave/Knitr, i.e., I could see both the code and the results in the same buffer, without having to compile the document or switch to another buffer. If not, what are the chances of this very useful functionality being re-implemented? I'd like to avoid re-implementing this hack, if possible. But if it had to be done, I think it would require to treat specially begin_org blocks during export by replacing them with their contents just before parsing (i.e. just after included files have been expanded). Hence, #+begin_src org ,* Headline #+end_src would become * Headline just before parser kicks in. But, again, let's see first if no solution can be found without creating yet another special case. Yes, of course. Thanks again for considering my use-case! Best, Ista Regards, -- Nicolas Goaziou
Re: [O] org-beginning-of-line, org-end-of-line, and visual line mode
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Alan Schmitt alan.schm...@polytechnique.org writes: I'm using a very recent version of org-mode (compiled earlier today from git), and I see that using visual-line-mode, the org-beginning-of-line goes to the beginning of the visual line (it does not ignore soft line breaks), whereas org-end-of-line goes to the end of the real line (it ignores soft line breaks). The FAQ says that this used to be broken back in 2009, but does not mention this asymmetry. Is this a bug? This is a bug, which should be fixed now. Could you confirm it? Yes, it's working. Thanks for reporting this. And thanks for fixing it so quickly! Alan
Re: [O] OSX to PDF: Minimal Install
Nathan Neff nathan.n...@gmail.com writes: I am using org-odt.el version 24.1 and org-mode version 7.8.11 (release_7.8.11-723-g0f3b6 --8---cut here---start-8--- $ git log 0f3b6 fatal: ambiguous argument '0f3b6': unknown revision or path not in the working tree. Use '--' to separate paths from revisions ^ --8---cut here---end---8--- That looks suspicious to me. I see no such commit in maint or master branch. The error that you report is not something I remember to have seen in the past. Can you not switch to 7.9.* versions? You can install the latest version via M-x list-packages RET. Follow the ELPA link from Org homepage: http://orgmode.org/, http://orgmode.org/elpa.html. For exporting to pdf, you can specify a value of pdf at M-x customize-variable RET org-export-odt-preferred-output-format RET or while visiting Org file do, M-x add-file-local-variable RET org-export-odt-preferred-output-format RET pdf RET and revisit (C-x C-v) that file. or You can follow the bind suggestion by Nicolas here: http://lists.gnu.org/archive/html/emacs-orgmode/2012-09/msg00039.html (Note that Nicolas' suggestion has a typo) --
[O] error: Execution of bibtex2html
I am having trouble in using org-exp-bibtex.el on debian sid. I was unable to install bibtex2html through the package manager because of dependency problem with ocaml-base-nox-3.12.1. I then installed ocaml separately, and compiled bibtex2html from source. Now, bibtex2html is working fine from the command line. But when I export a file having bibtex citations, orgmode complains saying Execution of bibtex2html failed. It seemed to me that orgmode was unable to find bibtex2html. bibtex2html is installed in /usr/local/bin/bibtex2html. Since it was not being found, I also myself created a symlink to /usr/bin.bibtex2html. But that does not help either. My orgmode version is 7.9.2 Could anyone suggest what to do. Thanks, Vikas
Re: [O] Test fails ons OSX
Now i can build again! On Nov 3, 2012, at 11:12 AM, Neuwirth Erich erich.neuwi...@univie.ac.at wrote: Sorry, this is when running make up2 (not make update2) On Nov 3, 2012, at 10:38 AM, Neuwirth Erich erich.neuwi...@univie.ac.at wrote: OSX 10.8.2 Emacs 24.2.1 SInce a few days now I get errors when I run make update2 Ran 330 tests, 329 results as expected, 1 unexpected (2012-11-03 10:35:01+0100) 4 expected failures 1 unexpected results: FAILED test-org/end-of-line make[1]: *** [test-dirty] Error 1 make: *** [up2] Error 2 And during the tests I see: Test test-org/end-of-line backtrace: signal(ert-test-failed (((should-not (org-test-with-temp-text #+BEG ert-fail(((should-not (org-test-with-temp-text #+BEGIN_CENTER\nCont (if (not (unwind-protect (setq value-4865 (let ((temp-buffer (genera (unless (not (unwind-protect (setq value-4865 (let ((temp-buffer (ge (let (form-description-4866) (unless (not (unwind-protect (setq valu (let ((value-4865 (ert--gensym ert-form-evaluation-aborted-))) (le (should-not (org-test-with-temp-text #+BEGIN_CENTER\nContents\n#+EN (lambda nil (should (org-test-with-temp-text Some text\nSome other byte-code(\306\307!q\210\310\216\311 \312\216\313\314\315\316\3 ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc byte-code(\306\307!\211r\310\311!q\210\312 d\313\223)L\210\314\216 ert-run-test([cl-struct-ert-test test-org/end-of-line Test `org-end ert-run-or-rerun-test([cl-struct-ert--stats \\(org\\|ob\\) [[cl-st ert-run-tests(\\(org\\|ob\\) #[(event-type rest event-args) \30 ert-run-tests-batch(\\(org\\|ob\\)) ert-run-tests-batch-and-exit(\\(org\\|ob\\)) (let ((org-id-track-globally t) (org-id-locations-file (convert-stan org-test-run-batch-tests() call-interactively(org-test-run-batch-tests nil nil) command-execute(org-test-run-batch-tests) command-line-1((--eval (add-to-list 'load-path \./lisp\) --ev command-line() normal-top-level() Test test-org/end-of-line condition: (ert-test-failed ((should-not (org-test-with-temp-text #+BEGIN_CENTER\nContents\n#+END_CENTER (progn ... ... ...))) :form (let ((temp-buffer ...)) (with-current-buffer temp-buffer (unwind-protect ... ...))) :value t)) FAILED 313/330 test-org/end-of-line
[O] error: Execution of bibtex2html
I am having trouble in using org-exp-bibtex.el on debian sid. I was unable to install bibtex2html through the package manager because of dependency problem with ocaml-base-nox-3.12.1. I then installed ocaml separately, and compiled bibtex2html from source. Now, bibtex2html is working fine from the command line. But when I export a file having bibtex citations, orgmode complains saying Execution of bibtex2html failed. It seemed to me that orgmode was unable to find bibtex2html. bibtex2html is installed in /usr/local/bin/bibtex2html. Since it was not being found, I also myself created a symlink to /usr/bin.bibtex2html. But that does not help either. My orgmode version is 7.9.2 Could anyone suggest what to do. Thanks, Vikas
[O] [new exporter] what is the label syntax for LaTeX export?
Hi,
If my org file has:
#+CAPTION[Here is a table]: A nice table
#+NAME: tab:niceone
| a |
Look at my \ref{tab:niceone}.
then M-x org-export-dispatch l L gives me:
\begin{table}[htb]
\caption[Here is a table]{\label{tab-niceone}A nice table}
\begin{center}
\begin{tabular}{l}
a\\
\end{tabular}
\end{center}
\end{table}
Look at my \ref{tab:niceone}.
So, the label tab:niceone exports as \label{tab-niceone}. Is that right
or am I using the wrong syntax somewhere?
Thanks,
Myles
Re: [O] [new exporter] what is the label syntax for LaTeX export?
Hello,
Myles English mylesengl...@gmail.com writes:
If my org file has:
#+CAPTION[Here is a table]: A nice table
#+NAME: tab:niceone
| a |
Look at my \ref{tab:niceone}.
then M-x org-export-dispatch l L gives me:
\begin{table}[htb]
\caption[Here is a table]{\label{tab-niceone}A nice table}
\begin{center}
\begin{tabular}{l}
a\\
\end{tabular}
\end{center}
\end{table}
Look at my \ref{tab:niceone}.
So, the label tab:niceone exports as \label{tab-niceone}. Is that right
or am I using the wrong syntax somewhere?
The correct syntax is:
[[tab:niceone]]
It will allow to move back and forth between the link and the target and
it will work across back-ends.
The new exporter comes with a cross-referencing system. Another example:
1. item 1
2. itmitem 3
As one can see in item [[itm]], ...
will be exported as As one can see in item 2,
Regards,
--
Nicolas Goaziou
Re: [O] [PATCH] Separate clocksum format for durations = 1 day
Toby Cubitt ts...@cantab.net writes: This is not far from your own suggestion to provide different functions depending on which output is desired, I just happen to think that these functions would all be so similar that they should be rolled into a single function that can produce different outputs. I think there'd only be a handful of possible values for fmt based on the current usage and that suggests just another cond form would be needed in implementing this function rather than a full-blown format string interpreter. It seems to me your `org--format-time' function would end up looking very like what I sketched. A cond to switch between hh:mm, hh.mm, dd hh:mm or dd hh.mm based only on the contents of the fmt argument would have to check whether fmt contains 2 or 3 %-sequences, then check if it contains . or : Again, these are strange and very limiting rules. What if I want to have 5 h 32 min? And 5,3 days? Achim didn't specify how he conceives the FMT argument. One possibility would be to have a placeholder-based template with, i.e. %d, %h, %m, %w for respectively number of days, hours, minutes and weeks. But it's still less flexible than functions because you need to have a fixed number of placeholders in every template. I still think functions are the way to go. Three options in the defcustom: - One to provide regular time (i.e 14:40 or 3d 18:32) - One to provide decimal time with the highest unit available (i.e. 18,75 h or 2,5 d). - One free slot for an user-defined function. Regards, -- Nicolas Goaziou
Re: [O] [new exporter] what is the label syntax for LaTeX export?
On 5 nov. 2012, at 23:18, Nicolas Goaziou n.goaz...@gmail.com wrote:
Hello,
Myles English mylesengl...@gmail.com writes:
If my org file has:
#+CAPTION[Here is a table]: A nice table
#+NAME: tab:niceone
| a |
Look at my \ref{tab:niceone}.
then M-x org-export-dispatch l L gives me:
\begin{table}[htb]
\caption[Here is a table]{\label{tab-niceone}A nice table}
\begin{center}
\begin{tabular}{l}
a\\
\end{tabular}
\end{center}
\end{table}
Look at my \ref{tab:niceone}.
So, the label tab:niceone exports as \label{tab-niceone}. Is that right
or am I using the wrong syntax somewhere?
The correct syntax is:
[[tab:niceone]]
It will allow to move back and forth between the link and the target and
it will work across back-ends.
The new exporter comes with a cross-referencing system. Another example:
1. item 1
2. itmitem 3
As one can see in item [[itm]], ...
will be exported as As one can see in item 2,
I had not fully realized this, this is great Nicolas!
- Carsten
Regards,
--
Nicolas Goaziou
- Carsten
