[Top][All Lists]

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

Re: forward-comment and syntax-ppss

From: Dmitry Gutov
Subject: Re: forward-comment and syntax-ppss
Date: Fri, 16 Dec 2016 03:33:45 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Thunderbird/50.0

On 11.12.2016 12:17, Alan Mackenzie wrote:

I don't think this is an issue.  (syntax-ppss-1 POS), when
new-local-variable is non-nil simulates (parse-partial-sexp
new-local-variable POS), and the latter would throw an error for
precisely the same values of POS as the former.

Indeed, but this way the first argument will be implicit, and, unlike point-min, often non-obvious to the code calling syntax-ppss. It's easy to produce a buffer position lower than the arbitrary value of the new variable. It's harder to produce a buffer position lower than point-min.

Anyway, it's a minor issue. A good error message should be sufficient.

Maybe, but these changes are the direct desired effect of narrowing.
They're not nasty unforeseen side effects.

"nasty" or "unforeseen" is beside the point. Like described previously, some code doesn't really know how to behave in the face of narrowing if the user's intent that resulted in narrowing, isn't known.

In particular, it doesn't change things like
whether a particular buffer position is inside a string.

Not every buffer position is unequivocally "inside a strong" or not.

Take this example.

// Here's a string: "abc".

Is abc inside a string? That depends on what exactly we mean by that,
for a given use case.

That may be the case, but that has nothing to do with what I said ("In
particular, it doesn't change ....").  Whether abc is inside a string or
not doesn't vary by the narrowing.  It's determined by other factors.

It can be determined by the narrowing (i.e. a function named `inside-a-string?' could confidently know whether to rely on the current narrowing or ignore it, to produce its result, if narrowing were annotated with intent).

In particular, I was thinking of what I think is
called "hard widening".  I think it would be a mistake to add this
feature.  At the moment, narrowing is a strong, direct, simple facility
- it does what it says it does and no more.

From where I'm standing, the things you use it for (hide buffer contents) can be implemented in a much better fashion using overlays with invisibility (in fact, one such implementation exists already), which don't introduce the difficulties of changing point-min and point-max. Thus, without making things harder for many other facilities.

Were "hard widening" to be
introduced, we could easily end up with a confused mess of `widen' and
`hard-widen' through the code, with nobody being quite sure which one to
use and why.  There might be lots of depressing errors where the wrong
one is used.

These are issues of design and documentation. The previous discussions of hard-widen didn't come up with any real conceptual problems. Just with low-level implementation ones.

More importantly, any change you would make to the "new" function you
could make to syntax-ppss instead.

The new function would be a different function, i.e. it would have a
different definition.  Just for clarity, it would not be written from
scratch, it would be based on the current syntax-ppss.

And then it would be utterly useless for third-party code, for years to come. Further, if it uses a separate variable for its cache, and the new function is used in the code, while the old function continues to be used by third-party code (and also stable packages like Gnus and CC-Mode) for compatibility reasons, we'll have two syntax caches that will interact in fascinating, difficult to predict ways.

Am I interpreting your intention correctly?

Further, the good part of this proposal is more or less equivalent to
"indexing syntax-ppss cache by point-min" as proposed by Stefan.

I think I agree here.  But "good part" implies the existence of a "less
good part".  What, in your view, constitues this "less good part"?

Well... both your and Stefan's proposals will end up actually having to maintain the index of syntax-ppss caches, and having to invalidate those values somehow. I'm sure it's possible to arrive at a satisfactory algorithm (like only keeping around two values, for point-min equal to 1 and the most recent other value), but there must be use cases which some other invalidation approach would be better.

With syntax-ppss-dont-widen, the caller code can take the responsibility of maintaining the values of syntax-ppss-cache and syntax-ppss-last. And it turns out, it's rather easy to bind them to nil around the same pieces of code that starts with (save-restriction (narrow-to-region ...)). Which currently seems to give the same result as the idea in the previous paragraph, with much less code.

In short, letting the caller code control cache invalidation has its benefits.

reply via email to

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