On 22/04/24 06:46, emm.charpent...@free.fr wrote:
Inline "throwaway" code : src_emacs-lisp((+ 2 3)). Does*not* work.
The inline code should be enclosed in curly brackets: src_emacs-lisp{(+
2 3)}
> Anyways, before I put this off for much longer, there is some more code
> attached. Live previews (and general environments) work now, and besides
> the above mentioned points there were no new surprises waiting—at least
> for getting the basic functionality to work.
Thank you for the update!
Hi Org folks,
I've noticed that in (org)Literal Examples[0], when documenting the switches
for example and source blocks, it is mentioned that they should be placed at
the *end* of the #+BEGIN line, while both in (org)Structure of Code Blocks[1]
and the Org Syntax document[2] the switches are
to be clear, i am not suggesting violating outline mode's inability to
continue text after children, or violating levels. let me redo.
i am ONLY saying i sometimes have the need to yank into the middle of the
text of an entry, even if what i am yanking is an entry.
it was probalby confusing
not sure i am fully following but it seems useful.
i thought i would report on a use case thtat might or might not be
relevant. it seems so.
i often have
===
* heading 1
text of heading 1
* heading 2
text of heading 2
|
and more text
===
where | just shows where i want to yank.
and i want to
On Tue, Apr 09 2024 22:06, Tony Zorman wrote:
> As a very brief summary, one currently needs to—in addition to supplying
> a preamble and a way to recognise maths and environments—patch the
> following functions:
>
> · org-latex-preview--place-from-elements
> ·
I'd have sworn that org could evaluate inline "throwaway" code. But I seem to
be mistaken.
The following :
#+options: toc:nil author:nil
For the life of me, I can't explain this:
#+name: foo
#+begin_src emacs-lisp :exports code
Morgan Smith writes:
>> It is the time to refactor this function yet again.
>> (a tricky endeavour considering all the edge cases we can encounter when
>> there are changes in buffer while `org-element-cache-map' is mapping
>> over it).
>
> See attached for a way to break :from-pos as well. I
Ihor Radchenko writes:
>
> Hmm. :after-element keyword logic is broken. It does not account for the
> case when :after-element is past the START point.
>
> It is the time to refactor this function yet again.
> (a tricky endeavour considering all the edge cases we can encounter when
> there are
Hi Ihor,
On Sun, 21 Apr 2024 at 15:20, Ihor Radchenko wrote:
> Pedro Andres Aranda Gutierrez writes:
>
> > +: #+cite_export: biblatex backend=bibtex,style=numeric
>
> What about something like
>
> #+cite_export: biblatex backend=bibtex,bibstyle=numeric
>
Just tested on a work document. It
On Sat, 18 Nov 2023 16:54:39 +0100 Max Nikulin wrote ---
> Hi,
>
> Trying to figure out the origin of the confusion with
> "bash -c bash /path/to/file-containing-the-source-code.sh"
> I have faced an inconsistency with :cmdline treatment in ob-shell.el. I
> expect same results in
Dear Ihor,
you mean like this?
>From 1c7bee53ac91a8296c144f157ab8646b1a7a6595 Mon Sep 17 00:00:00 2001
From: Alexander Gogl
Date: Wed, 17 Apr 2024 16:00:41 +0200
Subject: [PATCH] added option to customize latex footnote command in export
---
etc/ORG-NEWS | 4
lisp/ox-latex.el | 14
Alexander Gogl writes:
> I have tested the global and buffer local options with kaoscript and the
> article class. I could't find any problems with the option. Labels and
> footnotes inside footnotes work.
>
> The current version of the patch (fixed a typo) is attached.
Thanks!
May you please
Alexander Adolf writes:
> Ah, `org-column--clean-item'; well spotted!
>
> Two observations:
>
> 1) As is now, I'm generating the links in the data collection function
>`org-columns--capture-view'. As `org-column--clean-item' is called
>from code that runs after the data collection,
>
Pedro Andres Aranda Gutierrez writes:
> +: #+cite_export: biblatex backend=bibtex,style=numeric
What about something like
#+cite_export: biblatex backend=bibtex,bibstyle=numeric
> BTW, I was thinking that maybe "\\`[^=]+=" may be better than matching
> style= anywhere in the options string...
Max Nikulin writes:
>> I have no clue about the rationale of this special behaviour - it dates
>> back to the days when Org export was merged. It is also not documented
>> anywhere, AFAIK.
>
> I would not expect that the space after the following export snippet is
> ignored in the case of
Philipp Kiefer writes:
> To be honest, I don't see much need for fine-grained special cases. I'd
> be very happy with C-u yanking at the level of the heading at point and
> C-u C-u yanking at one level below that, regardless of the exact
> position of point. I realize that would mean C-u
Morgan Smith writes:
> So I found another bug in `org-element-cache-map'.
>
> Executing the following code just freezes up. I am struggling to work
> through the logic of `org-element-cache-map'. If no-one else magically
> solves my issues, I'll figure it out eventually. But I would
Ihor Radchenko writes:
> Upon further examination, I found that ^:{} does accept _only_ curly
> braces:
> ...
> So, round braces can be seen as another variant of DWIM behavior.
>
> I conclude that there is no reason to change the existing syntax.
>
> I will need to update
Hi Pedro,
dear community,
I have tested the global and buffer local options with kaoscript and the
article class. I could't find any problems with the option. Labels and
footnotes inside footnotes work.
The current version of the patch (fixed a typo) is attached.
>From
20 matches
Mail list logo
