For very large equations generated by sympy, mathjax in the ipython notebook sometimes fails to render the equation. Instead, it shows the latex source of the equation in a box (which stretches far off the page). I can copy and paste that source into a real latex document, and it renders just fine (though I might have to use the geometry package to make the output PDF extraordinarily wide).
I've actually successfully rendered longer equations, but these particular ones I found were long and also had very large numbers of \left \right pairs in them. I'm not sure if that has anything to do with the failure, but it seems relevant.
What is going on? How can I debug mathjax? And how can I get it to render those equations?
Using the debugging tip found in this question, I found that the buffer was too small, which led me to this mathjax page, where I found the solution. After I increase mathjax's MAXBUFFER value, the equations render just fine. To do this (and turn debugging on), I just put the following in my ~/.ipython/profile_default/static/custom/custom.js.
MathJax.Hub.Config({
TeX: {
noErrors: {disabled: true}, // Show error messages
MAXBUFFER: 25*1024, // Set size of buffer in bytes
},
});
[Note: Your profile may be elsewhere. To find it, run ipython profile locate. If you don't have the custom.js file or its directories, you may need to create them.]
Related
I have installed the R extension for VS Code. I am creating a book with bookdown, which is an extension of RMarkdown.
There is a Knit option (Ctrl + Shift + K). By default, it runs
rmarkdown::render("path/to/current/file", encoding = 'UTF-8').
[#CarlosLuisRivera pointed out that I had render_site here, rather than render before.]
In order to make bookdown work, I just need it to run
rmarkdown::render_site() or bookdown::render_book().
The encoding is the default, so that isn't needed. bookdown. Importantly, though, there shouldn't be a filename. I can't for the life of me work out how to adjust the settings to stop it from putting the filename in.
There is a setting r.rmarkdown.knit.command. This doesn't seem to do anything when the active file is called index.Rmd. Otherwise, whatever I write there gets appended with (path/to/current/file, encoding = 'UTF-8').
Even if I could get this fixed, I wanted to use VS Code for its preview—the RStudio in-built one is poor. When I try to preview, it can't compile anything, throwing an error:
The path C:/Users/USERNAME/Documents/Maths/Teaching/ST333/LectureNotes/libs/jquery-3.6.0 does not appear to be a descendant of C:/Users/USERNAME/vscode-R/tmp/.
The log also includes
output file: C:/Users/USERNAME/.vscode-R/tmp/index.knit.md
so I guess it's trying to make it in the wrong place.
Any help would be appreciated!
I'm not sure I can include reproducible code on this, given there's 4,000 lines of code and that may be part of the problem, but let me try to explain my question the best I can:
I love using beepr to play an audible sound when a bunch of code is done processing. If my computer is taking a while to run it, I'll go look at a different screen or do something else in the room when its thinking.
I have a large .rmd file. Its 4187 lines long and beep() is on line 4185. I made sure it was nowhere else in the document using ctrl+f. When I "run all", the beep goes off when I'm about this far through the document:
And then it'll continue thinking for another few minutes before its done. This defeats the entire purpose of beepr().
So I guess my question is: is this a known problem? Is there anything particular to a .rmd document that does this? Any known fixes?
{knitr} manpage says:
This function takes an input file, extracts the R code in it according to a list of patterns, evaluates the code and writes the output in another file.
So the thing you are observing is due to the fact all R code in the .rmd gets evaluated before the whole process is finished. The sound plays when the beepr line is executed, since this will happen (rcode chunk) before the document is processed by pandoc (or similar) i would just advise you to put the beeper outside of the .rmd itself to trigger it after the process finished. write a 3 line r sript:
knit("my.rmd")
Sys.sleep(1)
beepr()
This makes sure the beep will only start after the document is created (Sys.sleep just to make sure and prob. not necessary)
I am using the Vim-R-plugin to edit files containing markdown and R-code blocks such that the files can be complied using knitr. The filetype is: RMD. I have enabled spell checking. How can I disable the spell checking within the code blocks?
Spell checking is attached to certain syntax groups. Find the :syn region that covers the R code blocks, and append / edit in contains=#NoSpell.
Instead of trying to get the #NoSpell working by region, my approach is to toggle between languages.
I work in three languages which are set up to toggle with a function key where I include "nospell". This makes turning spellchecking on and off as easy as pressingt F7. When coding and writing nospell is turned on, when finalizing the edits I toggle to the appropriate language.
In fact, I find spellchecks in my code to be a plus. I make mistakes in the comment sections too, sometimes even in variable names/plot lables etc. This way you have a quick last check of all language items that are going to be visible .
I got this to work on OS X by editing the ~/.vim/syntax/R.vim and doing a search and replace of all instances of #Spell to #NoSpell. Then restarting vim. All the red underscores were gone from the code chunks but were still in the rest of the the rmarkdown.
Interestingly this has not effected the spell checking in pure R documents that have a .R extension, so I having thought I understood what I was doing perhaps I have to admit I don't fully. But at least it has turned off spell checking of the code chunks in rmarkdown (Rmd) documents while leaving it still working elsewhere in the document.
I am using R 2.15.2 on windows XP.
I was used to use Rgui.exe but it was lacking the UNIX standards I like to use like CTRL+R <=>backward research and CTRL+U <=>erase line ...
If I missed something please tell me !
Then I tried Rterm.exe (which looks identical to R.exe to me) which has all those nice features. I found how to tune it right clicking on the top of the window to set height-width (it is like tuning the window you get from cmd.exe).
The problem is that now I cannot see on the window more than 75 characters, with a $ at the end: like this:
R) ppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp$
Not sure if it is a R option of a windows one, but if I set options("width"=180) I can see data.frame on the full width of the window...
Not sure what is happening, can I modify this?
We still do not know the answer to that one, so I guess 50 pts goes to Oscar de León... good for him to bad for me...
Sadly, it appears to be built in.
There used to be a problem with R when trying to print long strings. Apparently it was fixed first in Rterm and other versions of R before being fixed in Rgui.
When Rgui was fixed, possibly it was by a different means, since this issue can be fixed in Rgui but not other windows versions of R. You can change the width of the console for output both in Rgui and (later) Rterm.
The prompt is another story. It is actually not the same as the output space, and thus is controlled with a different option; but, this only works for Rgui. To do it, set pgcolumns=180 in the Rconsole file under [R HOME]\etc\. This modifies the width of the internal pager of the Rgui console, and effectively enables you to type up to 180 characters per input prompt.
Possibly there is a way to integrate that behavior into Rterm, and maybe Duncan Murdoch can point you in the correct direction (or prove me completely wrong).
I'm not really sure what is being requested. If what is needed in RTerm.exe is to display the end of a long line (and position the cursor there), then use CTRL-E. You can go back to the beginning of a line with CTRL-A. One can go back and forth repeatedly as needed until the line is use ENTER.
The control character of readline seem to be active, for instance CTRL-P scrolls back one command and CTRL-N brings up the "next" command from history if you hit CTRL-P too many times. (These are the same behavior as the up/down arrow keys.) See link for other expected readline behaviors.
On my machine alt-f and alt-b (which should have been meta-f and meta-b) did not natively move forward or backward by words, but ESC-b and ESC-f did so on a line that exceeded the console width and had the $'s marking either the right or left extents as having further material to look consider.
If you want to wrap display lines, then you need to consider alternatives or additions to readline: link, but that is an untested suggestion and merely the results of a search for: "readline wrap display".
The command should be options(width = 180) (without the quotes around width), but when you run Rterm in the Windows shell, it doesn't respect changes to this value; it just prints output as wide as the console.
The best way of working with R is (almost always) to use an IDE. Try emacs + ESS or one of the many vim plugins (R.vim, vim-R, VIM:r-plugin) if you want something UNIXy.
When I scroll through an Sweave document (Rnw) with latex and R
code, the text jumps around when the mode changes between Latex and
ESS. The two modes disagree how text should be wrapped. Moreover, I've noticed that when I do
M-x toggle-truncate-lines to enable truncate long lines while the
cursor is within latex code
move the cursor to R code
return to the latex code
the truncated long lines mode is no longer on. Has anyone noticed this? Has anyone solved this problem?
By reading a similar question on the ess-help#r-project.org mailing list, this is what I've learned. When we scroll through the noweb file, we are switching major modes from ESS to LaTeX. Most major modes kill all local variables as part of their initialization, so when we just set the variable locally it's overwritten. To solve this, I modified a hook I found:
(add-hook 'LaTeX-mode-hook '(lambda () (if (string-match "\\.Rnw\\'" buffer-file-name) (setq fill-column 80))))
You could set a similar hook for longlines-mode or toggle-truncate-lines, etc, to meet your needs. The downside to this solution is that you're stuck with a single value for the variable set in the hook.