Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.]

[Vitalie Spinu]

I have elaborated on all these in my other long reply. I would just conclude
here that because both calculate-indent-function and prog-indentation-context
try to solve same problem, they are bound to have overlapping parts. It's just
that calculate-indent-function is more general, easier to understand for prog
authors and it solves three problems at once - replacement of
indent-line-function, removing extra prog-indentation-context/prog-widen and not
exposing multi-mode complexities.

Note also that the intention of the `hard-widen-limit` is to make it work
seamlessly for all existing code that use widen. While prog-indentation-context
requires to teach every mode out there to use prog-widen instead of widen. This
doesn't sound right at all.

  Vitalie


>> On Mon, Mar 21 2016 10:02, Stefan Monnier wrote:

>> Note that I don't mind FIRST-COLUMN functionality. I think it's harmless and
>> probably useful. I mostly mind the last two arguments of
>> prog-indentation-context.

> OK, so you're OK with FIRST-COLUMN.  The last two args are:
> - (START . END), which you actually do want, except you want to store it
>   in hard-widen-limit.  I'm OK with storing it elsewhere.
> - PREVIOUS-CHUNKS.  It can be a string, in which case it's just like your
>   STRING-BEFORE.  So your main issues with it are either that you don't
>   want to allow it to be a function, or that you want to store/pas it in
>   a different way, right?

>>> Almost all of them care whether the current line contains }, or `end', or
>>> `else', and so on.
>> Indeed. But this information is trivial to retrieve from STRING-AFTER.

> In the case of SMIE, it would probably not be too difficult to adjust it
> so it can work with STRING-AFTER, tho I definitely wouldn't call it
> trivial to implement the case of "END END END aligns with the matching
> outer BEGIN" which is currently supported (and was default until 24.5 or
> so).

> But I must say that I don't understand why you need this
> STRING-AFTER thingy.  Isn't that text already right there in the buffer?

> E.g. in prog-indentation-context, we do have something equivalent to
> hard-widen-limit and to STRING-BEFORE but we have nothing like
> STRING-AFTER: the indentation code is expected to get that info by
> looking at the buffer after point.

>         Stefan