Recent commit causes uncodable character

[Thibaut Cuvelier]

On Sun, 27 Feb 2022 at 04:02, Thibaut Cuvelier <tcuvelier at lyx.org> wrote:

> On Tue, 22 Feb 2022 at 16:14, Thibaut Cuvelier <tcuvelier at lyx.org> wrote:
>
>> On Tue, 22 Feb 2022 at 16:09, Scott Kostyshak <skostysh at lyx.org> wrote:
>>
>>> On Tue, Feb 22, 2022 at 11:43:23AM +0100, Jürgen Spitzmüller wrote:
>>> > Am Di., 22. Feb. 2022 um 10:48 Uhr schrieb Jürgen Spitzmüller <
>>> spitz at lyx.org
>>> > >:
>>> >
>>> > > Am Di., 22. Feb. 2022 um 04:55 Uhr schrieb Scott Kostyshak <
>>> > > skostysh at lyx.org>:
>>> > >
>>> > >> The attached example file used to compile to PDF a couple of days
>>> ago.
>>> > >>
>>> > >
>>> > > Bisect says:
>>> > > [0dc7f34e00e06e8b378236e32f86023313067b7c] unicodesymbols: parse
>>> > > supplementary lines to encode alternative ways to encode symbols in
>>> raw
>>> > > LaTeX.
>>> > >
>>> >
>>> > It's probably rather 3f9e21b82692, for that matter.
>>>
>>> CC'ing Thibaut.
>>>
>>
>> Indeed, it's probably due to a recent commit of mine. I'll have a look,
>> tentatively tomorrow.
>>
>
> The problem is that Encodings::read does not read the full unicodesymbols
> file, it mysteriously stops at character 0x0390 (which is not even the
> first one with multiple LaTeX commands).
>

I found the root cause: some entries require a \" in LaTeX, but \\" is
recognised as the end of the LaTeX command, unlike \\\". It would be
helpful to have better error messages in unicodesymbols to debug these
cases, but it would be hard to implement in a backward-compatible way. I
think the most useful check here would be for an end-of-file symbol, but
previous versions of the file format would no longer be recognised (even
worse, they would be said to be invalid).
But the problem should be solved for now :)!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20220227/2dd2faad/attachment.html>