Re: [O] Trouble evaluating R source code blocks with C-c C-c
> On 28-May-2016, at 7:57 pm, William Denton wrote: > > On 28 May 2016, Vikas Rawal wrote: > >> Thanks John. Appreciate that you cared to respond to such a vague query. I >> am at a loss with this one. It does not happen all the time. I think it >> happens when I am processing large datasets, and CPUs and RAM of my system >> are struggling to keep up. But I could be wrong. > > I've had the same kind of thing happen---but C-g (sometimes many) to kill the > command, then rerunning, usually works without any trouble. Some strange > combination of CPU and RAM and all that, the kind of thing that's not easily > reproducible. > This seems to be write. Upgrading ess did not help. The odd thing is that running the same code by doing C-‘ to open a temporary R buffer and running to code from there works fine. But then I come back to the org buffer, C-c C-c, and the whole thing just freezes. The R session shows that the code is running. I have to use C-g in the org-buffer, which releases the org buffer, and C-c several times in the R session, to stop the commands. If I have waited enough, doing C-c C-c at the end in the R session ends the command and actually shows the output of the last command in R buffer. Which means that the last command had been completed. But the output was not inserted in the org buffer, and R was going on doing something. Let me try ‘debug-on-quit' Vikas
Re: [O] problem with org-table-export
Nicolas Goaziou writes: > > IIRC I fixed it already some time ago. Besides, I'm not able to > reproduce the problem. The problem I reported exists with current master, but maybe I did not describe it well enough. Let me try once more with a specific file which shows the problem. Open the attached file "table.org" in emacs. Then do M-x org-table-export you will then be prompted with "Export table to:" for a filename, where you wish to export to. Note that already at this point two stars appear in the emacs status line, which indicate that the buffer has been modified. This is a bug, as no real modification of the buffer has happened at this point. The attached patch solves the problem for me by only calling org-table-align if both org-table-automatic-realign and org-table-may-need-update. However, I am not completely sure if this is the correct solution though, I simply used the same idiom as is used in org-table-next-field and org-table-previous-field functions. Regards, Andreas | test | >From 1aa422b0008af1c0375037eac2f075db8d4ef23c Mon Sep 17 00:00:00 2001 From: Andreas Amann Date: Sat, 28 May 2016 20:23:52 +0100 Subject: [PATCH] org-table-export: fix problem with modified flags org-table-export did always set the modified flags of a buffer, even if no modification happens during export. Fix by only calling org-table-align if required. --- lisp/org-table.el | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lisp/org-table.el b/lisp/org-table.el index c6a84b8..89677cc 100644 --- a/lisp/org-table.el +++ b/lisp/org-table.el @@ -662,7 +662,9 @@ extension of the given file name, and finally on the variable `org-table-export-default-format'." (interactive) (unless (org-at-table-p) (user-error "No table at point")) - (org-table-align) ; Make sure we have everything we need. + (if (and org-table-automatic-realign + org-table-may-need-update) + (org-table-align)) (let ((file (or file (org-entry-get (point) "TABLE_EXPORT_FILE" t (unless file (setq file (read-file-name "Export table to: ")) -- 2.8.2
Re: [O] Trouble evaluating R source code blocks with C-c C-c
p.s. one more thing - below On Sat, 28 May 2016, Charles C. Berry wrote: On Sat, 28 May 2016, William Denton wrote: On 28 May 2016, Vikas Rawal wrote: Thanks John. Appreciate that you cared to respond to such a vague query. I am at a loss with this one. It does not happen all the time. I think it happens when I am processing large datasets, and CPUs and RAM of my system are struggling to keep up. But I could be wrong. I've had the same kind of thing happen---but C-g (sometimes many) to kill the command, then rerunning, usually works without any trouble. Some strange combination of CPU and RAM and all that, the kind of thing that's not easily reproducible. Try this: customize `debug-on-quit' to `t' (and set for current session). Then when you have to quit via C-g, you will get a backtrace showing where the process was hanging and how it got there. This might be helpful in figuring out what is going on. Run your code and when you finally have to C-g out copy the *Backtrace* buffer and report it back here (or on the ESS list if appropriate). After you copy the buffer, you should type 'q' in the *Backtrace* buffer to finish up or you may have some odd messages and hangups afterwards. Chuck
Re: [O] Trouble evaluating R source code blocks with C-c C-c
On Sat, 28 May 2016, William Denton wrote: On 28 May 2016, Vikas Rawal wrote: Thanks John. Appreciate that you cared to respond to such a vague query. I am at a loss with this one. It does not happen all the time. I think it happens when I am processing large datasets, and CPUs and RAM of my system are struggling to keep up. But I could be wrong. I've had the same kind of thing happen---but C-g (sometimes many) to kill the command, then rerunning, usually works without any trouble. Some strange combination of CPU and RAM and all that, the kind of thing that's not easily reproducible. Try this: customize `debug-on-quit' to `t' (and set for current session). Then when you have to quit via C-g, you will get a backtrace showing where the process was hanging and how it got there. This might be helpful in figuring out what is going on. Run your code and when you finally have to C-g out copy the *Backtrace* buffer and report it back here (or on the ESS list if appropriate). Chuck
Re: [O] Trouble evaluating R source code blocks with C-c C-c
On 28 May 2016, Vikas Rawal wrote: Thanks John. Appreciate that you cared to respond to such a vague query. I am at a loss with this one. It does not happen all the time. I think it happens when I am processing large datasets, and CPUs and RAM of my system are struggling to keep up. But I could be wrong. I've had the same kind of thing happen---but C-g (sometimes many) to kill the command, then rerunning, usually works without any trouble. Some strange combination of CPU and RAM and all that, the kind of thing that's not easily reproducible. Relatedly, sometimes if I have ":results output" for one block and then ":results values" for the next one, the second block picks up the output from the first one. But then other times not! Seems to depend on how intensive the R work is. Bill -- William Denton :: Toronto, Canada :: https://www.miskatonic.org/ Caveat lector.
Re: [O] org mode capture to headline at point
Thanks! You misunderstood though! Ending up over the asterisk is what my function does (if it works as intended)! So it should work anywhere in the heading?
Re: [O] org-refile works but dosent work from within a capture window (org-capture-refile)
sure! do you mind guiding me on how to produce the backtrace and ECM, im not very technical ;-) thx alot! Z On Sat, May 28, 2016 at 2:57 PM, Nicolas Goaziou wrote: > Hello, > > Xebar Saram writes: > > > org-refile work well when i issue it from a normal org buffer > > > > yet when i try to use C-c C-w (org-capture-refile) i get an error: > > > > org-refile: Wrong type argument: arrayp, nil > > > > any clue what could possibly cause this issue? > > Could you send a backtrace and, if possible, an ECM reproducing the > issue? > > Thank you. > > Regards, > > -- > Nicolas Goaziou >
Re: [O] problem with org-table-export
Hello, Rasmus writes: > It sounds rather plausible. AFAIR, org-table basically deletes and redraws > the table (but I didn’t check the code), which would modify the buffer. > Perhaps org-table-align could run in a temporary buffer and only inserted > the "new" table if it the result differs from what’s already in the > buffer. IIRC I fixed it already some time ago. Besides, I'm not able to reproduce the problem. Regards, -- Nicolas Goaziou
Re: [O] org-refile works but dosent work from within a capture window (org-capture-refile)
Hello, Xebar Saram writes: > org-refile work well when i issue it from a normal org buffer > > yet when i try to use C-c C-w (org-capture-refile) i get an error: > > org-refile: Wrong type argument: arrayp, nil > > any clue what could possibly cause this issue? Could you send a backtrace and, if possible, an ECM reproducing the issue? Thank you. Regards, -- Nicolas Goaziou
Re: [O] Bug: Error upon HTML export of LaTeX source code [8.3.4 (release_8.3.4-831-gbf93e1 @ /home/dominik/.emacs.d/org-mode/lisp/)]
Hello,
you are right. I found the problem. I had the following code in my
initialization file to treat latex beamer \frametitle commands as
sections.
(defun my-reftex-mode-hook ()
"Tell reftex to treat \frametitle as section commands."
(add-to-list 'reftex-section-levels
'("frametitle" . 2))
(reftex-reset-mode))
(add-hook 'reftex-mode-hook 'my-reftex-mode-hook)
It turned out that (reftex-reset-mode) broke org mode html export. I
thought that this line was needed to make reftex aware of the newly
defined section labels but double checked now and it turns out that it
doesn't need the reset anyway.
Just so that you know the cause.
Thanks and best wishes,
Dominik
On Mon, May 23 2016, Nicolas Goaziou wrote:
> Hello,
>
> Dominik Schrempf writes:
>
>> I try to export a fontified LaTeX source code listing with HTML export.
>> It boils down to an error that is thrown upon execution of the following
>> function during HTML export:
>>
>> (org-html-fontify-code "\\begin{tabular}{@{} l @{}}\n\\hline\nno
>> leading space\n\\hline\n\\end{tabular}\n" "latex")
>>
>> The debugging information is:
>> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>> expand-file-name(nil)
>> reftex-TeX-master-file()
>
> I cannot reproduce the error.
>
> I do not use reftex. However I tried to
>
> (add-hook 'TeX-mode-hook #'turn-on-reftex)
>
> to no avail. This might be something in your config.
>
>
> Regards,
Re: [O] problem with org-table-export
Hi Andreas, Thanks for your bug report. Andreas Amann writes: > Hi list, > > whenever I use > > M-x org-table-export > > inside a table, the buffer is marked "modified". > > This is even the case if no modifications are done to the buffer by > exporting the table. > > This problem happens since at least two years and possibly longer and > persists with the current git version of org-mode. > > As it is quite annoying in my workflow, I tried to investigate the > problem. Looking at the definition of org-table-export in > lisp/org-table.el the problem seems to be that the line > >(org-table-align) ; Make sure we have everything we need. > > > which seems to always set the modified flag, irrespective of real > changes being done. When I comment out this line or surround it with > (org-with-silent-modifications ... ), then the buffer remains clean. > However both solutions likely introduce other problems. > > I guess the proper solution would be to improve org-table-align to not > unnecessarily set the "modified" flag, but I would not know how to do > this. It sounds rather plausible. AFAIR, org-table basically deletes and redraws the table (but I didn’t check the code), which would modify the buffer. Perhaps org-table-align could run in a temporary buffer and only inserted the "new" table if it the result differs from what’s already in the buffer. Andreas, do you want to try to fix this issue? Thanks, Rasmus -- In theory, practice and theory are the same. In practice they are not
Re: [O] Trouble evaluating R source code blocks with C-c C-c
Thanks John. Appreciate that you cared to respond to such a vague query. I am at a loss with this one. It does not happen all the time. I think it happens when I am processing large datasets, and CPUs and RAM of my system are struggling to keep up. But I could be wrong. Let me take your advice and upgrade ESS. Hope that would help. Vikas > On 27-May-2016, at 12:22 am, John Hendy wrote: > > Could you give a minimal example? The behavior does ring a bell, but I > can't recall what the solution might have been. I'd be happy to try > and reproduce if you'd like. > > I think my typical go-to is to wipe ESS and re-download/make... That's > all I'm good for without more info. > > > Sorry! > John > > On Thu, May 26, 2016 at 9:33 AM, Vikas Rawal > wrote: >> I face a strange problem with evaluating R source code blocks. Occasionally, >> they take much longer to produce the results when I try to evaluate them >> with C-c C-c. On the other hand, if I do C-c ‘, go to a temporary R buffer, >> and evaluate the code, everything works fine. In face, when I use C-c C-c, >> the session would sometimes get stuck. Then I have to stop the process using >> C-g, I find that the code had run in R, but the result was not being >> inserted in Org buffer. >> >> Has anyone else faced this problem? >> >> I am on OS-X, Emacs 24, Org-mode version 8.3.4 (release_8.3.4-748-g7e320e, >> and ess-version: 15.09-devel [elpa: 20150913.638] >> >> Vikas >> >> >> >>
[O] org-refile works but dosent work from within a capture window (org-capture-refile)
Hi guys so before i go through the hell of binary partition...:) I have a wierd issue org-refile work well when i issue it from a normal org buffer yet when i try to use C-c C-w (org-capture-refile) i get an error: org-refile: Wrong type argument: arrayp, nil any clue what could possibly cause this issue? best Z
