emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[O] Re: [BUG] Unmatched #+end-src


From: Nicolas
Subject: [O] Re: [BUG] Unmatched #+end-src
Date: Sun, 13 Mar 2011 01:31:38 +0100

Hello,

Martyn Jago <address@hidden> writes:

> I've supplied a patch which passes all of my tests, but I will look at
> providing additional tests looking at other cases within this loop since
> I'm currently in the habit of writing tests anyway.

Your patch has the same weakness as the previous one and I explained
why. For example, in the following example, calling (org-in-item-p) with
point anywhere on line "some text" will return nil, which is obviously
wrong.

- item 1
  #+end_
  some text
- item 2

Actually, it is not a matter of patch, which is just changing

#+begin_src emacs-lisp
((looking-at "^[ \t]*#\\+end_")
 (re-search-backward "^[ \t]*#\\+begin_" nil t))
#+end_src

into

#+begin_src emacs-lisp
((and (looking-at "^[ \t]*#\\+end_")
      (re-search-backward "^[ \t]*#\\+begin_" nil t)))
#+end_src

once for blocks and once for drawers, in both org-in-item-p and
org-list-struct.


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.

I hope I am clearer now.

Regards,

-- 
Nicolas



reply via email to

[Prev in Thread] Current Thread [Next in Thread]