tarao/multi-mode-util

Default highlighting not working?

jeroenk opened this issue · 6 comments

jeroenk commented

Following the example in the readme, I defined the following

(defun pytml-mode ()
  "Treat the current buffer as a pytml buffer."
  (interactive)
  (multi-mode-init 'html-mode)
  (multi-install-chunk-finder "<?python" "?>" 'python-mode))

If I M-x pytml-mode after loading a file, this works perfectly. However, if I add

(setq auto-mode-alist (cons '("\\.pytml$" . pytml-mode) auto-mode-alist))

to my .emacs the html parts of the files with extension pytml no longer highlight properly, only the python parts are properly highlighted. Am I doing something wrong, or is there a bug or limitation somewhere? I'm using Emacs 23.3.1.

tarao commented

The problem seems to be caused by jit-lock-mode (a just-in-time font-lock mode), which is not supported by multi-mode.el. For now, disabling the just-in-time fontification feature is the only way to fix the problem but this will slow down syntax highlighting especially on a large file.

You can add

(setq font-lock-support-mode nil)

to your .emacs to disable just-in-time fontification.

I will try to add jit-lock-mode support in multi-mode-util.el.

jeroenk commented

Thank for your answer! I'm only editing small files, so this is a pretty good work-around. This is not something I would have figured out with my limited knowledge of font-lock-mode.

Just a small glitch (maybe). To make the highlighting work properly, it does seem I have to reverse two lines in the above code. The following gives me proper highlighting (while the code in my original issue does not):

(defun pytml-mode ()
  "Treat the current buffer as a pytml buffer."
  (interactive)
  (multi-install-chunk-finder "<?python" "?>" 'python-mode)
  (multi-mode-init 'html-mode))

Please close this issue at your discretion.

tarao commented

Futher investigation revealed that multi-mode.el DOES support jit-lock-mode and what preventing jit-lock-mode from fontifying properly was the value of inhibit-eval-during-redisplay, which was set to be t in multi-mode-util.el to suppress annoying error messages.

I changed the default behavior not to set inhibit-eval-during-redisplay to t in commit f3cb231. You don't need (setq font-lock-support-mode nil) anymore to make the highlighting properly but it becomes to output "Error during redisplay: (args-out-of-range ...)" to *Messages* buffer many times. This annoying message seems to be due to a jit-lock-mode bug which is already patched in the latest version of Emacs. I'm sure that the message doesn't appear in Emacs 24.

If you still prefer non-jit-lock fontification and suppressing the annoying message,

(setq font-lock-support-mode nil)
(setq multi-mode-util-inhibit-eval-during-redisplay t)

will make it exactly the same behavior as before commit f3cb231.

jeroenk commented

Thanks for looking further into this. I don't see the error messages in the Messages buffer, but as I said above I'm using 23.3.1.

I noticed one other weird thing: If I open one of my "pytml" files it seems to create a lock file (symbolic link from #.filename.pytml to something with my user name and machine name in it). That's not weird by itself, but what is weird is that if immediately exit emacs without doing anything, then the lock file is not removed. Any idea what is causing this?

tarao commented

I don't see the error messages in the Messages buffer, but as I said above I'm using 23.3.1.

That's good! I was worrying whether the error messages appear in the latest Emacs since I could have tested only on 23.1.1 for Emacs 23.

If I open one of my "pytml" files it seems to create a lock file

This should be fiexed in commit e13aeaa. It was caused by possibly a bug of Emacs: restore-buffer-modified-p function does not respect indirect buffers. I wrote an advice to patch it up.

jeroenk commented

Work perfectly. Thanks!