Re: File format increases on master make it hard to test

[Scott Kostyshak]

On Mon, Apr 08, 2024 at 10:14:07AM GMT, José Matos wrote:
> On Sun, 2024-04-07 at 23:03 -0400, Scott Kostyshak wrote:
> > Thanks, that is a good idea, but I would not want to use that setting
> > for most of my documents. I find that doing repeated lyx2lyx does not
> > create a smooth workflow.
> > 
> > Scott
> 
> I pushed against the guarantee before. :-)
> The rationale was the main priority was to ensure the best upgrade
> (forward).
> 
> On the other hand after hundreds of file updates we have now a better
> understanding of what it involves and so I think that with some small
> effort we can improve, make it for a smoother experience, the round
> trip experience.
> 
> BTW, I know that this is orthogonal to your issue. :-)

Fair enough! You are more optimistic than I about making roundtrip smooth :)

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: File format increases on master make it hard to test

[José Matos]

On Sun, 2024-04-07 at 23:03 -0400, Scott Kostyshak wrote:
> Thanks, that is a good idea, but I would not want to use that setting
> for most of my documents. I find that doing repeated lyx2lyx does not
> create a smooth workflow.
> 
> Scott

I pushed against the guarantee before. :-)
The rationale was the main priority was to ensure the best upgrade
(forward).

On the other hand after hundreds of file updates we have now a better
understanding of what it involves and so I think that with some small
effort we can improve, make it for a smoother experience, the round
trip experience.

BTW, I know that this is orthogonal to your issue. :-)
-- 
José Abílio
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: File format increases on master make it hard to test

[Scott Kostyshak]

On Sun, Apr 07, 2024 at 03:13:44PM GMT, Richard Kimberly Heck wrote:
> On 4/7/24 12:46, José Matos wrote:
> > On Sun, 2024-04-07 at 11:31 -0400, Scott Kostyshak wrote:
> > > Fair enough. That was what I was afraid of (and expected).
> > > 
> > > Scott
> > A possible mid-term solution, to your use case, is to set the output
> > format of the latest stable version.
> > 
> > This would mean that any document is always imported to the latest
> > development release and when saved it is done in the stable file
> > format.
> > 
> > On the other hand what this would mean to stress the
> > conversion/reversion round trip.
> > 
> > This could be implemented as some kind of option to set, by default,
> > the save file format version or even better, because in this case this
> > is what it intended, the target version.
> > 
> > In the preferences file this could go as:
> > 
> > \save_file_format 2.4
> > 
> > If this option is not set then everything works as usual.
> > If it is set then, when the file is saved, the file is reverted to that
> > file format.
> > 
> > I hope that this idea helps, :-)
> 
> That is a good idea. It's too late for 2.4.x, but if it were added early to
> master, then it would be usable for Scott's purpose.
> 
> The roundtrip would of course only matter if one made use of features that
> required a format change.

Thanks, that is a good idea, but I would not want to use that setting
for most of my documents. I find that doing repeated lyx2lyx does not
create a smooth workflow.

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Layout file format change proposal

[Richard Kimberly Heck]

On 4/7/24 08:39, Lorenzo Bertini wrote:

Just out of curiosity I've tried converting a LyX document to YAML and
XML to see how they would look.


I spent some time once working on an XML file format, thinking I could 
use some of the machinery developed for XHTML output, which is now even 
more robust since Thibaut's work on DocBook. It quickly became clear, 
though, that this was going to be very non-trivial.


Riki



--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: File format increases on master make it hard to test

[Richard Kimberly Heck]

On 4/7/24 12:46, José Matos wrote:

On Sun, 2024-04-07 at 11:31 -0400, Scott Kostyshak wrote:

Fair enough. That was what I was afraid of (and expected).

Scott

A possible mid-term solution, to your use case, is to set the output
format of the latest stable version.

This would mean that any document is always imported to the latest
development release and when saved it is done in the stable file
format.

On the other hand what this would mean to stress the
conversion/reversion round trip.

This could be implemented as some kind of option to set, by default,
the save file format version or even better, because in this case this
is what it intended, the target version.

In the preferences file this could go as:

\save_file_format 2.4

If this option is not set then everything works as usual.
If it is set then, when the file is saved, the file is reverted to that
file format.

I hope that this idea helps, :-)


That is a good idea. It's too late for 2.4.x, but if it were added early 
to master, then it would be usable for Scott's purpose.


The roundtrip would of course only matter if one made use of features 
that required a format change.


Riki


--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: File format increases on master make it hard to test

[José Matos]

On Sun, 2024-04-07 at 11:31 -0400, Scott Kostyshak wrote:
> Fair enough. That was what I was afraid of (and expected).
> 
> Scott

A possible mid-term solution, to your use case, is to set the output
format of the latest stable version.

This would mean that any document is always imported to the latest
development release and when saved it is done in the stable file
format.

On the other hand what this would mean to stress the
conversion/reversion round trip.

This could be implemented as some kind of option to set, by default,
the save file format version or even better, because in this case this
is what it intended, the target version.

In the preferences file this could go as:

\save_file_format 2.4

If this option is not set then everything works as usual.
If it is set then, when the file is saved, the file is reverted to that
file format.

I hope that this idea helps, :-)
-- 
José Abílio
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: File format increases on master make it hard to test

[Scott Kostyshak]

On Sun, Apr 07, 2024 at 06:32:47AM GMT, Jürgen Spitzmüller wrote:
> Am Samstag, dem 06.04.2024 um 16:51 -0400 schrieb Scott Kostyshak:
> > I imagine others face the same situation? Is there anything that can
> > be done?
> 
> No, I think this will be a nightmare to maintain. And then, you really
> do not "text master" if you strip the most interesting commits.

Fair enough. That was what I was afraid of (and expected).

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Layout file format change proposal

[Lorenzo Bertini]

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:


  
italian
default
utf8
auto

  default
  default


  100
  100

  
  
LyX is a great editor
Lorenzo
Why LyX is great
  LyX can write equations like this with a
nice editor
(i\hbar\gamma^{\mu}\partial_{\mu}-mc)\psi(x)=0
  

Lyx is the best
  Lyx can make on tables
default and on figures default.

  document
  document
  false
  false
  collapsed
  

  empty.png

Example image
  

  

  


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
 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 

Re: File format increases on master make it hard to test

[Jürgen Spitzmüller]

Am Samstag, dem 06.04.2024 um 16:51 -0400 schrieb Scott Kostyshak:
> I imagine others face the same situation? Is there anything that can
> be done?

No, I think this will be a nightmare to maintain. And then, you really
do not "text master" if you strip the most interesting commits.

-- 
Jürgen


signature.asc
Description: This is a digitally signed message part
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

File format increases on master make it hard to test

[Scott Kostyshak]

I've been enjoying testing master, but on the first file format increment, I'll 
stop a lot of my testing since they're documents I will want to work on with 
other people.

I have a few documents that only I use and for that I'll try to continue to 
test master.

I imagine others face the same situation? Is there anything that can be done? I 
remember that Guillaume used to maintain a lyx-unstable (I think this was the 
name) where I think he removed the file format updates. How hard would that be 
to maintain?

I guess ideally anything that doesn't involve a file format bump would also 
eventually be pushed to 2.4.x, so our testing of 2.4.x should help indirectly 
to test master, but there are a lot of commits that don't go to 2.4.x (for good 
reason). I guess an alternative would be to have a master-no-file-format 
branch, that gets all the commits master does except file format increments? 
But in this case it seems it would be less work to maintain the lyx-unstable 
referenced above, so that we don't have to double-commit each time?

Not sure if anything can feasibly be done here, but wanted to ask.

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Layout file format change proposal

[José Matos]

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

Re: Layout file format change proposal

[Pavel Sanda]

On Thu, Mar 28, 2024 at 12:49:14PM +0100, Lorenzo Bertini wrote:
> I am proposing this because I've had people tell me layouts
> are "advanced", and one of the roadblocks to using LyX. Having easy
> tools to edit them would help.

Another thing to consider is how to support home-written modules
which were written by the users, probably do not have any version
string and all of the sudden documents break because of fundamental
format switch... 
We should be very careful about this I think.

Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Layout file format change proposal

[Pavel Sanda]

On Thu, Mar 28, 2024 at 12:40:10PM +0100, Lorenzo Bertini wrote:
> - TOML:
>   . pros: very easy to read and write, even for humans
>   . cons: not widespread, distant from .layout
> - YAML:
>   . pros: very easy to read and write, very close to .layout
>   . cons: indentation is prone to syntax errors

I value "very easy to read and write, even for humans" way above the others.
While new wave of designers coming from the fact that we have standard machine
readable format is a doubtful hope, the current devs are the warranted users
and are probably used to format which can be easily read/edited.

>From this perspective YAML looks closest to what my eyes are used to parse,
TOML is still in the range of sensible and other are in the land of PITA ;)

Thanks for your explicit examples...

Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Layout file format change proposal

[Thibaut Cuvelier]

On Thu, 28 Mar 2024 at 12:41, Lorenzo Bertini 
wrote:

> Il giorno gio 28 mar 2024 alle ore 11:40 José Matos
>  ha scritto:
> >
> > On Wed, 2024-03-27 at 11:02 -0400, Scott Kostyshak wrote:
> > > Cool idea, Lorenzo! There have been some discussions in the past on
> > > using standard formats, even for the .lyx file itself. I can see the
> > > advantages of that but I don't know what the cost of converting to
> > > them
> > > is.
> > >
> > > Scott
> >
> > Typical answer to this:
> > https://xkcd.com/927/
> >
> > :-)
> >
> > It makes sense for us to use a standard format.
> > Some of the questions then are:
> >  * which one is chosen (what is the most appropriate for our needs)?
> >  * what the are advantages and drawbacks from this change?
> >  * what is the transition plan?
> >  * what is the effort required for this transition?
> >
> > Best regards,
> > --
> > José Abílio
> > --
>
> Ah, a classic xkcd. For once, however, the talk is about "removing"
> one standard :)
>

Many standards aim at removing older standards :)!


> * Which one to choose?
> See research below.
>
> * The advantages and drawbacks
> As already mentioned, using a more common format means
>   - people generally more familiar with the format
>   - having more tools able to produce them, easing the efforts of
> publishers trying to provide layouts
>   - having parsers already available, for LyX and for people wanting
> to manipulate them externally
> The drawbacks that i can think of are
>   - migration always takes developer effort
>   - migration can take user effort too, to adapt to the new format
> (this can be greatly mitigated by which format is chosen)
>
> * The transition plan:
> The new format is introduced *alongside* the old format. The LyX
> version that brings the format will have all layouts converted, but
> will accept the old format too. This "transition period" can last
> indefinitely.
>

In a way, that's how LyX works right now: you can import a very old
document or layout, it should still work thanks to upgrade scripts. YAML,
TOML, or something else would just be a new version (which means you must
keep the version field: the format evolves a lot between versions). Here is
the script that does the conversion:
https://git.lyx.org/gitweb/?p=lyx.git;a=blob;f=lib/scripts/layout2layout.py;h=611639412a78e4235a55e41c890546f4e080c06f;hb=HEAD.



> * The efforts required for the transition
> We need to:
>   - write or choose a parser for the new format that maps a file to a
> LyX's params
>   - write a converter from the old format to the new one
>   - convert all the files to the new formats and test them
>
> Here is some info I dug up regarding configuration formats. For pros
> and cons I tried to limit them to one single aspect where they excel
> or fail
> - JSON:
>   . pros: most widely supported
>   . cons: not concise or readable, very distant from .layout
> - TOML:
>   . pros: very easy to read and write, even for humans
>   . cons: not widespread, distant from .layout
> - YAML:
>   . pros: very easy to read and write, very close to .layout
>   . cons: indentation is prone to syntax errors
> - XML:
>   . pros: the one and only, supports validation through schemas,
> widely supported
>   . cons: hard to read and write, very distant from .layout
>

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 asked a chatbot to convert LyX's following layout extract into those
> formats:
>
> LYX'S LAYOUT
>
> InsetLayout Marginal
> LabelString   Margin
> LatexType command
> Font
>   SizeSmall
> EndFont
> LabelFont
>   Color   marginlabel
>   SizeSmall
> EndFont
> HTMLStyle
> div.marginal {
> border: 2px solid black;
> font-style: normal;
> }
> EndHTMLStyle
> End
>
> JSON:
>
> {
>   "InsetLayout": {
> "LabelString": "Margin",
> "LatexType": "command",
> "Font": {
>   "Size": "Small"
> },
> "LabelFont": {
>   "Color": "marginlabel",
>   "Size": "Small"
> },
> "HTMLStyle": {
>   "div.marginal": {
> "border": "2px solid black",
> "font-style": "normal"
>   }
> }
>   }
> }
>
> TOML:
>
> [InsetLayout]
>   LabelString = 

