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: Alan Mackenzie
Subject: Re: font-lock-syntactic-keywords obsolet?
Date: Thu, 30 Jun 2016 09:52:15 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

Hello, Dmitry.

On Wed, Jun 29, 2016 at 03:30:27AM +0300, Dmitry Gutov wrote:
> On 06/23/2016 07:30 PM, Alan Mackenzie wrote:

> > 1)...  There were two functions in cc-fonts.el that were using
> > (point-max) as a limit for something, when they should have been using,
> > respectively, (min limit (point-max)), and limit.  A bit of playing
> > around suggests there is more to fix, there.

> 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!

The "limit" in my previous post was a bound supplied as an argument to
c-font-lock-declarators, which does what it says.  Up till now, that
precise bound wasn't important, since the function stopped anyway when it
reached the end of a (declaration) statement.  But with unterminated raw
strings, that didn't work, and the bound became important.

> Maybe it's not too terrible, but, depending on the limit's value, it 
> could be a problem in certain specialized files (e.g. in a game sources 
> where the author decided to keep some art assets in the code, or in some 
> test files).

> Anyway, that's the performance-vs-correctness tradeoff I've mentioned 
> earlier. Using syntax-propertize-function, I've never seen the necessity 
> to make that choice, so far. And Ruby has several counterparts to C++'s 
> raw strings, all with irregular syntax.

> > 2) ... This was caused by a low level function failing to do
> > (save-match-data ...) around a (looking-at ....) with the result that
> > the match-data was corrupted for the higher level function.  That bug's
> > been there for some while.

> That works now, thanks.

Excellent!

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

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