[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss return

From: Vitalie Spinu
Subject: Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.]
Date: Mon, 21 Mar 2016 06:05:26 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.91 (gnu/linux)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]