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

[Stefan Monnier]

> 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