Re: r34591 - in lyx-devel/trunk: lib/scripts src src/insets src/tex2lyx

[Guenter Milde]

On 2010-06-08, José Matos wrote:

 On the same vein as your work and since I dislike the latex output of
 lyx- beamer I have a workaround in the form of a python script and
 another layout.

Did already you consider using custom insets for the frames?

I started doing this for the seminar.layout.
This easily translates to the way these environments are used in LaTeX.

Unfortunately, there is no easy obsoleting a Layout with an Inset.

Günter

Re: XML format status

[Sam Liddicott]

 On 09/06/10 04:27, Peter Kümmel wrote:

Am Dienstag, den 08.06.2010, 17:22 -0400 schrieb Richard Heck:

On 06/08/2010 03:49 PM, Peter Kümmel wrote:

Am Dienstag, den 08.06.2010, 20:52 +0200 schrieb Andre Poenitz:


On Tue, Jun 08, 2010 at 04:29:21PM +0200, Abdelrazak Younes wrote:


On 06/08/2010 03:27 PM, Vincent van Ravesteijn wrote:


What is the current status or thinking of the XML format for lyx 2?



Ideally, LyX 2 would have an XML file format. However, no-one is
actively working on the issue, so we postponed it.

As far as I know, we didn't really decide when and how to do the transition.


I worked recently with JSon format (www.json.org), cleaner to the
human, faster to parse and less verbose than XML, quite nice...


This might indeed be a good option.


http://gitorious.org/JsonQt/
http://gitorious.org/qjson


But the question remains what is the aim of the new format: is it for
us, or is it for other who wanna generate, manipulate, ... LyX files.



My understanding was that the point was to make the LyX format more
easily parsable by LyX and, in particular, to provide validation that a
file really is in the proper format. So, for us, but without breaking
the easy manipulability of LyX files via sed, awk, etc.


I would prefer a more readable format than XML like json, even I would
use Lua, because it is the future scripting languange in LaTeX, but
I assume we could never explain the rest of the world, why we we don't
use beloved XML. So let's use XML. And validating a XML with a DTD is
really an advantage.


This last point should not be underestimated by those who want to 
transform Lyx documents using sed and awk. A DTD  lets you know that you 
did not break the document.


Because XSLT is such a convenient transforming tool, xml will make 
conversion to and from other (xml-ish) documents much simpler than it is 
for lyx at the moment.


XSLT is grep/sed/awk for xml. If you start with the default identity 
transform you just then add patterns for the paths you want to 
change/exclude. XSLT is sed for structured documents. (I've done some 
nasty 4K long sed scripts that are state-machines for transforming 
structured documents, and XSLT is much nicer).


However, I will admit there are rarely 1-liners for xslt; but I did 
write a sed pattern for xslt that lets you make 1-lines, by passing the 
xpath match pattern, and replace string on the command line.


JSON is an advantage where there is not an xml parser available, but are 
there any systems that can't provide a DOM tree from a document these days?


lua has xml parsing extensions and will need them as the future 
scripting language of latex, because it will be dealing with xml even if 
not with an xml tex format. (And I prefer an xml tex format because 
currently only tex can interpret tex because the syntax is extensible, 
hence the difficulty that Lyx can have importing tex documents - it 
can't even safely know how to ignore the bits it doesn't understand!).


--
*Sam's signature*

Re: XML format status

[Guenter Milde]

On 2010-06-08, Sam Liddicott wrote:
 This is a multi-part message in MIME format.
 --050502020101020702060201
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 Content-Transfer-Encoding: 7bit

   On 08/06/10 15:27, Pavel Sanda wrote:
 Sam Liddicott wrote:
 I also still dream about lyx being the first decent docbook editor.
 are you aware of the fact that lyx already have output routines for docbook?

 Yes, but I recall being told that it wasn't supported and that if it 
 still worked it was pretty much by good luck these days.

 If that  is no longer true, I'd be glad to know!

It is still true.

OTOH, native XHTML output is brand new (LyX 2) and actively worked
on, so you might give it a try.

Günter

Re: XML format status

[Pavel Sanda]

Guenter Milde wrote:
 On 2010-06-08, Sam Liddicott wrote:
  This is a multi-part message in MIME format.
  --050502020101020702060201
  Content-Type: text/plain; charset=ISO-8859-1; format=flowed
  Content-Transfer-Encoding: 7bit
 
