Re: [O] Inserting a comma as prefix of headlines (in Org code blocks)

[Nicolas Goaziou]

Hello,

Bastien <address@hidden> writes:

> "#" is already taken, for comments.

Ok then another binding. I still think freeing "," key is the best thing
to do. More on this below.

> I think "," is good for priorities, and that preventing speed commands
> in the several blocks is safe and non-intrusive, that's what my patch
> did. Let me know if you (strongly) think otherwise!

Well, yes, I strongly think otherwise.

Your patch is relying on `org-in-block-p', which is completely broken in
this situation.

The fact is that any strictly positive number of "*" at column
0 followed by a space define a headline, whatever the context is. In
other words, headlines have precedence over every other construct in Org
syntax. 

It's not about the parser. Every low level Org command (and most of the
high level too) assume, and have always assumed, this. For example, try
to cycle visibility in the following example (or move forward
heading...):

--8<---------------cut here---------------start------------->8---
* H1

** H11

#+begin_example
** H12
#+end_example
--8<---------------cut here---------------end--------------->8---

So, we have to make this point clear once and for all. Otherwise, we
should as well re-implement all functions working on headlines, because
if we accept that (org-in-block-p '("example")) returns a non-nil value
in the previous example, they become all wrong.

Therefore, "** H12" is a headline, and it is to be expected that speed
commands are triggered when point is on column 0. So my suggested
solution for the problem at hand is to simply avoid using "," in speed
keys, since "," is also used to protect headlines in blocks.

Let me stress this again:

  1. "stars + space" at column 0 define a headline. No exception. Most
     of Org code (reasonably) assumes this, so we should not let users
     think otherwise.

  2. Do not rely on `org-in-block-p'. Please use `org-element-at-point'
     or `org-element-context' instead. These are not broken, and they
     are fast enough for any interactive use (but let's not use them for
     fontification yet).


Regards,

-- 
Nicolas Goaziou