emacs-devel
[Top][All Lists]
Advanced

[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?

Attachment: c++-raw-string-example.diff
Description: Text Data


reply via email to

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