Re: Layout file format change proposal

[Lorenzo Bertini]

PS.

Reading JMarc comment under https://www.lyx.org/trac/ticket/13035 made
me think. I don't want to come off as suffering from "shiny new thing
syndrome". I am proposing this because I've had people tell me layouts
are "advanced", and one of the roadblocks to using LyX. Having easy
tools to edit them would help.

Also, provided some guidance, I volunteer to do the work necessary for this.

Lorenzo

Il giorno gio 28 mar 2024 alle ore 12:40 Lorenzo Bertini
 ha scritto:

>
> Il giorno gio 28 mar 2024 alle ore 11:40 José Matos
>  ha scritto:
> >
> > On Wed, 2024-03-27 at 11:02 -0400, Scott Kostyshak wrote:
> > > Cool idea, Lorenzo! There have been some discussions in the past on
> > > using standard formats, even for the .lyx file itself. I can see the
> > > advantages of that but I don't know what the cost of converting to
> > > them
> > > is.
> > >
> > > Scott
> >
> > Typical answer to this:
> > https://xkcd.com/927/
> >
> > :-)
> >
> > It makes sense for us to use a standard format.
> > Some of the questions then are:
> >  * which one is chosen (what is the most appropriate for our needs)?
> >  * what the are advantages and drawbacks from this change?
> >  * what is the transition plan?
> >  * what is the effort required for this transition?
> >
> > Best regards,
> > --
> > José Abílio
> > --
>
> Ah, a classic xkcd. For once, however, the talk is about "removing"
> one standard :)
>
> * Which one to choose?
> See research below.
>
> * The advantages and drawbacks
> As already mentioned, using a more common format means
>   - people generally more familiar with the format
>   - having more tools able to produce them, easing the efforts of
> publishers trying to provide layouts
>   - having parsers already available, for LyX and for people wanting
> to manipulate them externally
> The drawbacks that i can think of are
>   - migration always takes developer effort
>   - migration can take user effort too, to adapt to the new format
> (this can be greatly mitigated by which format is chosen)
>
> * The transition plan:
> The new format is introduced *alongside* the old format. The LyX
> version that brings the format will have all layouts converted, but
> will accept the old format too. This "transition period" can last
> indefinitely.
>
> * The efforts required for the transition
> We need to:
>   - write or choose a parser for the new format that maps a file to a
> LyX's params
>   - write a converter from the old format to the new one
>   - convert all the files to the new formats and test them
>
> Here is some info I dug up regarding configuration formats. For pros
> and cons I tried to limit them to one single aspect where they excel
> or fail
> - JSON:
>   . pros: most widely supported
>   . cons: not concise or readable, very distant from .layout
> - TOML:
>   . pros: very easy to read and write, even for humans
>   . cons: not widespread, distant from .layout
> - YAML:
>   . pros: very easy to read and write, very close to .layout
>   . cons: indentation is prone to syntax errors
> - XML:
>   . pros: the one and only, supports validation through schemas,
> widely supported
>   . cons: hard to read and write, very distant from .layout
>
> I asked a chatbot to convert LyX's following layout extract into those 
> formats:
>
> LYX'S LAYOUT
>
> InsetLayout Marginal
> LabelString   Margin
> LatexType command
> Font
>   SizeSmall
> EndFont
> LabelFont
>   Color   marginlabel
>   SizeSmall
> EndFont
> HTMLStyle
> div.marginal {
> border: 2px solid black;
> font-style: normal;
> }
> EndHTMLStyle
> End
>
> JSON:
>
> {
>   "InsetLayout": {
> "LabelString": "Margin",
> "LatexType": "command",
> "Font": {
>   "Size": "Small"
> },
> "LabelFont": {
>   "Color": "marginlabel",
>   "Size": "Small"
> },
> "HTMLStyle": {
>   "div.marginal": {
> "border": "2px solid black",
> "font-style": "normal"
>   }
> }
>   }
> }
>
> TOML:
>
> [InsetLayout]
>   LabelString = "Margin"
>   LatexType = "command"
>
>   [InsetLayout.Font]
> Size = "Small"
>
>   [InsetLayout.LabelFont]
> Color = "marginlabel"
> Size = "Small"
>
>   [InsetLayout.HTMLStyle.div.marginal]
> border = "2px solid black"
> font-style = "normal"
>
> YAML:
>
> InsetLayout:
>   LabelString: Margin
>   LatexType: command
>   Font:
> Size: Small
>   LabelFont:
> Color: marginlabel
> Size: Small
>   HTMLStyle:
> div.marginal:
>   border: 2px solid black
>   font-style: normal
>
> XML:
>
> 
>   Margin
>   command
>   
> Small
>   
>   
> marginlabel
> Small
>   
>   
> 
>   2px solid black
>   normal
> 
>   
> 
>
> Obviously there are errors because it considered the CSS inside it as
> part of the format. But I hope this gives you an impression of what
> each format can give us. 

Re: Layout file format change proposal

[Lorenzo Bertini]

Il giorno gio 28 mar 2024 alle ore 11:40 José Matos
 ha scritto:
>
> On Wed, 2024-03-27 at 11:02 -0400, Scott Kostyshak wrote:
> > Cool idea, Lorenzo! There have been some discussions in the past on
> > using standard formats, even for the .lyx file itself. I can see the
> > advantages of that but I don't know what the cost of converting to
> > them
> > is.
> >
> > Scott
>
> Typical answer to this:
> https://xkcd.com/927/
>
> :-)
>
> It makes sense for us to use a standard format.
> Some of the questions then are:
>  * which one is chosen (what is the most appropriate for our needs)?
>  * what the are advantages and drawbacks from this change?
>  * what is the transition plan?
>  * what is the effort required for this transition?
>
> Best regards,
> --
> José Abílio
> --

Ah, a classic xkcd. For once, however, the talk is about "removing"
one standard :)

* Which one to choose?
See research below.

* The advantages and drawbacks
As already mentioned, using a more common format means
  - people generally more familiar with the format
  - having more tools able to produce them, easing the efforts of
publishers trying to provide layouts
  - having parsers already available, for LyX and for people wanting
to manipulate them externally
The drawbacks that i can think of are
  - migration always takes developer effort
  - migration can take user effort too, to adapt to the new format
(this can be greatly mitigated by which format is chosen)

* The transition plan:
The new format is introduced *alongside* the old format. The LyX
version that brings the format will have all layouts converted, but
will accept the old format too. This "transition period" can last
indefinitely.

* The efforts required for the transition
We need to:
  - write or choose a parser for the new format that maps a file to a
LyX's params
  - write a converter from the old format to the new one
  - convert all the files to the new formats and test them

Here is some info I dug up regarding configuration formats. For pros
and cons I tried to limit them to one single aspect where they excel
or fail
- JSON:
  . pros: most widely supported
  . cons: not concise or readable, very distant from .layout
- TOML:
  . pros: very easy to read and write, even for humans
  . cons: not widespread, distant from .layout
- YAML:
  . pros: very easy to read and write, very close to .layout
  . cons: indentation is prone to syntax errors
- XML:
  . pros: the one and only, supports validation through schemas,
widely supported
  . cons: hard to read and write, very distant from .layout

I asked a chatbot to convert LyX's following layout extract into those formats:

LYX'S LAYOUT

InsetLayout Marginal
LabelString   Margin
LatexType command
Font
  SizeSmall
EndFont
LabelFont
  Color   marginlabel
  SizeSmall
EndFont
HTMLStyle
div.marginal {
border: 2px solid black;
font-style: normal;
}
EndHTMLStyle
End

JSON:

{
  "InsetLayout": {
"LabelString": "Margin",
"LatexType": "command",
"Font": {
  "Size": "Small"
},
"LabelFont": {
  "Color": "marginlabel",
  "Size": "Small"
},
"HTMLStyle": {
  "div.marginal": {
"border": "2px solid black",
"font-style": "normal"
  }
}
  }
}

TOML:

[InsetLayout]
  LabelString = "Margin"
  LatexType = "command"

  [InsetLayout.Font]
Size = "Small"

  [InsetLayout.LabelFont]
Color = "marginlabel"
Size = "Small"

  [InsetLayout.HTMLStyle.div.marginal]
border = "2px solid black"
font-style = "normal"

YAML:

InsetLayout:
  LabelString: Margin
  LatexType: command
  Font:
Size: Small
  LabelFont:
Color: marginlabel
Size: Small
  HTMLStyle:
div.marginal:
  border: 2px solid black
  font-style: normal

XML:


  Margin
  command
  
Small
  
  
marginlabel
Small
  
  

  2px solid black
  normal

  


Obviously there are errors because it considered the CSS inside it as
part of the format. But I hope this gives you an impression of what
each format can give us. Personally, and for what it counts (very
little), my pick would the the closest to the original format, and
that would be YAML.

Let me know what you think.
Lorenzo
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Layout file format change proposal

[José Matos]

On Wed, 2024-03-27 at 11:02 -0400, Scott Kostyshak wrote:
> Cool idea, Lorenzo! There have been some discussions in the past on
> using standard formats, even for the .lyx file itself. I can see the
> advantages of that but I don't know what the cost of converting to
> them
> is.
> 
> Scott

Typical answer to this:
https://xkcd.com/927/

:-)

It makes sense for us to use a standard format.
Some of the questions then are:
 * which one is chosen (what is the most appropriate for our needs)?
 * what the are advantages and drawbacks from this change?
 * what is the transition plan?
 * what is the effort required for this transition?

Best regards,
-- 
José Abílio
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Layout file format change proposal

[Scott Kostyshak]

On Wed, Mar 20, 2024 at 09:59:04AM +0100, Lorenzo Bertini wrote:
> Dear devs,
> I don't know if this has been discussed before. Lyx uses it's own
> format .layout (or .module), with it's own parser. However, the same
> information can be easily saved stored in another format. I asked a
> chatbot to convert "amsbook.layout" to an hypothetical "amsbook.yaml"
> file:
> 
> format: 104
> columns: 1
> sides: 2
> page_style: Headers
> docbook_root: book
> provides:
>   - amsmath: 1
>   - makeidx: 1
> class_options:
>   font_size: [8, 9, 10, 11, 12]
> default_modules:
>   - theorems-ams
>   - eqs-within-sections
>   - figs-within-sections
> styles:
>   Standard:
> category: MainText
> margin: Static
> latex_type: Paragraph
> latex_name: dummy
> par_indent: MM
> par_skip: 0.4
> align: Block
> align_possible: [Block, Left, Right, Center]
> label_type: No_Label
> docbook_tag: para
> preamble: "\numberwithin{section}{chapter}"
> inputs:
>   - stdsections.inc
>   - stdinsets.inc
>   - numreport.inc
>   - lyxmacros.inc
>   - stdlayouts.inc
>   - stdlists.inc
>   - stdfloats.inc
>   - stdcounters.inc
>   - amsdefs.inc
> unwanted_styles:
>   - Verse
>   - Bibliography:
>   toc_level: 0
> styles_append:
>   Section:
> align: Center
> font:
>   series: Bold
>   size: Large
> toc_level: 1
>   Subsection:
> font:
>   series: Bold
>   size: Normal
> toc_level: 2
>   Subsubsection:
> font:
>   shape: Italic
>   size: Normal
> toc_level: 3
>   Section*:
> align: Center
> font:
>   series: Bold
>   size: Large
>   Subsection*:
> font:
>   series: Bold
>   size: Normal
>   Subsubsection*:
> font:
>   shape: Italic
>   size: Normal
>   Paragraph:
> font:
>   series: Medium
> toc_level: 4
>   Chapter_Exercises:
> margin: First_Dynamic
> latex_type: Item_Environment
> latex_name: lyxxcb
> next_no_indent: 1
> left_margin: MMN
> label_sep: xx
> par_skip: 0.0
> item_sep: 0.2
> top_sep: 0.7
> bottom_sep: 0.7
> par_sep: 0.3
> align: Block
> align_possible: [Block, Left]
> label_type: Itemize
> label_font:
>   shape: Up
>   series: Bold
> preamble: "\newenvironment{lyxxcb}..."
> argument_listpreamble:
>   - label_string: "List preamble"
> menu_string: "List Preamble"
> tooltip: "LaTeX code to be inserted before the first item"
> pass_thru: 1
> font:
>   family: typewriter
>   color: latex
> docbook_tag: para
> docbook_attr: role='chapter-exercises'
> 
> I think it looks pretty good. The advantages of using an industry standard 
> are:
> 1. People already know the format. This could encourage publishers to
> provide layouts.
> 2. Existing and solid tools for parsing can be used. Even if not
> directly by LyX, someone manipulating layouts externally doesn't need
> to reinvent the wheel.
> 
> Let me know what you think.

