[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: Andreas Röhler
Subject: Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.]
Date: Mon, 21 Mar 2016 08:13:17 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Icedove/38.5.0

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