Upon running the source code from org mode by invoking M-x org-babel-execute-subtree
I have to respond to every code block with a 'y`
How could configure it run as default 'y'
Evaluate
(setq org-confirm-babel-evaluate nil)
If you really want to skip this step always, you have to add the above form to your initialization file.
Here's the doc string of the variable:
Documentation:
Confirm before evaluation.
Require confirmation before interactively evaluating code
blocks in Org buffers. The default value of this variable is t,
meaning confirmation is required for any code block evaluation.
This variable can be set to nil to inhibit any future
confirmation requests. This variable can also be set to a
function which takes two arguments the language of the code block
and the body of the code block. Such a function should then
return a non-nil value if the user should be prompted for
execution or nil if no prompt is required.
Warning: Disabling confirmation may result in accidental
evaluation of potentially harmful code. It may be advisable
remove code block execution from ‘C-c C-c’ as further protection
against accidental code block evaluation. The
‘org-babel-no-eval-on-ctrl-c-ctrl-c’ variable can be used to
remove code block execution from the ‘C-c C-c’ keybinding.
You can customize this variable.
You should at least be aware of the warning.
Related
Sometimes when in comint mode the point is anywhere in the buffer and I press Return by mistake. This sends the text at point to the underlying process, which can be really dangerous. Often this text contains many lines and, by chance or not, one of them could be a valid command.
Is there any way to tell comint not to execute anything on Return except the last input?
The documented way seems to be override comint-get-old-input variable with a custom function. Easiest will be something like this:
(setq comint-get-old-input (lambda () (end-of-buffer) (comint-get-old-input-default)))
It goes to the end of buffer first, and only then calls coming-get-olt-input-default, effectively not messing with the previous output. Put it in your init.el, brief testing shows that it works.
I wrote a custom debugger as described in perldebguts. There's something wrong with my debugger code, though, so I want to step through my DB::DB() and DB::sub() routines line-by-line to isolate the problem.
I suppose I can do this by setting $^D to 1<<30, since the documentation says:
When the execution of your program reaches a point that can hold a breakpoint, the DB::DB() subroutine is called if any of the variables $DB::trace, $DB::single, or $DB::signal is true. These variables are not localizable. This feature is disabled when executing inside DB::DB(), including functions called from it unless $^D & (1<<30) is true.
When execution of the program reaches a subroutine call, a call to &DB::sub (args) is made instead, with $DB::sub holding the name of the called subroutine. (This doesn't happen if the subroutine was compiled in the DB package.)
(emphasis added)
People on the IRC #perl-help channel said that with $^D & (1<<30) I may be able to debug my debugger but they didn't know any details beyond that.
How can I trace the execution of my DB::DB() and DB::sub() subroutines step-by-step?
UPD
According to the answer below. When set $^D |= (1<<30) flag this allows me to debug debugger commands which is defined outside of DB namespace, but that is not an answer for question: How to disable that feature when executing inside DB::DB?
This is my custom debugger Devel::DebugHooks which I want to debug.
When I run this expression from debugger $^D|=(1<<30) and after that run debugger command, like vars 2 $x, this will allow me to debug code which is called from DB:: namespace.
This feature is disabled when executing inside DB::DB(), including functions called from it unless $^D & (1<<30) is true
This sentence from DOC just makes confusion.
The feature is NOT disabled when executing inside DB::DB() unless $^D & (1<<30) is true.
This feature is disabled only for functions called from DB::DB() when $^D & (1<<30) is true
Is there a way to retrieve the output of a function that did not complete properly?
For instance, a (non global) variable that was correctly computed by a function but that couldn't be saved properly because of syntax errors.
In principle, you can't look into a function once the program has stopped with an error. (That's why I often try to avoid functions.)
However, you can achieve what you want by entering debugging mode, using the dbstop function to set a breakpoint:
The dbstop function is used to temporarily stop the execution of a
program and give the user an opportunity to examine the local
workspace.
In particular, typing
dbstop if error
in the command window before running your code will make it stop at the point that caused the error and look at the variables within that function.
To restore normal behaviour you need the dbclear function. Type
dbclear if error
to remove the previously set breakpoint, or
dbclear all
to remove all breakpoints.
I have an org file with lots of babel source blocks in it that only need to be re-executed when the code is changed.
How do I prevent org from executing all of the blocks during export? In other words, set them all to manual execution only?
I would prefer a single global option rather than having to edit each block individually.
The variable org-export-babel-evaluate, if set to nil, will prevent any code from being evaluated as part of the export process. This way, only the results inserted by way of manual execution will be exported.
You can define it, and others, as a file variable by placing the following comment line at the top of your org file:
# -*- org-export-babel-evaluate: nil -*-
Setting the variable org-export-babel-evaluate to nil will avoid code evaluation, but it will also cause all source block header arguments to be ignored This means that code blocks with the argument :exports none or :exports results will end up in the export. This caught me off guard.
The alternative is to use the header argument :eval never-export on a file basis and then remove that line when re-running the source code:
#+PROPERTY: header-args :eval never-export
See the docstring for org-babel-evaluate:
Switch controlling code evaluation and header processing during export.
When set to nil no code will be evaluated as part of the export
process and no header arguments will be obeyed. Users who wish
to avoid evaluating code on export should use the header argument
‘:eval never-export’.
You can set the cache to yes (see http://orgmode.org/manual/cache.html). This can also be set a property line in the file to act globally.
#+Property: header-args :cache yes just make sure to C-c C-c on that line to activate the property.
After placing the following:
# -*- org-export-use-babel: nil;-*-
at the top of the file, and executing C-c C-c, It didn't work for me. The variable's value is not set accordingly.
But the following:
#+BIND: org-export-use-babel nil
with an application of C-c C-c works as expected.
I found the answer here: http://joelmccracken.github.io/entries/org-mode-specifying-document-variables-and-keywords/
There are probably some changes in emacs 26, which I'm using.
I have a HTML page, with html-mode enabled. I call function sgml-validate to check for any markup errors. It's based on compilation-mode. I want to remove some warnings from the compilation output, so I wrote a function and hooked it to compilation-filter-hook (this variable is not documented, but compilation-filter invokes it). Everything works. My problem is that how can I ensure my filter function only gets called when I started the compilation process on a HTML page (via sgml-validate)?
I see two methods, but none of them worked:
First, I can check the value of major-mode. But it always returns compilation-mode, since that is enabled on the *compilation* buffer. (I found a filter function in the source code of grep+, and they did check the value of major-mode. I can't figure out how can it work correctly.)
The other idea was than to only hook my filter function to the HTML file's buffer, but for similar reasons it couldn't work as the output of compilation process goes to a seperate buffer.
It sounds like you can advise smgl-validate so that it performs the filtering before it performs all it's other operations. For example:
(defadvice sgml-validate (around fix-filtering command activate)
(let ((return-value ad-do-it))
(filter-function return-value))))
Meanwhile, I found that compilation-start accepts an optional argument mode, which will be the major mode for the compilation buffer. So I can create a major mode derived from compilation-mode, and define there my filter function now hooked to the proper buffer.
The only problem is now that sgml-validate does not allow me to set the mode argument on compilation-start, but that's another question.
(I don't consider this the ultimate solution, of course.)