Cool idea, Lorenzo! There have been some discussions in the past on
using standard formats, even for the .lyx file itself. I can see the
advantages of that but I don't know what the cost of converting to them
is.

Scott
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Layout file format change proposal

[Lorenzo Bertini]

Dear devs,
I don't know if this has been discussed before. Lyx uses it's own
format .layout (or .module), with it's own parser. However, the same
information can be easily saved stored in another format. I asked a
chatbot to convert "amsbook.layout" to an hypothetical "amsbook.yaml"
file:

format: 104
columns: 1
sides: 2
page_style: Headers
docbook_root: book
provides:
  - amsmath: 1
  - makeidx: 1
class_options:
  font_size: [8, 9, 10, 11, 12]
default_modules:
  - theorems-ams
  - eqs-within-sections
  - figs-within-sections
styles:
  Standard:
category: MainText
margin: Static
latex_type: Paragraph
latex_name: dummy
par_indent: MM
par_skip: 0.4
align: Block
align_possible: [Block, Left, Right, Center]
label_type: No_Label
docbook_tag: para
preamble: "\numberwithin{section}{chapter}"
inputs:
  - stdsections.inc
  - stdinsets.inc
  - numreport.inc
  - lyxmacros.inc
  - stdlayouts.inc
  - stdlists.inc
  - stdfloats.inc
  - stdcounters.inc
  - amsdefs.inc
unwanted_styles:
  - Verse
  - Bibliography:
  toc_level: 0
styles_append:
  Section:
align: Center
font:
  series: Bold
  size: Large
toc_level: 1
  Subsection:
font:
  series: Bold
  size: Normal
toc_level: 2
  Subsubsection:
font:
  shape: Italic
  size: Normal
toc_level: 3
  Section*:
align: Center
font:
  series: Bold
  size: Large
  Subsection*:
font:
  series: Bold
  size: Normal
  Subsubsection*:
font:
  shape: Italic
  size: Normal
  Paragraph:
font:
  series: Medium
toc_level: 4
  Chapter_Exercises:
margin: First_Dynamic
latex_type: Item_Environment
latex_name: lyxxcb
next_no_indent: 1
left_margin: MMN
label_sep: xx
par_skip: 0.0
item_sep: 0.2
top_sep: 0.7
bottom_sep: 0.7
par_sep: 0.3
align: Block
align_possible: [Block, Left]
label_type: Itemize
label_font:
  shape: Up
  series: Bold
preamble: "\newenvironment{lyxxcb}..."
argument_listpreamble:
  - label_string: "List preamble"
menu_string: "List Preamble"
tooltip: "LaTeX code to be inserted before the first item"
pass_thru: 1
font:
  family: typewriter
  color: latex
docbook_tag: para
docbook_attr: role='chapter-exercises'

I think it looks pretty good. The advantages of using an industry standard are:
1. People already know the format. This could encourage publishers to
provide layouts.
2. Existing and solid tools for parsing can be used. Even if not
directly by LyX, someone manipulating layouts externally doesn't need
to reinvent the wheel.

Let me know what you think.

Lorenzo
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: File format frozen?

[Jürgen Spitzmüller]

Am Dienstag, dem 18.07.2023 um 11:40 -0400 schrieb Richard Kimberly
Heck:
> It's fine to go ahead. We can freeze after you do that.

Thanks, done. I'll check for tex2lyx also.

-- 
Jürgen
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: File format frozen?

[Richard Kimberly Heck]

On 7/18/23 07:29, Jürgen Spitzmüller wrote:

Covington recently got several new features that resulted in a modified
syntax (additional arguments and some new macros).

I'd love to add support for this to the linguistics module, but it will
require a file format change.


It's fine to go ahead. We can freeze after you do that.

Riki


--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

File format frozen?

[Jürgen Spitzmüller]

Covington recently got several new features that resulted in a modified
syntax (additional arguments and some new macros).

I'd love to add support for this to the linguistics module, but it will
require a file format change.

Is this too late now? (I am fully fine with that; just asking).
 
-- 
Jürgen
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Should the author of a file format change update the file format of docs in master?

[Scott Kostyshak]

On Fri, Aug 12, 2016 at 07:23:54PM -0400, Scott Kostyshak wrote:
> On Sat, Aug 13, 2016 at 12:07:30AM +0100, José Abílio Matos wrote:
> > On Thursday, August 11, 2016 3:33:10 PM WEST Scott Kostyshak wrote:
> > > Good idea. I think it makes sense and does get rid of the problem.
> > > Please feel free to update Development.lyx with these instructions. Or
> > > if you want me to, I will do it eventually.
> > > 
> > > Scott
> > 
> > Please do.
> > 
> > I will be busy for some time. :-)
> 
> OK I'll do this if I don't see any objection in the next few days.

I instead created a trac ticket to create the script:
http://www.lyx.org/trac/ticket/10343

Without a script to automate the steps, I don't think there's a chance
that anyone would perform the steps manually.

Scott


signature.asc
Description: PGP signature

Re: Should the author of a file format change update the file format of docs in master?

[Scott Kostyshak]

On Sat, Aug 13, 2016 at 12:07:30AM +0100, José Abílio Matos wrote:
> On Thursday, August 11, 2016 3:33:10 PM WEST Scott Kostyshak wrote:
> > Good idea. I think it makes sense and does get rid of the problem.
> > Please feel free to update Development.lyx with these instructions. Or
> > if you want me to, I will do it eventually.
> > 
> > Scott
> 
> Please do.
> 
> I will be busy for some time. :-)

OK I'll do this if I don't see any objection in the next few days.

Scott


signature.asc
Description: PGP signature

Re: Should the author of a file format change update the file format of docs in master?

[José Abílio Matos]

On Thursday, August 11, 2016 3:33:10 PM WEST Scott Kostyshak wrote:
> Good idea. I think it makes sense and does get rid of the problem.
> Please feel free to update Development.lyx with these instructions. Or
> if you want me to, I will do it eventually.
> 
> Scott

Please do.

I will be busy for some time. :-)

-- 
José Abílio

Re: Should the author of a file format change update the file format of docs in master?

[Scott Kostyshak]

On Thu, Aug 11, 2016 at 10:46:29AM +0100, José Abílio Matos wrote:

> What do you think?

Good idea. I think it makes sense and does get rid of the problem.
Please feel free to update Development.lyx with these instructions. Or
if you want me to, I will do it eventually.

Scott


signature.asc
Description: PGP signature

Re: Should the author of a file format change update the file format of docs in master?

[José Abílio Matos]

On Sunday, August 7, 2016 8:00:53 PM WEST Scott Kostyshak wrote:
> I wrote that after what I recall being a discussion in a sub-thread. I
> wonder now if I should have made a separate discussion on the list, so
> I'm doing that now. Do others agree with the above paragraph? I have not
> actually authored many file format changes myself, so perhaps my
> intuition is off here.
> 
> Also, I wonder if updating the file format is annoying to document
> maintainers because they sometimes will need to compile the latest
> version of master in order to work on the documentation.
> 
> Please feel free to edit the above paragraph in Development.lyx.
> 
> Scott

I think that we can have a compromise if we ask developers to test the result 
of the lyx2lyx patches on the lyx documents.

If we assume that we are creating format N then it would be something like:

1) create a temporary directory and copy all the lyx documentation to there;

2) update all documents there to format N-1;

3) update all documents to format N and compare the differences with format 
N-1, noticing if there are any anomalies.

Eventually this can be automated and placed as a target for our build 
system(s).

Last month I did that for the existing format changes for the development 
branch.

What do you think?

Regards,
-- 
José Abílio

Re: Should the author of a file format change update the file format of docs in master?

[Pavel Sanda]

Scott Kostyshak wrote:
> Do others agree with the above paragraph? 

I do not think it's a smart idea. It makes keeping docs between
branch and master harder, add additional burden for devs and
add basically junk to git history. 

Pavel

Re: Should the author of a file format change update the file format of docs in master?

[Uwe Stöhr]

(I still don't have Internet at home and cannot have a look regularly.)

However, my opinion is not to update the docs, examples etc to a new format 
unless they contain features of the new format. ‎E.g. Jürgen's latest 
fileformat only affects Beamer documents. So it is OK to update the Beamer 
example files but not the other docs and templates.

Best regards Uwe

  Original Message  
From: Richard Heck
Sent: Montag, 8. August 2016 03:30
To: LyX Developers
Cc: Uwe Stöhr
Subject: Re: Should the author of a file format change update the file format 
of docs in master?

On 08/07/2016 08:00 PM, Scott Kostyshak wrote:
> When making a file format change, we currently have instructions for the 
> author of the file format change to update the file format of the docs.
>
> [snip]
>
> Also, I wonder if updating the file format is annoying to document
> maintainers because they sometimes will need to compile the latest
> version of master in order to work on the documentation.

I'd like to hear from Uwe about this.

Richard

Re: Should the author of a file format change update the file format of docs in master?

[Richard Heck]

On 08/07/2016 08:00 PM, Scott Kostyshak wrote:
> When making a file format change, we currently have instructions for the 
> author of the file format change to update the file format of the docs.
>
> [snip]
>
> Also, I wonder if updating the file format is annoying to document
> maintainers because they sometimes will need to compile the latest
> version of master in order to work on the documentation.

I'd like to hear from Uwe about this.

Richard

Should the author of a file format change update the file format of docs in master?

[Scott Kostyshak]

When making a file format change, we currently have instructions for the
author of the file format change to update the file format of the docs.
The following excerpt is in Development.lyx in Section 2.3:

  Update LyX's .lyx documentation files to the new format. The developer
  who makes the change knows best what changes to expect when inspecting
  the resulting diff. Because of this, you might be able to catch a bug
  in the lyx2lyx code that updates the format just by taking a quick
  scan through the large diff that is the result. Another advantage is
  that if later we suspect a bug in lyx2lyx we can easily see which
  layout update made an unexpected change by looking at the git log of a
  .lyx file that suffers the problem. To do this, first make sure that
  there are no changes to the git repository that you will not want to
  commit (this is needed because it will be convenient to commit with
  the command git commit -a). Then run the following command in the root
  folder of the source: python development/tools/updatedocs.py. Look at
  the resulting changes using the command git diff. If anything looks
  surprising, please investigate. Keep in mind that the case of
  LFUNs.lyx is special, because it is first generated with gen_lfuns.py
  before being converted to the latest format. Finally, commit using git
  commit -a.

I wrote that after what I recall being a discussion in a sub-thread. I
wonder now if I should have made a separate discussion on the list, so
I'm doing that now. Do others agree with the above paragraph? I have not
actually authored many file format changes myself, so perhaps my
intuition is off here.

Also, I wonder if updating the file format is annoying to document
maintainers because they sometimes will need to compile the latest
version of master in order to work on the documentation.

Please feel free to edit the above paragraph in Development.lyx.

Scott


signature.asc
Description: PGP signature

Re: layouts and file format changes (was: possible tag and tar of 2.2.0rc1 on Tuesday)

[Scott Kostyshak]

On Fri, Apr 01, 2016 at 08:39:14AM +, Guenter Milde wrote:
> Dear all,
> 
> 
> On 2016-04-01, Scott Kostyshak wrote:
> 
> > Günter has proposed layout patches to respond to changes in updated
> > LaTeX class files at the following two threads:
> > (acmsiggraph)
> > https://www.mail-archive.com/search?l=mid=ndgr7a%24kuf%241%40ger.gmane.org
> > (aastex6)
> > https://www.mail-archive.com/search?l=mid=ndj02g%244ht%241%40ger.gmane.org
> 
> For these patches to go in, we would need a consensus on the decision:
> 
>   New layouts and layouts with new styles/insets:
>   
> *do* require a file format change (status quo, see Development.lyx)
>   
>   or 
>   
> do *not* require a file format change if no lyx2lyx action is required.
> 
>   
> For the pros and cons see the recent thread on a policy for layout
> updates. For consequences, see the alternatives below.

From what I understand, you, Richard, and Georg are the ones who have
participated the most in the layout discussion and you are mostly in
agreement with each other, so I'm fine with whatever you all decide as
far as 2.2.0.

Thanks for your help on this complicated issue,

Scott


signature.asc
Description: PGP signature

layouts and file format changes (was: possible tag and tar of 2.2.0rc1 on Tuesday)

[Guenter Milde]

Dear all,


On 2016-04-01, Scott Kostyshak wrote:

> Günter has proposed layout patches to respond to changes in updated
> LaTeX class files at the following two threads:
> (acmsiggraph)
> https://www.mail-archive.com/search?l=mid=ndgr7a%24kuf%241%40ger.gmane.org
> (aastex6)
> https://www.mail-archive.com/search?l=mid=ndj02g%244ht%241%40ger.gmane.org

For these patches to go in, we would need a consensus on the decision:

  New layouts and layouts with new styles/insets:
  
    *do* require a file format change (status quo, see Development.lyx)
  
  or 
  
do *not* require a file format change if no lyx2lyx action is required.

  
For the pros and cons see the recent thread on a policy for layout
updates. For consequences, see the alternatives below.


Possible scenarios:

1. We decide (and note in Development.lyx), that new and updated layouts do
   *not* require a file format change.
   
   a) before Monday: -> the patches can go in rc1 (after a +1 for the
  acmsiggraph one)
  
  +1 better testing of new layouts before shipment of 2.2
  -1 time pressure
  
   b) after rc1:  -> patches can still go into 2.2.0 if Scott approves.
   
  -> patches can go into 2.2.x (as no file format
 change is required)
   
  
