Could anyone confirm the issue or explain me what I am missing?
Confirmed on Win64 with the same version.
But I did find a workaround: if I convert your example from NFC
(composed) to NFD (decomposed), it compiles fine.
$ xxd xml.tex
: 5c75 7365 6d6f 6475 6c65 5b73 6369 7465
Dear list,
I have this minimal sample (with current latest from 2022.05.11 11:36 on
Linux64):
\usemodule[scite]
\starttext
\startXML ñ\stopXML
\stoptext
Commenting out the first line avoids compilation error.
Replacing ñ with n also allows compilation.
I think there may be an error in
On 6/3/22 00:52, Max Chernoff via ntg-context wrote:
>> For the sake of consistency (with buff-imp-xml.lua), I think the patch
>> should read
> > [...]
>> +local alsoname = lpatterns.utf8two + lpatterns.utf8three +
>> lpatterns.utf8four
>
> I think that that pattern is a little too broad,
For the sake of consistency (with buff-imp-xml.lua), I think the patch
should read
> [...]
+local alsoname = lpatterns.utf8two + lpatterns.utf8three +
lpatterns.utf8four
I think that that pattern is a little too broad, since it will match any
non-ASCII Unicode character. Things like
On 6/2/22 17:36, Pablo Rodriguez via ntg-context wrote:
> On 6/1/22 23:58, Max Chernoff via ntg-context wrote:
>>
>> local name = (R("az","AZ","09") + S("_-.") +
>> lpeg.utfchartabletopattern(characters.csletters))^1
>
> I’m afraid I cannot make your proposed fix work.
Even with a brand new
On 6/1/22 23:58, Max Chernoff via ntg-context wrote:
>> Now, I still don’t understand LPEG and don’t know if there’s a general
>> “character” class that doesn’t need a list...
Many thanks for your reply, Hraban.
> The easiest way that I found was to just cheat and use everything with
> a TeX
Now, I still don’t understand LPEG and don’t know if there’s a general
“character” class that doesn’t need a list...
Well looking through the XML spec
https://www.w3.org/TR/REC-xml/#NT-NameChar
you'd think that we'd want a pattern like this:
local name = (R("az","AZ","09",
Am 01.06.22 um 19:45 schrieb Pablo Rodriguez via ntg-context:
But I don’t know which file deals with it (so I could try to submit a
patch).
That would be texmf-context/tex/context/modules/mkiv/m-scite.mkiv
and
texmf-context/context/data/scite/context/lexers/scite-context-lexer-xml.lua
and
On 6/1/22 18:58, Henning Hraban Ramm via ntg-context wrote:
> Am 01.06.22 um 18:47 schrieb Pablo Rodriguez via ntg-context:
>> [...]
>> Could anyone confirm the issue?
>
> Hi Pablo,
>
> with LMTX version 2022.05.11, both elements are displayed, but the first
> in blue, the second in red.
Am 01.06.22 um 18:47 schrieb Pablo Rodriguez via ntg-context:
Dear list,
I have the following sample:
\usemodule[scite]
\starttext
\startTEXpage[offset=1ex]
\type[option=xml]{}
\type[option=xml]{<áñß/>}
\stopTEXpage
\stoptext
Using scite, I don’t get the second element
Dear list,
I have the following sample:
\usemodule[scite]
\starttext
\startTEXpage[offset=1ex]
\type[option=xml]{}
\type[option=xml]{<áñß/>}
\stopTEXpage
\stoptext
Using scite, I don’t get the second element right.
Without scite, both elements are displayed right.
In both Geany
11 matches
Mail list logo
