Re: antlr-mode.el - need some support by python.el

[Dmitry Gutov]

On 02/19/2015 03:18 PM, Stefan Monnier wrote:

> Could be.  But using `widen' is a simple solution to those problems
> (until you bump into problematic cases like Rmail and Info where
> `widen' ends up widening too much).

Maybe, whenever `widen' is required, the original caller is doing 
something wrong. The only valid use for `widen' is to undo the "visual" 
sort of narrowing, enacted by the user interactively. If that feature 
ever gets removed, I won't shed a tear.

> BTW, a good start might be for someone to sit down and design a sane
> way for narrow and syntax-ppss to interact.  If that includes a cleanish
> way to support multiple modes, then it's even better.

My first reaction to this: invalidate the cache more often. Like if the 
cached entry is for the position above point-min, don't use it, and 
calculate the state starting from point-min. This way `syntax-ppss' will 
remain a good substitute for `parse-partial-sexp'.

But then, do we allow it to add entries to cache (and save 
syntax-ppss-last), when narrowed? What will happen if syntax-pps is 
called without narrowing, after these entries are added? To keep ideal 
results, we'd have to save syntax-ppss-point-min-last, as well as 
include point-min in the cache entries, and invalidate the latter 
whenever it doesn't match.

And I'm pretty sure, in this scenario, the cached entries from submode 
regions won't ever be useful in the primary region, nor a cache entry 
from one submode region will be useful in another. So we could as well 
discard them, and discard syntax-ppss-last after we leave (in a way 
dependent on the task we've using syntax-ppss for) the subregion.

On the other hand, as long as narrowing is only used locally (within, 
say, `save-restriction'), the same function might as well bind 
`syntax-ppss-last' and `syntax-ppss-cache' to nil, so that multiple 
calls to `syntax-ppss' within the narrowing are still quick (that's 
important if the function in question is 
font-lock-fontify-region-function; a "composite" one, if we're 
discussing the multiple-mode case), but after we're done, nothing is 
remembered.

The previously mentioned idea of adding a variable like 
syntax-ppss-function will help a lot more in the situation when there's 
no narrowing, and we need to compute the accurate level of nesting in 
the primary mode (or, to complicate everything by an order of magnitude, 
when we're in a region that itself has subregions, but I digress). To 
ignore several regions within, for the purposes of syntax-ppss.

`add-function' could even be used instead of the new variable.

To sum up:

- Strong transient narrowing solves a class of problems.
- Anyone doing it might have to take care of syntax-ppss cache (binding 
two vars to nil isn't hard).
- The effect of persistent narrowing (one that lives between command 
invocations) should be only visual (the rest of the buffer contents are 
not displayed). Alternatively, if we're worried about editing commands 
changing text beyond the visible area, it should be made read-only. Or 
we just keep the current narrowing mechanism for visual purposes, and 
avoid using it outside of interactive commands. Or remove it entirely, 
like mentioned above.

> > Not really. The leftmost-col avoidance scheme I described further on would
> > deal with latex as submode just fine.
>
> Still: why do you want to avoid LEFTMOST-COL at all?

I don't mind it that much, rather I'd like to avoid the variable 
submode-indentation-context. If prog-indent-calculate-function gets 
passed LEFTMOST-COL instead of nothing, that can work well.

Benefits:

- Since the value is passed to the function, the implementors are more 
likely to pay attention and include it in the calculation.

- It's somewhat more likely that they get it right. That nil is returned 
in all top-level places, is much harder to test interactively.

The one con, I guess, is a bit more complicated API.

> I don't see how that influences the usefulness (or not) for
> LEFTMOST-COL.

Um yeah, it's irrelevant.