Re: web-mode.el

[Dmitry Gutov]

Stefan Monnier <address@hidden> writes:
>> I'm also using narrowing during indentation, but some modes (like js)
>> use (widen) in indent-line-function. It should be somewhat fixable by
>
> I don't think it's worthwhile trying to make a "multi-major-mode" that
> works with any major mode, no matter what wicked thing it does.
> So it's OK to impose a few conventions that the major mode needs
> to obey.  The important and difficult part is to figure what those
> conventions need to be.

I agree in principle. And since fontification of chunks can already be
done reliably enough (if not with best performance), I think indentation
function conventions would be more important. Shall we start with
collecting cases?

So far I have two problems without obvious solutions:

1) js-mode uses (widen) at the beginning of js-indent-line, and then calls
(syntax-ppss).

2) sgml-indent-line calls sgml-parse-tag-backward, which does
(re-search-backward "[<>]"), finds "<" and performs simple regexp check.
Thus, <% if a < 3 %> breaks indentation on following lines, until first
closing tag.

So it's 3 built-in functions as candidates for special interaction
with new syntax-table value.

> Of course, tweaking some parts of the C mode might help.  E.g. we could
> maybe extend syntax-tables slightly so that chunk boundaries are marked
> with a special syntax-table value which then makes forward-comment skip
> over "other language" chunks, so that any indentation code which
> consistently ignores comments would then work in multi-major-mode.

Did you mean to write "C code" in the first sentence?

As far as I can see, enhanced (forward-comment) won't help much with
indentation.

And crossing two boundaries won't necessarily mean that we're in a chunk
in the same mode (or we're limited to supporting only two modes in the
same buffer), so that means syntax-table values can't be trivial.
Cons cell (mode-above . mode-below), and related code will need
to consider movement direction?