On 08/06/10 15:27, Pavel Sanda wrote:
  Sam Liddicott wrote:
  I also still dream about lyx being the first decent docbook editor.
  are you aware of the fact that lyx already have output routines for 
  docbook?
 
  Yes, but I recall being told that it wasn't supported and that if it 
  still worked it was pretty much by good luck these days.
 
  If that  is no longer true, I'd be glad to know!
 
 It is still true.

its not maintained, but it should work. the problem is that it outputs
docbook sgml, version 4.x. if i understand correctly transforming
it into docbook xml is oneliner patch in lyx sources. what involves
transformation into newer version, that i'm not sure but there are
already working tools which do this if its not easy for us.

to me it looks like that as far lyx sources is concerned it would
be quite easy to make your dream true. what we miss is somebody
who knows docbook well enough to provide us the information
what exactly should be changed in the output xml file (hint!).

http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg151947.html
http://www.neomantic.com/tutorials/lyx-and-docbookXML

pavel

Re: XML format status

[Pavel Sanda]

Sam Liddicott wrote:
 I would prefer a more readable format than XML like json, even I would
 use Lua, because it is the future scripting languange in LaTeX, but
 I assume we could never explain the rest of the world, why we we don't
 use beloved XML. So let's use XML. And validating a XML with a DTD is
 really an advantage.

 This last point should not be underestimated by those who want to transform 
 Lyx documents using sed and awk. A DTD  lets you know that you did not 
 break the document.

and not overestimated by those who want it to be readable and editable by
humans, which was starting point of this subthread... ;)

pavel

Re: XML format status

[Sam Liddicott]

 On 09/06/10 09:10, Pavel Sanda wrote:

Guenter Milde wrote:

On 2010-06-08, Sam Liddicott wrote:

This is a multi-part message in MIME format.
--050502020101020702060201
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
   On 08/06/10 15:27, Pavel Sanda wrote:

Sam Liddicott wrote:

I also still dream about lyx being the first decent docbook editor.

are you aware of the fact that lyx already have output routines for docbook?

Yes, but I recall being told that it wasn't supported and that if it
still worked it was pretty much by good luck these days.
If that  is no longer true, I'd be glad to know!

It is still true.

its not maintained, but it should work. the problem is that it outputs
docbook sgml, version 4.x. if i understand correctly transforming
it into docbook xml is oneliner patch in lyx sources. what involves
transformation into newer version, that i'm not sure but there are
already working tools which do this if its not easy for us.

to me it looks like that as far lyx sources is concerned it would
be quite easy to make your dream true. what we miss is somebody
who knows docbook well enough to provide us the information
what exactly should be changed in the output xml file (hint!).

http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg151947.html
http://www.neomantic.com/tutorials/lyx-and-docbookXML


Thanks - you give me good hope.
It is ironic that I want to use Lyx to avoid having to know docbook too 
well, but may have to learn it to fixup lyx!


Ah well!

Sam*

*

Re: XML format status

[Pavel Sanda]

Sam Liddicott wrote:
 Thanks - you give me good hope.
 It is ironic that I want to use Lyx to avoid having to know docbook too 
 well, but may have to learn it to fixup lyx!

we are waiting for your mail :)
pavel

Re: [Patch] New version of Keytest.

[Pavel Sanda]

John McCabe-Dansted wrote:
 I was wondering, would you prefer it if I could submit future updates
 to keytest as a set of smaller patches, rather than one big one?

i would prefer to give you a commit access.

its pita to apply patches with new files and changed svn properties because one
needs to do this manually. short peek in the archives shows you are at least
two years around and contributed 152k of scripts into kesytest. i think thats
enough. JMarc?

pavel

Re: Compiler Warnings

[Jean-Marc LASGOUTTES]

Stephan Witt st.w...@gmx.net writes:

 Apropos...

 What about this?

Looks good.

JMarc

Re: r34591 - in lyx-devel/trunk: lib/scripts src src/insets src/tex2lyx

[Jürgen Spitzmüller]

2010/6/9 Guenter Milde:
 Did already you consider using custom insets for the frames?

 I started doing this for the seminar.layout.
 This easily translates to the way these environments are used in LaTeX.

While I agree this is cleaner, there are also disadvantages:

1. you lose the outliner features. I.e., you cannot any longer reorder
frames via the outliner (which is a rather crucial feature for me).

2. inserting a frame is double work: you need to insert the frame and
you (usually) need to insert a title

Both are solveable, but both should be solved IMHO before we change the layout.

