[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: font-lock-syntactic-keywords obsolet?
From: |
Dmitry Gutov |
Subject: |
Re: font-lock-syntactic-keywords obsolet? |
Date: |
Sun, 10 Jul 2016 05:01:55 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:47.0) Gecko/20100101 Thunderbird/47.0 |
Hi Alan,
Sorry for the late response.
On 06/30/2016 12:52 PM, Alan Mackenzie wrote:
So now the raw strings are properly using limits? Does that mean there
is a limit on the length of a raw string that CC Mode supports? (Testing
indicates so).
There isn't any limit on the length of a raw string that I know about,
nor should there be. If you've got a test which shows there is such a
limit, please tell me about it!
Hmm, maybe not a limit, but long raw strings still aren't getting
handled right.
Example 1:
- Apply the attached patch to xdisp.c, which should make most of the
code belong within the raw string literal.
- Visit this file. Switch to c++-mode.
- See the literal highlighted as expected.
Press `M->', to get to the end of the buffer (that happens rather
slowly, esp. considering we're inside a string, and font-lock can get
this information quickly).
The literal ends at )foo".
- Modify the trailing "foo" piece: delete it, or replace with "bar", etc
=> the literal still ends at the same line.
I have to go back to the opener and fiddle with the delimiter there, for
it to finally notice that something is wrong.
If the raw string is small, on the other hand, I don't see this problem.
Example 2:
- Visit this file. Switch to c++-mode.
- See the literal highlighted as expected.
- M->.
Kill the closing delimiter and paste it a few lines below the opening
delimiter. See the new positions of the raw string recognized (or not,
I'm getting different results). But if they are recognized...
- Call `undo' a few times, until the closing delimiter is back at its
original position. The literal is broken again.
The "limit" in my previous post was a bound supplied as an argument to
c-font-lock-declarators, which does what it says.
I'm confused. If, as we discussed before, syntax properties are applied
in before/after-functions, why does c-font-lock-declarations need to be
concerned with scanning for raw string bounds?
c++-raw-string-example.diff
Description: Text Data
- Re: font-lock-syntactic-keywords obsolet?,
Dmitry Gutov <=