all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Theodor Thornhill via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>, casouri@gmail.com
Cc: 64818@debbugs.gnu.org, dianchengwang@gmail.com
Subject: bug#64818: 30.0.50; c++-ts-mode highlight does not work
Date: Mon, 24 Jul 2023 19:13:07 +0200	[thread overview]
Message-ID: <87mszl5j30.fsf@thornhill.no> (raw)
In-Reply-To: <83pm4hqme2.fsf@gnu.org>

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Mon, 24 Jul 2023 18:40:44 +0200
>> From: Theodor Thornhill <theo@thornhill.no>
>> 
>> >> Yep, nullptr was changed from named node to unnamed node last week [0].
>> >> 
>> >> I think we can live without a compat change and only target the node
>> >> as a normal keyword. I'll commit the fix if it is simple enough (the
>> >> simplest is just to remove the node altogether),
>> >> otherwise I'll send a patch for review. Sounds ok?
>> >
>> >I'd prefer to see the patch.  Also, can you tell more about the effect
>> >of the change you propose ("remove the node")?
>> >
>> 
>> In this case it will only make the symbol "nullptr" get no font locking.
>
> That's probably good enough.  And CC Mode doesn't fontify it, either.
>
> Can you show the patch?
>

diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el
index 7f4f6f11387..98797bf3ce7 100644
--- a/lisp/progmodes/c-ts-mode.el
+++ b/lisp/progmodes/c-ts-mode.el
@@ -574,9 +574,7 @@ c-ts-mode--font-lock-settings
    :feature 'constant
    `((true) @font-lock-constant-face
      (false) @font-lock-constant-face
-     (null) @font-lock-constant-face
-     ,@(when (eq mode 'cpp)
-         '((nullptr) @font-lock-constant-face)))
+     (null) @font-lock-constant-face)
 
    :language mode
    :feature 'keyword


>> >More generally, I'm a bit worried by such incompatible changes in the
>> >grammar libraries.  The developers must understand that they break
>> >users of tree-sitter, right?  So why are they making such incompatible
>> >changes?  And how do other editors cope with such changes, for example
>> >this one?
>> 
>> An example from nvim-treesitter: https://github.com/nvim-treesitter/nvim-treesitter/commit/823e67a1c9452075ec7f01e7aa05ac6e7b41fb1e
>> 
>> It seems most, if not all implementations use some sort of lockfile, where commits are frozen according to the current support. The consensus seems to be to do what I proposed some mails ago: show the last known commit the current file supports, and enable that one to be installed automatically.
>
> I'm not sure how we would maintain this data.  Emacs is a large
> project, and people come and go at will and without further notice.
> We don't have people who will reliably track the development of the
> grammar libraries and record the commits somewhere.  We'd basically
> need this when a release is being tarred, and for that it should be
> recorded somewhere in advance.
>

Yeah, it's not a super simple problem.

>> >I'm asking these questions because perhaps we are doing something we
>> >shouldn't, or not doing something we should.  I don't think we can
>> >tell our users to use only a specific commit from the grammar
>> >libraries' repositories: a significant portion of Emacs users tend to
>> >switch to a new version many moons after the release (e.g., I see
>> >reports from people who only now upgrade from Emacs 27 to Emacs 28,
>> >more than a year since Emacs 28 was released).  So a grammar library
>> >which was the current one on the release date will be hopelessly
>> >outdated by the time some users will switch to that Emacs version.
>> >
>> >So we must look for some more robust way, if it exists.
>> 
>> I agree, but I'm not sure what that looks like.
>
> What about catching errors inside treesit.c or treesit.el, so that the
> features that disappeared and queries that fail don't fail the entire
> font-lock?  Would that work, or at least make Emacs more robust in the
> face of such changes?
>
> Yuan, WDYT?
>
> (This more robust approach is certainly not for Emacs 29.1, even if we
> agree that it's a good idea.)

I'll defer that to Yuan, as I'm not 100% on where such errors can be
caught, and if it can make the parser enter some state it shouldn't be
in.

Theo





  reply	other threads:[~2023-07-24 17:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-24  4:49 bug#64818: 30.0.50; c++-ts-mode highlight does not work Wang Diancheng
2023-07-24 11:54 ` Eli Zaretskii
2023-07-24 13:10   ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-24 13:26   ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-24 13:46     ` Eli Zaretskii
2023-07-24 14:31       ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-24 16:08         ` Eli Zaretskii
     [not found]           ` <9173CE5D-08AE-4BF3-AD37-3B521845F8AC@thornhill.no>
2023-07-24 16:56             ` Eli Zaretskii
2023-07-24 17:13               ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2023-07-24 18:08                 ` Eli Zaretskii
2023-07-24 18:22                   ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-16  6:14                 ` Yuan Fu
2023-07-24 20:33               ` Dmitry Gutov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mszl5j30.fsf@thornhill.no \
    --to=bug-gnu-emacs@gnu.org \
    --cc=64818@debbugs.gnu.org \
    --cc=casouri@gmail.com \
    --cc=dianchengwang@gmail.com \
    --cc=eliz@gnu.org \
    --cc=theo@thornhill.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.