2. We decide, that new and updated layouts *do* require a file format change.

   -> I could commit the patches but would need a volunteer to do the
  file format update (currently I don't have the time to learn and
  perform this action).
  
   a) before Monday: -> patches can still go into 2.2.0 if Scott approves.
   
   b) after rc1:  
   
  -1 new layouts will have to wait for 2.3


 
Case 2b is "mitigated", if we decide on an official repository (download
URL) of new and update layouts for individuall installation. Then, users
depending on the new layouts can still use a stable LyX.



Günter

Re: [LyX/master] Missing file format bis from 0c3b88e3

[Jürgen Spitzmüller]

Am Donnerstag 10 Juli 2014, 21:59:59 schrieb Georg Baum:
 commit 1a073ea416674ed37b65a333126a65369a2882be
 Author: Georg Baum b...@lyx.org
 Date:   Thu Jul 10 21:59:17 2014 +0200
 
 Missing file format bis from 0c3b88e3

Sorry. And thanks.

Jürgen

Re: [LyX/master] Missing file format bis from 0c3b88e3

[Jürgen Spitzmüller]

Am Donnerstag 10 Juli 2014, 21:59:59 schrieb Georg Baum:
> commit 1a073ea416674ed37b65a333126a65369a2882be
> Author: Georg Baum <b...@lyx.org>
> Date:   Thu Jul 10 21:59:17 2014 +0200
> 
>     Missing file format bis from 0c3b88e3

Sorry. And thanks.

Jürgen

Re: file format question

[Richard Heck]

On 05/26/2014 05:02 PM, José Matos wrote:


On Monday 26 May 2014 22:07:01 Georg Baum wrote:

 What do you think? We cannot get a 100% correct solution, and I 
slightly


 tend towards the second option, since IMHO amsmath is needed for any 
serious


 math document anyway.





 Georg

I favour the second option for exactly the same arguments you have 
used. It is also reasonable to assume that people that relied on the 
bug/lyx current behaviour are capable to workaround the problems.




Same here.

Richard

Re: file format question

[Georg Baum]

Richard Heck wrote:

 On 05/26/2014 05:02 PM, José Matos wrote:

 I favour the second option for exactly the same arguments you have
 used. It is also reasonable to assume that people that relied on the
 bug/lyx current behaviour are capable to workaround the problems.

 
 Same here.

I hoped for these answers :-) This is implemented now.


Georg

Re: file format question

[Richard Heck]

On 05/26/2014 05:02 PM, José Matos wrote:


On Monday 26 May 2014 22:07:01 Georg Baum wrote:

> What do you think? We cannot get a 100% correct solution, and I 
slightly


> tend towards the second option, since IMHO amsmath is needed for any 
serious


> math document anyway.

>

>

> Georg

I favour the second option for exactly the same arguments you have 
used. It is also reasonable to assume that people that relied on the 
"bug"/lyx current behaviour are capable to workaround the problems.




Same here.

Richard

Re: file format question

[Georg Baum]

Richard Heck wrote:

> On 05/26/2014 05:02 PM, José Matos wrote:
>>
>> I favour the second option for exactly the same arguments you have
>> used. It is also reasonable to assume that people that relied on the
>> "bug"/lyx current behaviour are capable to workaround the problems.
>>
> 
> Same here.

I hoped for these answers :-) This is implemented now.


Georg

file format question

[Georg Baum]

Hi,

I am currently cleaning up my stash pile and finishing native support for 
\smash[t] and \smash[b] (this came from bug 8967) and \notag (same as 
\nonumber, but uses amsmath, this is helpful if you want to import AMS 
example documents with tex2lyx).

These commands cause now amsmath to be automatically loaded, and before they 
did not. This could in theory cause LaTeX erros, if a user used an own macro 
with a name used by amsmath. Therefore, we could say that this is a file 
format change, and disable amsmath in lyx2lyx if it was previously auto, one 
of the new commands is used and no other amsmath command is used.

Alternatively, we could consider the current status as a bug: Since we have 
the automatic amsmath loading already we could say that it should be 
complete, consider the current behaviour as a bug and no file format change 
is needed (this is different to the case where a new package is 
automatically loaded: In that case it is always a file format change).

The disadvantage of the first option is that the non-loading of amsmath is  
set for the future of this document which could cause similar issues as in 
bug 9069. The disadvantage of the second option is that it could create 
uncompilable documents.

What do you think? We cannot get a 100% correct solution, and I slightly 
tend towards the second option, since IMHO amsmath is needed for any serious 
math document anyway.


Georg

Re: file format question

[José Matos]

On Monday 26 May 2014 22:07:01 Georg Baum wrote:
 What do you think? We cannot get a 100% correct solution, and I slightly 
 tend towards the second option, since IMHO amsmath is needed for any serious 
 math document anyway.
 
 
 Georg

I favour the second option for exactly the same arguments you have used. It is 
also reasonable to assume that people that relied on the bug/lyx current 
behaviour are capable to workaround the problems.

-- 
José Abílio

file format question

[Georg Baum]

Hi,

I am currently cleaning up my stash pile and finishing native support for 
\smash[t] and \smash[b] (this came from bug 8967) and \notag (same as 
\nonumber, but uses amsmath, this is helpful if you want to import AMS 
example documents with tex2lyx).

These commands cause now amsmath to be automatically loaded, and before they 
did not. This could in theory cause LaTeX erros, if a user used an own macro 
with a name used by amsmath. Therefore, we could say that this is a file 
format change, and disable amsmath in lyx2lyx if it was previously auto, one 
of the new commands is used and no other amsmath command is used.

Alternatively, we could consider the current status as a bug: Since we have 
the automatic amsmath loading already we could say that it should be 
complete, consider the current behaviour as a bug and no file format change 
is needed (this is different to the case where a new package is 
automatically loaded: In that case it is always a file format change).

The disadvantage of the first option is that the non-loading of amsmath is  
set for the future of this document which could cause similar issues as in 
bug 9069. The disadvantage of the second option is that it could create 
uncompilable documents.

What do you think? We cannot get a 100% correct solution, and I slightly 
tend towards the second option, since IMHO amsmath is needed for any serious 
math document anyway.


Georg

Re: file format question

[José Matos]

On Monday 26 May 2014 22:07:01 Georg Baum wrote:
> What do you think? We cannot get a 100% correct solution, and I slightly 
> tend towards the second option, since IMHO amsmath is needed for any serious 
> math document anyway.
> 
> 
> Georg

I favour the second option for exactly the same arguments you have used. It is 
also reasonable to assume that people that relied on the "bug"/lyx current 
behaviour are capable to workaround the problems.

-- 
José Abílio

Re: About using git as file format for lyx ...

[Tommaso Cucinotta]

On 09/03/14 02:55, Pavel Sanda wrote:
 Tommaso Cucinotta wrote:
 luckily, we're filling up these weird .lyx files contents using that
 
 Believe it or not there are people who are using scripts for batch creation of
 lyx files for automatized reports and using sed for processing stuff inside 
 it.

I do believe it -- I can still remember when I sent a .lyx paper draft to a PhD
student, and he applied his changes with a plain-text editor, 
learning-by-example
the .lyx syntax, and later he asked me why don't we use for example latex?, 
and
when I showed him there was LyX to edit those .lyx files, his jaw dropped :-)...

Frankly speaking, if the current format works well, is unambiguous, supports 
well
various char encodings and languages, is parsed ok by external tools for example
for format upgrade and stuff, then let's just keep it as it is. To me, an XML
import/export would only make sense in view of .odt or .docx interoperability.

T.

Re: About using git as file format for lyx ...

[Pavel Sanda]

Tommaso Cucinotta wrote:
 student, and he applied his changes with a plain-text editor, 
 learning-by-example
 the .lyx syntax, and later he asked me why don't we use for example latex?, 
 and

You made my day :D 

Re: About using git as file format for lyx ...

[Tommaso Cucinotta]

On 09/03/14 02:55, Pavel Sanda wrote:
> Tommaso Cucinotta wrote:
>> luckily, we're filling up these weird .lyx files contents using that
> 
> Believe it or not there are people who are using scripts for batch creation of
> lyx files for automatized reports and using sed for processing stuff inside 
> it.

I do believe it -- I can still remember when I sent a .lyx paper draft to a PhD
student, and he applied his changes with a plain-text editor, 
learning-by-example
the .lyx syntax, and later he asked me "why don't we use for example latex?", 
and
when I showed him there was LyX to edit those .lyx files, his jaw dropped :-)...

Frankly speaking, if the current format works well, is unambiguous, supports 
well
various char encodings and languages, is parsed ok by external tools for example
for format upgrade and stuff, then let's just keep it as it is. To me, an XML
import/export would only make sense in view of .odt or .docx interoperability.

T.

Re: About using git as file format for lyx ...

[Pavel Sanda]

Tommaso Cucinotta wrote:
> student, and he applied his changes with a plain-text editor, 
> learning-by-example
> the .lyx syntax, and later he asked me "why don't we use for example latex?", 
> and

You made my day :D 

Re: About using git as file format for lyx ...

[Abdelrazak Younes]

On 07/03/2014 03:09, Tommaso Cucinotta wrote:

... instead of XML, as discussed so often ...

   https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV


Bad idea for a document, LyX is used to create structured document, not 
database, we are not going to create a new directory for each new 
inset... But I agree that XML is really not good for humans, we should 
switch to Json, not XML.


Abdel.

Re: About using git as file format for lyx ...

