This commit changes JSON from a custom filetype to one with its own lexer, as
requested in
https://github.com/geany/geany/issues/384#issuecomment-583869454. The lexer is
taken from Scintilla's upstream
(version 3.10.4).
This has the following effects:
- JavaScript comments (//, /* */) are no lo
Isn't it common that JSON parsers accept comments as an extension? I know many
also don't, but unless you want to split up into two separate JSON-pure and
JSON-with-comments file types it might be better to keep in the comment
highlighting
--
You are receiving this because you are subscribed t
@ell1e what is "common"? This is hard to define in a general way and the JSON
standard does *not* allow comments.
@d5l6 I wonder if it wouldn't be better to keep the custom filetype and just
add the Scintilla JSON lexer to Geany and update the custom filetype definition
to use it.
Otherwise we
@eht16 just google "JSON for comments", apart from posts telling you it's not
allowed you'll find quite a bunch of different parsers to enable this. And
Visual Studio Code (which is pretty popular) uses this style for all its
configs, too. I don't have proper statistics, but I think it should be
@ell1e I still think a dedicated JSON filetype should (at least by default) not
allow comments.
But we don't even need to make a hard decision here as the Scintilla JSON lexer
has a property to toggle highlighting of comments: `lexer.json.allow.comments`.
So, one can add:
```
[lexer_properties]
I think the best way could be to have a JSON with comments file type for the
lenient parsing if the core JSON type to allow it. A global option as you
suggest will basically force anyone to disable strict mode if they have just
have just 1+ files that rely on the expanded syntax, which IMHO turn
The JSON lexer setting is global for the filetype, so there would need to be
two filetypes to handle both commentable JSON and uncommentable JSON. Changing
a filetype setting during editing is simply not usable. But AFAIK there is
nothing to distinguish between the variants so different filety
> Changing a filetype setting during editing is simply not usable.
For what it's worth, I think that is what VS Code does: it attempts to
auto-detect (not sure if just based on file extension or actually content) but
t the docs suggest it shows the resulting filetype somewhere prominent, I thi
> @ell1e I still think a dedicated JSON filetype should (at least by default)
> not allow comments.
But we don't even need to make a hard decision here as the Scintilla JSON lexer
has a property to toggle highlighting of comments: lexer.json.allow.comments...
+1
> The JSON lexer setting is glob
I would recommend to ship a `JSON with comments` filetype from the start
because it does seem to be somewhat common to me (mostly due to MS's VS Code
which popularized). Being able to extend it is always cool, but obviously the
user experience is better if the right file mode is already availabl
> would recommend to ship a JSON with comments filetype from the start because
> it does seem to be somewhat common to me (mostly due to MS's VS Code which
> popularized)...
Sure, like "JSON (strict)" filetype using the real JSON lexer, and then a
custom filetype "JSON (loose)" inheriting from
Sounds good! Although I'd call it "JSON (strict)" & "JSON (with comments)",
because that is how most people seem to refer to the looser interpretation on
the web. But that's just my personal preference, obviously
--
You are receiving this because you are subscribed to this thread.
Reply to this
@d5l6 , update `LexJSON.cxx`, please: [Scintilla
3.21.1](https://github.com/geany/geany/commit/8f0909685dad46096ecf92152e82d309b0852bfd)
has `LexJSON.cxx` with small changes.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
For what it's worth, I've now seen JSONC files (with comments) stored in
`.json` multiple times, e.g. the launch settings in any VS Code project. So
while technically a different file type, I do wonder how you'd want to detect
it based on the file ending, making the idea of two different parsers
14 matches
Mail list logo
