Re: [O] org-tag-alist - fullscreen problem when adding tags
2016-05-19 10:27 GMT+02:00 Nicolas Goaziou : > > FWIW, I cannot reproduce it. You may want to debug > `org-fast-tag-selection' to understand what happens in your case. > > Are you using dedicated windows or some such ? No. I will try and debug. Thank you for your assistance.
Re: [O] Bug: org-export-babel-evaluate causes everything to be exported [8.3.4 (release_8.3.4-824-ga02fe8)]
On 2016-05-19 at 23:33, Charles C. Berry wrote: > On Thu, 19 May 2016, Ken Mankoff wrote: > >> I've noticed that code and results are all getting exported in the >> latest Org mode git head. This is new behavior. I haven't traced it >> to what commit caused this change, but the stock 8.2.10 install does >> not have this bug. >> >> The offending setting is: >> >> (setq org-export-babel-evaluate nil) > > I think this is a *feature* not a bug. > > It turns off all of babel on export. So the code will still be there > and any results that were already in the buffer will also be there. The documentation is: "Switch controlling code evaluation during export. When set to nil no code will be evaluated as part of the export process." which is different than "all code and results will be exported". Evaluation and export are two different things. > You can use `org-babel-remove-result-one-or-many' with a prefix if you > want results to be stripped (prior to export, say). > > You can use :cache to prevent re-evaluation of code blocks and set > org-export-babel-evaluate to t. Then the `:exports results' blocks > will not have their code run nor exported. (setq org-export-babel-evaluate t) #+BEGIN_SRC octave :exports results :cache nil "hello, world" #+END_SRC #+RESULTS: : hello, world Yes, the above appears to work. Thanks, -k.
Re: [O] Bug: org-export-babel-evaluate causes everything to be exported [8.3.4 (release_8.3.4-824-ga02fe8)]
On 2016-05-20 at 07:12, Ken Mankoff wrote:
> On 2016-05-19 at 23:33, Charles C. Berry wrote:
>> On Thu, 19 May 2016, Ken Mankoff wrote:
>
> (setq org-export-babel-evaluate t)
>
> #+BEGIN_SRC octave :exports results :cache nil
> "hello, world"
> #+END_SRC
> #+RESULTS:
> : hello, world
>
> Yes, the above appears to work.
But it doesn't work with sessions. Can you advise what settings to have how I
can have the following code in an Org document:
#+BEGIN_SRC python :results output :exports results :session foo :cache nil
print("hello, world")
#+END_SRC
#+RESULTS:
: hello, world
And easily export that document without evaluating the code?
Thanks,
-k.
Re: [O] sparse tree search still hides matching drawers (bug?)
Hello, Samuel Wales writes: > that would only either allow case folding or no case folding. in > isearch, if you search for lowercase, it folds. if you search for > uppercase CATEGORY, it doesn't. I added `org-occur-case-fold-search' variable in master. Setting it to `smart' should mimic isearch when calling org-occur. Regards, -- Nicolas Goaziou
[O] Litteral :var passing buggy for shell execution in org-babel when in :session
Hi.
I'm trying to apply the approach of litteral devops described in
http://www.howardism.org/Technical/Emacs/literate-devops.html and
noticed the following issue.
I'm trying to use execute shell blocks of the following form ("remote"
execution of
commands inside a Vagrant VM via tramp through ssh, using a shell mode session)
:
#+BEGIN_SRC sh :dir /symfonyvm:/vagrant :var SYNCEDDIR="/vagrant" :results
drawer :session centosvm
ls $SYNCEDDIR
#+END_SRC
This works well when not using a session, but when using the session,
the variable evaluation gets stuck, and when interrupted, I can see the
following inside the "centosvm" shell buffer :
/scp:symfonyvm: #$ SYNCEDDIR=$(cat <<'BABEL_TABLE'
The substitution doesn't seem to happen well over tramp in that case,
somehow.
Typing C-c C-d in the shell session allows me to recover.
I suspect an issue related to tramp + session, incompatible with the
variable initialisation mechanism.
Any clue ?
My setup should be org-mode version : 8.3.4 and normally, ob-sh.el
supposedly stock emacs in Debian testing context...
Thanks in advance.
Best regards,
--
Olivier BERGER
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)
[O] Org insert different hour than current time
Hi, 1. When I insert date and time format (C-u C-c .) the hour display in emacs calendar is the same as my system hour. Nonetheless,org-mode insert a different hour (it adds automatically 3 hours) 2. I make tests with different time zones and the same problem appeared. 3. When the time zone is UTC, there is no problem because org insert the system hour. How can I solve this issue? Regards, Levis
[O] exporting documents w/ babel results w/o evaluating babel blocks
Hi List,
I'm repeating a question here from a recent bug report because I have a feeling
official-looking bug reports might get read less than normal questions. Sorry
for the re-post.
As of an Org git commit a few weeks ago, Org exporting (and therefore Org) has
become basically unusable for me. I used to be able to export code block
results without evaluating the block during the export. I can no longer do this.
The following headers used to support the above behavior:
#+BEGIN_SRC python :exports results :results output
#+BEGIN_SRC python :exports results :results file
(and possibly with ":session foo" also)
Is anyone running the current git head? And if so, can you export a document
that consists of the following, or something similar to the following (i.e. do
you use ":cache t" or ":cache nil")?
#+BEGIN_SRC python :results output :exports results :session foo
print("hello, world")
#+END_SRC
#+RESULTS:
: hello, world
If you can export this without running the code, what settings are you using?
In particular, what is the value of =org-export-babel-evaluate=?
Thanks,
-k.
[O] History list for %^{...} in capture
Arising from a discussion here a couple of weeks ago, I'm thinking about
how best to add a history list to org-capture's current
%^{prompt|default|choice2|...|choiceN} escape syntax. Here's my thinking
so far.
%^{prompt|'histList}
%^{prompt|default|'histList}
%^{prompt|default|choiceToPrepend|...|'histList|choiceToAppend|...}
Note the quote distinguishing the variable name.
Effectively the third example means: merge choices "default" and
"choiceTo*" into 'histList, prepending or appending each choice (if it
is not already an element of `histList') according to whether it occurs
before or after 'histList. Usually we would not expect prepending and
appending, just the prompt, default and history list as in the second
example. However, this form might be useful for pre-populating an
otherwise empty list.
I've identified the place in the code where the changes would need to be
coded, but I thought I should get your ideas before I dive in.
Effectively something similar is being done behind the scenes already
and then discarded; I would just be bringing it into the light of day
and making it persistent across calls.
WDYT? Good idea? Too complex? Too "busy"? Useful? Not useful?
--
Phil Hudson http://hudson-it.ddns.net
@UWascalWabbit PGP/GnuPG ID: 0x887DCA63
Re: [O] exporting documents w/ babel results w/o evaluating babel blocks
On Fri, May 20, 2016 at 10:57 AM, Ken Mankoff wrote:
> Hi List,
>
> I'm repeating a question here from a recent bug report because I have a
> feeling official-looking bug reports might get read less than normal
> questions. Sorry for the re-post.
>
> As of an Org git commit a few weeks ago, Org exporting (and therefore Org)
> has become basically unusable for me. I used to be able to export code block
> results without evaluating the block during the export. I can no longer do
> this.
>
> The following headers used to support the above behavior:
>
> #+BEGIN_SRC python :exports results :results output
> #+BEGIN_SRC python :exports results :results file
> (and possibly with ":session foo" also)
Well, you're exporting them at least *once*, right? If not, where are
the results coming from?
Perhaps my use case is similar. I often write up an org doc with a
pretty heavy setup heading containing my main data reading in,
manipulation, statistics, etc. Maybe up to 100k total rows in a data
frame in R. Once I run that block the first time I'm working on the
document I just put =:eval no= in the src block options.
I do the same as I'm tweaking plots. Every code block I create has
:eval yes initially and once I'm satisfied with the results I just
change to :eval no and the generated results (for me, typically a
#+results line containing a link to a pdf plot generated by my code
block) are still included.
Does this help at all? Sorry if I'm not understanding
>
> Is anyone running the current git head? And if so, can you export a document
> that consists of the following, or something similar to the following (i.e.
> do you use ":cache t" or ":cache nil")?
>
> #+BEGIN_SRC python :results output :exports results :session foo
> print("hello, world")
> #+END_SRC
> #+RESULTS:
> : hello, world
>
> If you can export this without running the code, what settings are you using?
> In particular, what is the value of =org-export-babel-evaluate=?
Mine is set to t. Interestingly, when I export the above after
deleting the results bit, no new results are generated. When I C-c
C-c, they are replaced. When I add :eval no, it does't appear to run
the code.
Hope that helps,
John
>
> Thanks,
>
> -k.
>
Re: [O] exporting documents w/ babel results w/o evaluating babel blocks
On Friday, 20 May 2016 at 15:57, Ken Mankoff wrote: > Hi List, > > I'm repeating a question here from a recent bug report because I have > a feeling official-looking bug reports might get read less than normal > questions. Sorry for the re-post. > > As of an Org git commit a few weeks ago, Org exporting (and therefore > Org) has become basically unusable for me. I used to be able to export > code block results without evaluating the block during the export. I > can no longer do this. I can export your example without evaluating the babel block and the results appear in the exported output. My org is relatively recent but may be of a similar vintage to yours (see my signature). -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.92.1, Org release_8.3.4-775-g3308a5
Re: [O] exporting documents w/ babel results w/o evaluating babel blocks
Eric: You're running something newer (by date) than the commit which changed the behavior, which was: ec615b1 - Fix `org-export-babel-evaluate' handling (2016-04-28) But with all the branches in git, I don't know if you have that commit or not. Anyway, I'm not sure why it works for you. It doesn't appear to work for John and I the way it used to. Do you have a global "eval: no" set somewhere? On 2016-05-20 at 12:14, John Hendy wrote: > On Fri, May 20, 2016 at 10:57 AM, Ken Mankoff wrote: >> As of an Org git commit a few weeks ago, Org exporting (and therefore >> Org) has become basically unusable for me. I used to be able to >> export code block results without evaluating the block during the >> export. I can no longer do this. >> > > Well, you're exporting them at least *once*, right? If not, where are > the results coming from? Yes, but only once. Or sometimes I generate the figure elsewhere (via org-edit-special) and then manually put [[file:fig.pdf]] below the #+RESULTS:. > I do the same as I'm tweaking plots. Every code block I create has > :eval yes initially and once I'm satisfied with the results I just > change to :eval no and the generated results (for me, typically a > #+results line containing a link to a pdf plot generated by my code > block) are still included. > > Does this help at all? Sorry if I'm not understanding You understand, and this sort-of helps. I have never used :eval before. Things just didn't evaluate by default, and I like it like that. ":eval no" fixes the problem at export, but then I can't evaluate the code myself manually when not exporting. > Mine is set to t. Interestingly, when I export the above after > deleting the results bit, no new results are generated. When I C-c > C-c, they are replaced. When I add :eval no, it does't appear to run > the code. Yes same here. This new behavior really sucks. I'm still trying to find a way where: + code results do export + code does not export + code does not evaluate at export + code can still be evaluated by me This was the behavior prior to ec615b1 - Fix `org-export-babel-evaluate' handling (2016-04-28) But not since. -k.
Re: [O] exporting documents w/ babel results w/o evaluating babel blocks
Hi Eric, On 2016-05-20 at 12:59, Eric S Fraga wrote: > When I export, org asks whether to evaluate the code block and I > respond with no. The existing results block is therefore exported but > not changed. If I say yes, a new results block is generated and > exported (and I can tell because it is different to what was there > before). > > I have org-export-babel-evaluate set to t but also > org-confirm-babel-evaluate to t. Thanks for clarifying your workflow. That seems to work for a small example. But what would you do if you had a manuscript with 100 code blocks in it? And in general you're exporting it a lot without changing anything in code, just editing the non-code text. But occasionally you want to modify a code block (and its results) too? In the above scenario, I used to edit the code, and =C-c C-c= it manually to get the updates into the results. When I exported the document (C-e l l), it would export in ~1 second (even a >100 page document) and not prompt me about executing code blocks. -k
Re: [O] exporting documents w/ babel results w/o evaluating babel blocks
On Friday, 20 May 2016 at 17:06, Ken Mankoff wrote: [...] > Thanks for clarifying your workflow. That seems to work for a small > example. But what would you do if you had a manuscript with 100 code > blocks in it? And in general you're exporting it a lot without > changing anything in code, just editing the non-code text. But > occasionally you want to modify a code block (and its results) too? So, if I understand correctly, you have org-export-babel-evaluate set to nil? If I set that, I no longer get asked whether I want anything evaluated but the (existing) results do get exported. I just tried it to confirm. > In the above scenario, I used to edit the code, and =C-c C-c= it > manually to get the updates into the results. When I exported the > document (C-e l l), it would export in ~1 second (even a >100 page > document) and not prompt me about executing code blocks. Yes, I do this as well in such a case. -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.92.1, Org release_8.3.4-775-g3308a5
Re: [O] Division of Org documentation: Org manual and Worg
On Wed, May 18 2016, Rasmus wrote: > Hi Daniele, > >> So... here is the patch for worg about python and utf-8! I skipped >> the part related to the tables, since I do not have a clean >> workaround. > > Thanks for contributing to Worg! > > For Worg you just need to have your ssh key added. Then you can push > changes yourself. > > http://orgmode.org/worg/worg-about.html > > You can email your public ssh key to e.g. Bastien (bzg at gnu dot org). Hello Rasmus, Done, just pushed the change succesfully! I will look forward to integrate more docs about org-mode and python. Of course feedback are welcome! Best, Daniele
Re: [O] exporting documents w/ babel results w/o evaluating babel blocks
On Fri, May 20, 2016 at 12:11 PM, Eric S Fraga wrote:
> On Friday, 20 May 2016 at 17:06, Ken Mankoff wrote:
>
> [...]
>
>> Thanks for clarifying your workflow. That seems to work for a small
>> example. But what would you do if you had a manuscript with 100 code
>> blocks in it? And in general you're exporting it a lot without
>> changing anything in code, just editing the non-code text. But
>> occasionally you want to modify a code block (and its results) too?
>
> So, if I understand correctly, you have org-export-babel-evaluate set to
> nil? If I set that, I no longer get asked whether I want anything
> evaluated but the (existing) results do get exported. I just tried it
> to confirm.
Using this block,
#+begin_src R :exports results
print("hello")
#+end_src
I get the following (with *no* pre-existing #+results block manually
created with C-c C-c):
| *o-e-b-e* | *o-c-b-e* | *buffer* | *doc*|
|---+---+---+--|
| nil | t | nothing | =print("hello")= |
| t | t | nothing | =hello= |
| t | nil | nothing | =hello= |
| nil | nil | nothing | =print("hello")= |
|---+---+---+--|
Variables org-export-babel-evaluate and org-confirm-babel-evaluate
abbreviated above.
I find two things bizarre:
- these options (well, just o-e-b-e it seems) would change what's exported?
- why without C-c C-c which initiates the #+results block, exporting
which causes babel to execute code doesn't insert the results block.
Is this intended or for a reason?
I've not really looked into these variables and just use :eval yes/no
to toggle things. I find it easy enough to create all my blocks with
:eval no, and do a quick change to =yes= as I'm iteratively exporting.
Finally, I can do a replace-string to catch any missed :eval yes's
before a final export.
>
>> In the above scenario, I used to edit the code, and =C-c C-c= it
>> manually to get the updates into the results. When I exported the
>> document (C-e l l), it would export in ~1 second (even a >100 page
>> document) and not prompt me about executing code blocks.
>
> Yes, I do this as well in such a case.
>
> --
> : Eric S Fraga (0xFFFCF67D), Emacs 25.0.92.1, Org release_8.3.4-775-g3308a5
Re: [O] exporting documents w/ babel results w/o evaluating babel blocks
On Fri, May 20, 2016 at 11:45 AM, Ken Mankoff wrote: > > Eric: You're running something newer (by date) than the commit which changed > the behavior, which was: > > ec615b1 - Fix `org-export-babel-evaluate' handling (2016-04-28) > > But with all the branches in git, I don't know if you have that commit or > not. Anyway, I'm not sure why it works for you. It doesn't appear to work for > John and I the way it used to. Do you have a global "eval: no" set somewhere? > > On 2016-05-20 at 12:14, John Hendy wrote: >> On Fri, May 20, 2016 at 10:57 AM, Ken Mankoff wrote: >>> As of an Org git commit a few weeks ago, Org exporting (and therefore >>> Org) has become basically unusable for me. I used to be able to >>> export code block results without evaluating the block during the >>> export. I can no longer do this. >>> >> >> Well, you're exporting them at least *once*, right? If not, where are >> the results coming from? > > Yes, but only once. Or sometimes I generate the figure elsewhere (via > org-edit-special) and then manually put [[file:fig.pdf]] below the #+RESULTS:. > >> I do the same as I'm tweaking plots. Every code block I create has >> :eval yes initially and once I'm satisfied with the results I just >> change to :eval no and the generated results (for me, typically a >> #+results line containing a link to a pdf plot generated by my code >> block) are still included. >> >> Does this help at all? Sorry if I'm not understanding > > You understand, and this sort-of helps. I have never used :eval before. > Things just didn't evaluate by default, and I like it like that. > > ":eval no" fixes the problem at export, but then I can't evaluate the code > myself manually when not exporting. Not in the buffer so as to replace results, but you *can* go into interactive mode (if python has one) with =C-c '=. I use this constantly, which allows me to ignore whatever :eval is set to, and just putz around in the new code block buffer to my heart's content. I'm approx. 100% R usage, so this still gives me access to the R pop-up device to view plots or an R buffer to see results. You're right though, there's no way to update the results block without toggling :eval, manually running, and then resetting :eval back to no. John > >> Mine is set to t. Interestingly, when I export the above after >> deleting the results bit, no new results are generated. When I C-c >> C-c, they are replaced. When I add :eval no, it does't appear to run >> the code. > > Yes same here. This new behavior really sucks. > > I'm still trying to find a way where: > + code results do export > + code does not export > + code does not evaluate at export > + code can still be evaluated by me > > This was the behavior prior to > > ec615b1 - Fix `org-export-babel-evaluate' handling (2016-04-28) > > But not since. > > -k.
Re: [O] Bug: org-export-babel-evaluate causes everything to be exported [8.3.4 (release_8.3.4-824-ga02fe8)]
On Fri, 20 May 2016, Ken Mankoff wrote:
On 2016-05-20 at 07:12, Ken Mankoff wrote:
On 2016-05-19 at 23:33, Charles C. Berry wrote:
On Thu, 19 May 2016, Ken Mankoff wrote:
(setq org-export-babel-evaluate t)
#+BEGIN_SRC octave :exports results :cache nil
"hello, world"
#+END_SRC
#+RESULTS:
: hello, world
Yes, the above appears to work.
Really? I do not see the hash in your results block.
But it doesn't work with sessions. Can you advise what settings to have how I
can have the following code in an Org document:
#+BEGIN_SRC python :results output :exports results :session foo :cache nil
print("hello, world")
#+END_SRC
#+RESULTS:
: hello, world
And easily export that document without evaluating the code?
`:cache yes'
Of course, you must eval at least once with `:cache yes' to set the hash.
Chuck
p.s. I like to use stuff like
: import time
: print(time.strftime("%H:%M:%S"))
in src blocks to do :cache experiments
Re: [O] exporting documents w/ babel results w/o evaluating babel blocks
On 2016-05-20 at 13:11, Eric S Fraga wrote: > On Friday, 20 May 2016 at 17:06, Ken Mankoff wrote: > So, if I understand correctly, you have org-export-babel-evaluate set > to nil? yes. > If I set that, I no longer get asked whether I want anything evaluated > but the (existing) results do get exported. I just tried it to > confirm. Yes results get exported, but so does code. Both, always, even if ":exports none" or ":exports results". There may have been a misunderstanding, but when I mentioned this in the bug report, I was told this is a "feature". http://thread.gmane.org/gmane.emacs.orgmode/107230/focus=107231 -k.
Re: [O] exporting documents w/ babel results w/o evaluating babel blocks
Nicolas Goaziou added to To: field, because he committed the change. Question: Why does "org-export-babel-evaluate" change what is exported? Shouldn't it just change what is evaluated at export time? That is what the doc string implies. A recent commit changed this behavior. -k. On 2016-05-20 at 13:23, John Hendy wrote: > Variables org-export-babel-evaluate and org-confirm-babel-evaluate > abbreviated above. > > I find two things bizarre: > - these options (well, just o-e-b-e it seems) would change what's exported?
Re: [O] Bug: org-export-babel-evaluate causes everything to be exported [8.3.4 (release_8.3.4-824-ga02fe8)]
On 2016-05-20 at 13:29, Charles C. Berry wrote: > On Fri, 20 May 2016, Ken Mankoff wrote: >>> >>> #+BEGIN_SRC octave :exports results :cache nil >>> "hello, world" >>> #+END_SRC >>> #+RESULTS: >>> : hello, world >>> >>> Yes, the above appears to work. > > Really? I do not see the hash in your results block. Correct. I've never used cache, and ":cache t" doesn't work, it has to be ":cache yes". I'll try to set this up and see if it works better w/ caching. That may be the trick as you suggested in the other thread, and perhaps most of the issues here are my improper use of cache (which wasn't required before). -k.
Re: [O] Bug: org-export-babel-evaluate causes everything to be exported [8.3.4 (release_8.3.4-824-ga02fe8)]
On Fri, 20 May 2016, Ken Mankoff wrote: On 2016-05-20 at 13:29, Charles C. Berry wrote: On Fri, 20 May 2016, Ken Mankoff wrote: #+BEGIN_SRC octave :exports results :cache nil "hello, world" #+END_SRC #+RESULTS: : hello, world Yes, the above appears to work. Really? I do not see the hash in your results block. Correct. I've never used cache, and ":cache t" doesn't work, it has to be ":cache yes". I'll try to set this up and see if it works better w/ caching. That may be the trick as you suggested in the other thread, and perhaps most of the issues here are my improper use of cache (which wasn't required before). But I see that you said: I'm still trying to find a way where: + code results do export + code does not export + code does not evaluate at export + code can still be evaluated by me So, you want `:exports results :eval never-export' and forget about `:cache yes'. And leave `org-export-babel-evaluate' at `t'. Also, see (info "(org) eval") Chuck
[O] latex newcommand in org
Hi there,
In my group, we typically response to reviewers comments (in latex) by first
defining the following command in the header
\newcommand{\response}[1]{\textcolor{red}{#1}}
then marking up the text as follows
\response{red text}
I try to do the same in org, i.e., putting
#+latex_header:\newcommand{\response}[1]{\textcolor{red}{#1}}
then \response{BLAH BLAH} in the text. The only snag is that on export I get
\response\{BLAH BLAH\}
Any suggestion how to fix this
cheers,
M
Re: [O] exporting documents w/ babel results w/o evaluating babel blocks
On Friday, 20 May 2016 at 16:45, Ken Mankoff wrote: > Eric: You're running something newer (by date) than the commit which > changed the behavior, which was: > > ec615b1 - Fix `org-export-babel-evaluate' handling (2016-04-28) > > But with all the branches in git, I don't know if you have that commit > or not. Anyway, I'm not sure why it works for you. It doesn't appear > to work for John and I the way it used to. Do you have a global "eval: > no" set somewhere? I do have that commit incorporated in the version I am running from what I see in the git log. When I export, org asks whether to evaluate the code block and I respond with no. The existing results block is therefore exported but not changed. If I say yes, a new results block is generated and exported (and I can tell because it is different to what was there before). I have org-export-babel-evaluate set to t but also org-confirm-babel-evaluate to t. -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.92.1, Org release_8.3.4-775-g3308a5
Re: [O] latex newcommand in org
On Friday, 20 May 2016 at 18:10, Doyley, Marvin M. wrote:
> Hi there,
>
> In my group, we typically response to reviewers comments (in latex) by first
> defining the following command in the header
>
> \newcommand{\response}[1]{\textcolor{red}{#1}}
> then marking up the text as follows
>
> \response{red text}
>
> I try to do the same in org, i.e., putting
> #+latex_header:\newcommand{\response}[1]{\textcolor{red}{#1}}
> then \response{BLAH BLAH} in the text. The only snag is that on export I get
> \response\{BLAH BLAH\}
Easiest solution is @@latex:\response{blah blah}@@ but that will lose you
all the org formatting. Longer solution is to use environments, such as
#+begin_response
blah blah blah
#+end_response
and define a "response" LaTeX environment, along these lines:
#+latex_header:
\makeatletter\newenvironment{response}{\textcolor{red}}{}\makeatother
(untested)
--
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.92.1, Org release_8.3.4-775-g3308a5
Re: [O] Division of Org documentation: Org manual and Worg
Daniele Pizzolli writes: > Done, just pushed the change succesfully! I will look forward to > integrate more docs about org-mode and python. Grazie mille! Caio -- C is for Cookie
Re: [O] exporting documents w/ babel results w/o evaluating babel blocks
Ken Mankoff writes: > On 2016-05-20 at 13:11, Eric S Fraga wrote: >> On Friday, 20 May 2016 at 17:06, Ken Mankoff wrote: >> So, if I understand correctly, you have org-export-babel-evaluate set >> to nil? > > yes. > Are you getting an evaluation on export? I don't get that with o-e-b-e set to nil. >> If I set that, I no longer get asked whether I want anything evaluated >> but the (existing) results do get exported. I just tried it to >> confirm. > > Yes results get exported, but so does code. Both, always, even if ":exports > none" or ":exports results". > With ":exports results" and o-e-b-e set to nil, I get no evaluation on export, but I get both code and results in the output. > There may have been a misunderstanding, but when I mentioned this in > the bug report, I was told this is a "feature". > > http://thread.gmane.org/gmane.emacs.orgmode/107230/focus=107231 > Not sure what exactly Chuck meant is a feature, but IIUC, the fact that I get both code and results even if I specify ":exports results" looks like a bug to me. I'm on more-or-less latest master: Org-mode version 8.3.4 (release_8.3.4-824-ga02fe8 @ /home/nick/elisp/org-mode/lisp/) -- Nick
Re: [O] sparse tree search still hides matching drawers (bug?)
thank you! On 5/20/16, Nicolas Goaziou wrote: > I added `org-occur-case-fold-search' variable in master. Setting it to > `smart' should mimic isearch when calling org-occur. -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. And ANYBODY can get it. Denmark: free Karina Hansen NOW.
Re: [O] latex newcommand in org
On 2016-05-20, at 20:45, Eric S Fraga wrote:
> On Friday, 20 May 2016 at 18:10, Doyley, Marvin M. wrote:
>> Hi there,
>>
>> In my group, we typically response to reviewers comments (in latex) by first
>> defining the following command in the header
>>
>> \newcommand{\response}[1]{\textcolor{red}{#1}}
>> then marking up the text as follows
>>
>> \response{red text}
>>
>> I try to do the same in org, i.e., putting
>> #+latex_header:\newcommand{\response}[1]{\textcolor{red}{#1}}
>> then \response{BLAH BLAH} in the text. The only snag is that on export I get
>> \response\{BLAH BLAH\}
>
> Easiest solution is @@latex:\response{blah blah}@@ but that will lose you
> all the org formatting. Longer solution is to use environments, such as
>
> #+begin_response
> blah blah blah
> #+end_response
>
> and define a "response" LaTeX environment, along these lines:
>
> #+latex_header:
> \makeatletter\newenvironment{response}{\textcolor{red}}{}\makeatother
>
> (untested)
Notice also that commands and environments in LaTeX are not
interchangeable; there are things only commands can do and things only
environments can do. (Well, not really - technically, I guess,
environments are strictly more powerful than commands, though I'm not
100% sure - but some things are quite difficult to do with environments
and trivial with commands.)
See also
http://tex.stackexchange.com/questions/102141/what-are-the-consideration-when-choosing-either-newcommand-or-newenvironment
Best,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University
Re: [O] org-mode html export background/foreground inconsistency
lad writes: > I attempted to follow this blog to enable a background html export on > org file save: > > http://stephanus-volke.de/posts/2015/Dez/22/org-mode-live-preview-en/ > > I tried adding the following to the top of the org file: > > # -*- after-save-hook: org-html-export-to-html; > org-export-in-background: t; -*- > > by the way I also tried: > > -*- after-save-hook: org-html-export-to-html; > org-export-in-background: t; -*- > > I even tried the following which I thought would work since I'm setting > the optional ASYNC variable to true: > > #-*- after-save-hook: (org-html-export-to-html t); > org-export-in-background: t; -*- > > For each test I tried I quit emacs and reopened to org file fresh. I was > prompted to accept some security settings and chose "y" so the variable > org-export-in-background is set correctly. The funny thing is when I go > through (C-c C-e h o) the export goes to the background, otherwise when > I save the file it happens in the foreground (which freezes emacs for > some time). :( > > Running: > > Org-mode version 8.3.4 (8.3.4-50-g83e373-elpa) > GNU Emacs 25.1.50.1 > > I'm not sure if this is correct behavior? Thank you in advance for any > insight or suggestions you may have. > I tried it and it works for me, so I suspect that org-export-in-background is just not implemented in the stable release (based on the maint branch of the git repo - the elpa releases come from that branch), but *is* implemented in master (which is what I use). If that is correct, your options are to wait until version 9.0 is released, or to use the master branch of the git repo, with the possible bugs/instabilities that that might entail. -- Nick
Re: [O] Bug: org links do not work in some latex files [8.3.4 (8.3.4-34-gacfd41-elpaplus @ /home/oub/.emacs.d/elpa/org-plus-contrib-20160411/)]
Hello,
Uwe Brauer writes:
> Please look at the following example
>
> \documentclass[addpoints,12pt]{exam}
> \begin{document}
> %
> [[file:~/ALLES/tex/vorlesungen/HGBioQuim/Examen+geogebra/Examen2/README.org::*Overview][Overview]]
> \begin{questions}
> %
> [[file:~/ALLES/tex/vorlesungen/HGBioQuim/Examen+geogebra/Examen2/README.org::*Overview][Overview]]
>
> \end{questions}
>
> `org-open-at-point' opens the first link, but not the one in the
> environment questions.
`org-open-at-point' in an Org function, which is meant to be called in
an Org buffer. IIUC, you are calling it from a LaTeX buffer.
`org-open-at-point-global' provides sloppy Org link (and time-stamp)
following in any buffer. You should use it in this case.
Note that however `org-open-at-point-global' was bugged, so I just fixed
it in master. Thank you for the report.
Regards,
--
Nicolas Goaziou
Re: [O] Org insert different hour than current time
Mambo Levis writes: > Hi, > > 1. When I insert date and time format (C-u C-c .) the hour display in emacs > calendar is the same as my > system hour. Nonetheless, > org-mode insert a different hour (it adds automatically 3 hours) > FWIW, everything is working fine here. But I don't understand what "the hour display in emacs calendar" means, or what your "system hour" is. Can you specify *exactly* what you do? > 2. I make tests with different time zones and the same problem appeared. > > 3. When the time zone is UTC, there is no problem because org insert the > system hour. > How do you set the timezone? -- Nick
Re: [O] exporting documents w/ babel results w/o evaluating babel blocks
On Fri, 20 May 2016, Nick Dokos wrote:
Ken Mankoff writes:
[deleted discussion of `org-export-babel-evaluate' settings]
With ":exports results" and o-e-b-e set to nil, I get no evaluation on
export, but I get both code and results in the output.
There may have been a misunderstanding, but when I mentioned this in
the bug report, I was told this is a "feature".
http://thread.gmane.org/gmane.emacs.orgmode/107230/focus=107231
Not sure what exactly Chuck meant is a feature, but IIUC, the fact
that I get both code and results even if I specify ":exports results"
looks like a bug to me.
I meant this, as of commit ec615b1..., `org-export-babel-evaluate' set to
`nil' keeps the exporter from running this line
(org-export-execute-babel-code)
during exports. So, 'no Babel code is run' in the sense that the above
line does not execute.
src-blocks and inline-src-blocks are neither run nor removed, and no
#+results: or {{{results()}}} are added, removed, or
modified. Babel handles all that. The exporter merely formats those
things once Babel is done.
So the bug, if any, is in the docstring in failing to mention that
everything that babel does is switched off.
Since the behavior that the OP wanted can be had by setting babel
header args, I don't see this as a bug even though the behavior
changed in a way that surprised him.
Chuck
Re: [O] latex newcommand in org
Thanks,
I will give Eric’s suggestion a go.
Cheers,
M
On May 20, 2016, at 3:50 PM, Marcin Borkowski
mailto:mb...@mbork.pl>> wrote:
On 2016-05-20, at 20:45, Eric S Fraga
mailto:e.fr...@ucl.ac.uk>> wrote:
On Friday, 20 May 2016 at 18:10, Doyley, Marvin M. wrote:
Hi there,
In my group, we typically response to reviewers comments (in latex) by first
defining the following command in the header
\newcommand{\response}[1]{\textcolor{red}{#1}}
then marking up the text as follows
\response{red text}
I try to do the same in org, i.e., putting
#+latex_header:\newcommand{\response}[1]{\textcolor{red}{#1}}
then \response{BLAH BLAH} in the text. The only snag is that on export I get
\response\{BLAH BLAH\}
Easiest solution is @@latex:\response{blah blah}@@ but that will lose you
all the org formatting. Longer solution is to use environments, such as
#+begin_response
blah blah blah
#+end_response
and define a "response" LaTeX environment, along these lines:
#+latex_header:
\makeatletter\newenvironment{response}{\textcolor{red}}{}\makeatother
(untested)
Notice also that commands and environments in LaTeX are not
interchangeable; there are things only commands can do and things only
environments can do. (Well, not really - technically, I guess,
environments are strictly more powerful than commands, though I'm not
100% sure - but some things are quite difficult to do with environments
and trivial with commands.)
See also
https://urldefense.proofpoint.com/v2/url?u=http-3A__tex.stackexchange.com_questions_102141_what-2Dare-2Dthe-2Dconsideration-2Dwhen-2Dchoosing-2Deither-2Dnewcommand-2Dor-2Dnewenvironment&d=CwIBAg&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=T41F_5QsIVBGYhPPUkgYHUp9iPHgs2rOCjs7rfKaTMU&m=BXygbrudx0ZbLjXB7_QSNrR5Nwf_kj7fU2GbMseZG9Q&s=u6a29DcYPvJ-0G5l--k-db1OPj9GPF2DO89fbOOfje0&e=
Best,
--
Marcin Borkowski
https://urldefense.proofpoint.com/v2/url?u=http-3A__octd.wmi.amu.edu.pl_en_Marcin-5FBorkowski&d=CwIBAg&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=T41F_5QsIVBGYhPPUkgYHUp9iPHgs2rOCjs7rfKaTMU&m=BXygbrudx0ZbLjXB7_QSNrR5Nwf_kj7fU2GbMseZG9Q&s=msRYXf0n_C3V5ncax1tSsNPVzKQ8OOotiw7ibezCLxU&e=
Faculty of Mathematics and Computer Science
Adam Mickiewicz University
Re: [O] org-mode html export background/foreground inconsistency
On Fri, May 20, 2016, at 01:14 PM, Nick Dokos wrote: > lad writes: > > > I attempted to follow this blog to enable a background html export on > > org file save: > > > > http://stephanus-volke.de/posts/2015/Dez/22/org-mode-live-preview-en/ > > > > I tried adding the following to the top of the org file: > > > > # -*- after-save-hook: org-html-export-to-html; > > org-export-in-background: t; -*- > > > > by the way I also tried: > > > > -*- after-save-hook: org-html-export-to-html; > > org-export-in-background: t; -*- > > > > I even tried the following which I thought would work since I'm setting > > the optional ASYNC variable to true: > > > > #-*- after-save-hook: (org-html-export-to-html t); > > org-export-in-background: t; -*- > > > > For each test I tried I quit emacs and reopened to org file fresh. I was > > prompted to accept some security settings and chose "y" so the variable > > org-export-in-background is set correctly. The funny thing is when I go > > through (C-c C-e h o) the export goes to the background, otherwise when > > I save the file it happens in the foreground (which freezes emacs for > > some time). :( > > > > Running: > > > > Org-mode version 8.3.4 (8.3.4-50-g83e373-elpa) > > GNU Emacs 25.1.50.1 > > > > I'm not sure if this is correct behavior? Thank you in advance for any > > insight or suggestions you may have. > > > > I tried it and it works for me, so I suspect that > org-export-in-background is just not implemented in the stable release > (based on the maint branch of the git repo - the elpa releases come from > that branch), but *is* implemented in master (which is what I use). > > If that is correct, your options are to wait until version 9.0 is > released, or to use the master branch of the git repo, with the > possible bugs/instabilities that that might entail. > > -- > Nick > > > Hey Nick, That did the trick. Thanks for the hint, much appreciated! I don't mind living on the edge. ;) - lad
Re: [O] Bug: orgtbl-self-insert-command does not overwrite whitespace [8.3.4 (8.3.4-50-g83e373-elpa @ /home/alex/.emacs.d/elpa/org-20160509/)]
Hello, Alex writes: > As per the title, orgtbl-mode doesn't overwrite whitespace in tables > like it does normally in org-mode. Fixed. Thank you. Regards, -- Nicolas Goaziou
Re: [O] latex newcommand in org
You can use also macros in combination with latex \newcommand:
Following there's a sample with html:
#+MACRO: color @@html:$2@@
# macro sample: {{{color(red, aceitação)}}}
Note: untested with latex newcommand1
Cheers,
LEslie
On Fri, May 20, 2016 at 4:50 PM, Marcin Borkowski wrote:
>
> On 2016-05-20, at 20:45, Eric S Fraga wrote:
>
> > On Friday, 20 May 2016 at 18:10, Doyley, Marvin M. wrote:
> >> Hi there,
> >>
> >> In my group, we typically response to reviewers comments (in latex) by
> first defining the following command in the header
> >>
> >> \newcommand{\response}[1]{\textcolor{red}{#1}}
> >> then marking up the text as follows
> >>
> >> \response{red text}
> >>
> >> I try to do the same in org, i.e., putting
> >> #+latex_header:\newcommand{\response}[1]{\textcolor{red}{#1}}
> >> then \response{BLAH BLAH} in the text. The only snag is that on export
> I get \response\{BLAH BLAH\}
> >
> > Easiest solution is @@latex:\response{blah blah}@@ but that will lose
> you
> > all the org formatting. Longer solution is to use environments, such as
> >
> > #+begin_response
> > blah blah blah
> > #+end_response
> >
> > and define a "response" LaTeX environment, along these lines:
> >
> > #+latex_header:
> \makeatletter\newenvironment{response}{\textcolor{red}}{}\makeatother
> >
> > (untested)
>
> Notice also that commands and environments in LaTeX are not
> interchangeable; there are things only commands can do and things only
> environments can do. (Well, not really - technically, I guess,
> environments are strictly more powerful than commands, though I'm not
> 100% sure - but some things are quite difficult to do with environments
> and trivial with commands.)
>
> See also
>
> http://tex.stackexchange.com/questions/102141/what-are-the-consideration-when-choosing-either-newcommand-or-newenvironment
>
> Best,
>
> --
> Marcin Borkowski
> http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
> Faculty of Mathematics and Computer Science
> Adam Mickiewicz University
>
>
--
Leslie H. Watter
Re: [O] Starting source code export at non-zero (-n value)
Hello, Brian Carlson writes: > Hello other org mode aficionados! (I apologize for the errant email I > send a minute ago. ) > > I have created a (possible) patch to the export (ox.el and other > ox-XXX.el) files that allow for "source code" and "example" blocks to > have line numbers starting at an arbitrary number. Before the > (wonderful) ox redesign I used to have advice around some functions. I > hadn't needed this functionality for a while, but now that I did I > thought I would share. > > > The code is written with the following design: > > -n is the same as -n 1 : The functionality is unchanged > +n is the same as +n 1 : The functionality is unchanged > > -n X will "reset" and start new code block starting at line X > +n X will "add" X to the last line of the block before. Thank you for the patch. It looks like an useful addition to Org. Some comments follow. > From 6b4db0a978cc3492f0d0ac7e29008de6846fbe4a Mon Sep 17 00:00:00 2001 > From: Brian Carlson > Date: Mon, 16 May 2016 10:58:01 -0400 > Subject: [PATCH] ox: provide [+-]n functionality Here you need to specify all the functions being modified. You may want to look at other commit messages in the repository. > @@ -1488,9 +1488,9 @@ contextual information." > (custom-env (and lang >(cadr (assq (intern lang) >org-groff-custom-lang-environments > - (num-start (case (org-element-property :number-lines src-block) > + (num-start (case (car (org-element-property :number-lines > src-block)) >(continued (org-export-get-loc src-block info)) > - (new 0))) > + (new (or (cdr (org-element-property :number-lines > src-block)) 0 This pattern appears often in your patch, and, of course in the code base. I suggest to factorize it out. Indeed, we could take advantage of the new behaviour of `org-export-get-loc' that your patch introduces. IIUC, the new `org-export-get-loc' returns the number for the first line of the current block, not the number of the last line in the previous block, like it used to do. It can then includes the construct above: (pcase (org-element-property :number-lines src-block) ;; No need to compute line numbers before this one. (`(new . ,n) (or n 2)) (`(continued . ,_) ;; Count all lines above, up to the first block that has "new" line ;; numbering. (let ((loc 0)) (org-element-map (plist-get info :parse-tree) ... Of course, tests would have to be changed or updated accordingly. > - ((string-match "-n\\>" switches) 'new) > - ((string-match "+n\\>" switches) 'continued))) > + ((string-match "-n *\\([0-9]+\\)" switches) (cons 'new > (- (string-to-number (match-string 1 switches)) 1 ))) There is a spurious white space after the last 1. > + ((string-match "+n *\\([0-9]+\\)" switches) (cons > 'continued (- (string-to-number (match-string 1 switches)) 1 ))) Ditto. > + ((string-match "-n" switches) (cons 'new 0)) > + ((string-match "+n" switches) (cons 'continued 0)) > + )) These parens should be moved at the end of the previous line. >(preserve-indent > (and switches (string-match "-i\\>" switches))) >;; Should labels be retained in (or stripped from) example > @@ -2393,7 +2396,7 @@ Assume point is at the beginning of the block." > (looking-at >(concat "^[ \t]*#\\+BEGIN_SRC" >"\\(?: +\\(\\S-+\\)\\)?" > - "\\(\\(?: +\\(?:-l > \".*?\"\\|[-+][A-Za-z]\\)\\)+\\)?" > + "\\(\\(?: +\\(?:-l \".+\"\\|[+-]n > *[[:digit:]]+\\|[+-][[:alpha:]]\\)\\)+\\)?" I don't think "[-+][[:alpha:]]" is correct here and neither was [-+][A-Za-z]. We only want to match valid switches: k, r and i. Besides, there is no +k, +r or +i. Thus, it should be "-[iIkKrR]". >"\\(.*\\)[ \t]*$")) > (org-match-string-no-properties 1))) >;; Get switches. > @@ -2403,8 +2406,11 @@ Assume point is at the beginning of the block." >;; Switches analysis >(number-lines > (cond ((not switches) nil) > - ((string-match "-n\\>" switches) 'new) > - ((string-match "+n\\>" switches) 'continued))) > + ((string-match "-n *\\([0-9]+\\)" switches) (cons 'new > (- (string-to-number (match-string 1 switches)) 1 ))) > + ((string-match "+n *\\([0-9]+\\)" switches) (cons > 'continued (- (string-to-number (match-string 1 switches)) 1 ))) > + ((string-match "-n" switches) (cons 'new 0)) > + ((string-match "+n" switches) (cons 'cont
Re: [O] error: org-meta-return release_8.3.4.zip
Mambo Levis writes: > On Thursday, May 19, 2016 12:45 PM, Mambo Levis wrote: > > Hi, > > Yesterday I reported an issue (see bellow). How can I see its status? I open > an account in lists.gnu.org > Mailing Lists but I couldn't find > how to search for a reported issue. > Did you send it to the bug-gnu-emacs mailing list or to the org-mode mailing list? If the latter, you cannot check its status: org-mode does not have a bug tracking system as such. You need to wait for a maintainer or other interested party to respond (please, wait at least a week before pinging the list again: it might take a while for somebody to get around to it, but after a week or so, it's a fair supposition that it fell through the cracks). For the specific problems you are reporting below, it looks to me as if you are missing some initialization. I would add (require 'org-loaddefs) to init-org-minimal.el and try again. For the "mixed installation" problem, please search the list: there have been tens or hundreds of these problems reported. The best way to avoid it is to follow the instructions in (info "(org) Installation") exactly and use a tried-and-true method rather than going your own way. HTH, but please realize it's all untested conjecture. -- Nick > Thanks, > > Levis > > On Wednesday, May 18, 2016 9:18 PM, Mambo Levis wrote: > > Hi, > > 1.) By testing org-mode release_8.3.4.zip from ( > http://orgmode.org/cgit.cgi/org-mode.git/) without > compile it in emacs 25.1.50.1 an error is shown > when typing M-RET to add a new heading/item (see attached backtrace). > > I am using the minimal configuration suggested in the manual. > > - > ;; init.el > -- > (use-package org-mode > :load-path "~/.emacs.d/user/site-lisp/org-mode" > :init > (load-file "~/.emacs.d/user/lisp/init-org-minimal.el") > ) > -- > > ;;; init-org-minimal.el --- org-mode minimal configuration > > ;;; Minimal setup to load latest 'org-mode' > ;; activate debugging > (setq debug-on-error t > debug-on-signal nil > debug-on-quit nil) > ;; add latest org-mode to load path > (add-to-list 'load-path "~/.emacs.d/user/site-lisp/org-mode/lisp") > (add-to-list 'load-path "~/.emacs.d/user/site-lisp/org-mode/contrib/lisp" t) > ;;(org-capture) > > (provide 'init-org-minimal) > ;;; init-org-minimal.el ends here > --- > > 2) If I use the option reload Org uncompiled there is no problem when using > M-RET but the following > message appears: > Successfully reloaded Org > Org-mode version 8.2.10 (release_8.2.10 @ mixed installation! > c:/emacs/emacs-25.1.50/share/emacs/25.1.50 > /lisp/org/ and c:/home/.emacs.d/user/site-lisp/org-mode/lisp/) > > 3) Now I force emacs to search the new org-mode version by adding a org__ to > the original installation. > The following message appears: > File error: Cannot open load file, No such file or directory, org-table > > Questions: > - How can isolate the new org version from the default installed? > - How can I solve this issue? > > I appreciate your help, > regards, > > Levis >
Re: [O] error: org-meta-return release_8.3.4.zip
Hello, Mambo Levis writes: > On Thursday, May 19, 2016 12:45 PM, Mambo Levis > wrote: > > Hi, > 1.) By testing org-mode release_8.3.4.zip from ( > http://orgmode.org/cgit.cgi/org-mode.git/) without compile it in emacs > 25.1.50.1 an error is shown > when typing M-RET to add a new heading/item (see attached backtrace). It means that Emacs is confused and doesn't load the latest Org. > Questions: - How can isolate the new org version from the default > installed?- How can I solve this issue? Did you follow installation instructions (http://orgmode.org/manual/Installation.html#Installation)? Regards, -- Nicolas Goaziou
Re: [O] Bug: orgtbl-self-insert-command does not overwrite whitespace [8.3.4 (8.3.4-50-g83e373-elpa @ /home/alex/.emacs.d/elpa/org-20160509/)]
Alex G writes: >> > Backspace works as expected, however. >> I'm afraid that as of org-20160516 on ELPA, backspace also does not >> overwrite whitespace. > > Oh, it seems like backspace works fine in text modes like > fundamental-mode and message-mode, but not prog-derived modes. I'd say > that's another bug. > > A git bisect says that this commit by Bastien Guerry is the culprit: > f0a64ab3b5c46c8c7b1c838de2ed20511357e43d > > Does anyone know why it also affects orgtbl-self-insert-command? I believe I have figured out the issue for both problems: a) orgtbl-self-insert-command wasn't updated along with org-self-insert-command in the commit 73a5c27cc1751721344886e7518f20ff382265b5. Changing it accordingly fixes the issue. b) Backspace doesn't work in prog-derived modes as orgtbl-mode seems to just remap delete-backward-char to orgtbl, but in prog modes backspace is bound to backward-delete-char-untabify. Perhaps something extra should be done about backspace in orgtbl-mode instead of just a simple remapping?
Re: [O] Bug: org-export-babel-evaluate causes everything to be exported [8.3.4 (release_8.3.4-824-ga02fe8)]
Hi Chuck, On 2016-05-20 at 13:48, Charles C. Berry wrote: >> On Fri, 20 May 2016, Ken Mankoff wrote: >> >> I'm still trying to find a way where: >> + code results do export >> + code does not export >> + code does not evaluate at export >> + code can still be evaluated by me >> > > So, you want `:exports results :eval never-export' and forget about > `:cache yes'. > > And leave `org-export-babel-evaluate' at `t'. > > Also, see > (info "(org) eval") > Yes, this setup now appears to work. Thank you! I can get back to work... I think this option to :eval might also be useful for John Hendy who was manually toggling eval from no to yes. -k.
Re: [O] exporting documents w/ babel results w/o evaluating babel blocks
On 2016-05-20 at 14:46, Nick Dokos wrote: > Are you getting an evaluation on export? I don't get that with o-e-b-e > set to nil. No I was not, but things were still exporting, which was confusing. I agree, seems like a bug. > ... the fact that I get both code and results even if I specify > ":exports results" looks like a bug to me. Yes. -k.
Re: [O] latex newcommand in org
Eric’s suggestion works like a charm with the following modification
#+latex_header:\newenvironment{response}{\color{red}}{\ignorespacesafterend}
Thanks I really appreciate the help.
Cheers,
M
On May 20, 2016, at 5:00 PM, Leslie Watter
mailto:les...@watter.net>> wrote:
You can use also macros in combination with latex \newcommand:
Following there's a sample with html:
#+MACRO: color @@html:$2@@
# macro sample: {{{color(red, aceitação)}}}
Note: untested with latex newcommand1
Cheers,
LEslie
On Fri, May 20, 2016 at 4:50 PM, Marcin Borkowski
mailto:mb...@mbork.pl>> wrote:
On 2016-05-20, at 20:45, Eric S Fraga
mailto:e.fr...@ucl.ac.uk>> wrote:
> On Friday, 20 May 2016 at 18:10, Doyley, Marvin M. wrote:
>> Hi there,
>>
>> In my group, we typically response to reviewers comments (in latex) by first
>> defining the following command in the header
>>
>> \newcommand{\response}[1]{\textcolor{red}{#1}}
>> then marking up the text as follows
>>
>> \response{red text}
>>
>> I try to do the same in org, i.e., putting
>> #+latex_header:\newcommand{\response}[1]{\textcolor{red}{#1}}
>> then \response{BLAH BLAH} in the text. The only snag is that on export I get
>> \response\{BLAH BLAH\}
>
> Easiest solution is @@latex:\response{blah blah}@@ but that will lose you
> all the org formatting. Longer solution is to use environments, such as
>
> #+begin_response
> blah blah blah
> #+end_response
>
> and define a "response" LaTeX environment, along these lines:
>
> #+latex_header:
> \makeatletter\newenvironment{response}{\textcolor{red}}{}\makeatother
>
> (untested)
Notice also that commands and environments in LaTeX are not
interchangeable; there are things only commands can do and things only
environments can do. (Well, not really - technically, I guess,
environments are strictly more powerful than commands, though I'm not
100% sure - but some things are quite difficult to do with environments
and trivial with commands.)
See also
http://tex.stackexchange.com/questions/102141/what-are-the-consideration-when-choosing-either-newcommand-or-newenvironment
Best,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University
--
Leslie H. Watter
