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

[Vitalie Spinu]

>> On Mon, Mar 21 2016 13:47, Dmitry Gutov wrote:

> On 03/21/2016 03:05 AM, Vitalie Spinu wrote:
>>
>>>> On Sun, Mar 20 2016 17:58, Dmitry Gutov wrote:
>>
>>
>> The inner mode cannot often make that decision either.

> What decision? 

Decision of how much to indent. Inner mode just doesn't have a complete picture
of what is going on. Just having access to previous chunk is not enough.

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.

> I'm not claiming that using previous-chunk is good.

Good ;)

>> Instead of teaching modes about multi-modes, a much better idea is to 
>> introduce
>> `calculate-indent-function` which would accept POS and optional STRING-AFTER 
>> and
>> STRING-BEFORE. This function will return the indentation of STRING-AFTER at 
>> POS
>> assuming there is a virtual STRING-BEFORE just before POS.

> Strings? Indentation engines do not deal with strings, they deal with buffer
> contents. Having them handle this possibility would also amount to sharing a
> part of multi-mode logic.

Yeh. That's the sucky part. My hope is that BEFORE-STRING will be seldom
used. Given that this case applies only to continuation chunks and assuming that
multi-mode engine can identify those (at least at multi-mode level) this is a
reasonable trade off IMO. In polymode I haven't even got down to indentation of
continuation chunks yet. They are not that common in literate programming.

Performance is not a primary concern for indentation. Correctness and conceptual
cleanness is at a much higher stake here. My hope is that generic helper
functions can be optimized to re-use same temp buffer for multiple invocations
of calculate-indent-function.

>> Then a lot of modes don't even care about what's in the current line, so
>> STRING-AFTER will be irrelevant as well.

> 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 any case, your hard-narrowing proposal is very similar. Surely you don't 
> want
> to keep the second element of prog-indentation-context after hard-narrowing
> becomes available?

Indeed. I was not thinking about algorithmic complexities.

AFAIK if second element is removed, the third one should go as well. That leaves
only FIRST-COLUMN then, which I personally don't mind.

>> Only consumers of `hard-widen-limits` should be concerned with its side
>> effects. But that's uniformly better than current situation when you cannot 
>> do
>> much about restricting widen.

> OK, so *every* consumer of widen will have to obey the hard limits. That might
> work, if there's no low-level code that absolutely has to always be able to
> widen to the whole buffer.

I think as long as low level code uses BEGV and ZV instead of BEG and Z
everything should be fine. That is with an implicit assumption that hard limits
are always wider than the current visual narrowing which is a reasonable
contract IMO.

Even better, as long as low level routines use BEG and Z consistently (and it
looks like they do) BEG and Z can be modified to take care of
hard-widen-limits. This might be the easiest solution. In any case going through
all C code and checking usage of widen is not such an insurmountable task.

>> BTW, I parse-partial-sexp must abide hard-widen-limits as well.

> If you want parse-partial-sexp to obey limits, you narrow the buffer around 
> it.

>> This way the
>> request aired in bug#22983 of parse-partial-sexp == syntax-ppss will be
>> automatically satisfied. You won't need syntax-ppss-dont-widen either.

> That doesn't seem relevant. That bug is about stale cache values between
> different narrowing bounds.

Right. Those stale values won't occur in multi-modes because both syntax-ppss
and parse-partial-sexp will always operate on same hard-narrowed regions.

  Vitalie