[Liviu Andronic]

On Sat, Mar 8, 2014 at 8:54 AM, Abdelrazak Younes you...@lyx.org wrote:
 On 07/03/2014 03:09, Tommaso Cucinotta wrote:

 ... instead of XML, as discussed so often ...

https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV


 Bad idea for a document, LyX is used to create structured document, not
 database, we are not going to create a new directory for each new inset...
 But I agree that XML is really not good for humans, we should switch to
 Json, not XML.

See related:
JSON vs XML: How JSON Is Superior To XML
https://www.udemy.com/blog/json-vs-xml/


Liviu

 Abdel.







-- 
Do you know how to read?
http://www.alienetworks.com/srtest.cfm
http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader
Do you know how to write?
http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail

Re: About using git as file format for lyx ...

[Liviu Andronic]

On Sat, Mar 8, 2014 at 10:51 AM, Liviu Andronic landronim...@gmail.com wrote:
 On Sat, Mar 8, 2014 at 8:54 AM, Abdelrazak Younes you...@lyx.org wrote:
 On 07/03/2014 03:09, Tommaso Cucinotta wrote:

 ... instead of XML, as discussed so often ...

https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV


 Bad idea for a document, LyX is used to create structured document, not
 database, we are not going to create a new directory for each new inset...
 But I agree that XML is really not good for humans, we should switch to
 Json, not XML.

 See related:
 JSON vs XML: How JSON Is Superior To XML
 https://www.udemy.com/blog/json-vs-xml/

For those dreaming of XML, the advantage of JSON would be that there
are readily available routes of conversion to and from XML (using
Python):
http://stackoverflow.com/questions/8988775/convert-json-to-xml-in-python
https://github.com/quandyfactory/dicttoxml
http://stackoverflow.com/questions/191536/converting-xml-to-json-using-python
https://github.com/martinblech/xmltodict


Liviu



 Liviu

 Abdel.







 --
 Do you know how to read?
 http://www.alienetworks.com/srtest.cfm
 http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader
 Do you know how to write?
 http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail



-- 
Do you know how to read?
http://www.alienetworks.com/srtest.cfm
http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader
Do you know how to write?
http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail

Re: About using git as file format for lyx ...

[Richard Heck]

On 03/08/2014 10:31 AM, Liviu Andronic wrote:

On Sat, Mar 8, 2014 at 10:51 AM, Liviu Andronic landronim...@gmail.com wrote:

On Sat, Mar 8, 2014 at 8:54 AM, Abdelrazak Younes you...@lyx.org wrote:

On 07/03/2014 03:09, Tommaso Cucinotta wrote:

... instead of XML, as discussed so often ...

https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV


Bad idea for a document, LyX is used to create structured document, not 
database, we are not going to create a new directory for each new inset...
But I agree that XML is really not good for humans, we should switch to Json, 
not XML.


See related:
JSON vs XML: How JSON Is Superior To XML
https://www.udemy.com/blog/json-vs-xml/


For those dreaming of XML, the advantage of JSON would be that there
are readily available routes of conversion to and from XML (using
Python):
http://stackoverflow.com/questions/8988775/convert-json-to-xml-in-python
https://github.com/quandyfactory/dicttoxml
http://stackoverflow.com/questions/191536/converting-xml-to-json-using-python
https://github.com/martinblech/xmltodict


Of course, that also means there are readily available routes of 
conversion to and from JSON, if we were using XML.


For what it's worth, I find JSON completely unreadable.

Richard

Re: About using git as file format for lyx ...

[Abdelrazak Younes]

On 08/03/2014 17:20, Richard Heck wrote:

On 03/08/2014 10:31 AM, Liviu Andronic wrote:
On Sat, Mar 8, 2014 at 10:51 AM, Liviu Andronic 
landronim...@gmail.com wrote:
On Sat, Mar 8, 2014 at 8:54 AM, Abdelrazak Younes you...@lyx.org 
wrote:

On 07/03/2014 03:09, Tommaso Cucinotta wrote:

... instead of XML, as discussed so often ...

https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV


Bad idea for a document, LyX is used to create structured document, 
not database, we are not going to create a new directory for each 
new inset...
But I agree that XML is really not good for humans, we should 
switch to Json, not XML.



See related:
JSON vs XML: How JSON Is Superior To XML
https://www.udemy.com/blog/json-vs-xml/


For those dreaming of XML, the advantage of JSON would be that there
are readily available routes of conversion to and from XML (using
Python):
http://stackoverflow.com/questions/8988775/convert-json-to-xml-in-python
https://github.com/quandyfactory/dicttoxml
http://stackoverflow.com/questions/191536/converting-xml-to-json-using-python 


https://github.com/martinblech/xmltodict


Of course, that also means there are readily available routes of 
conversion to and from JSON, if we were using XML.


For what it's worth, I find JSON completely unreadable.


Weird :-)

Anyway, moving to XML (or Json) will be a already an excellent move; and 
the one that does the work is the one that decide! I reckon that it 
would be much easier at this point to switch to XML thanks to your hard 
work on the XHTML export. So I will support your decision in any case ;-)


That being said, I *personally* find XML much too verbose and error 
prone compared to Json if you write it with a plain text editor. Json is 
also much more compact, has nice notion of arrays and numerical values, 
etc. Also an efficient binary representation of Json is really easy to 
do and would be very valuable to optimize parsing if needed. We could 
probably also reuse the one proposed by Qt if we modify it a bit (ucs4 
versus utf16).
Last by not least, if we were to switch to Json, I would also move all 
the layout and config files to Json; but hey, there's close to zero 
chance that I find the time to do it so talk is cheap ;-)


Cheers,
Abdel.

Re: About using git as file format for lyx ...

[Tommaso Cucinotta]

On 08/03/14 19:44, Abdelrazak Younes wrote:
 That being said, I *personally* find XML much too verbose and error
 prone compared to Json if you write it with a plain text editor.

luckily, we're filling up these weird .lyx files contents using that
convenient editor, what's its name?, was it ... LyX :-D?

And, after all, in terms of compactness, there's also that other quite
popular format..., should be called  ehm  was it ... LaTeX :-D?

AFAICS, JSON seems convenient when there's JavaScript processing
of these segments somewhere, but it's probably gaining ground outside
of web programming as well?

My2c,

T.

Re: About using git as file format for lyx ...

[Pavel Sanda]

Tommaso Cucinotta wrote:
 luckily, we're filling up these weird .lyx files contents using that

Believe it or not there are people who are using scripts for batch creation of
lyx files for automatized reports and using sed for processing stuff inside it.
But sure, one can move to plain latex.

Pavel

Re: About using git as file format for lyx ...

[Abdelrazak Younes]

On 07/03/2014 03:09, Tommaso Cucinotta wrote:

... instead of XML, as discussed so often ...

   https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV


Bad idea for a document, LyX is used to create structured document, not 
database, we are not going to create a new directory for each new 
inset... But I agree that XML is really not good for humans, we should 
switch to Json, not XML.


Abdel.

Re: About using git as file format for lyx ...

[Liviu Andronic]

On Sat, Mar 8, 2014 at 8:54 AM, Abdelrazak Younes  wrote:
> On 07/03/2014 03:09, Tommaso Cucinotta wrote:
>>
>> ... instead of XML, as discussed so often ...
>>
>>https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV
>
>
> Bad idea for a document, LyX is used to create structured document, not
> database, we are not going to create a new directory for each new inset...
> But I agree that XML is really not good for humans, we should switch to
> Json, not XML.
>
See related:
"JSON vs XML: How JSON Is Superior To XML"
https://www.udemy.com/blog/json-vs-xml/


Liviu

> Abdel.
>
>
>
>



-- 
Do you know how to read?
http://www.alienetworks.com/srtest.cfm
http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader
Do you know how to write?
http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail

Re: About using git as file format for lyx ...

[Liviu Andronic]

On Sat, Mar 8, 2014 at 10:51 AM, Liviu Andronic  wrote:
> On Sat, Mar 8, 2014 at 8:54 AM, Abdelrazak Younes  wrote:
>> On 07/03/2014 03:09, Tommaso Cucinotta wrote:
>>>
>>> ... instead of XML, as discussed so often ...
>>>
>>>https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV
>>
>>
>> Bad idea for a document, LyX is used to create structured document, not
>> database, we are not going to create a new directory for each new inset...
>> But I agree that XML is really not good for humans, we should switch to
>> Json, not XML.
>>
> See related:
> "JSON vs XML: How JSON Is Superior To XML"
> https://www.udemy.com/blog/json-vs-xml/
>
For those dreaming of XML, the advantage of JSON would be that there
are readily available routes of conversion to and from XML (using
Python):
http://stackoverflow.com/questions/8988775/convert-json-to-xml-in-python
https://github.com/quandyfactory/dicttoxml
http://stackoverflow.com/questions/191536/converting-xml-to-json-using-python
https://github.com/martinblech/xmltodict


Liviu


>
> Liviu
>
>> Abdel.
>>
>>
>>
>>
>
>
>
> --
> Do you know how to read?
> http://www.alienetworks.com/srtest.cfm
> http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader
> Do you know how to write?
> http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail



-- 
Do you know how to read?
http://www.alienetworks.com/srtest.cfm
http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader
Do you know how to write?
http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail

Re: About using git as file format for lyx ...

[Richard Heck]

On 03/08/2014 10:31 AM, Liviu Andronic wrote:

On Sat, Mar 8, 2014 at 10:51 AM, Liviu Andronic  wrote:

On Sat, Mar 8, 2014 at 8:54 AM, Abdelrazak Younes  wrote:

On 07/03/2014 03:09, Tommaso Cucinotta wrote:

... instead of XML, as discussed so often ...

https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV


Bad idea for a document, LyX is used to create structured document, not 
database, we are not going to create a new directory for each new inset...
But I agree that XML is really not good for humans, we should switch to Json, 
not XML.


See related:
"JSON vs XML: How JSON Is Superior To XML"
https://www.udemy.com/blog/json-vs-xml/


For those dreaming of XML, the advantage of JSON would be that there
are readily available routes of conversion to and from XML (using
Python):
http://stackoverflow.com/questions/8988775/convert-json-to-xml-in-python
https://github.com/quandyfactory/dicttoxml
http://stackoverflow.com/questions/191536/converting-xml-to-json-using-python
https://github.com/martinblech/xmltodict


Of course, that also means there are readily available routes of 
conversion to and from JSON, if we were using XML.


For what it's worth, I find JSON completely unreadable.

Richard

Re: About using git as file format for lyx ...

[Abdelrazak Younes]

On 08/03/2014 17:20, Richard Heck wrote:

On 03/08/2014 10:31 AM, Liviu Andronic wrote:
On Sat, Mar 8, 2014 at 10:51 AM, Liviu Andronic 
 wrote:
On Sat, Mar 8, 2014 at 8:54 AM, Abdelrazak Younes  
wrote:

On 07/03/2014 03:09, Tommaso Cucinotta wrote:

... instead of XML, as discussed so often ...

https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV


Bad idea for a document, LyX is used to create structured document, 
not database, we are not going to create a new directory for each 
new inset...
But I agree that XML is really not good for humans, we should 
switch to Json, not XML.



See related:
"JSON vs XML: How JSON Is Superior To XML"
https://www.udemy.com/blog/json-vs-xml/


For those dreaming of XML, the advantage of JSON would be that there
are readily available routes of conversion to and from XML (using
Python):
http://stackoverflow.com/questions/8988775/convert-json-to-xml-in-python
https://github.com/quandyfactory/dicttoxml
http://stackoverflow.com/questions/191536/converting-xml-to-json-using-python 


https://github.com/martinblech/xmltodict


Of course, that also means there are readily available routes of 
conversion to and from JSON, if we were using XML.


For what it's worth, I find JSON completely unreadable.


Weird :-)

Anyway, moving to XML (or Json) will be a already an excellent move; and 
the one that does the work is the one that decide! I reckon that it 
would be much easier at this point to switch to XML thanks to your hard 
work on the XHTML export. So I will support your decision in any case ;-)


