Re: [O] Erroneous "No such file or directory" with babel and remote dir
In a previous mail, I wrote: , | Which tells me that the tmp file error is a red herring and the real | breakage occurred after 5cb80c7, probably through a commit that touched | ob-sh.el (although that's far from guaranteed). Here's that list: | | $ git log --oneline -- lisp/ob-sh.el | 86e515d fix remote execution w/empty shebang header arg | 70dd119 Massive code clean-up. | 966447c Don't use `org-flet' in ob-awk.el and ob-sh.el | 8eb5843 Add punctuation at the end of the first line of docstrings. Code cleanup. | 63b5f8f replace flet/labels with org-flet/org-labels | ecd0562 Fix the master branch. | 6e306f6 Fix copyright years in maint. | de42649 Manually revert maint to e85080. | 73bb18b Manually revert to the Release 7.8.04 tag. | 38c5045 Fix copyright years. | 6e534f9 Manually revert back to commit e85080. | 5cb80c7 apply :shebang and :padline to shell script execution | ... ` Continuing along these lines, I think I've figured it out and it's not pretty. The executive summary is that the last commit in the list introduced a small bug that was fixed by the first commit in the list. But neither of those has much to do with the remote-dir breakage (except that the bug made things harder to bisect). The principal culprits are two sets of commits for code transformations that were supposed to do nothing functionally: they were just supposed to get away from using flet/labels (which are deprecated and will be obsolete by emacs version 24.3.) The end result is that one change fixes the remote dir problem in Loris's example. I'm not sure that it solves every such problem though: I haven't audited all the code. The change is a one-liner: in org-babel-shell-command-on-region, replace the line (call-process-region start end shell-file-name t by (funcall call-process-region start end shell-file-name t BTW, I'm using Org-mode version 7.9.2 (release_7.9.2-582-g6d099e.dirty @ /home/nick/elisp/org-mode/lisp/). The rest of the email explains why the change is needed (in excruciating detail: grab a beer or maybe a cup of coffee before starting on it.) I hope this is (mostly) correct but corrections would be more than welcome. The problem seems multi-faceted and therefore needs as many eyes on it as possible. Nick P.S. I'm not sure whether to thank Loris or to curse him for pushing me on this path, but there is no question that he is responsible for finding the bug, providing the reproducer and then beating on the gates with pitchfork and torch :-) === * Root cause The root cause of the problem was a set of code transformations that were supposed to leave the functionality intact. The code transformations were driven by the need to replace the flet/labels constructs which were declared obsolete (as of 24.3 - they are still available, but cause warnings to be issued). The problem was hard to find because there were four commits (at widely varying times) that contributed to various manifestations of the problem and it was difficult to bisect. In chronological order, they were - commit 5cb80c7 apply :shebang and :padline to shell script execution This did not cause the problem, but it introduced a bug that causes errors when executing a source block with a remote :dir spec. That confused the issue (at least it confused me: I fingered this as the culprit in a bisect, but it was only guilty of the bug fixed by commit 86e515d - see below -, not of the remote-dir problem). - commit 63b5f8f replace flet/labels with org-flet/org-labels Section [[flet --> org-flet]] describes this. - commit e85479a Don't use `org-flet' in some functions and several others that slowly got rid of org-flet in favor of let, and org-labels (somehow - I didn't check this carefully), the latter reverted and reapplied, presumably because problems were found and fixed in several iterations. I've only skimmed the surface here: I think this has the potential to be a minefield of problems waiting to explode - see the [[org-flet --> let]] section below. - commit 86e515d fix remote execution w/empty shebang header arg This finally fixed the little bug that was introduced by 5cb80c7. The first and the last of these commits are irrelevant to the remote-dir problem, except that the bug gets in the way of testing: any version later than 5cb80c7 exhibits the bug and that bug hides whether the remote-dir problem is present or not. The general procedure I followed was to make a branch with some commit as its tip and then manually apply the patch of commit 86e515d. Only then could I test for the remote-dir problem. In the following, when I say commit X, I mean commit X *plus* the manually applied patch from 86e515d. ** flet --> org-flet # < org-flet>> The first set of code transformations (implemented as commit 63b5f8f2e85b3059a2d30041db6939347a7a2d7d) dealt with the situation by doing a mass substitu
Re: [O] [PATCH] Time specifications: Allow specifying relative times
Achim Gratz (2012-11-14 20:44:55 +0100) wrote: > Ivan Vilata i Balaguer writes: >> Bastien (2012-11-13 23:02:40 +0100) wrote: >>> I'm not sure what went wrong on your side but the patch >>> has been applied here: >>> >>> http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=001bcb9645bf0a5ea72f09ae502a8410319473c0 >> >> I apologise if I'm getting confused with git or the way the Org repo >> is structured, but maybe the change was accidentally reverted later. > > It was reverted with 6f78edd68c, two hours after having been applied. So the relative time specifications patch caused some kind of problem? That'd be a real shame, the feature could be very useful. :( Thanks for the info, -- Ivan Vilata i Balaguer -- https://elvil.net/
Re: [O] change the latex header per subtree
Achim Gratz writes: > Speaking of which, couldn't this be made easier? There's only one > org-export-latex-packages-alist and if you're trying to use very > different LaTeX classes you'll end up specifying [NO-DEFAULT-PACKAGES] > and then copying a lot of \usepackage stuff around. So what? You define your latex classes once in your configuration variable, and you're all set. That doesn't sound that bad. > If it was possible to give an argument to [PACKAGES] (default, header, > ), then there would be no need for [NO-PACKAGES] and > [DEFAULT-PACKAGES] and one yould use several sets of package > definitions in multiple class definitions. It would be especially neat > if there was a pendant to LATEX_HEADER that would allow to specify > additional package collections on the fly. So, you may to make it easier by providing an even more complex machinery? ;) IMO, the current system is good enough for the job, even if the initial step introduces a lot of duplicate lines. Also, if you want to add package collections, you may include a header-only file in your class, I guess. Regards, -- Nicolas Goaziou
Re: [O] change the latex header per subtree
Nicolas Goaziou writes: > Define two LaTeX classes, one with "endfloat" package and one without. > Then use :EXPORT_LATEX_CLASS: node property. Speaking of which, couldn't this be made easier? There's only one org-export-latex-packages-alist and if you're trying to use very different LaTeX classes you'll end up specifying [NO-DEFAULT-PACKAGES] and then copying a lot of \usepackage stuff around. If it was possible to give an argument to [PACKAGES] (default, header, ), then there would be no need for [NO-PACKAGES] and [DEFAULT-PACKAGES] and one yould use several sets of package definitions in multiple class definitions. It would be especially neat if there was a pendant to LATEX_HEADER that would allow to specify additional package collections on the fly. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: [O] Erroneous "No such file or directory" with babel and remote dir
Nick Dokos wrote: > I checked successive versions from 7.01h onwards and found breakage > between release_7.8 and release_7.9. So I bisected and came up > with this as the bad commit: > > , > | commit 5cb80c7e5b9bcae180b799d2a49c78d529e029f0 > | Author: Eric Schulte > | Date: Mon Mar 12 13:23:53 2012 -0400 > | > | apply :shebang and :padline to shell script execution > | > | * lisp/ob-sh.el (org-babel-execute:sh): Pass all params to subroutine. > | (org-babel-sh-evaluate): Apply :shebang and :padline to shell script > | execution. > ` > > Reverting it caused a merge conflict that I didn't have the patience to > resolve. But I made branches, one with this commit as its tip and one > with its predecessor: > > git checkout -b foo 5cb80c7 > git checkout -b bar de09874 > > Testing on foo gives me an error, testing on bar gives the correct > result. So I'm pretty sure this commit introduced the problem. Eric has > applied a partial fix since then which gets rid of the error but still > gives the wrong answer (not Eric's fault: he followed my suggestion, but > I was treating the symptom, not the disease). > > But I think this commit is the place that deserves more scrutiny. > The plot thickens. If I create a branch with 5cb80c7 as the tip and then immediately apply the later patch that fixes the error, then things are working as they should. Here is the procedure in case somebody wants to try to replicate: o First, save the later commit as a patch to apply: git show 86e515d > patch.to.apply o Then go back in time: git checkout -b foo 5cb80c7 That gets you back to 7.8.03 and when I try the code block with emacs -q -l /path/to/minimal.emacs.that.requires.ob-sh /path/to/loris.org I get an error: /bin/bash: /scpc:n...@lefou.usa.hp.com:/tmp/sh-script-6207TKx: No such file or directory o I then apply the patch: git apply patch.to.apply and retry: I get the remote host name as I should. Which tells me that the tmp file error is a red herring and the real breakage occurred after 5cb80c7, probably through a commit that touched ob-sh.el (although that's far from guaranteed). Here's that list: $ git log --oneline -- lisp/ob-sh.el 86e515d fix remote execution w/empty shebang header arg 70dd119 Massive code clean-up. 966447c Don't use `org-flet' in ob-awk.el and ob-sh.el 8eb5843 Add punctuation at the end of the first line of docstrings. Code cleanup. 63b5f8f replace flet/labels with org-flet/org-labels ecd0562 Fix the master branch. 6e306f6 Fix copyright years in maint. de42649 Manually revert maint to e85080. 73bb18b Manually revert to the Release 7.8.04 tag. 38c5045 Fix copyright years. 6e534f9 Manually revert back to commit e85080. 5cb80c7 apply :shebang and :padline to shell script execution ... So unless somebody sees something wrong with the above procedure, we are a bit closer to finding the culprit, but it's certainly not who I thought it was. Nick
Re: [O] [PATCH] Time specifications: Allow specifying relative times
Ivan Vilata i Balaguer writes: > Bastien (2012-11-13 23:02:40 +0100) wrote: >> I'm not sure what went wrong on your side but the patch >> has been applied here: >> >> http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=001bcb9645bf0a5ea72f09ae502a8410319473c0 > > I apologise if I'm getting confused with git or the way the Org repo is > structured, but maybe the change was accidentally reverted later. It was reverted with 6f78edd68c, two hours after having been applied. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: [O] [PATCH] Make org-notify.el work with latest org-element.el
Hello, Peter Münster writes: > * contrib/lisp/org-notify.el (org-notify-convert-deadline): New function. > (org-notify-make-todo): Use that function. Applied. Thank you. Regards, -- Nicolas Goaziou
Re: [O] Export tables as matrices (change tbl-export function on the fly)
Nicolas Goaziou writes:
> Hello,
>
> Rasmus writes:
>
>> I'm doing some stuff where the natural output of my tables are
>> matrices. I found a decent translation function here ¹. However,
>> I'm not very successful in making org use it.
>
> Using the new exporter, something like should replace any table using
> default environment (i.e. no special attribute) and without horizontal
> rules with bmatrix environment. It should also insert it in math mode
> automatically.
this one seems to work better for me, but might be more ugly . . .
#+begin_src emacs-lisp
(defun my-latex-table-to-matrix (table backend info)
(when (and (memq backend '(e-latex e-beamer))
(not (string-match "^[A-Za-z]+$" table))
(not (string-match "\\begin{\\(table*\\|sidewaystable\\)}" table)))
(let ((default-env (format "\\(begin\\|end\\){\\(%s\\)}.*"
org-e-latex-default-table-environment)))
(when (string-match default-env table)
(concat "\\[\n"
(org-trim
(replace-regexp-in-string "\n\n" "\n"
(replace-regexp-in-string
"\\(begin\\|end\\){\\(center\\|table\\)}\\|toprule\\|bottomrule\\|\[[htbH]+?\]"
""
(replace-regexp-in-string
default-env "\\1{bmatrix}" table
"\n\\]\n")
(add-to-list 'org-export-filter-table-functions 'my-latex-table-to-matrix)
#+end_src
--
Dung makes an excellent fertilizer
Re: [O] Extending org-koma-letter.el
Nicolas Goaziou writes: > I cannot reproduce it. Also, I think Luis provided a better option for > letters with his Groff backend. You may want to try it. > > Anyway, for the record, I'm posting an updated version[1] of the file, > compatible with latest Org (master branch). It may solve your problem. > > > Regards, > > [1] I do not seriously maintain this file. It was a proof of concept. Thanks a lot. If there is no plan to maintain a Koma backend, I'll have a look ot Luis's Groff backend. Thanks again, Alan
[O] replace-disputed-keys by default; but not for calendar
Hi all, I configured (setq org-replace-disputed-keys t) since I'm used to windmove.el. I would, however, like to use shift+arrow keys just for calendar. Does anyone have a suggestion how to accomplish such a feat? I'm looking at source code for `org-read-date' but I'm not getting any ideas. If it matters, I'm using org-version 7.8.11. Kind Regards, Miro
Re: [O] Export tables as matrices (change tbl-export function on the fly)
Hello,
Rasmus writes:
> I'm doing some stuff where the natural output of my tables are
> matrices. I found a decent translation function here ¹. However,
> I'm not very successful in making org use it.
Using the new exporter, something like should replace any table using
default environment (i.e. no special attribute) and without horizontal
rules with bmatrix environment. It should also insert it in math mode
automatically.
Untested.
#+begin_src emacs-lisp
(defun my-latex-table-to-matrix (table backend info)
(when (and (memq backend '(e-latex e-beamer))
(not (string-match "^[A-Za-z]+$" table))
(not (string-match "\\begin{\\(table*\\|sidewaystable\\)}" table)))
(let ((default-env (format "\\(begin\\|end\\){\\(%s\\)}.*"
org-e-latex-default-table-environment)))
(when (string-match default-env table)
(concat "\\[\n"
(org-trim
(replace-regexp-in-string
"\\(begin\\|end\\){\\(center\\)}" ""
(replace-regexp-in-string
default-env "\\1{bmatrix}" table)))
"\n\\]")
(add-to-list 'org-export-filter-table-functions 'my-latex-table-to-matrix)
#+end_src
Regards,
--
Nicolas Goaziou
Re: [O] [PATCH] Separate clocksum format for durations >= 1 day
On Wed, Nov 14, 2012 at 05:09:38PM +0100, Nicolas Goaziou wrote: > Toby Cubitt writes: > > > I can easily allow org-time-clocksum-fractional-format to be a list of > > formats. But "1d 3.4h" doesn't seem very useful to me. Probably it should > > work a bit differently: format the time as a fractional quantity, using > > the largest time unit which will give a non-zero integer part. > > > > Does that sound reasonable? > > That's the idea, yes. Though, it will be the largest time unit _with > a format string_ which will give a non-zero integer part. Yes, that's what I meant. > > OK, but in this case I think the single-format-string option is still > > useful. It gives users a simpler way of customizing the format if they > > don't want to do anything fancy. > > If they don't want to do anything fancy, they use the default value, > whatever it may be. ;) I don't mind keeping the single format string > option anyway. I'll leave it in my patch. If you want to remove it for 8.0, it'll be a simple case of deleting some code. > > I'll post an updated patch when I get time to make the changes. > > Since it's for 8.0, there's no hurry. I'll wait for you to merge the two > patches and make subsequent changes. OK. 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: > I can easily allow org-time-clocksum-fractional-format to be a list of > formats. But "1d 3.4h" doesn't seem very useful to me. Probably it should > work a bit differently: format the time as a fractional quantity, using > the largest time unit which will give a non-zero integer part. > > Does that sound reasonable? That's the idea, yes. Though, it will be the largest time unit _with a format string_ which will give a non-zero integer part. > OK, but in this case I think the single-format-string option is still > useful. It gives users a simpler way of customizing the format if they > don't want to do anything fancy. If they don't want to do anything fancy, they use the default value, whatever it may be. ;) I don't mind keeping the single format string option anyway. > I'll post an updated patch when I get time to make the changes. Since it's for 8.0, there's no hurry. I'll wait for you to merge the two patches and make subsequent changes. Thank you. Regards, -- Nicolas Goaziou
[O] Logging properties, values in notes on TODO state change for column view usage?
Wondered if anyone had any thoughts about this? I am trying to utilise the LOGBOOK and I think column view is the way to go. Many thanks, 'Mash > From: "'Mash (Thomas Herbert)" > Date: Mon, 29 Oct 2012 16:39:57 + > To: emacs-orgmode@gnu.org > Subject: Logging properties, values in notes on TODO state change for column > view usage? > > I have been looking at trying to track training performance with > org-mode. > > I currently just set a reoccurring schedule with note logging on > state change, but wondered if there was a way to log values within > this :LOGBOOK: logs? > > It is not a lot of effort to simply type in ":abc: 5", etc in the note > window. The idea being it would be nice to use column view to collect > these various logged values. > > > ** TODO Training > :LOGBOOK: > - State "DONE" [2012-10-29 Mon 16:26] \\ > :abc: 5 > :xyz: 9 > - State "DONE" [2012-10-30 Tue 16:25] \\ > :abc: 6 > :xyz: 8 > :PROPERTIES: > :LAST_REPEAT: [2012-10-30 Tue 16:26] > :COLUMNS: %25ITEM %10abc %10xyz > :END: > <2012-10-29 Mon +1d> >
Re: [O] [PATCH] Separate clocksum format for durations >= 1 day
On Wed, Nov 14, 2012 at 04:04:05PM +0100, Nicolas Goaziou wrote:
> Toby Cubitt writes:
>
> Thanks for your work. Some comments below.
>
> > The second patch:
> > - further extends org-time-clocksum-format to allow separate month and
> > year components (where a month is taken to be 30 days, a year to be 365
> > days).
>
> I suggest to add week instead of month, as the duration of the former is
> more stable and [1;52[ range is still readable.
Yes, not sure why I didn't think of adding weeks. But using months and
years is optional and not the default, so I see no great harm in
including them too (as long as the fact that 1 month = 30 days and 1 year
= 365 days here is well documented).
> > The reason for retaining separate org-time-clocksum-format and
> > org-time-clocksum-fractional-format's is that (i) it doesn't make much
> > sense to have a list of formats for separate components when using the
> > fractional format (see Nicolas' examples earlier in this discussion
> > thread);
>
> Then, my examples weren't clear. It is useful to have a list of formats
> when using fractional time as the unit used may change:
>
> 1.2 dor1.2 h
I can easily allow org-time-clocksum-fractional-format to be a list of
formats. But "1d 3.4h" doesn't seem very useful to me. Probably it should
work a bit differently: format the time as a fractional quantity, using
the largest time unit which will give a non-zero integer part.
Does that sound reasonable?
> > I'm not wedded to new customization type I've used in
> > org-time-clocksum-format. If you prefer a plist, or a different ordering
> > of the format strings in the list, or a different customization ui,
> > that's fine by me.
>
> I think a plist would be clearer. More on that below.
>
> > +(org-add-props (concat (format "%s " (make-string l ?*))
> > + (org-minutes-to-clocksum-string
> > time)
> > + (format "%s" (make-string (- 16 l)
> > ?\ )))
>
> Shouldn't it be:
>
> (org-add-props (concat (make-string l ?*) " "
>(org-minutes-to-clocksum-string time)
>(make-string (- 16 l) ? ))
Yes. This was an artifact of converting the previous code over to
org-minutes-to-clocksum-string.
> > -(defcustom org-time-clocksum-format "%d:%02d"
> > +(defcustom org-time-clocksum-format '(":%02d" "%d" "%dd ") ;"%d:%02d"
> >"The format string used when creating CLOCKSUM lines.
> > -This is also used when org-mode generates a time duration."
> > +This is also used when org-mode generates a time duration.
>
> This is not about your patch, but while you're working in this area: in
> documentation, it should be "Org mode".
OK.
> > +The value can be a single format string containing two
> > +%-sequences, which will be filled with the number of hours and
> > +minutes in that order.
>
> Ok, for backward compatibility. Note that, for a major release (8.0),
> such changes are acceptable even without it.
OK, but in this case I think the single-format-string option is still
useful. It gives users a simpler way of customizing the format if they
don't want to do anything fancy.
> > +Alternatively, the value can be a list of up to three format
> > +strings. In this case, the first format string in the list is
> > +used for the number of minutes, the second for the number of
> > +hours, and the third for the number of days if the duration is
> > +longer than 1 day. The complete formatted duration is obtained by
> > +concatenating these in the order: days, minutes, hours.
> > +
> > +If the list contains fewer than three format strings, it
> > +restricts the largest time unit in the formatted duration to be
> > +the largest one in the list. A two-element list means the
> > +duration will always be expressed in hours and minutes, a
> > +one-element list means the duration will always be expressed in
> > +minutes."
>
> There, I think we would benefit from using a plist. Indeed,
> a two-element list might mean that duration should be expressed in days
> and hours instead. Also I suggest to report duration targeted at missing
> format strings to the smaller unit.
Good idea. This adds (yet more) flexibility, and it makes customization
more transparent too.
> So:
>
> '(:day nil :hour "%d" :minute ":%02d")
>
> will be the equivalent of the current default format string. Then we can
> specify that "%d:%02d" is still available but should be deprecated.
I don't see any pressing need to deprecate the old format.
> It would also allow to skip months/weeks.
>
> > +(defalias 'org-minutes-to-hh:mm-string 'org-minutes-to-clocksum-string)
> > +(make-obsolete 'org-minutes-to-hh:mm-string 'org-minutes-to-clocksum-string
> > + "org-mode version 7.9.3")
>
> Good idea.
Don't forget to fix the WHEN argument when the patch is applied.
I'll post an updated patch when I get time to make the changes.
Cheers,
Toby
-
Re: [O] clickable text in org-mode not working (Sebastien Vauban)
Hi John, John Kitchin wrote: > Sebastien Vauban wrote: >> John Kitchin wrote: >>> It appears that one cannot define "clickable" text in org-mode. I was >>> trying to make some text in an org-file respond to different types of >>> clicking. I know that links provide some functionality for this, but >>> out of curiosity I wanted to see what else I could do. >>> >>> If I run the following code on a buffer in text-mode, the first four >>> characters in the buffer turn blue with a white background, they turn >>> a light green when the mouse is over them, and finally a message box >>> pops up when I click on the characters. >>> >>> (let ((map (make-sparse-keymap))) >>> (define-key map (kbd "") >>> '(lambda() (interactive) (message-box "it works!"))) >>> (add-text-properties 1 5 `(keymap, map >>> font-lock-face (:foreground "blue" >>> :background "white") >>> mouse-face highlight))) >>> >>> If I switch to org-mode, the clickability and mouse highlighting go >>> away. They also do not appear when I run the function in an >>> org-buffer. >>> >>> Does anyone know if there is a feature in org-mode that turns this >>> off, or if there is a way to get the clickability to work? Is it >>> related to having links that are clickable? >> >> I'm not sure to understand your use case -- why do you want clickable text in >> the first place (other than links)? >> >> But, did you look at `org-add-link-type' which does allow some kind of >> powerful stuff (mainly for export, but can maybe be diverted from its >> original >> purpose)? >> >> I guess you also are aware of the elisp and shell links you can already put >> in >> any Org file, as clickable "buttons"? > > I was just learning about programming interactive features into emacs > buffers, and something that worked in one major mode did not work in > org-mode. I have narrowed it down to an effect of font-lock-mode. When that > is off, the mouse-clicking works fine, when it is on, the font syntax > highlighting works fine, but not the clicking in org-mode. > > In terms of usage, I could see this as a way to automatically make "links" > out of different words, or in a related application to overlay tooltips on > specific words without having to markup the org-file. In essence, moving > some markup to a lisp file that is run before opening the org-file. > > I am familiar with `org-add-link-type' and have used that to do some pretty > cool things, as well as the elisp and shell links. With the clickable text > code I described, you can actually do different things with different mouse > clicks, including different mouse buttons, and presumably on mouse button up > events. It is not obvious that can be done with `org-add-link-type'; you get > the same behavior with any mouse button click. I havent advanced to a point > where I could get emacs-lisp to tell me which mouse event occurred on > clicking on a link. That seems possible though. Thanks for giving more information about what you're looking for. However, I must admit having no experience in that. Sorry. But, if I had to try and understand why your above code does not work, I would first give a deep look at some agenda commands: I know they *do* use "text properties" (for handling the clicks on the agenda line, in particular). These could help you achieving your goal, maybe? Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] Separate clocksum format for durations >= 1 day
Toby Cubitt writes:
Thanks for your work. Some comments below.
> The second patch:
> - further extends org-time-clocksum-format to allow separate month and
> year components (where a month is taken to be 30 days, a year to be 365
> days).
I suggest to add week instead of month, as the duration of the former is
more stable and [1;52[ range is still readable.
> The reason for retaining separate org-time-clocksum-format and
> org-time-clocksum-fractional-format's is that (i) it doesn't make much
> sense to have a list of formats for separate components when using the
> fractional format (see Nicolas' examples earlier in this discussion
> thread);
Then, my examples weren't clear. It is useful to have a list of formats
when using fractional time as the unit used may change:
1.2 dor1.2 h
> I'm not wedded to new customization type I've used in
> org-time-clocksum-format. If you prefer a plist, or a different ordering
> of the format strings in the list, or a different customization ui,
> that's fine by me.
I think a plist would be clearer. More on that below.
> + (org-add-props (concat (format "%s " (make-string l ?*))
> + (org-minutes-to-clocksum-string
> time)
> + (format "%s" (make-string (- 16 l)
> ?\ )))
Shouldn't it be:
(org-add-props (concat (make-string l ?*) " "
(org-minutes-to-clocksum-string time)
(make-string (- 16 l) ? ))
> -(defcustom org-time-clocksum-format "%d:%02d"
> +(defcustom org-time-clocksum-format '(":%02d" "%d" "%dd ") ;"%d:%02d"
>"The format string used when creating CLOCKSUM lines.
> -This is also used when org-mode generates a time duration."
> +This is also used when org-mode generates a time duration.
This is not about your patch, but while you're working in this area: in
documentation, it should be "Org mode".
> +The value can be a single format string containing two
> +%-sequences, which will be filled with the number of hours and
> +minutes in that order.
Ok, for backward compatibility. Note that, for a major release (8.0),
such changes are acceptable even without it.
> +Alternatively, the value can be a list of up to three format
> +strings. In this case, the first format string in the list is
> +used for the number of minutes, the second for the number of
> +hours, and the third for the number of days if the duration is
> +longer than 1 day. The complete formatted duration is obtained by
> +concatenating these in the order: days, minutes, hours.
> +
> +If the list contains fewer than three format strings, it
> +restricts the largest time unit in the formatted duration to be
> +the largest one in the list. A two-element list means the
> +duration will always be expressed in hours and minutes, a
> +one-element list means the duration will always be expressed in
> +minutes."
There, I think we would benefit from using a plist. Indeed,
a two-element list might mean that duration should be expressed in days
and hours instead. Also I suggest to report duration targeted at missing
format strings to the smaller unit. So:
'(:day nil :hour "%d" :minute ":%02d")
will be the equivalent of the current default format string. Then we can
specify that "%d:%02d" is still available but should be deprecated.
It would also allow to skip months/weeks.
> +(defalias 'org-minutes-to-hh:mm-string 'org-minutes-to-clocksum-string)
> +(make-obsolete 'org-minutes-to-hh:mm-string 'org-minutes-to-clocksum-string
> +"org-mode version 7.9.3")
Good idea.
Regards,
--
Nicolas Goaziou
[O] Export tables as matrices (change tbl-export function on the fly)
Hi,
I'm doing some stuff where the natural output of my tables are
matrices. I found a decent translation function here ¹. However,
I'm not very successful in making org use it.
I tried to add
#+begin_src org
* heading
:PROPERTIES:
:TABLE_EXPORT_FORMAT: orgtbl-to-latex-matrix
:END:
#+end src
to the relevant section of my document, but this does not seem to be
the correct usage.
I also tried to radio tables. The problem is that when I do
#+NAME: P
#+ORGTBL: SEND P orgtbl-to-latex-matrix
|1|
I cannot send P to R/Octave. When I swap the ORGTBL and NAME around,
I can't send it to a radio table. I also tried with TBLNAME.
Anyway, the optimal would be to have Org just use a different
translation mechanism on the fly. Is that possible?
Thanks,
Rasmus
Footnotes:
¹ http://www.patokeefe.com/archives/742
#+begin_src emacs-lisp
(defun orgtbl-to-latex-matrix (table params)
"Convert the Orgtbl mode TABLE to a LaTeX Matrix."
(interactive)
(let* ((params2
(list
:tstart (concat "\\[\n\\begin{bmatrix}")
:tend "\\end{bmatrix}\n\\]"
:lstart "" :lend " " :sep " & "
:efmt "%s\\,(%s)" :hline "\\hline")))
(orgtbl-to-generic table (org-combine-plists params2 params
(defcustom orgtbl-latex-matrix-string "% BEGIN RECEIVE ORGTBL %n
% END RECEIVE ORGTBL %n
\\begin{comment}
#+ORGTBL: SEND %n orgtbl-to-latex-matrix :splice nil :skip 0
\\end{comment}\n"
"Template for the latex matrix orgtbl translator
All occurrences of %n in a template will be replaced with the name of the
table, obtained by prompting the user."
:type 'string
:group 'org-table)
#+end_src
--
C is for Cookie
Re: [O] orgmode html export - cygwin - browser
On Mon, Nov 12, 2012 at 4:20 AM, Jan-Mark Batke wrote: > [snip (19 lines)] >>> >>> Or is a cygwin browser mandatory anyway (I would like to avoid >>> that)? >> >> >> can you please help understand/rephrase this last line? >> > > Well, a cygwin browser would expect (and understand) a file locator > like file:///cygdrive/c/file.html (I guess), whereas chrome wants to > see the same but c: instead of cygdrive/c > > I am wondering if anybody here is using cygwin ... > I do use Cygwin but prefer using native Emacs from http://alpha.gnu.org/gnu/emacs/windows. Sorry I couldn't be of help. --Manish
Re: [O] txt2tags exporter: patch & questions
Hello, Matteo Cypriani writes: > I worked on an exporter to the txt2tags format (http://txt2tags.org/) via org- > export-generic, and I have got a few questions (that are also included as > comments in the attached patch). There's a more powerful generic exporter being tested right now: org-export.el. Assuming you use a very recent Org , it lives in contrib/ directory and should be moved into core soon. You may want to try it in order to implement the text2tags backend. There is documentation for backend developers using this framework at: http://orgmode.org/worg/dev/org-export-reference.html Thanks for your interest in Org. Regards, -- Nicolas Goaziou
Re: [O] change the latex header per subtree
Hello, Andreas Leha writes: > I'd like to change the LaTeX header per subtree. Is that possible? > > Use case: I have two documents that I want to export from a single > orgmode file. Each in its own subtree. One of them should use the > endfloat package, the other should not. Define two LaTeX classes, one with "endfloat" package and one without. Then use :EXPORT_LATEX_CLASS: node property. Regards, -- Nicolas Goaziou
Re: [O] org-reload and new exporter
Hello, Andreas Leha writes: > Good suggestion. I did, and org-export is the guilty one. > > Should that be loaded before? You should try to update Org and try again. I just commited a patch which should fix the issue. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] org-e-latex: Tables get correct amount of vertical space
Hello,
Myles English writes:
> Nick, I think you are right about this, the modified patch at the end of
> this email makes only the replacements that are necessary just to
> replace the center environment within table blocks.
>
> The other \begin{center}'s in the org-e-latex.el file may be changed
> some other time, if needed.
Applied. Thank you.
Regards,
--
Nicolas Goaziou
Re: [O] Error in export to odt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14/11/12 13:46, Jambunathan K wrote: > Rainer M Krug writes: > >> Hi >> >> I am exporting a document to odt (Org-mode version 7.9.2 >> (release_7.9.2-459-g6f7e92 @ >> /home/rkrug/.emacs.d/org-mode/lisp/) and the odt generates fine, but it is >> corrupt. The >> simple org document looks like followed: >> >> * Required data / field work 100m^2--1000m2 >> >> This results in a "Format error discovered in the file in sub-document >> content.xml at >> 353,50(row,col)" >> >> simply adding spaces around the "--" solves the problem. > > Above example works fine with the new exporter. OK - this is fine with me - then I will use the new exporter. > > Old exporter is pretty much on the way out and I would strongly recommend > that you use the new > exporter as much as possible. No problem - from my side, no fix needed - I just got the new exporter to work and the result is fine. SNIP > One warning though: > > Make sure that you require ONLY ONE of org-odt and org-e-odt in your .emacs. > If you require > them simulatneously org-odt will not be usable. There is some error which I > haven't had time to > investigate. > Hm - I never had the any require for org-odt in my .emacs? Now I have the one for org-e-odt... Thanks, Rainer >> I attach the tmp.odt with the error. >> >> Libre Office - Version 3.6.2.2 (Build ID: 360m1(Build:2)) Ubuntu Quantal >> >> Cheers, >> >> Rainer > - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCjl8oACgkQoYgNqgF2egp3CACfVxacN8Y3N8VfjrFGcsZZ6qEb WP0An01g3Iz0tKpJtuq4tnHOXz3kXTQh =OSOo -END PGP SIGNATURE- tmpNew.odt Description: application/vnd.oasis.opendocument.text tmpNew.odt.sig Description: PGP signature
Re: [O] org-reload and new exporter
Hi Achim, Achim Gratz writes: > Andreas Leha med.uni-goettingen.de> writes: >> *Messages* does not show anything suspicious: > > Indeed. Since the org-export backends clearly are reloaded, some of the later > reloads must subvert them. I'd assume that this is due to something else from > contrib you have loaded, but you could simply reload org step by step in the > order that org-reload does and check where the export backends drop out. > Good suggestion. I did, and org-export is the guilty one. Should that be loaded before? Regards, Andreas
Re: [O] Error in export to odt
Rainer M Krug writes:
> Hi
>
> I am exporting a document to odt (Org-mode version 7.9.2
> (release_7.9.2-459-g6f7e92 @
> /home/rkrug/.emacs.d/org-mode/lisp/) and the odt generates fine, but
> it is corrupt. The simple org
> document looks like followed:
>
>
> * Required data / field work
> 100m^2--1000m2
>
>
> This results in a "Format error discovered in the file in sub-document
> content.xml at 353,50(row,col)"
>
> simply adding spaces around the "--" solves the problem.
Above example works fine with the new exporter.
Old exporter is pretty much on the way out and I would strongly
recommend that you use the new exporter as much as possible.
(require 'org-e-odt)
M-x org-export-dispatch RET
That said, this is what happens. I will accept any suggestions for
possible fix or blindly apply a patch if one would circulate that to me.
Step 1. 100m^2--1000m2
Step 2. 100m^2–1000m2
Step 3. 100m2–1000m2
Step 1 to Step 2 sounds good. This happens as part of
`org-lparse-convert-special-strings'.
Step 2 to Step is not OK. Note that the "&" that introduces the `ndash'
gets pulled in as part of subscript. This happens as part of
`org-lparse-apply-sub-superscript-styles'.
Now `org-match-substring-regexp' which goes something like
"\\([^\\]\\|^\\)\\([_^]\\)\\(\\({\\([^{}]*?\\|\\(?:[^{}]*?{[^{}]*?}\\)+[^{}]*?\\|\\(?:[^{}]*?{\\(?:[^{}]*?{[^{}]*?}\\)+[^{}]*?}\\)+[^{}]*?\\)}\\)\\|\\((\\([^()]*?\\|\\(?:[^()]*?([^()]*?)\\)+[^()]*?\\|\\(?:[^()]*?(\\(?:[^()]*?([^()]*?)\\)+[^()]*?)\\)+[^()]*?\\))\\)\\|\\(\\(?:\\*\\|[-+]?[^-+*!@#$%^_
\n,:\"?<>~;./{}=()]+\\)\\)\\)"
looks like a swear word to me :-). Frankly, I don't know or care about
latex-ism.
I am not sure whether there is a bug in that regexp or the regexp is
doing the right thing but that a `org-protected' property should be
applied to some part of the string that is undergoing transformation.
If someone can make sense out of what is happening and if I happen to
trust the other person's judgment, then this bug has some hope of
getting addressed. Otherwise, this bug will remain un-fixed.
But, I am sure what a ndash is doing in a Math expression. May be it is
a minus-that-is-aspiring-to-be-a-ndash, I don't know.
Anyways, try the new exporter.
One warning though:
Make sure that you require ONLY ONE of org-odt and org-e-odt in your
.emacs. If you require them simulatneously org-odt will not be usable.
There is some error which I haven't had time to investigate.
> I attach the tmp.odt with the error.
>
> Libre Office - Version 3.6.2.2 (Build ID: 360m1(Build:2))
> Ubuntu Quantal
>
> Cheers,
>
> Rainer
--
Re: [O] org-reload and new exporter
Andreas Leha med.uni-goettingen.de> writes: > *Messages* does not show anything suspicious: Indeed. Since the org-export backends clearly are reloaded, some of the later reloads must subvert them. I'd assume that this is due to something else from contrib you have loaded, but you could simply reload org step by step in the order that org-reload does and check where the export backends drop out. > I am installing to a custom location. Is that the problem here? I don't think so, I do that all the time. But I'm not using nearly as many packages from contrib... Regards, Achim.
[O] Error in export to odt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi I am exporting a document to odt (Org-mode version 7.9.2 (release_7.9.2-459-g6f7e92 @ /home/rkrug/.emacs.d/org-mode/lisp/) and the odt generates fine, but it is corrupt. The simple org document looks like followed: * Required data / field work 100m^2--1000m2 This results in a "Format error discovered in the file in sub-document content.xml at 353,50(row,col)" simply adding spaces around the "--" solves the problem. I attach the tmp.odt with the error. Libre Office - Version 3.6.2.2 (Build ID: 360m1(Build:2)) Ubuntu Quantal Cheers, Rainer - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCje64ACgkQoYgNqgF2egqjRgCfWvnkIs8lelZZC5x+i4dpG683 nqAAnArpg16etKE6NkCJlqYPg0Yz+/3u =eF5T -END PGP SIGNATURE- tmp.odt Description: application/vnd.oasis.opendocument.text tmp.odt.sig Description: PGP signature
Re: [O] org-reload and new exporter
Hi Achim, thanks for checking. Achim Gratz writes: > Andreas Leha med.uni-goettingen.de> writes: >> When I call org-reload the new exporter forgets all loaded backends and > > Did you check *Messages*? I've tried again just now to be sure and this is > working as expected for me. > *Messages* does not show anything suspicious: , | Loading /home/andreas/local/emacs/org-mode-install/lisp/ob...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/ob-R...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/ob-comint...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/ob-ditaa...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/ob-emacs-lisp...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/ob-eval...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/ob-exp...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/ob-keys...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/ob-lilypond...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/ob-lob...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/ob-ref...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/ob-sh...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/ob-table...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/ob-tangle...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-agenda...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-attach...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-bbdb...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-beamer...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-bibtex...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-clock...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-compat...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-contacts...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-docview...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-e-ascii...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-e-beamer...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-e-html...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-e-latex...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-e-odt... | Debug (org-e-odt): Searching for OpenDocument styles files... | Debug (org-e-odt): Trying /home/andreas/local/emacs/org-mode/etc/styles/... | Debug (org-e-odt): Using styles under /home/andreas/local/emacs/org-mode/etc/styles/ | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-e-odt...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-e-publish...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-element...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-entities...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-exp...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-exp-bibtex...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-export...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-faces...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-footnote...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-gnus...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-html...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-id...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-indent...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-info...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-inlinetask...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-irc...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-jsinfo...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-list...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-macs...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-mew...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-mhe...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-pcomplete...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-protocol...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-rmail...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-special-blocks...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-src...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-table...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-vm...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-w3m...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-wl...done | Loading /home/andreas/local/emacs/org-mode-install/lisp/org-version.el
Re: [O] [PATCH] org-e-latex: Tables get correct amount of vertical space
Sebastien Vauban writes:
> Hi Nick,
>
> Nick Dokos wrote:
>> Nick Dokos wrote:
>>>
>>> I think I read the whole thread but I'm still not clear on why
>>> the change is needed. What goes awry with the environment instead
>>> of the declaration?
>>
>> Never mind - I didn't read the whole thread.
>
> To summarize:
>
> - \begin{center}...\end{center} adds (undesired) vertical space
> - replacing by {\centering...\par} is the solution against that.
Or just \centering when contained in a figure or table environment
block so making the {...\par} unecessary.
Myles
Re: [O] org-reload and new exporter
Andreas Leha med.uni-goettingen.de> writes: > When I call org-reload the new exporter forgets all loaded backends and Did you check *Messages*? I've tried again just now to be sure and this is working as expected for me. > even re-evaluating (require 'org-e-latex), etc. does not bring them > back. That doesn't do anything if (featurep 'org-e-latex) is true, try load-library instead. Regards, Achim.
[O] org-reload and new exporter
Hi all, I just stumbled on this. I am building org (Org-mode version 7.9.2 release_7.9.2-585-g3d56f5) now basically with 'ORG_ADD_CONTRIB = org*' in local.mk (not sure if that is relevant, though). When I call org-reload the new exporter forgets all loaded backends and even re-evaluating (require 'org-e-latex), etc. does not bring them back. Regards, Andreas
Re: [O] [PATCH] org-e-latex: Tables get correct amount of vertical space
Hi Nick,
Nick Dokos wrote:
> Nick Dokos wrote:
>>
>> I think I read the whole thread but I'm still not clear on why
>> the change is needed. What goes awry with the environment instead
>> of the declaration?
>
> Never mind - I didn't read the whole thread.
To summarize:
- \begin{center}...\end{center} adds (undesired) vertical space
- replacing by {\centering...\par} is the solution against that.
Best regards,
Seb
--
Sebastien Vauban
Re: [O] Bug? R: Org babel block execution *drastically* slower than in ESS session directly
t...@tsdye.com (Thomas S. Dye) writes: > Aloha Aaron, > > Welcome to Org-mode. > > Aaron Ecay writes: > >> 2012ko azaroak 13an, John Hendy-ek idatzi zuen: >> >> [...] >>> Crazy. I really wondered if it had something to do with trying to spit >>> out the results into the minibuffer. Why is that behavior included? >> >> “:results silent” just means “silent except for the minibuffer”; IDK >> why. > [...] Just for the record: I would also love to see the "really-silent results". Regards, Andreas
Re: [O] Bug? R: Org babel block execution *drastically* slower than in ESS session directly
Aloha Aaron, Welcome to Org-mode. Aaron Ecay writes: > 2012ko azaroak 13an, John Hendy-ek idatzi zuen: > > [...] >> Crazy. I really wondered if it had something to do with trying to spit >> out the results into the minibuffer. Why is that behavior included? > > “:results silent” just means “silent except for the minibuffer”; IDK > why. I think "silent" has to do with the Org buffer that contains the source code block. Non-silent blocks do something in the buffer. This was, for me, one of the amazing things about babel when it was being developed. One could "speak" any language and have sensible results written back to a plain text file. > >> Are you sure it's only on file import? I was generating some large >> output when I first experienced this. > > Yes, that’s what I meant (and didn’t explain well). Org writes R’s > output to a file, and then imports it into Emacs (to print in the > minibuffer). But it also does an expensive transformation before > printing it – whence the slowdown. > >> I have to >> change to the R buffer to see if there were any errors. > > I agree that this is sub-optimal. > > I seem to remember that ob-R.el is unmaintained (or was at some point in > the past). Once there is consensus on what a fix should look like, I > can attempt to produce a patch implementing it. And I’ll take a crack > at error reporting in the minibuffer too. Yes, ob-R.el is currently without a maintainer. My sense and experience is that Eric S. is happy to entertain patches to the various ob language files. My experience is also that active maintainers welcome patches--I don't think there is a barrier to patch proposals. I can help with documentation if your patch results in some substantive changes to R support in babel. Please don't hesitate to ask if need be. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
