GNU bug report logs - #23501
Non-regex-based syntax highlighting

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Stefan Kangas <stefan <at> marxist.se>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#23501: closed (Non-regex-based syntax highlighting)
Date: Wed, 12 Aug 2020 02:32:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Tue, 11 Aug 2020 19:31:07 -0700
with message-id <CADwFkmkpW4Koi56FHS+d5gxZzU3fGRgEhC-8D6jhFbdzn21stQ <at> mail.gmail.com>
and subject line Re: bug#23501: Non-regex-based syntax highlighting
has caused the debbugs.gnu.org bug report #23501,
regarding Non-regex-based syntax highlighting
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
23501: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23501
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Nir Friedman <quicknir <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Non-regex-based syntax highlighting
Date: Mon, 9 May 2016 23:12:47 -0400

[Message part 3 (text/plain, inline)]

I'm considering using emacs as a platform for C++ development. One thing
that seems to lag behind on emacs at the moment is that all of the syntax
highlighting for C++ is (as far as I can tell) regex based. This severely
limits the accuracy and discrimination that the syntax highlighter can
achieve. There are now some packages for emacs that use a clang based
backends to get actual AST information. Perhaps it would be possible to
write some kind of hooks or template for major modes that would make it
easier for package authors to change how syntax highlighting is performed
in major modes?

[Message part 4 (text/html, inline)]

[Message part 5 (message/rfc822, inline)]

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Nir Friedman <quicknir <at> gmail.com>, 23501-done <at> debbugs.gnu.org
Subject: Re: bug#23501: Non-regex-based syntax highlighting
Date: Tue, 11 Aug 2020 19:31:07 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Nir Friedman <quicknir <at> gmail.com>
>> Date: Tue, 10 May 2016 16:16:03 -0400
>> Cc: 23501 <at> debbugs.gnu.org
>>
>> My idea for a hook was basically to make it possible to provide a callback function to the Major mode. If this
>> callback function is provided, then when a new file is loaded or an existing one saved with modifications, the
>> callback function is called with the full path to the file.
>
> The syntax highlighting should change also when you modify the buffer,
> not only when you save it.  How will that work with your proposed hook?
>
>> The callback function must return something that
>> basically tells the major mode how to color everything. A simple way would just be to return a list of the colors
>> for every single non-whitespace character taken sequentially. A single very fast pass through this list would
>> then be able to color every character.
>
> The hook cannot return a color, because the colors are defined via
> faces.  It should return faces instead.
>
>> Is there a reason why that would not be workable?
>
> Maybe it is workable, but you are missing too many details of how
> syntax highlight works in Emacs.  As I wrote previously, I encourage
> you to study how that works, in order for the proposal to be workable
> and practical.
>
>> Also, can you point me to where exactly (e.g. via link to the
>> emacs github mirror) the major modes are stored?
>
> It's not the major mode that you need to look at, it's the font-lock
> machinery.  Major modes just use the font-lock features by setting the
> font-lock faces on portions of the buffer.  Then at display time, the
> visible portion of the buffer are displayed as specified by those
> faces.  You will see that each major mode simply sets the font-lock
> faces, and leaves the rest to the core features.
>
> See font-lock.el and font-core.el for the font-lock features, and
> jit-lock.el for the JIT coloring of the visible portions of the
> buffer.

It seems like there was a proposal here 4 years ago, that Eli said was
unworkable.  There were also some outstanding questions regarding said
proposal.  But there were no further updates after that.

I'm therefore closing this bug report now.  If anyone wants to continue
working on something along these lines, feel free to reopen this bug
report or file a new one.

Thanks.

Best regards,
Stefan Kangas

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.