From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: Inserting a comma as prefix of headlines (in Org code blocks) Date: Wed, 27 Feb 2013 23:55:49 +0100 Message-ID: <878v69nz7u.fsf@bzg.ath.cx> References: <86fw0i9lu4.fsf@somewhere.org> <87sj4irt1y.fsf@gmail.com> <87r4k2eyub.fsf@bzg.ath.cx> <87obf5syru.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:40343) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UApv2-0007l5-Pg for emacs-orgmode@gnu.org; Wed, 27 Feb 2013 17:56:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UApv1-0004a2-N2 for emacs-orgmode@gnu.org; Wed, 27 Feb 2013 17:56:12 -0500 Received: from plane.gmane.org ([80.91.229.3]:46703) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UApv1-0004Zg-Fn for emacs-orgmode@gnu.org; Wed, 27 Feb 2013 17:56:11 -0500 Received: from public by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UApvE-0000Wt-LM for emacs-orgmode@gnu.org; Wed, 27 Feb 2013 23:56:24 +0100 In-Reply-To: <87obf5syru.fsf@gmail.com> (Nicolas Goaziou's message of "Wed, 27 Feb 2013 13:54:13 +0100") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Nicolas Goaziou Cc: public-emacs-orgmode-mXXj517/zsQ@plane.gmane.org, Sebastien Vauban Hi Nicolas, Nicolas Goaziou 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