That being said, I *personally* find XML much too verbose and error 
prone compared to Json if you write it with a plain text editor. Json is 
also much more compact, has nice notion of arrays and numerical values, 
etc. Also an efficient binary representation of Json is really easy to 
do and would be very valuable to optimize parsing if needed. We could 
probably also reuse the one proposed by Qt if we modify it a bit (ucs4 
versus utf16).
Last by not least, if we were to switch to Json, I would also move all 
the layout and config files to Json; but hey, there's close to zero 
chance that I find the time to do it so talk is cheap ;-)


Cheers,
Abdel.

Re: About using git as file format for lyx ...

[Tommaso Cucinotta]

On 08/03/14 19:44, Abdelrazak Younes wrote:
> That being said, I *personally* find XML much too verbose and error
> prone compared to Json if you write it with a plain text editor.

luckily, we're filling up these weird .lyx files contents using that
convenient editor, what's its name?, was it ... LyX :-D?

And, after all, in terms of compactness, there's also that other quite
popular format..., should be called  ehm  was it ... LaTeX :-D?

AFAICS, JSON seems convenient when there's JavaScript processing
of these segments somewhere, but it's probably gaining ground outside
of web programming as well?

My2c,

T.

Re: About using git as file format for lyx ...

[Pavel Sanda]

Tommaso Cucinotta wrote:
> luckily, we're filling up these weird .lyx files contents using that

Believe it or not there are people who are using scripts for batch creation of
lyx files for automatized reports and using sed for processing stuff inside it.
But sure, one can move to plain latex.

Pavel

Re: About using git as file format for lyx ...

[Pavel Sanda]

Liviu Andronic wrote:
 On Fri, Mar 7, 2014 at 3:09 AM, Tommaso Cucinotta tomm...@lyx.org wrote:
  ... instead of XML, as discussed so often ...
 
https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV
 
 He makes a strong case for GIT, and against XML. Especially taking
 into account human readability of the source file.

If human readability is the goal we should stay with the current format
in the first place ;)
Pavel

Re: About using git as file format for lyx ...

[Guenter Milde]

On 2014-03-07, Pavel Sanda wrote:
 Liviu Andronic wrote:
 On Fri, Mar 7, 2014 at 3:09 AM, Tommaso Cucinotta tomm...@lyx.org wrote:
  ... instead of XML, as discussed so often ...
 
https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV
 
 He makes a strong case for GIT, and against XML. Especially taking
 into account human readability of the source file.

However, reading the post and comments I saw just bold statements but no
evidence for backing this up.

 If human readability is the goal we should stay with the current format
 in the first place ;)

Not really. All the extra lines for inline constructs make it
considerabely more difficult to read as e.g. LaTeX (and in this regard
even more difficult to read than XML).

Günter

Re: About using git as file format for lyx ...

[Pavel Sanda]

Guenter Milde wrote:
  If human readability is the goal we should stay with the current format
  in the first place ;)
 
 Not really. All the extra lines for inline constructs make it
 considerabely more difficult to read as e.g. LaTeX (and in this regard
 even more difficult to read than XML).

Then we must have differrent eyes. Reading and hacking XML code is
worse for me than reading the current format.

Pavel

Re: About using git as file format for lyx ...

[Pavel Sanda]

Liviu Andronic wrote:
> On Fri, Mar 7, 2014 at 3:09 AM, Tommaso Cucinotta  wrote:
> > ... instead of XML, as discussed so often ...
> >
> >   https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV
> >
> He makes a strong case for GIT, and against XML. Especially taking
> into account human readability of the source file.

If human readability is the goal we should stay with the current format
in the first place ;)
Pavel

Re: About using git as file format for lyx ...

[Guenter Milde]

On 2014-03-07, Pavel Sanda wrote:
> Liviu Andronic wrote:
>> On Fri, Mar 7, 2014 at 3:09 AM, Tommaso Cucinotta  wrote:
>> > ... instead of XML, as discussed so often ...
>> >
>> >   https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV
>> >
>> He makes a strong case for GIT, and against XML. Especially taking
>> into account human readability of the source file.

However, reading the post and comments I saw just bold statements but no
evidence for backing this up.

> If human readability is the goal we should stay with the current format
> in the first place ;)

Not really. All the extra lines for inline constructs make it
considerabely more difficult to read as e.g. LaTeX (and in this regard
even more difficult to read than XML).

Günter

Re: About using git as file format for lyx ...

[Pavel Sanda]

Guenter Milde wrote:
> > If human readability is the goal we should stay with the current format
> > in the first place ;)
> 
> Not really. All the extra lines for inline constructs make it
> considerabely more difficult to read as e.g. LaTeX (and in this regard
> even more difficult to read than XML).

Then we must have differrent eyes. Reading and hacking XML code is
worse for me than reading the current format.

Pavel

About using git as file format for lyx ...

[Tommaso Cucinotta]

... instead of XML, as discussed so often ...

  https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV

T.

Re: About using git as file format for lyx ...

[stefano franchi]

On Mar 6, 2014 8:09 PM, Tommaso Cucinotta tomm...@lyx.org wrote:

 ... instead of XML, as discussed so often ...

   https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV

 T.

GSOC 2015?

S.

Re: About using git as file format for lyx ...

[Liviu Andronic]

On Fri, Mar 7, 2014 at 3:09 AM, Tommaso Cucinotta tomm...@lyx.org wrote:
 ... instead of XML, as discussed so often ...

   https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV

He makes a strong case for GIT, and against XML. Especially taking
into account human readability of the source file.

Liviu


 T.



-- 
Do you know how to read?
http://www.alienetworks.com/srtest.cfm
http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader
Do you know how to write?
http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail

About using git as file format for lyx ...

[Tommaso Cucinotta]

... instead of XML, as discussed so often ...

  https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV

T.

Re: About using git as file format for lyx ...

[stefano franchi]

On Mar 6, 2014 8:09 PM, "Tommaso Cucinotta"  wrote:
>
> ... instead of XML, as discussed so often ...
>
>   https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV
>
> T.

GSOC 2015?

S.

Re: About using git as file format for lyx ...

[Liviu Andronic]

On Fri, Mar 7, 2014 at 3:09 AM, Tommaso Cucinotta  wrote:
> ... instead of XML, as discussed so often ...
>
>   https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV
>
He makes a strong case for GIT, and against XML. Especially taking
into account human readability of the source file.

Liviu


> T.



-- 
Do you know how to read?
http://www.alienetworks.com/srtest.cfm
http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader
Do you know how to write?
http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail

Re: About XML LyX file format [was: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats]

[Richard Heck]

On 02/27/2014 03:58 PM, Georg Baum wrote:

Richard Heck wrote:


On 02/27/2014 11:27 AM, Alex Vergara Gil wrote:

I´m a LyX enthusiast and I can see how great this software is because
I have used it for 5 years by now. I´ve always asked in this list for
a static target lyx format that should be an intrinsic xml format,
which can evolve without change its structure and has some great
advantages over the current plain text format. Conversely the elyxer,
lyx2lyx and other scripts should need an upgrade.
My point is, Unless you have defined a static lyx format in which
every one can work without worry of format changes you cannot have a
robust plugin system. Developers can have more time to develop new
features than parsing every new format.
If xml is selected as static format, then a docx roundtrip will became
easier to achieve because it is a matter of converting xml structures
and the xml handling is very vast!

I think it's broadly agreed that LyX should have such a format. The
problem is finding the time to do it. It's on my radar, hopefully for
this summer.

Do you mean a native LyX file format which would be the primary format, or
an auxiliary format for interfacing with external tools? The native file
format would need to be non-static and would need format changes as LyX
develops (so would face similar problems to external tools as current .lyx),
and an intermediate static format would face similar problems regarding new
features as current lyx2lyx when converting into an older format. In both
cases I don't see how the format change problem could be solved.


I just meant an XML-based format that would at least always be parsable. 
Of course new constructs would be added, e.g., new kinds of insets.


Richard

Re: About XML LyX file format [was: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats]

[Georg Baum]

Alex Vergara Gil wrote:

 Do you mean a native LyX file format which would be the primary format,
 or an auxiliary format for interfacing with external tools?
 
 I mean xml as primary format.

Well, I wanted to know what Richard meant, but your opinion is welcome as 
well;-)

 If you have xml as primary format you doesn´t need anymore to change the
 format, just the content which can be dinamically added as xml is self
 descriptive, so you doesn´t have the problem of format changing, new
 features can be added as new self described objects. So a conversor must
 handle only with xml objects, and of course older versions may not be
 fully compatible with new features but they would still be able to read
 most of the files created with newer versions. Moreover a converter can
 handle insets, figures, etc in a more robust way if they are grouped into
 xml objects. I mean the objects it can interpret it can handle with them,
 and those who cannot well put as text or metadata as you wish, but it
 would still be readable.

OK, so you mean by static something else than I thought: A format that has 
some standard ways how the contents is formatted, but it would not forbid 
new stuff, e.g. a new inset. This is something we have more or less already 
(of course not in XML, but an inset is inbetween \begin_inset and 
\end_inset, its parameters use a standard form as well etc). This is of 
course possible and desirable.

My point is that any converter which should be part of a reliable export or 
round trip must be written for a specific version of the LyX (native or 
intermediate) file format. This is also true for XML based formats. They 
make it easier to handle unknown stuff gracefully and have a lot of other 
advantages, but if you want to really understand stuff and export it to a 
different format, then you need additional knowledge which you only have if 
you know the version.

Let me give an example: Suppose an inset has a parameter named foo which 
can take two different values: 0 and 1. Now some LyX developer extends 
the inset so that it can be used in different ways, and this requires to 
tweak its parameters. The result is that the parameter foo can now be one 
of the four values a, b, c and d. The old value 0 is 1:1 
equivalent to a, the old value 1 becomes either b or c, depending on 
another setting, and the new value d has no equivalent old value.

Now assume that this is an important inset that is converted to some object 
in the output file of the converter. If the converter now gets the new 
format, how should it know how to handle the new values? Of course it could 
ignore them and assume some default, but this would result in a less 
accurate conversion. If you feed it the correct file format version, then 
all goes well.

Therefore I am pretty sure that any conversion which would operate on a file 
produced by LyX (native or intermediate, XML or not) needs to be written for 
a specific version of this file format, and if the format evolves there 
should be a way to convert the newer versions into the one expected by the 
converter (either using something like lyx2lyx, some XSLT transformations or 
whatever is suitable). Otherwise you need too much guessing, and this does 
not work (the tex2lyx predecessor reLyX proved that).


Georg

Re: About XML LyX file format [was: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats]

[Richard Heck]

On 02/27/2014 03:58 PM, Georg Baum wrote:

Richard Heck wrote:


On 02/27/2014 11:27 AM, Alex Vergara Gil wrote:

I´m a LyX enthusiast and I can see how great this software is because
I have used it for 5 years by now. I´ve always asked in this list for
a static target lyx format that should be an intrinsic xml format,
which can evolve without change its structure and has some great
advantages over the current plain text format. Conversely the elyxer,
lyx2lyx and other scripts should need an upgrade.
My point is, Unless you have defined a static lyx format in which
every one can work without worry of format changes you cannot have a
robust plugin system. Developers can have more time to develop new
features than parsing every new format.
If xml is selected as static format, then a docx roundtrip will became
easier to achieve because it is a matter of converting xml structures
and the xml handling is very vast!

I think it's broadly agreed that LyX should have such a format. The
problem is finding the time to do it. It's on my radar, hopefully for
this summer.

Do you mean a native LyX file format which would be the primary format, or
an auxiliary format for interfacing with external tools? The native file
format would need to be non-static and would need format changes as LyX
develops (so would face similar problems to external tools as current .lyx),
and an intermediate static format would face similar problems regarding new
features as current lyx2lyx when converting into an older format. In both
cases I don't see how the "format change" problem could be solved.


I just meant an XML-based format that would at least always be parsable. 
Of course new constructs would be added, e.g., new kinds of insets.


Richard

Re: About XML LyX file format [was: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats]

[Georg Baum]

Alex Vergara Gil wrote:

>> Do you mean a native LyX file format which would be the primary format,
>> or an auxiliary format for interfacing with external tools?
> 
> I mean xml as primary format.

