special blocks end lists

[m3hgu5t4]

It seems that the blocks created by this package cause lists to stop when exporting, as well as generally leaving empty lines after the content in the exported file. Would it be possible to have the blocks remain inside the list?

An example:

1. builtin block
   #+begin_src latex
   \uline{does not end lists}
   #+end_src
2. org-special-blocks
   #+begin_proposition
   does not end lists
   #+end_proposition
3. org-special-block-extras builtin block
   #+begin_stutter 5
   this ends lists
   #+end_stutter
4. org-special-block-extras custom defblock
   #+begin_thm
   this ends lists
   #+end_thm

becomes

\begin{enumerate}
\item builtin block
\begin{verbatim}
   \uline{does not end lists}
\end{verbatim}
\item org-special-blocks
\begin{proposition}
does not end lists
\end{proposition}
\item org-special-block-extras builtin block
\end{enumerate}

this ends lists

this ends lists

this ends lists

this ends lists

this ends lists

\begin{enumerate}
\item org-special-block-extras custom defblock
\end{enumerate}
\begin{theorem}
this ends lists

\end{theorem}

and similarly in HTML.

[alhassy]

This is a known issue ---I've been meaning to get to it for some time.

Maybe on the weekend I can get to it.

---

The problem seems to lie with org-special-block-extras--support-special-blocks-with-args, which does not save the indentation of a block when insert-ing the block's result.

[m3hgu5t4]

Perhaps this could be solved by indenting the #+begin_export and #+end_export to match the line above/below?

[alhassy]

That was exactly the fix ;-)

Enjoy!

[m3hgu5t4]

Thanks for the update. This seems to fix the issue for blocks inside lists, but unfortunately not for blocks inside lists inside blocks. Would it be possible to instead indent the #+begin/end_export to the level of the #+begin/end_block tags before running the defblock'd function so that lists inside blocks aren't misaligned? Additonally, if you have time, I think de-indenting content before passing to the defblock'd function may make it easier to write a defblock that can be used inside lists.

[alhassy]

You're welcome =)

Hmmm, for blocks inside lists inside blocks I'm gonna need an example ;-)

In general, a block has complete control over its contents and it can decide what to do with inner blocks...

Maybe you want to use defblock not with contents (which does the exports) but instead with raw-contents?

[m3hgu5t4]

For example,

#+begin_stutter 1
1. something\\
   this loses indent
2. something else
   #+begin_remark
   this loses indent
   #+end_remark
3. something else
#+end_stutter
1. something else
   #+begin_remark
   this keeps indent
   #+end_remark

where thm and prf are defblock'd. This becomes

#+begin_export latex 

#+end_export
1. something\\\\
this loses indent
2. something else
#+begin_export latex 
{\\color{black} \\fbox{\\bf [Editor Remark:} 
#+end_export
this loses indent

#+begin_export latex
\\fbox{\\bf ]}}
#+end_export
3. something else

#+begin_export latex

#+end_export
1. something else
   #+begin_export latex 
   {\\color{black} \\fbox{\\bf [Editor Remark:} 
   #+end_export
   this keeps indent

   #+begin_export latex
   \\fbox{\\bf ]}}
   #+end_export

after processing (this was taken from buffer-string at org-export-before-parsing-hook). The (indent-region blk-start (point) blk-column) forces all lines inside the block to have the same indent as the #+begin_block, which breaks lists as well as any other possible formatting requiring indentation. It might be better to instead only change the indent of the #+begin/end_export lines to match the level of the #+begin/end_block line before evaluating the defblock'd function, without affecting the content of the block at all.

[alhassy]

That's a good suggestion ---thank-you! [ If you have edited the relevant code yourself, I'm happy to place it into the source ;-) ]

Would you please provide a more "realistic" use-case for this scenario; I haven't encountered it yet.

[m3hgu5t4]

I've been using this in my notes and this causes issues with things such as multiple-part theorems and lists of propositions containing proofs:

#+begin_props
- \(\Var(X) \geq 0\) and if \(\Var(X) = 0\), then \(\prob[X = {\expec{X}}] = 1\).
- If \(c \in \R\), then \(\Var(cX) = c^2 \Var(X)\).
- \(\Var(X) = \expec{X^2} - \expec{X}^2\)
  #+begin_prf :qed yes
  \begin{align*}
  \Var(X) &= \expec{(X - {\expec{X}})^2}\\
  &= \expec{X^2 - 2X\expec{X} + \expec{X}^2}\\
  &= \expec{X^2} - 2\expec{X}\times\expec{X} + \expec{X}^2\\
  &= \expec{X^2} - \expec{X}^2
  .\end{align*}
  #+end_prf
- \(\Var(X) = \min_{c\in\R}(\expec{(X-c)^2})\) and the minimum is achieved for \(c = \expec{X}\).
  #+begin_prf :qed yes
  Call \(f(c) = \expec{(X-c)^2} = \expec{X^2} - 2c\expec{X} + c^2\)

  Minimise \(f\) to get \(\min(f(c)) = f(\expec{X}) = \Var(X)\).
  #+end_prf
#+end_props

where props and prf just wrap the contents with \begin/\end{proposition/proof} in this case.

I don't think I'm familiar enough with both elisp and the structure of this package to be able to implement the change soon, but I think the change should be to remove the indent-region in 85e1ccd82addd5a1ff45b5488624043d25e262ac and to modify org-export and org-parse to have the #+begin/end_export copy the indent from the line after/before them.

Additionally it would make writing certain types of defblocks easier if, before sending contents, it counted the least indented line inside and deindented every line by that much, reindenting afterwards, so the defblock'd function sees the contents as though they weren't in a list, but this may be too complex or uncommon to reasonably implement.

[alhassy]

Thanks for the example =)

• The prf + align combination is already built-into org-special-block-extras as calc ;-)

• The most recent commit makes some progress, but does not yet fix the problem :'(

  I need to tinker with this a bit more, maybe your suggestion of modifying org-parse is the way to go.

• Regarding the unindentation, do you mean something along the lines of this?

[m3hgu5t4]

• It seems as though the #+begin/end_export blocks around the content which are placed by org-export aren't being indented.
• The unindentation I'm referring to is similar to that, but it seems like it may change relative indents if there's a line in the contents that's less indented than the first line, or otherwise cause issues if there are no indented lines. Ideally it would use the indent level of the least indented nonempty line, so it guarantees that line indents are preserved relative to each other.