|Subject:||bug#22983: syntax-ppss returns wrong result.|
|Date:||Fri, 8 Sep 2017 18:04:37 +0200|
|User-agent:||Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.2.1|
On 07.09.2017 22:45, Alan Mackenzie wrote:
Hello, John. On Tue, Sep 05, 2017 at 13:28:52 +0100, John Wiegley wrote:Dmitry Gutov <address@hidden> writes:I'm sure we want to fix design flaws. As long as there is a solid plan that does not swap one flaw for another.Can we have a summary of the current proposal(s) on the table? It would help to clarify, rather than navigating past discussions. Alan has told me that this issue is affecting people and has been outstanding for some time; I'd like to get a better idea of its seriousness/scope, and what effect the available solutions would have (as Dmitry says, we don't want to replace one flaw with another).First, I think it's worthwhile emphasising what the function purports to do: syntax-ppss is a compiled Lisp function in `syntax.el'. (syntax-ppss &optional POS) Parse-Partial-Sexp State at POS, defaulting to point. The returned value is the same as that of `parse-partial-sexp' run from `point-min' to POS except that values at positions 2 and 6 in the returned list (counting from 0) cannot be relied upon. Point is at POS when this function returns. The solution I propose is to introduce a second cache into syntax-ppss, and this cache would be used whenever (not (eq (point-min) 1)). Whenever point-min changes, and isn't 1, this second cached would be calculated again from scratch. This proposal has these advantages: (i) It would make the function deliver what its unchanged doc string says. This is important, given that syntax-ppss has been very widely used within Emacs, and likely by external packages too; these will typically have assumed the advertised behaviour of the function, without having tested it in narrowed buffers. (i) In the case which currently works, namely a non-narrowed buffer, there would be only a minute slow-down (basically, there would be extra code to check point-min and select the cache to use). (ii) The cache for use in a narrowed buffer might well be sufficiently fast in normal use. If it is not, it could be enhanced readily. I think Dmitry also proposed a method of solution some months ago, though I don't remember in detail what it was. Dmitry, do you still think your solution would work? If so, please elaborate on it.-- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
Hi Alan and all,
assume a complex matter behind, a bunch of bugs resp. design issues, not a single one.
Fixing this would affect syntax-propertize, parse-partial-sexp, syntax-ppss and font-lock stuff at once.
points at some spot. There should be more.
As a first step listing referential tests including benchmarks should be helpful.
|[Prev in Thread]||Current Thread||[Next in Thread]|