Jürgen

Re: [PATCH for branch] warnings and const

[Jean-Marc LASGOUTTES]

Jürgen Spitzmüller sp...@lyx.org writes:

 Jean-Marc LASGOUTTES wrote:
 OK for branch?

 Yes.

The 3 patches have been applied.

JMarc

Re: [Patch] New version of Keytest.

[Jean-Marc LASGOUTTES]

Pavel Sanda sa...@lyx.org writes:

 John McCabe-Dansted wrote:
 I was wondering, would you prefer it if I could submit future updates
 to keytest as a set of smaller patches, rather than one big one?

 i would prefer to give you a commit access.

 its pita to apply patches with new files and changed svn properties
 because one needs to do this manually. short peek in the archives
 shows you are at least two years around and contributed 152k of
 scripts into kesytest. i think thats enough. JMarc?

John, do you want to have access?

JMarc

Re: lyxrc.dist: Path relative to installation directory

[Jean-Marc LASGOUTTES]

Joost Verburg jo...@lyx.org writes:
 I was wondering how I can make paths in e.g. the path_prefix in
 lyxrc.dist relative to the LyX installation directory?

 For example, instead of,

 \path_prefix C:\Program Files (x86)\LyX16\dir

 something like:

 \path_prefix %LYXDIR%\dir

 I'm trying to make LyX/Windows more portable and get rid of the
 LyXLauncher hack because this is causing problems with Windows 7.

One solution would be to make relative paths relative to lyxdir (and
maybe userdir too). Would that make sense to you?

JMarc

Re: r34635 - lyx-devel/trunk/src/tex2lyx

[Jean-Marc LASGOUTTES]

rgh...@lyx.org writes:
 Also, disable corresponding code for required arguments. tex2lyx does
 not produce a high enough file format yet for this to make sense, I
 don't think.

Indeed.

JMarc

Re: lyxrc.dist: Path relative to installation directory

[Joost Verburg]

On 6/9/2010 10:17 AM, Jean-Marc LASGOUTTES wrote:

One solution would be to make relative paths relative to lyxdir (and
maybe userdir too). Would that make sense to you?


Yes, that makes perfect sense. It will make the Windows installer less 
complicated and allow for a portable version to be created.


Joost

Re: r34591 - in lyx-devel/trunk: lib/scripts src src/insets src/tex2lyx

[Guenter Milde]

On 2010-06-08, José Matos wrote:

> On the same vein as your work and since I dislike the latex output of
> lyx- beamer I have a workaround in the form of a python script and
> another layout.

Did already you consider using custom insets for the frames?

I started doing this for the seminar.layout.
This easily translates to the way these environments are used in LaTeX.

Unfortunately, there is no easy obsoleting a Layout with an Inset.

Günter

Re: XML format status

[Sam Liddicott]

 On 09/06/10 04:27, Peter Kümmel wrote:

Am Dienstag, den 08.06.2010, 17:22 -0400 schrieb Richard Heck:

On 06/08/2010 03:49 PM, Peter Kümmel wrote:

Am Dienstag, den 08.06.2010, 20:52 +0200 schrieb Andre Poenitz:


On Tue, Jun 08, 2010 at 04:29:21PM +0200, Abdelrazak Younes wrote:


On 06/08/2010 03:27 PM, Vincent van Ravesteijn wrote:


What is the current status or thinking of the XML format for lyx 2?



Ideally, LyX 2 would have an XML file format. However, no-one is
actively working on the issue, so we postponed it.

As far as I know, we didn't really decide when and how to do the transition.


I worked recently with JSon format (www.json.org), cleaner to the
human, faster to parse and less verbose than XML, quite nice...


This might indeed be a good option.


http://gitorious.org/JsonQt/
http://gitorious.org/qjson


But the question remains what is the aim of the new format: is it for
us, or is it for other who wanna generate, manipulate, ... LyX files.



My understanding was that the point was to make the LyX format more
easily parsable by LyX and, in particular, to provide validation that a
file really is in the proper format. So, for us, but without breaking
the easy manipulability of LyX files via sed, awk, etc.


I would prefer a more readable format than XML like json, even I would
use Lua, because it is the future scripting languange in LaTeX, but
I assume we could never explain the rest of the world, why we we don't
use beloved XML. So let's use XML. And validating a XML with a DTD is
really an advantage.


This last point should not be underestimated by those who want to 
transform Lyx documents using sed and awk. A DTD  lets you know that you 
did not break the document.


