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

[Nicolas]

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