Frequent font-lock glitches, especially when opening a file

[bronger]

I observe incomplete syntax highlighting when using mmm-mode for having reStructuredText in Python docstrings, embedded into otherwise Python files. If I revert the buffer, those glitches are healed in most cases. I attached a screenshot where in the second plot_url, only t_url is correctly highlighted.

And idea how such a thing can be debugged?

[purcell]

I know that @dgutov has provided tips in past issues, so perhaps look for similar ones. In general there's a wide range of "cheating" things that major modes can do which stop them from working smoothly with mmm-mode, e.g. assumptions about parse state and buffer extents.

[dgutov]

I suggest you check out https://github.com/purcell/mmm-mode/blob/master/mmm-erb.el#L86-L98 and see whether a similar derived mode for Python is appropriate.

Or use mmm-after-syntax-propertize-functions is a similar fashion inside python-mode-hook.

In short: when two major modes' syntax definitions conflict, it's helpful to specifically annotate certain characters inside the "inner" regions as . (punctuation). Those characters which otherwise confuse the outer mode's indentation and font-lock.

[dgutov]

You didn't post the configuration used, though. Or an example file. So the problem could be different and solvable in some easier way.

[bronger]

I fear that this is difficult to reproduce, even if I share my complete configuration (or a minimal example thereof). FWIW, the directly involved part in my .emacs is:

(require 'mmm-mode)
(setq mmm-global-mode 'maybe)
(mmm-add-classes
 '((python-rst
    :submode rst-mode
    :front "^ *\"\"\"\\b"
    :back "^ *\"\"\"$"
    :include-front nil
    :include-back nil
    :end-not-begin t)))
(mmm-add-mode-ext-class 'python-mode nil 'python-rst)

My docstring layout in Python files is like this one:

def myfun():
    """Hello, I’m a docstring.
    """
    ...

That’s why I asked for the best way to debug oneself, as I have no error message currently.

[dgutov]

Try adding

(setq mmm-parse-when-idle t)

Does that decrease the glitches, or make it worse?

[bronger]

This does not change anything noticeable. Interestingly enough, I activated this option (with delay 0.2), visited a totally misformatted part of my file, inserted a letter, waited, but nothing happened. A revert-buffer afterwards corrected the formatting successfully. Strange.

[dgutov]

This does not change anything noticeable. Interestingly enough, I activated this option (with delay 0.2), visited a totally misformatted part of my file, inserted a letter, waited, but nothing happened.

Did you try putting that line in your init script? It only takes effect when the minor mode function is running.

A revert-buffer would do that too, though (that command re-enables all appropriate major and minor modes).

[bronger]

Did you try putting that line in your init script? It only takes effect when the minor mode function is running.

I put it in my .emacs immediately after the other mm-mode-related commands.

[dgutov]

OK, how hard is it to reproduce?

A repro is: a sample file (in text, the shorter the better) and some example steps to see the problem.

[bronger]

I admit that I must make this issue actionable. I will create a minimal example soon, hoping that it’s not too much dependent on races that only happen on some computers.

[snogge]

I've also seen this with my bitbake-mode https://bitbucket.org/olanilsson/bitbake-modes/src/master/bitbake-mmm.el .
There is some weird stuff in that file that needs to be cleaned out, but the mmm-classes work.
Trying to debug this with something like font-lock-studio always show that it is not a problem with the font-lock rules of the outer mode. It has never bothered me enough to investigate further, and I don't have any 100% reproducible case either.

[dgutov]

The outer mode's font-lock may work fine, it's usually the conflict between the syntaxes of the major modes which can create problems.

Does by any chance the patch in #112 (comment) fix that behavior for you?