Because XSLT is such a convenient transforming tool, xml will make 
conversion to and from other (xml-ish) documents much simpler than it is 
for lyx at the moment.


XSLT is grep/sed/awk for xml. If you start with the default "identity" 
transform you just then add patterns for the paths you want to 
change/exclude. XSLT is sed for structured documents. (I've done some 
nasty 4K long sed scripts that are state-machines for transforming 
structured documents, and XSLT is much nicer).


However, I will admit there are rarely 1-liners for xslt; but I did 
write a sed pattern for xslt that lets you make 1-lines, by passing the 
xpath match pattern, and replace string on the command line.


JSON is an advantage where there is not an xml parser available, but are 
there any systems that can't provide a DOM tree from a document these days?


lua has xml parsing extensions and will need them as the future 
scripting language of latex, because it will be dealing with xml even if 
not with an xml tex format. (And I prefer an xml tex format because 
currently only tex can interpret tex because the syntax is extensible, 
hence the difficulty that Lyx can have importing tex documents - it 
can't even safely know how to ignore the bits it doesn't understand!).


--
*Sam's signature*

Re: XML format status

[Guenter Milde]

On 2010-06-08, Sam Liddicott wrote:
> This is a multi-part message in MIME format.
> --050502020101020702060201
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit

>   On 08/06/10 15:27, Pavel Sanda wrote:
>> Sam Liddicott wrote:
>>> I also still dream about lyx being the first decent docbook editor.
>> are you aware of the fact that lyx already have output routines for docbook?

> Yes, but I recall being told that it wasn't supported and that if it 
> still worked it was pretty much by good luck these days.

> If that  is no longer true, I'd be glad to know!

It is still true.

OTOH, native XHTML output is brand new (LyX 2) and actively worked
on, so you might give it a try.

Günter

Re: XML format status

[Pavel Sanda]

Guenter Milde wrote:
> On 2010-06-08, Sam Liddicott wrote:
> > This is a multi-part message in MIME format.
> > --050502020101020702060201
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> > Content-Transfer-Encoding: 7bit
> 
> >   On 08/06/10 15:27, Pavel Sanda wrote:
> >> Sam Liddicott wrote:
> >>> I also still dream about lyx being the first decent docbook editor.
> >> are you aware of the fact that lyx already have output routines for 
> >> docbook?
> 
> > Yes, but I recall being told that it wasn't supported and that if it 
> > still worked it was pretty much by good luck these days.
> 
> > If that  is no longer true, I'd be glad to know!
> 
> It is still true.

its not maintained, but it should work. the problem is that it outputs
docbook sgml, version 4.x. if i understand correctly transforming
it into docbook xml is oneliner patch in lyx sources. what involves
transformation into newer version, that i'm not sure but there are
already working tools which do this if its not easy for us.

to me it looks like that as far lyx sources is concerned it would
be quite easy to make your dream true. what we miss is somebody
who knows docbook well enough to provide us the information
what exactly should be changed in the output xml file (hint!).

http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg151947.html
http://www.neomantic.com/tutorials/lyx-and-docbookXML

pavel

Re: XML format status

[Pavel Sanda]

Sam Liddicott wrote:
>> I would prefer a more readable format than XML like json, even I would
>> use Lua, because it is the future scripting languange in LaTeX, but
>> I assume we could never explain the rest of the world, why we we don't
>> use beloved XML. So let's use XML. And validating a XML with a DTD is
>> really an advantage.
>
> This last point should not be underestimated by those who want to transform 
> Lyx documents using sed and awk. A DTD  lets you know that you did not 
> break the document.

and not overestimated by those who want it to be readable and editable by
humans, which was starting point of this subthread... ;)

pavel

Re: XML format status

[Sam Liddicott]

 On 09/06/10 09:10, Pavel Sanda wrote:

Guenter Milde wrote:

On 2010-06-08, Sam Liddicott wrote:

This is a multi-part message in MIME format.
--050502020101020702060201
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
   On 08/06/10 15:27, Pavel Sanda wrote:

Sam Liddicott wrote:

I also still dream about lyx being the first decent docbook editor.

are you aware of the fact that lyx already have output routines for docbook?

Yes, but I recall being told that it wasn't supported and that if it
still worked it was pretty much by good luck these days.
If that  is no longer true, I'd be glad to know!

It is still true.

