[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Something like #+BIND but for the destination buffer

From: Jonas Bernoulli
Subject: Re: [O] Something like #+BIND but for the destination buffer
Date: Sat, 14 Jan 2017 18:47:40 +0100

I did notice myself that the two-space indentation for blocks that are part of a list element are reserved and also that one can do what you are suggesting here to keep the code-block as part of the list item while at the same time not get those two extra spaces. (By the way, I don't like that work-around.)

However for me that's what happened for example blocks only. For source blocks I got an additional five spaces, for which I found no explanation. (The only indentation in the Org source before the code-block lines are the two part-of-a-list-element spaces.)

On Sat, Jan 14, 2017 at 3:46 PM, Nicolas Goaziou <address@hidden> wrote:

Jonas Bernoulli <address@hidden> writes:

> This seemed promising at first but let to all kinds of strange behavior.
> Code-blocks that are part of a list item turned out to particularly
> painful, as here "Finally, you can use ‘-i’ to preserve the indentation of
> a specific code block" means that an additional five (if I remember
> correctly) spaces appear out of nowhere (only for code-blocks,
> example-blocks behaved as expected (or at least in an reasonable
> way)).

With -i, indentation is taken from column 0, so the five spaces didn't
come out of nowhere, but probably from the indentation you gave to the
contents of the source block, which is not necessary. E.g.,

- Some list item

  #+BEGIN_SRC emacs-lisp -i
This is the code, and it will not break list


Nicolas Goaziou

reply via email to

[Prev in Thread] Current Thread [Next in Thread]