Dear devs,
thanks to everyone who chimed in. I didn't understand José's reply
until I looked at the lexers we use and found only one. I just didn't
occur to me that most files LyX uses are in this same format,
documents and configurations alike. This is a considerable advantage
of LyX's own format, and made me rethink my proposal.
Indeed it would make sense, if we have to change, to choose only one
format. But in my opinion, the best option for documents would be XML,
contrary to what so far we discussed about configuration files.
Perhaps it's best to leave things as they are.
Just out of curiosity I've tried converting a LyX document to YAML and
XML to see how they would look.
LYX:
\lyxformat 620
\begin_document
\begin_header
\language italian
\language_package default
\inputencoding utf8
\fontencoding auto
\font_roman "default" "default"
\font_sf_scale 100 100
\end_header
\begin_body
\begin_layout Title
LyX is a great editor
\end_layout
\begin_layout Author
Lorenzo
\end_layout
\begin_layout Section
Why LyX is great
\end_layout
\begin_layout Standard
\SpecialChar LyX
can write
\series bold
equations
\series default
like this with a nice editor
\begin_inset Formula
\[
(i\hbar\gamma^{\mu}\partial_{\mu}-mc)\psi(x)=0
\]
\end_inset
\end_layout
\begin_layout Section
Lyx is the best
\end_layout
\begin_layout Standard
Lyx can make
\emph on
tables
\emph default
and
\emph on
figures
\emph default
.
\begin_inset Float figure
placement document
alignment document
wide false
sideways false
status collapsed
\begin_layout Plain Layout
\begin_inset Graphics
filename empty.png
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Caption Standard
\begin_layout Plain Layout
Example image
\end_layout
\end_inset
\end_layout
\end_inset
\end_layout
\end_body
\end_document
YAML:
document:
header:
language: italian
language_package: default
inputencoding: utf8
fontencoding: auto
font_roman: [default, default]
font_sf_scale: [100, 100]
body:
- Title: "LyX is a great editor"
- Author: "Lorenzo"
- Section: "Why LyX is great"
Standard: |
"LyX can write **equations** like this with a nice editor"
"\\[ (i\hbar\gamma^{\mu}\partial_{\mu}-mc)\psi(x)=0 \\]"
- Section: "Lyx is the best"
Standard: |
"Lyx can make *on* tables *default* and *on* figures *default*."
Float_figure:
placement: document
alignment: document
wide: false
sideways: false
status: collapsed
Plain_Layout:
- Graphics:
filename: empty.png
- Caption: "Example image"
XML:
<document>
<header>
<language>italian</language>
<language_package>default</language_package>
<inputencoding>utf8</inputencoding>
<fontencoding>auto</fontencoding>
<font_roman>
<item>default</item>
<item>default</item>
</font_roman>
<font_sf_scale>
<item>100</item>
<item>100</item>
</font_sf_scale>
</header>
<body>
<Title>LyX is a great editor</Title>
<Author>Lorenzo</Author>
<Section>Why LyX is great
<Standard>LyX can write <bold>equations</bold> like this with a
nice editor
<Formula>(i\hbar\gamma^{\mu}\partial_{\mu}-mc)\psi(x)=0</Formula>
</Standard>
</Section>
<Section>Lyx is the best
<Standard>Lyx can make <emph>on</emph> tables
<emph>default</emph> and <emph>on</emph> figures <emph>default</emph>.
<Float_figure>
<placement>document</placement>
<alignment>document</alignment>
<wide>false</wide>
<sideways>false</sideways>
<status>collapsed</status>
<Plain_Layout>
<Graphics>
<filename>empty.png</filename>
</Graphics>
<Caption>Example image</Caption>
</Plain_Layout>
</Float_figure>
</Standard>
</Section>
</body>
</document>
More informations about the XML structure can be found in the wiki
page about the hypothetical transition. I updated it with some
examples and things yet to determine.
Thanks to everyone that contributed to this discussion. It was insightful.
Lorenzo.
Il giorno ven 5 apr 2024 alle ore 11:52 José Matos
<jaoma...@gmail.com> ha scritto:
>
> On Thu, 2024-03-28 at 13:00 +0100, Thibaut Cuvelier wrote:
> > All of these formats are rather well supported and far from shiny new
> > things (I think all of them have at least a decade of existence).
> >
> > Regarding validation: XML Schema has many offsprings, such as JSON
> > Schema (https://json-schema.org/), with implementations that work on
> > YAML and TOML (https://json-schema-everywhere.github.io/toml). In any
> > case, these schemas are extremely lacking compared to 21st-century
> > XML validation (RelaxNG with Schematron).
> > We currently have no validation, but it would be great to have it as
> > part of the test suite.
> >
> > How well do these formats work with (long) strings? What's great with
> > the current format is that you don't need to escape anything when LyX
> > expects a string. This aspect of the design removes a huge source of
> > typos.
>
> I agree with Thibaut's analysis.
>
> In addition I would say that with all its faults the upgrade mechanism
> between the different file formats is well defined and streamlined,
> note for example the number of LyX file formats that we have (more than
> 100).
>
> And this is also the part that lead us to the elephant in the room, the
> LyX file format where most of these discussions took place.
>
> IMHO it only makes sense to choose a file format if the purpose is to
> change all the different file formats to that model:
>
> * bind (key bindings);
> * citeengine
> * kmap (keyboard mappings);
> * layouts;
> * ui;
> * xtemplate;
>
> and
>
> * .lyx (the LyX file format - the elephant).
>
> Or else we risk the xkcd joke where in order to establish a unique
> standard we introduce another one.
>
> Do not underestimate the work required for the later.
>
> The advantages of having a standard format are many but the obstacles
> are also many.
>
> In any case it would be nice to compile the information here in a wiki
> page, in the development components, so that the next time this comes
> we have a central reference.
>
> That was also the rationale to the PEPs (Python Enhance Proposals), even
> if the proposal would be rejected there was a place where the reasons
> were stated.
>
> Best regards,
> --
> José Abílio
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
