Re: [Orgmode] Re: Debugger entered--Lisp error: (void-function -mode)

[Eric Schulte]

Hi,

Does this error still exist?  If so could you send a small example
org-mode file which reproduces the problem?

Thanks, and my apologies if such an example has already been shared with
the list -- Eric

Sébastien Vauban <address@hidden> writes:

> Hi David,
>
> David Maus wrote:
>> Sébastien Vauban wrote:
>
> Thanks a lot for looking at this, really!
>
>>> When having the following code in any Org page, I now have an error 
>>> generated.
>>> 
>>> - If the code is in a =begin_src html= block, no problem.
>>> - If between a =begin_html=, see what I get.
>>> 
>>> * Some code
>>> 
>>> #+begin_html
>>> <script type="text/javascript" src="jquery-1.4.4.min.js"></script>
>>> <script type="text/javascript">
>>> $(document).ready(function () {
>>> $('<a class="backtotop" href="#top">^</a>')
>>>     .insertAfter('h2');
>>> $('<a id="top"></a>')
>>>     .prependTo('body');
>>> });
>>> </script>
>>> #+end_html
>>> 
>>> * Debug info
>>> 
>>> #+begin_src emacs-lisp
>>> Debugger entered--Lisp error: (void-function -mode)
>>>   -mode()
>>>   funcall(-mode)
>>>   (if (eq major-mode lang-mode) nil (funcall lang-mode))
>>>   (unless (eq major-mode lang-mode) (funcall lang-mode))
>>>   (save-current-buffer (set-buffer (get-buffer-create ...)) (delete-region 
>>> (point-min) (point-max)) (insert string) (unless (eq major-mode lang-mode) 
>>> (funcall lang-mode)) (font-lock-fontify-buffer) (setq pos (point-min)) 
>>> (while (setq next ...) (put-text-property ... ... ... ... org-buffer) (setq 
>>> pos next)))
>>>   (with-current-buffer (get-buffer-create (concat " org-src-fontification:" 
>>> ...)) (delete-region (point-min) (point-max)) (insert string) (unless (eq 
>>> major-mode lang-mode) (funcall lang-mode)) (font-lock-fontify-buffer) (setq 
>>> pos (point-min)) (while (setq next ...) (put-text-property ... ... ... ... 
>>> org-buffer) (setq pos next)))
>>>   (let* ((lang-mode ...) (string ...) (modified ...) (org-buffer ...) pos 
>>> next) (remove-text-properties start end (quote ...)) (with-current-buffer 
>>> (get-buffer-create ...) (delete-region ... ...) (insert string) (unless ... 
>>> ...) (font-lock-fontify-buffer) (setq pos ...) (while ... ... ...)) 
>>> (add-text-properties start end (quote ...)) (set-buffer-modified-p 
>>> modified))
>>>   org-src-font-lock-fontify-block("" 27 287)
>>> #+end_src
>>> 
>>> I don't understand why. Maybe it will ring a bell to you?
>>
>> I cannot reproduce this on
>>
>>
>> Org-mode version 7.3 (release_7.3.123.g950be)
>>
>> GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.1) of
>>  2010-11-03 on potassium, modified by Debian
>>
>> It looks like some problem with the font-locking: I suspect you have
>> `org-fontify-natively' set to a non-nil value and for whatever reason
>> Org tries to fontify the #+begin_html as a source block with the
>> language beeing the empty string.
>
> I was testing some patches both from Eric and Dan (about native
> fontification)...
>
> I've pulled a new version, temporarily setting the patches aside, as I needed
> to be able to export. Since then, I don't have the problem anymore.
>
>
>> I have no idea about how font-locking works, but one thing for sure:
>> The regexp in `org-fontify-meta-lines-in-blocks' does match
>> a #+begin_html statement and the matching group used to determine the
>> language (it's 7) returns an empty string.
>
> That looks like the explanation of what I observed. Do I understand you
> correctly if I read that the regexp should be patched to be more restrictive?
>
> Best regards,
>   Seb