Can't make universal class work from python-mode on Emacs 26.3

[ssb22]

Hi, I installed mmm-mode 20200705.2339 from Melpa on GNU Emacs 26.3 installed by dnf on Fedora 32, and I tried it by embedding some XML in a Python script and delimiting it for mmm-mode's "universal" class:

my_xml_document = r"""{%xml-mode%}<?xml version="1.0" encoding="utf-8"?>
<doc><elem attr="value">hi there</elem></doc>
{%/xml-mode%}""".replace("{%"+"xml-mode}","").replace("{%/"+"xml-mode}","")
# Local Variables:
# mode: python
# mmm-classes: (universal)
# eval: (if (condition-case nil (require 'mmm-mode) (error nil)) (mmm-mode-on))
# End:

When I loaded this file, Emacs set the XML string to a different background but did not fontify anything (although fontify was turned on), and Emacs gave me the following message in the minibuffer:

File local-variables error: (wrong-type-argument number-or-marker-p nil)

The same thing happened when I did package-delete on mmm-mode and asked the package manager to install the older version 0.5.8 from gnu. So I tried changing the xml-mode to sgml-mode and got this:

File local-variables error: (wrong-type-argument stringp (sgml-xml-mode XML SGML))

So to make sure it wasn't some problem in my .emacs files, I tried:

EMACSLOADPATH=$HOME/.emacs.d/elpa/mmm-mode-0.5.8: emacs -q test.py

and this time:

• with xml-mode it partially fontified the XML string, didn't fontify the surrounding Python, and still displayed the "wrong-type-argument number-or-marker-p nil" message in the minibuffer;
• with sgml-mode or html-mode it completely fontified the XML string, only partially fontified the surrounding Python but didn't display any errors;

and when I installed the Melpa package again and ran:

EMACSLOADPATH=$HOME/.emacs.d/elpa/mmm-mode-20200705.2339 emacs -q test.py

I got exactly the same result as above, for each of the 3 cases.

The same thing happened when I omitted the -mode part of {%xml-mode%} etc and just wrote things like {%xml%}.

So I tried js-mode:

my_javascript_code = r"""{%js-mode%}function(){var e=45; "hi there"}
{%/js-mode%}"""

and this time there was no error message, the surrounding Python was fontified, but the Javascript was not fontified.

So I tried c-mode:

my_c_code = r"""{%c-mode%}#include <stdio.h>
main() { puts("hi"); }
{%/c-mode%}"""

and I got the "wrong-type-argument stringp nil" error again, and fontification was incomplete.

So to try to give us some idea of where that "wrong-type-argument" message is coming from, I wrapped the call to mmm-mode-on in a debug-on-error:

(let ((debug-on-error t)) (mmm-mode-on))

and I got this:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  looking-at(nil)
  c-forward-decl-or-cast-1(0 top nil)
  #f(compiled-function (match-pos inside-macro &optional toplev) #<bytecode 0x10dc699>)(0 nil t)
  c-find-decl-spots(112 "[[:alpha:]_]" nil #f(compiled-function (match-pos inside-macro &optional toplev) #<bytecode 0x10dc699>))
  c-font-lock-declarations(112)
  font-lock-fontify-keywords-region(1 112 nil)
  font-lock-default-fontify-region(1 112 nil)
  c-font-lock-fontify-region(27 69 nil)
  #f(compiled-function (reg) #<bytecode 0x10192f9>)((27 69 #<overlay from 27 to 69 in test.py>))
  mapc(#f(compiled-function (reg) #<bytecode 0x10192f9>) ((27 69 #<overlay from 27 to 69 in test.py>)))
  mmm-fontify-region-list(c-mode ((27 69 #<overlay from 27 to 69 in test.py>)) 1 289)
  #f(compiled-function (elt) #<bytecode 0x1019ad5>)((c-mode (27 69 #<overlay from 27 to 69 in test.py>)))
  mapc(#f(compiled-function (elt) #<bytecode 0x1019ad5>) ((c-mode (27 69 #<overlay from 27 to 69 in test.py>)) (python-mode (1 27 nil) (69 289 nil))))
  mmm-fontify-region(1 289 nil)
  font-lock-fontify-region(1 289)
  font-lock-after-change-function(1 289)
  font-lock-flush(1 289)
  mmm-refontify-maybe(1 289)
  mmm-apply-all()
  mmm-mode-on()
  (let ((debug-on-error t)) (mmm-mode-on))
  (if (condition-case nil (require (quote mmm-mode)) (error nil)) (let ((debug-on-error t)) (mmm-mode-on)))
  eval((if (condition-case nil (require (quote mmm-mode)) (error nil)) (let ((debug-on-error t)) (mmm-mode-on))))
  hack-one-local-variable(eval (if (condition-case nil (require (quote mmm-mode)) (error nil)) (let ((debug-on-error t)) (mmm-mode-on))))
  hack-local-variables-apply()
  hack-local-variables(no-mode)
  run-mode-hooks(python-mode-hook)
  python-mode()
  set-auto-mode-0(python-mode nil)
  set-auto-mode()
  normal-mode(t)
  after-find-file(nil t)
  find-file-noselect-1(#<buffer test.py> "/tmp/test.py" nil nil "/tmp/test.py" (189262 49))
  find-file-noselect("/tmp/test.py")
  #f(compiled-function (displayable-buffers dir line column name) #<bytecode 0x1e786f>)((nil) "/tmp/" (0) (0) "test.py")
  command-line-1(("test.py"))
  command-line()
  normal-top-level()

which looks as if there's some bad interaction going on between the fontify code of the different modes involved. I don't know how to fix this.

[dgutov]

Hi!

Regarding the first example, I've pushed a fix for nxml-mode. Let's see how it goes, on the first glance it seems to be working, but since it generally expects the full control of the buffer, as well as valid XML, you'll probably encounter other cases where it causes problems. But that depends on your usage. Generally, I'd recommend sgml-mode. And when I try it here, I don't see the error you described (with Emacs 27 or 26.3).

c-mode is an old pain. I'm not able to debug it to the necessary extent, and it changes often enough to make any support broken over time. So it's unlikely to work. js-mode should, however.

[dgutov]

I can repro js-mode's lack of syntax highlighting here. Can't see the reason for it, will have to continue the investigation later.