Hello,
Martyn Jago <martyn.j...@btinternet.com> 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
