Hi Nicolas,
Nicolas Goaziou <n.goaz...@gmail.com> writes: > Ok then another binding. I still think freeing "," key is the best thing > to do. More on this below. Users will still be able to use the "," so this will not really fix the issue. >> 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...): > > * H1 > > ** H11 > > #+begin_example > ** H12 > #+end_example > > 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. I got your point, but "broken" is contextual. The fact that (org-in-block-p '("src")) returns a non-nil value in #+begin_src org ** H12 #+end_src is not wrong in the context of checking whether a speed command should be prevented or not. It might be wrong in other contexts, but for this purpose it is not. That's similar to TAB, which comma-escapes the content of the block instead of cycling through the folding states, because it knows it is in a src block. > 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. Yes. But it is not because the cursor is at the beginning of a headline that every function should behave the same. TAB does not, speed commands do not either. > 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). Btw, can you think of cases where it would be nice to have `org-element-context' check against a wider context than the closest one? -- Bastien