After a bit of investigation, it seems that wallyqs implementation of
ob-racket does not treat/manage :prologue arguments correctly, which
is worrying because I would assume that the semantics for how prologue
works should not be something that could be accidentally broken by
ob-* implementations (
Hah, this is what I get for not reading carefully enough. I wonder if
it is possible to stick <> in the prologue and have it
expand.
On Fri, Aug 7, 2020 at 9:18 PM Tom Gillespie wrote:
>
> I don't see a direct answer to the original question in the thread, so
> here is an example of how I do it t
I don't see a direct answer to the original question in the thread, so
here is an example of how I do it taken from
https://raw.githubusercontent.com/SciCrunch/sparc-curation/master/docs/developer-guide.org.
You can ctrl-f for racket-graph-helper to see the relevant blocks. A
reduced version is bel
Is there a straightforward way to have a multiline prologue? Or maybe use
the body of named block as prologue?
On Fri, Aug 7, 2020 at 5:02 PM William McCoy wrote:
> Yes, of course, that was it! I ran into that issue a few months ago and
> then I forgot about again!
>
> Thanks both for your help
Yes, of course, that was it! I ran into that issue a few months ago and
then I forgot about again!
Thanks both for your help!
Bill
On 8/7/20 5:25 PM, Berry, Charles wrote:
Good catch. Also it works if you put the property block at the very beginning
of the file.
This sometimes helps:
M-x
Good catch. Also it works if you put the property block at the very beginning
of the file.
This sometimes helps:
M-x org-lint RET
which in this case reports "Incorrect contents for PROPERTIES drawer"
which is a bit cryptic IMO, but does point to any issue with the property.
HTH,
Chuck
> On
It works here if you remove the blank line between the headline
and the PROPERTIES block.
William McCoy writes:
Chuck,
Thanks very much for your response. I didn't know about those
options. When I
use C-c C-v C-i, I get the following:
Lang: python
Properties:
:header-argsnil
Hi.
I have some example
Here the in org, the source code:
#+NAME: secuencia_1
#+ATTR_LATEX: :width 0.6
#+BEGIN_SRC plantuml :file ./img/secuencia_1.png
actor Usuario
Usuario -> Computador : iniciar programa
Computador -> Usuario : pedir nombre
Usuario -> Computador : entregar nombre
Computador -
I can't figure this one out. Let's say I have a table in an Org file, like so:
# -
* Primes
#+NAME: test_table
| number | prime |
|+---|
| two| yes |
| three | yes |
| four | no|
# -
In another file, I want to bring this table into a source block as a varia
Chuck,
Thanks very much for your response. I didn't know about those options.
When I use C-c C-v C-i, I get the following:
Lang: python
Properties:
:header-args nil
:header-args:python nil
Header Arguments:
:cache no
:exports code
:hlines no
> On Aug 7, 2020, at 8:39 AM, William McCoy wrote:
>
> This use of :prologue appeared to me to be very useful. But for some reason
> when I try it out it does not work for me. I just get a message that the
> code block produced no output and that 'np' is not defined. Just to check,
> whe
This use of :prologue appeared to me to be very useful. But for some
reason when I try it out it does not work for me. I just get a message
that the code block produced no output and that 'np' is not defined.
Just to check, when I put the import statements directly within my code
block it wo
Kyle Meyer writes:
> Kévin Le Gouguec writes:
>
>> Since 27.1-rc1 is out, I'd like to bump this; it'd be a shame if 27.1
>> shipped with this bug, which seems to be getting some attention (I just
>> spotted a Reddit thread[1] about it, in addition to the original report
>> on Debbugs).
>
> In the
Hi,
I'm using clocking within org mode.
I feel the rounding of the clock-in/out is not working correctly.
E.g. if I'm clocked-in in one task and the time is 9:29
Then I clock in to another task
The clock-in time of the new taks will jump to 9:25 (rounding-down)
The clock-out time of the old task w
On Thursday, 6 Aug 2020 at 14:35, Bo Grimes wrote:
> It feels to me like this should be possible because syntax
> highlighting mixes colors.
hi-lock-mode may do what the OP wanted with some careful insertion of
tags in the document, maybe in the form of comment lines.
--
: Eric S Fraga via Emac
15 matches
Mail list logo