emacs-devel
[Top][All Lists]
Advanced

[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 18:15:29 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Icedove/38.5.0



On 21.03.2016 16:06, Stefan Monnier wrote:
I have elaborated on all these in my other long reply. I would just
conclude here that because both calculate-indent-function and
prog-indentation-context try to solve same problem, they are bound to
have overlapping parts. It's just that calculate-indent-function is
more general, easier to understand for prog authors and it solves
three problems at once - replacement of indent-line-function, removing
extra prog-indentation-context/prog-widen and not exposing
multi-mode complexities.
STRING-BEFORE/STRING-AFTER/PREVIOUS-CHUNKS look like the main complexity
(from smie.el's point of view, they all seem pretty painful to support).

Would expect that.



Note also that the intention of the `hard-widen-limit` is to make it
work seamlessly for all existing code that use widen.  While
prog-indentation-context requires to teach every mode out there to use
prog-widen instead of widen. This doesn't sound right at all.
The reason is that your suggestion risks breaking code since it changes
the behavior of `widen'.

Maybe the breakage would be extremely limited or even not exist at all,
in which case the tradeoff is probably worth it.  My gut feeling is that
it's too risky, but that's just my gut feeling.

Note also that most modes don't bother using widen, and search&replace
is pretty easy to do.  But if my fear is unfounded, then indeed it's
better to just change `widen' directly.


         Stefan



What about if going back and reflect from the starting point, if a well defined result of narrowing would be the best - without changing code in core at all?

When it narrows from midst of a sexp, its beginning is missing, okay. Where is the problem? If this wasn't wanted, the narrowing was wrong. No need to fix this from Emacs side.

Sorry, should I not have understood what's at stake...








reply via email to

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