bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#59833: 29.0.60; json-ts-mode fontifies everything as string


From: Jostein Kjønigsen
Subject: bug#59833: 29.0.60; json-ts-mode fontifies everything as string
Date: Mon, 5 Dec 2022 15:52:17 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1

On 05.12.2022 15:42, Randy Taylor wrote:

Thanks, I meant just the treesit-font-lock-feature-list variable :) (so moving 
pair before string).

Having the font-lock settings alphabetized too is great, but I remember running 
into some highlighting issues depending on the order of things.
For example, since error is above number, the number face will not be 
highlighted as error when an error occurs.

Try:
{
   "test": 2
}

and remove the colon. Before your patch, the entire line is red. After, only 
"test" is red.

So in general, I think we should stick all :overrides at the bottom of that 
list (with error being the ultimate one), and keep everything above and below 
alphabetized, but separately, which is how I organized json-ts-mode.
Good observation. Agreed.

Are you guys talking about the json-mode package? Jostein mentioned "Emacs still 
defaults to json-mode", but when I open a JSON file I get js-json-mode, which is 
what I assumed he meant. js-json-mode is what I was trying to match in json-ts-mode.

I've never heard of js-json-mode until today. I always use json-mode (which AFAIK) is still the default for json-files, unless overridden in your own .emacs setup.

I can see that in Emacs git right now, json-ts-mode behaves closely to js-json-mode. I honestly expected it to match the Emacs-default json-mode though, and found the current highlighting ... somewhat unexpected.

IMO, yes the keys are technically speaking strings, but the are predominantly and semantically keys, and IMO should be highlighted as such. Just like json-mode does.

I realise this is somewhat subjective and preferential, but as far as my preference goes, I clearly prefer json-mode over js-json-mode, and as such also prefer the current patch-sets for json-ts-mode which Theo has submitted.

(On my part we can avoid side-tracking related to why there are multiple json-modes, unless has a deep need to contextualize these changes related to those ;) )

--
Jostein





reply via email to

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