Hello,
Martin Carlé writes:
> Keeping the tags is actually crucial to my practice, since I run some
> filters during export based on tags.
>
> Couldn't the algorithm be adopted to check for tags assigned to the
> org-footnote-section and then re-create them as well?
Footnote section is special,
Hello,
David Jacobs writes:
> The following example shows how renaming the ITEM column in column view
> causes the parent heading to show up. Anyone know how to fix this?
>
> ** Bad Summary
> #+BEGIN: columnview :skip-empty-rows t :id "bad"
> | Name | Nick |
> |---
Hello,
Thomas S. Dye writes:
> Exporting these two special blocks to LaTeX
>
> ,--
> | #+name: eq:foobar
> | #+begin_equation
> | foo = bar
> | #+end_equation
> |
> | #+begin_equation
> | bar = baz
> | #+end_equation
> `--
Hello,
Andreas Reuleaux writes:
> I have been using Julien Danjou's org-contacts for a while now,
> cf
>
> http://orgmode.org/worg/org-contrib/
> org-contacts.el – manage contacts
> Written by Julien Danjou. Link to raw file.
> https://julien.danjou.info/projects/emacs-packages#org-co
Hello,
Aaron Miller writes:
> Can you provide some insight on why the behavior was changed?
You needed to conform your labels to the target language, i.e, make sure
the label didn't contain any forbidden characters, which you were
expected to know.
`org-latex-prefer-user-labels' explains it ve
Dear Nicolas!
On Wed, Feb 24, 2016 at 06:38:09PM +0100, Nicolas Goaziou wrote:
> Hello,
>
> Josef Atmin writes:
>
> >> when a shell command in an unnumbered list includes '::', it is not
> >> recognized as a shell
> >> command anymore.
> >>
> >> To reproduce the bug, paste the following two l
Thanks for inviting me to elaborate.
Well, I wrapped the exporter mechanism into some advice functions that
allow for many different exports from a single file in such a manner that
multiple exports are not restricted to subtrees.
This extended export mechanism collects sections as marked by tags
Aloha Nicolas,
Nicolas Goaziou writes:
>>
>> The blank line after \label{orgspecialblock1} causes the equation number
>> to be set on the following line, rather than to the right of the
>> equation. My expectation is there is no blank line after the \label,
>> which yields the desired behavior.
>
Nicolas Goaziou wrote:
> Skip Collins writes:
> > Org throws an error when I export html with a link type that it does
> > not know about. I would like it to simply add the link to the exported
> > document without checking its validity. For example, I have a link
> > that, when tapped on an iPho
This seems a catch-22: I want to render code in an org-mode export (html or
latex pdf) where the snippet below done as a ~code block
> (cons 1 nil) \to (1)
actually renders \to as a proper right arrow (yields). Of course if I do
the snippet as inline latex
$> (cons 1 nil) \to (1)$
I get the pro
Aloha Lawrence,
Lawrence Bottorff writes:
> This seems a catch-22: I want to render code in an org-mode export (html or
> latex pdf) where the snippet below done as a ~code block
>
>> (cons 1 nil) \to (1)
>
> actually renders \to as a proper right arrow (yields). Of course if I do the
> snippet a
Got it set
(custom-set-variables ... '(org-pretty-entities t) ...
but nothing changed. ~> (cons 1 nil) \to (1)~ still outputs the raw \to
even though in the buffer it changes.
On Sat, Feb 27, 2016 at 8:41 PM, Thomas S. Dye wrote:
> Aloha Lawrence,
>
> Lawrence Bottorff writes:
>
> > This seems
Nicolas Goaziou writes:
> It looks like a lexical binding problem. We switched "org.el" to lexical
> binding in development version. You may be having a mixed installation,
> somehow.
>
> Regards,
Ah, OK, thanks a lot (and as already answered in private e-mail):
I will take a closer look at my i
I have the following org file:
--8<---cut here---start->8---
#+BEGIN_SRC python :exports both
import numpy as np
return np.matrix([[.123456789, 2], [3, 4]])
#+END_SRC
#+RESULTS:
| 0.12345679 | 2 |
| 3 | 4 |
--8<---cut here-
Hello,
Josef Atmin writes:
> Well, one could also say [[shell:cat ~/tmp | grep "asdf :: "]] is link
> syntax, no matter how you look at it. It is a question of precedence.
Of course. I'm just telling you how Org sees it.
> I think it is more obvious to interpret
>
>* [[ ... :: ... ]]
Hello,
Martin Carlé writes:
> Well, I wrapped the exporter mechanism into some advice functions that
> allow for many different exports from a single file in such a manner that
> multiple exports are not restricted to subtrees.
Not sure to understand this.
> This extended export mechanism coll
16 matches
Mail list logo
