From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [BUG] Unmatched #+end-src Date: Thu, 17 Mar 2011 13:09:04 +0100 Message-ID: <87mxku7xun.fsf@gmail.com> References: <87ei6cffbw.fsf@btinternet.com> <87bp1gw1a4.fsf@gmail.com> <87d3lwkq1v.fsf@btinternet.com> <877hc3x3md.fsf@gmail.com> <87ipvnyvtb.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from [140.186.70.92] (port=33844 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q0C1H-0002Ru-W5 for emacs-orgmode@gnu.org; Thu, 17 Mar 2011 08:09:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q0C1G-0002lj-37 for emacs-orgmode@gnu.org; Thu, 17 Mar 2011 08:09:35 -0400 Received: from mail-bw0-f41.google.com ([209.85.214.41]:56440) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q0C1F-0002lG-NB for emacs-orgmode@gnu.org; Thu, 17 Mar 2011 08:09:34 -0400 Received: by bwz17 with SMTP id 17so2668741bwz.0 for ; Thu, 17 Mar 2011 05:09:32 -0700 (PDT) In-Reply-To: <87ipvnyvtb.fsf@gmail.com> (Eric Schulte's message of "Sun, 13 Mar 2011 07:49:36 -0600") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Eric Schulte Cc: Martyn Jago , emacs-orgmode@gnu.org --=-=-= Content-Type: text/plain Hello, "Eric Schulte" writes: >> The real problem is: how should Org react when parsing syntactically >> erroneous buffers? I concede that freezing Emacs isn't nice, but otoh, >> code can't deal with every possible user error. >> >> So, what is the expected behavior here? Consider orphan #+end_ as >> normal text, throw an error, or both? An answer to this question would >> be more useful than code, honestly. >> > > This is just opinion and gut reaction, but my first instinct is to say > that Org just treat an orphan #+end_ as normal text (or technically as > an Org-mode comment). > > The same is true for a floating #+begin_src. Until the block is closed, > it is just a comment. As it's the only answer so far, I guess it was more trivial than I thought. Here is a patch that should fix the original problem. Martyn, as you are writing tests, would you mind running it against them, before I apply it? Many thanks in advance. Regards, --=-=-= Content-Type: text/plain Content-Disposition: inline; filename=0001-org-list-fix-infinite-loop-on-erroneous-block-and-dr.patch Content-Description: patch infloop with erroneous constructs >From 805e11e419c58a9f3fdb470987056c5ac970817f Mon Sep 17 00:00:00 2001 From: Nicolas Goaziou Date: Thu, 17 Mar 2011 13:01:06 +0100 Subject: [PATCH] org-list: fix infinite loop on erroneous block and drawer constructs * lisp/org-list.el (org-list-struct,org-in-item-p): don't assume end of blocks or drawers necessarily start somewhere. It it isn't the case, treat them as normal text. --- lisp/org-list.el | 24 ++++++++++++------------ 1 files changed, 12 insertions(+), 12 deletions(-) diff --git a/lisp/org-list.el b/lisp/org-list.el index aea8634..8bfd359 100644 --- a/lisp/org-list.el +++ b/lisp/org-list.el @@ -465,10 +465,10 @@ This checks `org-list-ending-method'." (looking-at org-list-end-re)) (throw 'exit nil)) ;; Skip blocks, drawers, inline-tasks, blank lines - ((looking-at "^[ \t]*#\\+end_") - (re-search-backward "^[ \t]*#\\+begin_" nil t)) - ((looking-at "^[ \t]*:END:") - (re-search-backward org-drawer-regexp nil t) + ((and (looking-at "^[ \t]*#\\+end_") + (re-search-backward "^[ \t]*#\\+begin_" lim-up t))) + ((and (looking-at "^[ \t]*:END:") + (re-search-backward org-drawer-regexp lim-up t)) (beginning-of-line)) ((and inlinetask-re (looking-at inlinetask-re)) (org-inlinetask-goto-beginning) @@ -686,10 +686,10 @@ Assume point is at an item." (memq (assq (car beg-cell) itm-lst) itm-lst)))) ;; Skip blocks, drawers, inline tasks, blank lines ;; along the way. - ((looking-at "^[ \t]*#\\+end_") - (re-search-backward "^[ \t]*#\\+begin_" nil t)) - ((looking-at "^[ \t]*:END:") - (re-search-backward drawers-re nil t) + ((and (looking-at "^[ \t]*#\\+end_") + (re-search-backward "^[ \t]*#\\+begin_" lim-up t))) + ((and (looking-at "^[ \t]*:END:") + (re-search-backward drawers-re lim-up t)) (beginning-of-line)) ((and inlinetask-re (looking-at inlinetask-re)) (org-inlinetask-goto-beginning) @@ -753,11 +753,11 @@ Assume point is at an item." (throw 'exit (push (cons 0 (point)) end-lst-2))) ;; Skip blocks, drawers, inline tasks and blank lines ;; along the way - ((looking-at "^[ \t]*#\\+begin_") - (re-search-forward "^[ \t]*#\\+end_") + ((and (looking-at "^[ \t]*#\\+begin_") + (re-search-forward "^[ \t]*#\\+end_" lim-down t)) (forward-line 1)) - ((looking-at drawers-re) - (re-search-forward "^[ \t]*:END:" nil t) + ((and (looking-at drawers-re) + (re-search-forward "^[ \t]*:END:" lim-down t)) (forward-line 1)) ((and inlinetask-re (looking-at inlinetask-re)) (org-inlinetask-goto-end)) -- 1.7.4.1 --=-=-= Content-Type: text/plain -- Nicolas Goaziou --=-=-=--