<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 13 Feb 2021 at 22:42, Scott Kostyshak <<a href="mailto:skostysh@lyx.org">skostysh@lyx.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Feb 13, 2021 at 08:58:40PM +0100, Thibaut Cuvelier wrote:<br>
> Hi Julien,<br>
> <br>
> This would be awesome! It would still be quite a lot of work, though (I<br>
> have been through a similar pain when rewriting the DocBook export).<br>
> <br>
> As far as I can see, the Pandoc format is really poor (after all, it's very<br>
> similar to Markdown) compared to LyX: conversion to that format will lose a<br>
> lot of information from LyX. The HTML and DocBook exporters try to keep as<br>
> much information from LyX as possible, on the contrary, because these<br>
> formats are really flexible (even though the semantic information remains<br>
> at a presentational level for HTML). I'm afraid this could be a<br>
> road-blocker for using LyX as a Markdown editor for some users: you could<br>
> do so much more in LyX than in Markdown, without knowing in advance what<br>
> will be exportable in Markdown.<br>
> <br>
> Therefore, I don't think it's adviseable to use the Pandoc road for as many<br>
> formats as possible, but rather as a safety net. (It would be much better<br>
> if LyX could generate many formats without using external dependencies,<br>
> like DocBook and HTML — but unlike the new ePub support, for instance.)<br>
> <br>
> Due to the volatility of the LyX file format (and the lack of precise<br>
> definition, as far as I know), I would advise against your solution 2: LyX<br>
> can change its format between any two versions (except patch releases, if I<br>
> got it correctly), so that Pandoc would have to follow LyX for every change<br>
> in file format (LyX can convert between any two versions, but new features<br>
> may be lost when going backwards — and thus some content). Solution 1<br>
> (implementing everything in LyX) would protect against any format changes,<br>
> as it would be implemented at the level of the LyX data structures instead<br>
> of the file format. Pandoc could then learn how to call LyX to perform the<br>
> conversion into their JSON schema, and you would use Pandoc to convert LyX<br>
> files directly.<br>
> <br>
> Projects like<br>
> <a href="https://github.com/nicowilliams/lyx2rfc/blob/master/src/lyx2xml.py" rel="noreferrer" target="_blank">https://github.com/nicowilliams/lyx2rfc/blob/master/src/lyx2xml.py</a> are, in<br>
> my opinion, doomed to fail in the long run. It is really easier to write<br>
> code to work with LyX documents that directly within LyX, but the second<br>
> option gives more confidence in having the conversion work reliably in the<br>
> long term.<br>
> <br>
> Regarding the XML conversion of the LyX file format, you can also see<br>
> places where it's planned for 3.0, but it's not really alive right now (at<br>
> least, not that I know).<br>
> <br>
> These are just my thoughts on your proposal. I have not been a LyX<br>
> developer for a long time, so take everything with a pinch of salt or two.<br>
> However, I can guide you if you are willing to implement something in LyX.<br>
> <br>
> On Sat, 13 Feb 2021 at 17:42, Julien Dutant <<a href="mailto:julien.dutant@gmail.com" target="_blank">julien.dutant@gmail.com</a>> wrote:<br>
> <br>
> > Hi Lyx devs,<br>
> ><br>
> > tl;dr: interfacing LyX with pandoc's native or markdown formats would<br>
> > greatly expand its reach by adding many formats to the outputs it can<br>
> > generate and by making it by far the best visual editor for markdown<br>
> > available. What's the best way to go about it?<br>
> ><br>
> > I love LyX and have been using it for many years, I'm very grateful for<br>
> > your work. Like many people in academia and developers I'm also using<br>
> > markdown more and more, including for generating LaTeX. Pandoc (the<br>
> > "universal document converter", <a href="https://pandoc.org/" rel="noreferrer" target="_blank">https://pandoc.org/</a>) has a rich flavour<br>
> > of markdown that can cover most of academic needs and can be extended<br>
> > through 'filters. As I explain in this post:<br>
> > <a href="https://github.com/jgm/pandoc/issues/5555" rel="noreferrer" target="_blank">https://github.com/jgm/pandoc/issues/5555</a> on Pandoc's repo, there is a<br>
> > need for markdown visual editors and the few ones that exist are nowhere<br>
> > near as feature-rich and fast as an editor like LyX.<br>
> > But it would only take for LyX to read/write pandoc's markdown or native<br>
> > formats, or for Pandoc to read Lyx's format, to instantly turn LyX into a<br>
> > visual markdown editor. The layout system could be use to have a "markdown"<br>
> > class, and the extension system could even be used in combination with<br>
> > Pandoc's filters to extend markdown.<br>
> ><br>
> > In addition, doing this would allow LyX to generate all the outputs<br>
> > formats that Pandoc can generate: ebook, JATS XML, RST, various flavours of<br>
> > markdown, 6 slides formats, etc., etc., without going through LaTeX. I<br>
> > think this would significantly increase LyX's audience, esp. among<br>
> > documentation writers.<br>
> ><br>
> > Pandoc works by converting all documents to its Abstract Syntax Tree,<br>
> > which is simple and systematically specified (<br>
> > <a href="https://hackage.haskell.org/package/pandoc-types-1.22/docs/Text-Pandoc-Definition.html" rel="noreferrer" target="_blank">https://hackage.haskell.org/package/pandoc-types-1.22/docs/Text-Pandoc-Definition.html</a><br>
> > ). Pandoc can read it from a JSON file; alternatively, Pandoc's markdown<br>
> > can match it pretty closely. So all it would take would be either:<br>
> ><br>
> > 1) that Lyx reads and writes Pandoc's markdown or JSON<br>
> > 2) that Pandoc reads and writes Lyx's format .lyx .<br>
> ><br>
> > The first would be developping something like the DocBook or LyXHTML<br>
> > extension in Lyx. The second would be developing a reader and writer for<br>
> > Pandoc (in Haskell).<br>
> ><br>
> > It seems to me that the second line is easier (because there's already all<br>
> > the library to build pandoc AST objects in Haskell).<br>
> ><br>
> > There are people in the pandoc community that might get involved. Or<br>
> > someone could develop something on the LyX side (happy to get involved but<br>
> > in the longer term). The main obstacle, however, is that there doesn't seem<br>
> > to be a specification of LyX format, and (if I understand well) we can't<br>
> > rely on it being stable between releases (though we could rely on LyX's own<br>
> > conversion between versions of the LyX format).<br>
> ><br>
> > Around version 2.1 there was a "road to XML" but that has been abandoned,<br>
> > right?<br>
> ><br>
> > I'd be curious to have your thoughts on the project and what you think<br>
> > would be the best way to go about it and the main hurdles.<br>
> ><br>
> > All best,<br>
> ><br>
> > Julien<br>
<br>
I have no idea if the following is related, or even relevant since it is<br>
not active for several years, but just in case:<br>
<br>
<a href="https://github.com/crcowan/MultiMarkdown-4-LyX-Maintenance" rel="noreferrer" target="_blank">https://github.com/crcowan/MultiMarkdown-4-LyX-Maintenance</a><br></blockquote><div><br></div><div>I understand that this projects works in reverse, i.e. from Markdown to LyX. <br></div></div></div>