@techee commented on this pull request.
> @@ -0,0 +1,59 @@
+# For complete documentation of this file, please see Geany's main
documentation
+[styling]
+# Edit these in the colorscheme .conf file instead
+default=default
+number=number_1
+string=string_1
+stringeol=string_eol
@techee pushed 1 commit.
f53b82cd6747495062d3e44ea710c9cd03b3ff0d Use identical style for compactiri
and propertyname
--
View it on GitHub:
https://github.com/geany/geany/pull/3647/files/2298cac67b23fdf7d087a57b099cd0136ea8b3c0..f53b82cd6747495062d3e44ea710c9cd03b3ff0d
You are receiving this
I would have to agree with the commenter referenced above.
JSON-LD is something far more than just JSON, it is an attempt to allow
sematics of the simple `name : value` pairs of JSON to be agreed between two
users of JSON for data interchange, by reference to external schema which the
IRI
> > I didn't read the specs of JSON-LD but are those always present in the keys
> > of json dicts?
>
> I suppose its the old lexers lack of context issue, IIUC the compact IRIs
> need to be specified by `@context` specifications, otherwise they are just
> strings with `:` in them.
>From what I
> This isn't a lexilla problem
I suppose its the old lexers lack of context issue, IIUC the compact IRIs need
to be specified by `@context` specifications, otherwise they are just strings
with `:` in them. But I guess thats beyond Lexilla, so maybe @rdipardo's
suggestion of unifying the
> It might be better to map one consistent style to property names and compact
> IRIs (even though the latter are really a [component of
> JSON-LD](https://www.w3.org/TR/json-ld/#dfn-compact-iri)).
I didn't read the specs of JSON-LD but are those always present in the keys of
json dicts?
>
@elextr commented on this pull request.
> @@ -0,0 +1,59 @@
+# For complete documentation of this file, please see Geany's main
documentation
+[styling]
+# Edit these in the colorscheme .conf file instead
+default=default
+number=number_1
+string=string_1
+stringeol=string_eol
@rdipardo commented on this pull request.
> @@ -0,0 +1,59 @@
+# For complete documentation of this file, please see Geany's main
documentation
+[styling]
+# Edit these in the colorscheme .conf file instead
+default=default
+number=number_1
+string=string_1
+stringeol=string_eol
> Do we have to convert the existing filetype to a builtin filetype?
I guess the answer is yes because the lexer_filetype setting can only reference
existing filetypes in Geany?
This is what I thought too.
> I don't want to say we should not do this, but maybe we should remind us
> ourselves
Do we have to convert the existing filetype to a builtin filetype?
I guess the answer is yes because the `lexer_filetype` setting can only
reference existing filetypes in Geany?
I don't want to say we should not do this, but maybe we should remind us
ourselves by directly adding a NEWS item for
Great idea.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3647#issuecomment-1775024815
You are receiving this because you are subscribed to this thread.
Message ID:
11 matches
Mail list logo