its not maintained, but it should work. the problem is that it outputs
docbook sgml, version 4.x. if i understand correctly transforming
it into docbook xml is oneliner patch in lyx sources. what involves
transformation into newer version, that i'm not sure but there are
already working tools which do this if its not easy for us.

to me it looks like that as far lyx sources is concerned it would
be quite easy to make your dream true. what we miss is somebody
who knows docbook well enough to provide us the information
what exactly should be changed in the output xml file (hint!).

http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg151947.html
http://www.neomantic.com/tutorials/lyx-and-docbookXML


Thanks - you give me good hope.
It is ironic that I want to use Lyx to avoid having to know docbook too 
well, but may have to learn it to fixup lyx!


Ah well!

Sam*

*

Re: XML format status

[Pavel Sanda]

Sam Liddicott wrote:
> Thanks - you give me good hope.
> It is ironic that I want to use Lyx to avoid having to know docbook too 
> well, but may have to learn it to fixup lyx!

we are waiting for your mail :)
pavel

Re: [Patch] New version of Keytest.

[Pavel Sanda]

John McCabe-Dansted wrote:
> I was wondering, would you prefer it if I could submit future updates
> to keytest as a set of smaller patches, rather than one big one?

i would prefer to give you a commit access.

its pita to apply patches with new files and changed svn properties because one
needs to do this manually. short peek in the archives shows you are at least
two years around and contributed 152k of scripts into kesytest. i think thats
enough. JMarc?

pavel

Re: Compiler Warnings

[Jean-Marc LASGOUTTES]

Stephan Witt  writes:

> Apropos...
>
> What about this?

Looks good.

JMarc

Re: r34591 - in lyx-devel/trunk: lib/scripts src src/insets src/tex2lyx

[Jürgen Spitzmüller]

2010/6/9 Guenter Milde:
> Did already you consider using custom insets for the frames?
>
> I started doing this for the seminar.layout.
> This easily translates to the way these environments are used in LaTeX.

While I agree this is cleaner, there are also disadvantages:

1. you lose the outliner features. I.e., you cannot any longer reorder
frames via the outliner (which is a rather crucial feature for me).

2. inserting a frame is double work: you need to insert the frame and
you (usually) need to insert a title

Both are solveable, but both should be solved IMHO before we change the layout.

Jürgen

Re: [PATCH for branch] warnings and const

[Jean-Marc LASGOUTTES]

Jürgen Spitzmüller  writes:

> Jean-Marc LASGOUTTES wrote:
>> OK for branch?
>
> Yes.

The 3 patches have been applied.

JMarc

Re: [Patch] New version of Keytest.

[Jean-Marc LASGOUTTES]

Pavel Sanda  writes:

> John McCabe-Dansted wrote:
>> I was wondering, would you prefer it if I could submit future updates
>> to keytest as a set of smaller patches, rather than one big one?
>
> i would prefer to give you a commit access.
>
> its pita to apply patches with new files and changed svn properties
> because one needs to do this manually. short peek in the archives
> shows you are at least two years around and contributed 152k of
> scripts into kesytest. i think thats enough. JMarc?

John, do you want to have access?

JMarc

Re: lyxrc.dist: Path relative to installation directory

[Jean-Marc LASGOUTTES]

Joost Verburg  writes:
> I was wondering how I can make paths in e.g. the path_prefix in
> lyxrc.dist relative to the LyX installation directory?
>
> For example, instead of,
>
> \path_prefix "C:\Program Files (x86)\LyX16\dir"
>
> something like:
>
> \path_prefix "%LYXDIR%\dir"
>
> I'm trying to make LyX/Windows more portable and get rid of the
> LyXLauncher hack because this is causing problems with Windows 7.

One solution would be to make relative paths relative to lyxdir (and
maybe userdir too). Would that make sense to you?

JMarc

Re: r34635 - lyx-devel/trunk/src/tex2lyx

[Jean-Marc LASGOUTTES]

rgh...@lyx.org writes:
> Also, disable corresponding code for required arguments. tex2lyx does
> not produce a high enough file format yet for this to make sense, I
> don't think.

Indeed.

JMarc

Re: lyxrc.dist: Path relative to installation directory

[Joost Verburg]

On 6/9/2010 10:17 AM, Jean-Marc LASGOUTTES wrote:

One solution would be to make relative paths relative to lyxdir (and
maybe userdir too). Would that make sense to you?


Yes, that makes perfect sense. It will make the Windows installer less 
complicated and allow for a portable version to be created.


Joost