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

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>> 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.

You mean it should ignore the current (user)narrowing?  Why?
I'd think that if something needs to ignore the (user)narrowing it'd be
parse-partial-sexp's *caller* but not parse-partial-sexp itself.

> So ideally it should take (max FROM (car hard-widen-limits)) as the starting
> position.

You mean: as opposed to (max FROM (point-min))?

I disagree.  Functions should usually not accept to talk about positions
outside of the point-min/max range.

Notice how syntax-ppss is different in this regard: since it doesn't
receive FROM, that same rule doesn't prevent syntax-ppss from widening
to (car hard-widen-limits).

> 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.

I'd be curious to know in which circumstances (i.e. specific code in
specific packages) this would make a difference.  As mentioned above,
I think these cases would be better fixed by changing the calling code
to perform widening before calling parse-partial-sexp.

>>> A patch that would require hunting every single mode out there and
>>> implementing multi-modes locally should have been more carefully
>>> considered IMO.

>   - 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.

I understand that's your claim, but I don't understand why/how this is
different between the two proposals.

>   - 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.

Same here.

>   - Arguably calculate-indent-function is a simpler concept to grasp

As mentioned, I fully agree with the need to replace
indent-line-function with calculate-indent-function (tho I like to name
it prog-indent-function).  So the difference is w.r.t your
STRONG-BEFORE/AFTER: which code provides them, which code obeys them,
and how that compares to the way prog-indentation-context is provided
and obeyed.

>> 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.

My hunch is that if STRING-BEFORE/AFTER don't matter, then it should not
be hard to come up with a generic function in prog.el which can be
invoked with a one liner in the major mode (assuming the major mode
sets (prog|calculate)-indent-function).


        Stefan