Well, I wanted to know what Richard meant, but your opinion is welcome as 
well;-)

> If you have xml as primary format you doesn´t need anymore to change the
> format, just the content which can be dinamically added as xml is self
> descriptive, so you doesn´t have the problem of format changing, new
> features can be added as new self described objects. So a conversor must
> handle only with xml objects, and of course older versions may not be
> fully compatible with new features but they would still be able to read
> most of the files created with newer versions. Moreover a converter can
> handle insets, figures, etc in a more robust way if they are grouped into
> xml objects. I mean the objects it can interpret it can handle with them,
> and those who cannot well put as text or metadata as you wish, but it
> would still be readable.

OK, so you mean by static something else than I thought: A format that has 
some standard ways how the contents is formatted, but it would not forbid 
new stuff, e.g. a new inset. This is something we have more or less already 
(of course not in XML, but an inset is inbetween \begin_inset and 
\end_inset, its parameters use a standard form as well etc). This is of 
course possible and desirable.

My point is that any converter which should be part of a reliable export or 
round trip must be written for a specific version of the LyX (native or 
intermediate) file format. This is also true for XML based formats. They 
make it easier to handle unknown stuff gracefully and have a lot of other 
advantages, but if you want to really understand stuff and export it to a 
different format, then you need additional knowledge which you only have if 
you know the version.

Let me give an example: Suppose an inset has a parameter named "foo" which 
can take two different values: "0" and "1". Now some LyX developer extends 
the inset so that it can be used in different ways, and this requires to 
tweak its parameters. The result is that the parameter "foo" can now be one 
of the four values "a", "b", "c" and "d". The old value "0" is 1:1 
equivalent to "a", the old value "1" becomes either "b" or "c", depending on 
another setting, and the new value "d" has no equivalent old value.

Now assume that this is an important inset that is converted to some object 
in the output file of the converter. If the converter now gets the new 
format, how should it know how to handle the new values? Of course it could 
ignore them and assume some default, but this would result in a less 
accurate conversion. If you feed it the correct file format version, then 
all goes well.

Therefore I am pretty sure that any conversion which would operate on a file 
produced by LyX (native or intermediate, XML or not) needs to be written for 
a specific version of this file format, and if the format evolves there 
should be a way to convert the newer versions into the one expected by the 
converter (either using something like lyx2lyx, some XSLT transformations or 
whatever is suitable). Otherwise you need too much guessing, and this does 
not work (the tex2lyx predecessor reLyX proved that).


Georg

About XML LyX file format [was: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats]

[Alex Vergara Gil]

The downside to any python-based approach, though, is that the LyX format 
is

a moving target. The script would need to be updated with every syntax
change.


I assume this problem would persist with a pandoc approach, isn't it?
The Lyx reader module would still be format-dependent, unless we go
with LaTeX.

Stefano



Dear all

I´m a LyX enthusiast and I can see how great this software is because I have 
used it for 5 years by now. I´ve always asked in this list for a static 
target lyx format that should be an intrinsic xml format, which can evolve 
without change its structure and has some great advantages over the current 
plain text format. Conversely the elyxer, lyx2lyx and other scripts should 
need an upgrade.
My point is, Unless you have defined a static lyx format in which every one 
can work without worry of format changes you cannot have a robust plugin 
system. Developers can have more time to develop new features than parsing 
every new format.
If xml is selected as static format, then a docx roundtrip will became 
easier to achieve because it is a matter of converting xml structures and 
the xml handling is very vast!


I only wanted to drop 2 cents in this discussion, so see this mail as a 
personal point of view


Regards!

Alex Vergara Gil
MSc Nuclear Physics
SSDL, CPHR, Havana Cuba
http://www.cphr.edu.cu 

Re: About XML LyX file format [was: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats]

[Richard Heck]

On 02/27/2014 11:27 AM, Alex Vergara Gil wrote:


The downside to any python-based approach, though, is that the LyX 
format is

a moving target. The script would need to be updated with every syntax
change.


I assume this problem would persist with a pandoc approach, isn't it?
The Lyx reader module would still be format-dependent, unless we go
with LaTeX.

Stefano



Dear all

I´m a LyX enthusiast and I can see how great this software is because 
I have used it for 5 years by now. I´ve always asked in this list for 
a static target lyx format that should be an intrinsic xml format, 
which can evolve without change its structure and has some great 
advantages over the current plain text format. Conversely the elyxer, 
lyx2lyx and other scripts should need an upgrade.
My point is, Unless you have defined a static lyx format in which 
every one can work without worry of format changes you cannot have a 
robust plugin system. Developers can have more time to develop new 
features than parsing every new format.
If xml is selected as static format, then a docx roundtrip will became 
easier to achieve because it is a matter of converting xml structures 
and the xml handling is very vast!


I think it's broadly agreed that LyX should have such a format. The 
problem is finding the time to do it. It's on my radar, hopefully for 
this summer.


Richard

Re: About XML LyX file format [was: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats]

[Georg Baum]

Richard Heck wrote:

 On 02/27/2014 11:27 AM, Alex Vergara Gil wrote:

 I´m a LyX enthusiast and I can see how great this software is because
 I have used it for 5 years by now. I´ve always asked in this list for
 a static target lyx format that should be an intrinsic xml format,
 which can evolve without change its structure and has some great
 advantages over the current plain text format. Conversely the elyxer,
 lyx2lyx and other scripts should need an upgrade.
 My point is, Unless you have defined a static lyx format in which
 every one can work without worry of format changes you cannot have a
 robust plugin system. Developers can have more time to develop new
 features than parsing every new format.
 If xml is selected as static format, then a docx roundtrip will became
 easier to achieve because it is a matter of converting xml structures
 and the xml handling is very vast!
 
 I think it's broadly agreed that LyX should have such a format. The
 problem is finding the time to do it. It's on my radar, hopefully for
 this summer.

Do you mean a native LyX file format which would be the primary format, or 
an auxiliary format for interfacing with external tools? The native file 
format would need to be non-static and would need format changes as LyX 
develops (so would face similar problems to external tools as current .lyx), 
and an intermediate static format would face similar problems regarding new 
features as current lyx2lyx when converting into an older format. In both 
cases I don't see how the format change problem could be solved.


Georg

Re: About XML LyX file format [was: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats]

[Alex Vergara Gil]

Do you mean a native LyX file format which would be the primary format, or
an auxiliary format for interfacing with external tools?


I mean xml as primary format.


The native file
format would need to be non-static and would need format changes as LyX
develops (so would face similar problems to external tools as current 
.lyx),
and an intermediate static format would face similar problems regarding 
new

features as current lyx2lyx when converting into an older format. In both
cases I don't see how the format change problem could be solved.



If you have xml as primary format you doesn´t need anymore to change the 
format, just the content which can be dinamically added as xml is self 
descriptive, so you doesn´t have the problem of format changing, new 
features can be added as new self described objects. So a conversor must 
handle only with xml objects, and of course older versions may not be fully 
compatible with new features but they would still be able to read most of 
the files created with newer versions. Moreover a converter can handle 
insets, figures, etc in a more robust way if they are grouped into xml 
objects. I mean the objects it can interpret it can handle with them, and 
those who cannot well put as text or metadata as you wish, but it would 
still be readable.




Georg



Alex

About XML LyX file format [was: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats]

[Alex Vergara Gil]

The downside to any python-based approach, though, is that the LyX format 
is

a moving target. The script would need to be updated with every syntax
change.


I assume this problem would persist with a pandoc approach, isn't it?
The Lyx reader module would still be format-dependent, unless we go
with LaTeX.

Stefano



Dear all

I´m a LyX enthusiast and I can see how great this software is because I have 
used it for 5 years by now. I´ve always asked in this list for a static 
target lyx format that should be an intrinsic xml format, which can evolve 
without change its structure and has some great advantages over the current 
plain text format. Conversely the elyxer, lyx2lyx and other scripts should 
need an upgrade.
My point is, Unless you have defined a static lyx format in which every one 
can work without worry of format changes you cannot have a robust plugin 
system. Developers can have more time to develop new features than parsing 
every new format.
If xml is selected as static format, then a docx roundtrip will became 
easier to achieve because it is a matter of converting xml structures and 
the xml handling is very vast!


I only wanted to drop 2 cents in this discussion, so see this mail as a 
personal point of view


Regards!

Alex Vergara Gil
MSc Nuclear Physics
SSDL, CPHR, Havana Cuba
http://www.cphr.edu.cu 

Re: About XML LyX file format [was: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats]

[Richard Heck]

On 02/27/2014 11:27 AM, Alex Vergara Gil wrote:


The downside to any python-based approach, though, is that the LyX 
format is

a moving target. The script would need to be updated with every syntax
change.


I assume this problem would persist with a pandoc approach, isn't it?
The Lyx reader module would still be format-dependent, unless we go
with LaTeX.

Stefano



Dear all

I´m a LyX enthusiast and I can see how great this software is because 
I have used it for 5 years by now. I´ve always asked in this list for 
a static target lyx format that should be an intrinsic xml format, 
which can evolve without change its structure and has some great 
advantages over the current plain text format. Conversely the elyxer, 
lyx2lyx and other scripts should need an upgrade.
My point is, Unless you have defined a static lyx format in which 
every one can work without worry of format changes you cannot have a 
robust plugin system. Developers can have more time to develop new 
features than parsing every new format.
If xml is selected as static format, then a docx roundtrip will became 
easier to achieve because it is a matter of converting xml structures 
and the xml handling is very vast!


I think it's broadly agreed that LyX should have such a format. The 
problem is finding the time to do it. It's on my radar, hopefully for 
this summer.


Richard

Re: About XML LyX file format [was: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats]

[Georg Baum]

Richard Heck wrote:

> On 02/27/2014 11:27 AM, Alex Vergara Gil wrote:
>>
>> I´m a LyX enthusiast and I can see how great this software is because
>> I have used it for 5 years by now. I´ve always asked in this list for
>> a static target lyx format that should be an intrinsic xml format,
>> which can evolve without change its structure and has some great
>> advantages over the current plain text format. Conversely the elyxer,
>> lyx2lyx and other scripts should need an upgrade.
>> My point is, Unless you have defined a static lyx format in which
>> every one can work without worry of format changes you cannot have a
>> robust plugin system. Developers can have more time to develop new
>> features than parsing every new format.
>> If xml is selected as static format, then a docx roundtrip will became
>> easier to achieve because it is a matter of converting xml structures
>> and the xml handling is very vast!
> 
> I think it's broadly agreed that LyX should have such a format. The
> problem is finding the time to do it. It's on my radar, hopefully for
> this summer.

Do you mean a native LyX file format which would be the primary format, or 
an auxiliary format for interfacing with external tools? The native file 
format would need to be non-static and would need format changes as LyX 
develops (so would face similar problems to external tools as current .lyx), 
and an intermediate static format would face similar problems regarding new 
features as current lyx2lyx when converting into an older format. In both 
cases I don't see how the "format change" problem could be solved.


Georg

Re: About XML LyX file format [was: [GSoC 2014]Interested in Round trip conversion between LyX and .docx formats]

[Alex Vergara Gil]

Do you mean a native LyX file format which would be the primary format, or
an auxiliary format for interfacing with external tools?


I mean xml as primary format.


The native file
format would need to be non-static and would need format changes as LyX
develops (so would face similar problems to external tools as current 
.lyx),
and an intermediate static format would face similar problems regarding 
new

features as current lyx2lyx when converting into an older format. In both
cases I don't see how the "format change" problem could be solved.



If you have xml as primary format you doesn´t need anymore to change the 
format, just the content which can be dinamically added as xml is self 
descriptive, so you doesn´t have the problem of format changing, new 
features can be added as new self described objects. So a conversor must 
handle only with xml objects, and of course older versions may not be fully 
compatible with new features but they would still be able to read most of 
the files created with newer versions. Moreover a converter can handle 
insets, figures, etc in a more robust way if they are grouped into xml 
objects. I mean the objects it can interpret it can handle with them, and 
those who cannot well put as text or metadata as you wish, but it would 
still be readable.




