bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#22983: syntax-ppss returns wrong result.


From: Dmitry Gutov
Subject: bug#22983: syntax-ppss returns wrong result.
Date: Mon, 14 Mar 2016 02:47:49 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0

On 03/13/2016 08:57 PM, Alan Mackenzie wrote:

I happen to use it frequently.  I expect other users do, to.  It's
useful.

It might be, but it's not very well-designed. If you only want to hide some parts of buffer from being displayed, changing point-min and point-max, which affect quite a lot of Lisp functions, seems unnecessary.

Introducing a couple of global variables that would only be read by the display code, seems like a better approach. I don't think that narrow-to-region should be a user-level function. Introducing a new function, using a different mechanism shouldn't be too hard though, if we reuse the existing binding.

What were
strings and comments before narrowing should remain strings and comments
after narrowing.  Otherwise, nothing would work in such a narrowed
buffer.  font-locking, for example, behaves properly in a narrowed
buffer.

It behaves like we tell it to behave. If I bind font-lock-dont-widen to t, font-lock won't look beyond the narrowing.

Hence, so far, I didn't make any effort to try and "do the right thing"
for user-activated narrowing, since these are just not well defined
enough to even determine what is "the right thing".

Lets define them as I said in the previous paragraph.  Or can you
conceive of a use case where one would want narrowing to invert strings
and non-strings, leaving comments totally random?

At risk of inviting further confusion, yes, mmm-mode and polymode (new example!) use narrowing to persuade font-lock and indentation code that there's nothing beyond the narrowed region. We might declare such usages invalid, and that's a possible choice, but I think keeping support for them wouldn't be too hard, at least for a while.

Note that if your comment cache always widens the buffer before calculating the values to save, its result might conflict with syntax-ppss in mmm-mode and polymode (right?). Leading to font-lock, indentation and certain commands behaving in different, conflicting ways. That's just conjecture at this point, of course.

Do you have any views on how the bug should be resolved?

Stefan probably has another opinion, but I'd either ignore the issue of narrowing, or introduce syntax-ppss-dont-widen like proposed (and thus make syntax-ppss widen by default). Together with adding a command that would replace interactive use of narrow-to-region.





reply via email to

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