[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#22983: syntax-ppss returns wrong result.
From: |
Alan Mackenzie |
Subject: |
bug#22983: syntax-ppss returns wrong result. |
Date: |
Thu, 7 Sep 2017 20:45:02 +0000 |
User-agent: |
Mutt/1.7.2 (2016-11-26) |
Hello, John.
On Tue, Sep 05, 2017 at 13:28:52 +0100, John Wiegley wrote:
> >>>>> Dmitry Gutov <dgutov@yandex.ru> 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
--
Alan Mackenzie (Nuremberg, Germany).
- bug#22983: syntax-ppss returns wrong result., Eli Zaretskii, 2017/09/02
- bug#22983: syntax-ppss returns wrong result., Alan Mackenzie, 2017/09/02
- bug#22983: syntax-ppss returns wrong result., Eli Zaretskii, 2017/09/02
- bug#22983: syntax-ppss returns wrong result., John Wiegley, 2017/09/04
- bug#22983: syntax-ppss returns wrong result., Dmitry Gutov, 2017/09/04
- bug#22983: syntax-ppss returns wrong result., Dmitry Gutov, 2017/09/09
- bug#22983: syntax-ppss returns wrong result., Alan Mackenzie, 2017/09/09
- bug#22983: syntax-ppss returns wrong result., Dmitry Gutov, 2017/09/09
- bug#22983: syntax-ppss returns wrong result., Alan Mackenzie, 2017/09/10
- bug#22983: [ Patch ] Re: bug#22983: syntax-ppss returns wrong result., Alan Mackenzie, 2017/09/10
- bug#22983: [ Patch ] Re: bug#22983: syntax-ppss returns wrong result., Stefan Monnier, 2017/09/10
- bug#22983: [ Patch ] Re: bug#22983: syntax-ppss returns wrong result., Dmitry Gutov, 2017/09/10
- bug#22983: [ Patch ] Re: bug#22983: syntax-ppss returns wrong result., Stefan Monnier, 2017/09/11