Nicolas Goaziou <n.goaz...@gmail.com> writes: > Hello, > > Eric Abrahamsen <e...@ericabrahamsen.net> writes: > >> While editing a plain list yesterday I noticed what I guess was a bug in >> the caching mechanism. > > It looks like it, indeed. > >> The list item was wrapped to several lines, and I noticed that calling >> C-e while on the last line gave me "wrong-type-argument >> integer-or-marker-p nil". Trying to fill the item with M-q gave me >> "user-error: An element cannot be parsed line 635". > > [...] > > Unfortunately, the source of the cache corruption may be totally > unrelated to the action triggering the error. Thus, cache bugs are quite > hard to reproduce. When hunting down one of them, I usually call the > following function after each non-trivial buffer modification. > > (defun ngz-random-test (&optional n contextp) > (save-excursion > (dotimes (k (or n 100)) > (goto-char (1+ (random (point-max)))) > (let ((real-element (let (org-element-use-cache) > (if contextp (org-element-context) > (org-element-at-point))))) > (or (equal real-element > (if contextp (org-element-context) > (org-element-at-point))) > (message "`%s' at %d is corrupted." > (org-element-type real-element) > (org-element-property :begin real-element))))))) > > BTW, is your Org recent? I fixed a similar problem (i.e. cache > corruption in lists) about two weeks ago in commit > 4466af5c115b56377d7251e848860dc03212c583.
Yes, it's up to date -- after I sent this message I started wondering if it had been a while since I updated, so I pulled and reloaded, and not long after that saw the bug again. I expect to see this again, so I can run the function above, but will reporting the results be of any use to you? If I know which element is corrupted, what should I be reporting back? E
