Henning Redestig <henning....@googlemail.com> wrote:
> Better now but still some issues here, now if I start a new org buffer and
> type
>
> <s [TAB]
>
> to complete the source block, I get org-mode fontification error again.
Probably more off-by-1 errors - the backtrace shows:
,----
|
| Debugger entered--Lisp error: (args-out-of-range 15 25)
| add-text-properties(25 15 (face org-block-end-line))
| (progn (setq end (match-end 0) end1 ....))
| (if (re-search-forward (concat "^[ ]*#\\+end" (match-string 4) "\\>.*")
nil t) (progn (setq end (match-end 0) end1 ...)))
| (when (re-search-forward (concat "^[ ]*#\\+end" (match-string 4)
"\\>.*") nil t) (setq end (match-end 0) end1 ...)))
| ...
| org-fontify-meta-lines-and-blocks-1(24)
| (condition-case nil (org-fontify-meta-lines-and-blocks-1 limit) ((debug
error) (message "org-mode fontification error")))
| org-fontify-meta-lines-and-blocks(24)
| font-lock-fontify-keywords-region(1 24 nil)
| font-lock-default-fontify-region(1 24 nil)
| font-lock-fontify-region(1 24)
| run-hook-with-args(font-lock-fontify-region 1 24)
| byte-code("\302\303 #\207" [start next run-hook-with-args
jit-lock-functions] 4)
| jit-lock-fontify-now(1 501)
| jit-lock-function(1)
`----
so this code is probably at fault:
,----
| ...
| (quoting
| (add-text-properties beg1 (min (point-max) (1+ end1))
| '(face org-block))) ; end of source block
| ((not org-fontify-quote-and-verse-blocks))
| ((string= block-type "quote")
| (add-text-properties beg1 (1+ end1) '(face org-quote)))
| ((string= block-type "verse")
| (add-text-properties beg1 (1+ end1) '(face org-verse))))
| (add-text-properties beg beg1 '(face
org-block-begin-line))
| (add-text-properties (1+ end) (1+ end1) '(face
org-block-end-line)) <<<<<<<<
| ...
`----
In this case, adding 1 to end1 seems to be correct, but adding 1 to end
does not. However, I'm getting more and more worried that fixing things
in this instance might break other situations.
Also, as you can see there are more (1+ end1) instances, which will
probably cause similar problems in other situations: this whole function
could do with a review.
And another point: even though these changes apparently fix these
problems, if there are *other* problems (e.g. the wrong thing fontified,
particularly if the "wrong" thing is displaced one char from the "right"
thing), then these changes are probably wrong and will need some more
complicated solution, perhaps along the lines of Bastien's suggestion
below. So keep an eye out not only for the fontification error message,
but also for wrong fontification in the buffer.
Nick
PS. BTW, here's a debugging hint: getting a backtrace from inside a
condition-case that eats the error required two things: setting
debug-on-error to t and modifying
--8<---------------cut here---------------start------------->8---
(defun org-fontify-meta-lines-and-blocks (limit)
(condition-case nil
(org-fontify-meta-lines-and-blocks-1 limit)
((debug error) (message "org-mode fontification error"))))
--8<---------------cut here---------------end--------------->8---
to add that debug cookie - see the doc for condition-case: C-h f
condition-case RET.
>
> 2012/4/4 Bastien <b...@gnu.org>:
> > Hi Nick,
> >
> > Nick Dokos <nicholas.do...@hp.com> writes:
> >
> >> Confirmed. It only happens when you start typing into an empty buffer.
> >> Looks like an off-by-one error in
> >> org.el:org-fontify-meta-lines-and-blocks-1,
> >> aroung line 5487:
> >>
> >> ,----
> >> | ;; just any other in-buffer setting, but not indented
> >> | (add-text-properties
> >> | beg (1+ (match-end 0))
> >> | '(font-lock-fontified t face org-meta-line))
> >> `----
> >>
> >> The second arg should probably be just (match-end 0).
> >
> > That's correct. I first thought (min (point-max) (1+ (match-end 0)))
> > would have been safer, but I really don't see why the 1+.
> >
> > Please confirm this is fixed.
> >
> > Thanks,
> >
> > --
> > Bastien
>
>
>
> --
> /Henning
>
