@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
As far as my short studying,
```
Hello :: h
```
is incorrect (in meaning of syntax) fortran code.
See http://www.icl.utk.edu/~mgates3/docs/fortran.html#Variable for an example.
For such garbage input, u-ctags emits garbage.
ctags captures i, test1, test2 and h itself If you put the `Hello` in `
I'm working this topic in u-ctags side.
With the change I proposed in
https://github.com/universal-ctags/ctags/pull/2543, ctags can capture `foo`
well:
```
$ cat /tmp/foo.c
#define BLEH
struct foo BLEH { int _; };
$ u-ctags --param-CPreProcessor:_expand=1 --fields-C=+{macrodef} --fields=+S -o
As far as trying the input directly with u-ctags, it captures all expected tags.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/349#issuecomment-629691440
This issue doesn't happen while using monospace if you use font size "10"
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/1387#issuecomment-629704133
Yeah, Seems not valid even in Fortran 2018 so marking invalid and closing, if
the OP can post references for validity can re-open.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2115#is
Closed #2115.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2115#event-3344052252
14 matches
Mail list logo
