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

["Andreas Röhler" <andreas.roehler@online.de>]

On 21.03.2016 06:05, Vitalie Spinu wrote:
>
>>> On Sun, Mar 20 2016 23:11, Stefan Monnier wrote:
>>> BTW, I parse-partial-sexp must abide hard-widen-limits as well.
>> I don't understand what this means.  parse-partial-sexp is passed
>> 2 locations and it works between them.  There's not much opportunity
>> for widening.
> parse-partial-sexp should work between hard limits (at least the lower
> bound). It should operate as if hard-narrowed buffer is the real buffer.
>
> So ideally it should take (max FROM (car hard-widen-limits)) as the starting
> position. This will give the desired consistency between parse-partial-sexp and
> syntax-ppss with the price of slightly modifying the semantics of
> parse-partial-sexp in a backward compatible way.
>
>>> A patch that would require hunting every single mode out there and
>>> implementing multi-modes locally should have been more carefully
>>> considered IMO.
>> I must say I don't understand how what we have is so very different from
>> what you suggest.
> It's quite a bit different:
>
>    - Major mode authors won't need to know about multi-modes. That means not
>      dealing with chunks/spans/headers etc. These concepts are not even uniformly
>      defined between existing multi-mode engines.
>    
>    - Major mode authors won't need to re-implement the indentation logic already
>      there in multi-modes. The logic is likely to be too simplistic and major
>      mode authors will have to re-do it anyways.
>
>    - Setup is more general. multi-mode engine decides where to call
>      calculate-indent-function and with what parameters and with what narrowing.
>
>    - Arguably calculate-indent-function is a simpler concept to grasp
>
>    - calculate-indent-function is needed anyways
>
>> I think both suggestions require changes to every mode, and in both cases the
>> changes can be reduced to a one-liner or close enough (for the simple
>> case). Admittedly, for it to be a one-liner, we'll need to provide a standard
>> helper function.
> Judging from python.el it might be quite hard to provide a generic one liner to
> deal with all those 3 elements. For calculate-indent-function instead you can
> provide a straightforward one line assuming that STRING-BEFORE/AFTER do not
> matter.
>
>
>    Vitalie
>

+1