Apply classes 10 times or less

[charJe]

Before each class was only applied once. Now each class will be
applied over and over again until either all classes do not create new
regions or each class has tried 10 times. 10 is an arbitrary limit; I
just figured that it was as good as any limit.

This is to solve #113.

[charJe]

Upon further testing, this is not a full solution to nesting. It updates mmm-current-submode flawlessly (I wonder if this can be used to our advantage), but with enough edits to the buffer, mmm-mode will stop using the keymap and the font-locking for the submode.

[dgutov]

Is that with (setq mmm-parse-when-idle t)?

[charJe]

It can be t or nil. Mode specialization last slightly longer with t. I have also tried periodically calling mmm-update-submode-region, but it seems to have no effect.

[dgutov]

Could be a general bug in this package.

If you could show a semi-reliable repro, at least, I'll make sure to look into it.

[charJe]

I really appreciate it. By semi-reliable repo do you mean containing samples?

[dgutov]

Some example and a scenario I could reproduce locally.

[charJe]

My mistake. I just realized what is causing this and it is a completely unrelated thing. This pull request is not the problem at all.

[charJe]

In case anyone is interested. The problem was caused by programatically calling

(progn
  (mmm-update-current-submode)
  mmm-current-submode)

in order to get the current submode. My somewhat of a solution is to call (overlay-get (mmm-overlay-at) 'mmm-mode) instead.

[charJe]

I you would still like some samples: there is retro-games and the sample code from #114.
Here is a sample table that has a fair amount of nesting:

<table>
  <thead>
    <tr>
      ,@(mapcar
         (lambda (head)
           <th>,(progn head)</th>)
         (enumerate (car rows)))
    </tr>
  </thead>
  <tbody>
    ,@(mapcar
       (lambda (row)
         <tr>
           ,@(mapcar
              (lambda (column)
                <td>
                  ,(progn column)
                </td>)
              row)
         </tr>)
       rows)
  </tbody>
</table>

[dgutov]

Yeah, having a call to (mmm-update-current-submode) at a different position and then failing to call it again at the current position can break some things. This hasn't really come up as a problem before, but there are some possible mitigations we could add to mmm-mode to decrease the odds of this kind of problem.