Georg



Alex

Re: Select file format with save-as?

[Guenter Milde]

On 2012-05-15, Tommaso Cucinotta wrote:
 On 11/05/12 10:41, Jürgen Spitzmüller wrote:
 2012/5/11 Jean-Marc Lasgouttes:
 Tell us how to do that with Qt and we will do it :)
 I think adding a way to (optionally) pass a different name to the
 export target would not be too difficult.

 isn't that already part of the File-Export-Export As... dialog ?
 There, you can specify the target file-name and format.

You can only specify the file-name but the format is always LyX-native.
(There is a drop-down list to filter the list of existing files.)

Günter

Re: Select file format with save-as?

[Tommaso Cucinotta]

On 16/05/12 07:47, Guenter Milde wrote:

On 2012-05-15, Tommaso Cucinotta wrote:

On 11/05/12 10:41, Jürgen Spitzmüller wrote:
I think adding a way to (optionally) pass a different name to the 
export target would not be too difficult. 

isn't that already part of the File-Export-Export As... dialog ?
There, you can specify the target file-name and format.

You can only specify the file-name but the format is always LyX-native.
(There is a drop-down list to filter the list of existing files.)


Well, picking a format from the drop-down list allows you to export to 
that format.
For example, I open the Intro.lyx manual, then I do File-Export-Export 
As...,
then I choose /tmp/intro.txt, and I get the introduction exported as 
plain text.

If I pick-up the PDF (ps2pdf) as format, then I get /tmp/Intro.pdf.
So, you can choose the target file-name and export format. What else 
would you

need ?

Thanks,

T.

Re: Select file format with save-as?

[Guenter Milde]

On 2012-05-16, Tommaso Cucinotta wrote:
 On 16/05/12 07:47, Guenter Milde wrote:
 On 2012-05-15, Tommaso Cucinotta wrote:
 On 11/05/12 10:41, Jürgen Spitzmüller wrote:
 I think adding a way to (optionally) pass a different name to the 
 export target would not be too difficult. 
 isn't that already part of the File-Export-Export As... dialog ?
 There, you can specify the target file-name and format.
 You can only specify the file-name but the format is always LyX-native.
 (There is a drop-down list to filter the list of existing files.)

 Well, picking a format from the drop-down list allows you to export to 
 that format.

Sorry, I mixed this up with the Save_As (which only allows lyx-native
format in the LyX-instances' version.) My original request was to support
other document source formats (older/newer LyX formats, tex, but not PDF, PS)
in the Save_As dialogue (but I was overruled on this).


 For example, I open the Intro.lyx manual, then I do File-Export-Export 
 As...,
 then I choose /tmp/intro.txt, and I get the introduction exported as 
 plain text.
 If I pick-up the PDF (ps2pdf) as format, then I get /tmp/Intro.pdf.
 So, you can choose the target file-name and export format. What else 
 would you  need ?

This is what I need. The current release 2.0.3, does not have the
Export_As dialogue. So now I only need a 2.1 release...

Thanks and sorry for the noise,

Günter

Re: Select file format with save-as?

[Guenter Milde]

On 2012-05-15, Tommaso Cucinotta wrote:
> On 11/05/12 10:41, Jürgen Spitzmüller wrote:
>> 2012/5/11 Jean-Marc Lasgouttes:
>>> Tell us how to do that with Qt and we will do it :)
>> I think adding a way to (optionally) pass a different name to the
>> export target would not be too difficult.

> isn't that already part of the File->Export->Export As... dialog ?
> There, you can specify the target file-name and format.

You can only specify the file-name but the format is always LyX-native.
(There is a drop-down list to filter the list of existing files.)

Günter

Re: Select file format with save-as?

[Tommaso Cucinotta]

On 16/05/12 07:47, Guenter Milde wrote:

On 2012-05-15, Tommaso Cucinotta wrote:

On 11/05/12 10:41, Jürgen Spitzmüller wrote:
I think adding a way to (optionally) pass a different name to the 
export target would not be too difficult. 

isn't that already part of the File->Export->Export As... dialog ?
There, you can specify the target file-name and format.

You can only specify the file-name but the format is always LyX-native.
(There is a drop-down list to filter the list of existing files.)


Well, picking a format from the drop-down list allows you to export to 
that format.
For example, I open the Intro.lyx manual, then I do File->Export->Export 
As...,
then I choose /tmp/intro.txt, and I get the introduction exported as 
plain text.

If I pick-up the PDF (ps2pdf) as format, then I get /tmp/Intro.pdf.
So, you can choose the target file-name and export format. What else 
would you

need ?

Thanks,

T.

Re: Select file format with save-as?

[Guenter Milde]

On 2012-05-16, Tommaso Cucinotta wrote:
> On 16/05/12 07:47, Guenter Milde wrote:
>> On 2012-05-15, Tommaso Cucinotta wrote:
>>> On 11/05/12 10:41, Jürgen Spitzmüller wrote:
 I think adding a way to (optionally) pass a different name to the 
 export target would not be too difficult. 
>>> isn't that already part of the File->Export->Export As... dialog ?
>>> There, you can specify the target file-name and format.
>> You can only specify the file-name but the format is always LyX-native.
>> (There is a drop-down list to filter the list of existing files.)

> Well, picking a format from the drop-down list allows you to export to 
> that format.

Sorry, I mixed this up with the Save_As (which only allows lyx-native
format in the LyX-instances' version.) My original request was to support
other document source formats (older/newer LyX formats, tex, but not PDF, PS)
in the Save_As dialogue (but I was overruled on this).


> For example, I open the Intro.lyx manual, then I do File->Export->Export 
> As...,
> then I choose /tmp/intro.txt, and I get the introduction exported as 
> plain text.
> If I pick-up the PDF (ps2pdf) as format, then I get /tmp/Intro.pdf.
> So, you can choose the target file-name and export format. What else 
> would you > need ?

This is what I need. The current release 2.0.3, does not have the
Export_As dialogue. So now I only need a 2.1 release...

Thanks and sorry for the noise,

Günter

Re: Select file format with save-as?

[Tommaso Cucinotta]

On 11/05/12 10:41, Jürgen Spitzmüller wrote:

2012/5/11 Jean-Marc Lasgouttes:

Tell us how to do that with Qt and we will do it :)

I think adding a way to (optionally) pass a different name to the
export target would not be too difficult.

isn't that already part of the File-Export-Export As... dialog ?
There, you can specify the target file-name and format.

Bye,

T.

Re: Select file format with save-as?

[Tommaso Cucinotta]

On 11/05/12 10:41, Jürgen Spitzmüller wrote:

2012/5/11 Jean-Marc Lasgouttes:

Tell us how to do that with Qt and we will do it :)

I think adding a way to (optionally) pass a different name to the
export target would not be too difficult.

isn't that already part of the File->Export->Export As... dialog ?
There, you can specify the target file-name and format.

Bye,

T.

Re: Select file format with save-as?

[Guenter Milde]

On 2012-05-11, Scott Kostyshak wrote:
 Guenter Milde [mi...@users.sf.net]
 Sent: Friday, May 11, 2012 1:50 AM

Currently, the filename of the exported file is determined by LyX and you
 can only change it later in a file manager (e.g. when exporting to an
 older lyx file format). OTOH, LyX's save-as dialogue does only save in
 LyX's native format.

In Inkscape and OpenOffice, the save-as dialogue has a format selector
 that allows saving in other source formats (and our FileExport is called
 FileSave_Copy_as). I would like to see such a format selector (for older
 LyX formats, LaTeX, pdfLaTeX, ..., HTML, OpenOffice, rtf, txt) in LyX
 too.

 Does
 file  export  export as
 do what you want?

Probably. I can't tell, as I cannot find it in my LyX 2.0.3. But it would
solve a long standing issue.

Still, this leaves open my suggestion to provide this option under
save_as via a Format drop-down list.

Günter

RE: Select file format with save-as?

[Scott Kostyshak]

From: Guenter Milde [mi...@users.sf.net]
Sent: Friday, May 11, 2012 2:12 AM

Probably. I can't tell, as I cannot find it in my LyX 2.0.3. But it would
solve a long standing issue.

It was implemented in the development version. See here:
http://git.lyx.org/?p=lyx.git;a=blob_plain;f=RELEASE-NOTES;hb=HEAD

Still, this leaves open my suggestion to provide this option under
save_as via a Format drop-down list.

You are correct. This is not implemented. I think this is just a matter of 
preference. I like it how it is because it makes you realize that you are 
losing information by exporting instead of saving. There is no extra time that 
would be saved if it were changed to how you suggest. You do have to realize 
before you go to save that what you really want to do is export. Perhaps an 
infrequent user of LyX might forget this. And I do agree with you that many 
other programs behave how you suggest. To chalk another point up for your 
argument, it's a little strange that there is a files of type drop-down box in 
the save dialog even though there is only one choice. Nonetheless, I still 
prefer how it is.

Scott

Re: Select file format with save-as?

[Jean-Marc Lasgouttes]

Le 11/05/12 08:33, Scott Kostyshak a écrit :

Still, this leaves open my suggestion to provide this option under
save_as via a Format drop-down list.


You are correct. This is not implemented. I think this is just a matter of 
preference. I like it how it is because it makes you realize that you are 
losing information by exporting instead of saving. There is no extra time that 
would be saved if it were changed to how you suggest. You do have to realize 
before you go to save that what you really want to do is export. Perhaps an 
infrequent user of LyX might forget this. And I do agree with you that many 
other programs behave how you suggest. To chalk another point up for your 
argument, it's a little strange that there is a files of type drop-down box in 
the save dialog even though there is only one choice. Nonetheless, I still 
prefer how it is.


Tell us how to do that with Qt and we will do it :)

JMarc

Re: Select file format with save-as?

[Jürgen Spitzmüller]

2012/5/11 Jean-Marc Lasgouttes:
 Tell us how to do that with Qt and we will do it :)

I think adding a way to (optionally) pass a different name to the
export target would not be too difficult. GUI-wise, we can add this
possibility to the Custom export (f.k.a. Send to) dialog. I agree
with Scott's concerns wrt the save dialog.

Jürgen

 JMarc

RE: Select file format with save-as?

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Friday, May 11, 2012 4:28 AM

Tell us how to do that with Qt and we will do it :)

Ah. The only relevant option I see is QFileDialog::HideNameFilterDetails() 
which doesn't help us. I thought there would be a way to disable that box.

Scott

Re: Select file format with save-as?

[Jean-Marc Lasgouttes]

Le 11/05/12 12:12, Scott Kostyshak a écrit :

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Friday, May 11, 2012 4:28 AM


Tell us how to do that with Qt and we will do it :)


Ah. The only relevant option I see is QFileDialog::HideNameFilterDetails() 
which doesn't help us. I thought there would be a way to disable that box.


What we need to do is reimplement our own native file dialogs on mac, 
windows and maybe gnome. It might be simpler that we expect, but 
programmers are needed.


JMarc

Re: Select file format with save-as?

[Olivier Ripoll]

On 11.05.2012 08:33, Scott Kostyshak wrote:

From: Guenter Milde [mi...@users.sf.net]
Sent: Friday, May 11, 2012 2:12 AM


[...]

Still, this leaves open my suggestion to provide this option under
save_as via a Format drop-down list.


You are correct. This is not implemented. I think this is just a
matter of  preference. I like it how it is because it makes you
realize that you are  losing information by exporting instead of
saving. There is no extra time  that would be saved if it were
changed to how you suggest. You do have to  realize before you go
to save that what you really want to do is export.Perhaps an
infrequent user of LyX might forget this. And I do agree with you
that many other programs behave how you suggest. To chalk another
point up foryour argument, it's a little strange that there is a
files of type drop-down  box in the save dialog even though there
is only one choice. Nonetheless,  I still prefer how it is.


Gimp 2.8 was released recently, and one of the GUI changes is that from 
now on, Save, Save As and Save a Copy only save as xcf (native 
file format) and to zipped versions of that format.

To save under any other image format, one must use Export.

Their rational is explained in the release notes:
http://www.gimp.org/release-notes/gimp-2.8.html

Best regards,

Olivier.