Manveru wrote:
Have you ever merge XML? I tried - it is horrible work.
It depends entirely on how the XML document is formatted. There's
nothing that prevents XML with sensible line breaks, for example.
I keep lots of XHTML documents in CVS. They're well-formatted, so
merging works just
Steve Litt wrote:
Trouble is, replacing \begin..\end with .../ is a hack. LyX developers
have defined LyX native format as \begin always is the first character on a
line. There's no such requirement in XML, and if we require it, that's a
hack. If we don't require it, LyX-XML parsing becomes
Michael Wojcik wrote:
I don't expect the
switch to XML to cause me any problems, and to be honest I'm a bit
puzzled by all the worrying.
/me too :-)
Abdel.
Manveru wrote:
Have you ever merge XML? I tried - it is horrible work.
It depends entirely on how the XML document is formatted. There's
nothing that prevents XML with sensible line breaks, for example.
I keep lots of XHTML documents in CVS. They're well-formatted, so
merging works just
Steve Litt wrote:
Trouble is, replacing \begin..\end with .../ is a hack. LyX developers
have defined LyX native format as \begin always is the first character on a
line. There's no such requirement in XML, and if we require it, that's a
hack. If we don't require it, LyX-XML parsing becomes
Michael Wojcik wrote:
I don't expect the
switch to XML to cause me any problems, and to be honest I'm a bit
puzzled by all the worrying.
/me too :-)
Abdel.
Manveru wrote:
Have you ever merge XML? I tried - it is horrible work.
It depends entirely on how the XML document is formatted. There's
nothing that prevents XML with sensible line breaks, for example.
I keep lots of XHTML documents in CVS. They're well-formatted, so
merging works just
Steve Litt wrote:
Trouble is, replacing \begin..\end with <>... is a hack. LyX developers
have defined LyX native format as \begin always is the first character on a
line. There's no such requirement in XML, and if we require it, that's a
hack. If we don't require it, LyX-XML parsing becomes
Michael Wojcik wrote:
I don't expect the
switch to XML to cause me any problems, and to be honest I'm a bit
puzzled by all the worrying.
/me too :-)
Abdel.
On Monday 28 July 2008 01:10, John McCabe-Dansted wrote:
On Fri, Jul 25, 2008 at 4:43 PM, Manveru [EMAIL PROTECTED] wrote:
To the discussion about data format preference:
I am reading all your comments about XML, YAML and other suggested data
formats. And this discussion reminds me
On 28.07.08, Steve Litt wrote:
On Monday 28 July 2008 01:10, John McCabe-Dansted wrote:
On Fri, Jul 25, 2008 at 4:43 PM, Manveru [EMAIL PROTECTED] wrote:
To the discussion about data format preference:
... Have you ever merged XML? I tried - it is horrible work.
I don't see why it
G. Milde wrote:
On 28.07.08, Steve Litt wrote:
On Monday 28 July 2008 01:10, John McCabe-Dansted wrote:
On Fri, Jul 25, 2008 at 4:43 PM, Manveru[EMAIL PROTECTED] wrote:
To the discussion about data format preference:
... Have you ever merged XML? I tried - it is horrible work.
I don't see
John McCabe-Dansted wrote:
On Fri, Jul 25, 2008 at 4:43 PM, Manveru[EMAIL PROTECTED] wrote:
To the discussion about data format preference:
I am reading all your comments about XML, YAML and other suggested data
formats. And this discussion reminds me something about XML what almost
nobody is
On Monday 28 July 2008 01:10, John McCabe-Dansted wrote:
On Fri, Jul 25, 2008 at 4:43 PM, Manveru [EMAIL PROTECTED] wrote:
To the discussion about data format preference:
I am reading all your comments about XML, YAML and other suggested data
formats. And this discussion reminds me
On 28.07.08, Steve Litt wrote:
On Monday 28 July 2008 01:10, John McCabe-Dansted wrote:
On Fri, Jul 25, 2008 at 4:43 PM, Manveru [EMAIL PROTECTED] wrote:
To the discussion about data format preference:
... Have you ever merged XML? I tried - it is horrible work.
I don't see why it
G. Milde wrote:
On 28.07.08, Steve Litt wrote:
On Monday 28 July 2008 01:10, John McCabe-Dansted wrote:
On Fri, Jul 25, 2008 at 4:43 PM, Manveru[EMAIL PROTECTED] wrote:
To the discussion about data format preference:
... Have you ever merged XML? I tried - it is horrible work.
I don't see
John McCabe-Dansted wrote:
On Fri, Jul 25, 2008 at 4:43 PM, Manveru[EMAIL PROTECTED] wrote:
To the discussion about data format preference:
I am reading all your comments about XML, YAML and other suggested data
formats. And this discussion reminds me something about XML what almost
nobody is
On Monday 28 July 2008 01:10, John McCabe-Dansted wrote:
> On Fri, Jul 25, 2008 at 4:43 PM, Manveru <[EMAIL PROTECTED]> wrote:
> > To the discussion about data format preference:
> >
> > I am reading all your comments about XML, YAML and other suggested data
> > formats. And this discussion
On 28.07.08, Steve Litt wrote:
> On Monday 28 July 2008 01:10, John McCabe-Dansted wrote:
> > On Fri, Jul 25, 2008 at 4:43 PM, Manveru <[EMAIL PROTECTED]> wrote:
> > > To the discussion about data format preference:
> > >
> > > ... Have you ever merged XML? I tried - it is horrible work.
> >
> > I
G. Milde wrote:
On 28.07.08, Steve Litt wrote:
On Monday 28 July 2008 01:10, John McCabe-Dansted wrote:
On Fri, Jul 25, 2008 at 4:43 PM, Manveru<[EMAIL PROTECTED]> wrote:
To the discussion about data format preference:
... Have you ever merged XML? I tried - it is horrible work.
I don't
John McCabe-Dansted wrote:
On Fri, Jul 25, 2008 at 4:43 PM, Manveru<[EMAIL PROTECTED]> wrote:
To the discussion about data format preference:
I am reading all your comments about XML, YAML and other suggested data
formats. And this discussion reminds me something about XML what almost
nobody
On Thursday 24 July 2008 13:07:19 Pavel Sanda wrote:
frankly - these are nice dreams, but there is not manpower to do it.
my feeling is that the xml-branch commit activity pefectly shows what will
happen after the worst bugs will be repaired in xml merged trunk.
or you have some particular
On Thursday 24 July 2008 13:07:19 Pavel Sanda wrote:
frankly - these are nice dreams, but there is not manpower to do it.
my feeling is that the xml-branch commit activity pefectly shows what will
happen after the worst bugs will be repaired in xml merged trunk.
or you have some
To the discussion about data format preference:
I am reading all your comments about XML, YAML and other suggested data
formats. And this discussion reminds me something about XML what almost
nobody is remeber about. How many LyX user are working in large team
projects? How often they have to
On Fri, Jul 25, 2008 at 4:43 PM, Manveru [EMAIL PROTECTED] wrote:
To the discussion about data format preference:
I am reading all your comments about XML, YAML and other suggested data
formats. And this discussion reminds me something about XML what almost
nobody is remeber about. How many
On Thursday 24 July 2008 13:07:19 Pavel Sanda wrote:
frankly - these are nice dreams, but there is not manpower to do it.
my feeling is that the xml-branch commit activity pefectly shows what will
happen after the worst bugs will be repaired in xml merged trunk.
or you have some particular
On Thursday 24 July 2008 13:07:19 Pavel Sanda wrote:
frankly - these are nice dreams, but there is not manpower to do it.
my feeling is that the xml-branch commit activity pefectly shows what will
happen after the worst bugs will be repaired in xml merged trunk.
or you have some
To the discussion about data format preference:
I am reading all your comments about XML, YAML and other suggested data
formats. And this discussion reminds me something about XML what almost
nobody is remeber about. How many LyX user are working in large team
projects? How often they have to
On Fri, Jul 25, 2008 at 4:43 PM, Manveru [EMAIL PROTECTED] wrote:
To the discussion about data format preference:
I am reading all your comments about XML, YAML and other suggested data
formats. And this discussion reminds me something about XML what almost
nobody is remeber about. How many
On Thursday 24 July 2008 13:07:19 Pavel Sanda wrote:
> frankly - these are nice dreams, but there is not manpower to do it.
> my feeling is that the xml-branch commit activity pefectly shows what will
> happen after the worst bugs will be repaired in xml merged trunk.
>
> or you have some
> On Thursday 24 July 2008 13:07:19 Pavel Sanda wrote:
> > frankly - these are nice dreams, but there is not manpower to do it.
> > my feeling is that the xml-branch commit activity pefectly shows what will
> > happen after the worst bugs will be repaired in xml merged trunk.
> >
> > or you have
To the discussion about data format preference:
I am reading all your comments about XML, YAML and other suggested data
formats. And this discussion reminds me something about XML what almost
nobody is remeber about. How many LyX user are working in large team
projects? How often they have to
On Fri, Jul 25, 2008 at 4:43 PM, Manveru <[EMAIL PROTECTED]> wrote:
> To the discussion about data format preference:
>
> I am reading all your comments about XML, YAML and other suggested data
> formats. And this discussion reminds me something about XML what almost
> nobody is remeber about. How
On Wednesday 23 July 2008 19:24:16 Pavel Sanda wrote:
this depends on what you master. i'm used on the bunch of small unix
utilities so i gave that sed example. if you know python you will do in
python. my point was not propose the best tools but to groan and moan about
xml :)
FWIW this chunk
On Wed, 23 Jul 2008, Steve Litt wrote:
As a sed/awk/perl/ruby parser, I appreciate that very much.
The more I think about it, the more I think I should make the XML-YAML
and YAML-XML converters. That way, if future generations of LyX project
programmers forget why it's important to space
what I claim is that we need better
script tools to handle lyx documents. Those tools should be stable across lyx
versions and should not depend of any particular file format.
frankly - these are nice dreams, but there is not manpower to do it.
my feeling is that the xml-branch commit
On Wednesday 23 July 2008 19:24:16 Pavel Sanda wrote:
this depends on what you master. i'm used on the bunch of small unix
utilities so i gave that sed example. if you know python you will do in
python. my point was not propose the best tools but to groan and moan about
xml :)
FWIW this chunk
On Wed, 23 Jul 2008, Steve Litt wrote:
As a sed/awk/perl/ruby parser, I appreciate that very much.
The more I think about it, the more I think I should make the XML-YAML
and YAML-XML converters. That way, if future generations of LyX project
programmers forget why it's important to space
what I claim is that we need better
script tools to handle lyx documents. Those tools should be stable across lyx
versions and should not depend of any particular file format.
frankly - these are nice dreams, but there is not manpower to do it.
my feeling is that the xml-branch commit
On Wednesday 23 July 2008 19:24:16 Pavel Sanda wrote:
> this depends on what you master. i'm used on the bunch of small unix
> utilities so i gave that sed example. if you know python you will do in
> python. my point was not propose the best tools but to groan and moan about
> xml :)
FWIW this
On Wed, 23 Jul 2008, Steve Litt wrote:
As a sed/awk/perl/ruby parser, I appreciate that very much.
The more I think about it, the more I think I should make the XML->YAML
and YAML->XML converters. That way, if future generations of LyX project
programmers forget why it's important to space
> what I claim is that we need better
> script tools to handle lyx documents. Those tools should be stable across lyx
> versions and should not depend of any particular file format.
frankly - these are nice dreams, but there is not manpower to do it.
my feeling is that the xml-branch commit
On Tuesday 22 July 2008 19:24, Pavel Sanda wrote:
Pavel Sanda wrote:
Moreover, if you're editing by hand, you can use
something that recognizes XML.
of course it will work, but it will take x-times more time.
quite difference to write sed one-liner or start doing some
xslt templating.
On Wednesday 23 July 2008 00:19:09 Pavel Sanda wrote:
by 'outside' i mean tweakings which i regularly do and watching users list
power users do that too _and_ are happy about the current simplicity of
format.
tweaks like assembling of the whole file for various datasets, global
changes of
On Wednesday 23 July 2008 00:19:09 Pavel Sanda wrote:
while you are right that xml could be better technology for internal
lyx parsing (and i can understand your viewpoint as lyx2lyx fan:)
this was not my mail about.
It is funny to see all this nostalgia around something that is/was a
On Wednesday 23 July 2008 12:19:16 Pavel Sanda wrote:
i've done incorrect file, it's my fault if lyx crashes. i take my
responsibility, no problem.
trial method is the fastest if you want something quickly.
If LyX crashes that is a bug. LyX should not ever crash, it can refused to
load a file
Guys,
Have you even looked at TinyXML?
I have a project once where we use XML as a message passing protocol and we
were using XSLT as C++ code generator for classes handling XML and
converting them to data structures handling all data we need. This freed us
from portability problems (Litte
On Tuesday 22 July 2008 18:21, José Matos wrote:
Clearly you did not had to deal with the lyx file format like I did. :-)
If your idea of a parser is a set of regexp's that is so 80's. ;-)
[clip]
It is funny to see all this nostalgia around something that is/was a
nightmare. If the syntax was
On Wednesday 23 July 2008 07:00, José Matos wrote:
XML will not change the current status.
grep 'style name=Section' somefile.lyx
will still work and it not so different from what we have now. You need the
'' already if you have spaces in your expression...
The trouble is, XML tags can be
On Tuesday 22 July 2008 19:24, Pavel Sanda wrote:
Pavel Sanda wrote:
Moreover, if you're editing by hand, you can use
something that recognizes XML.
of course it will work, but it will take x-times more time.
quite difference to write sed one-liner or start doing some
xslt templating.
Steve Litt wrote:
Perhaps our best hope of continuing tweakability of native LyX is to create
1.5.x to XML and XML to 1.5.x converters. Then all the parsing/tweaking can
continue to be done in the 1.5.x format.
I'm presuming that the LyX developers will create the 1.5.x to XML converter
so
On Wednesday 23 July 2008 15:33:16 Steve Litt wrote:
The trouble is, XML tags can be anywhere -- spacing and linefeeds are
immaterial. That means you can no longer parse based on position, such as:
/^begin_layout/
because technically the whole XML file could be in a single line. Or a
single
On Wednesday 23 July 2008 15:20:59 Steve Litt wrote:
When the discussion reverts to your thingamabob is from another
decade/century so it must not be good by today's standards, you know that
thingamabob is pretty darn good, or else there would have been a more
powerful argument against it.
On Wednesday 23 July 2008 15:58:56 Steve Litt wrote:
Hi Pavel,
Perhaps our best hope of continuing tweakability of native LyX is to create
1.5.x to XML and XML to 1.5.x converters. Then all the parsing/tweaking can
continue to be done in the 1.5.x format.
I will advise against such practice.
On Wednesday 23 July 2008 14:49:12 Manveru wrote:
Guys,
Have you even looked at TinyXML?
Thanks for the link. :-)
--
José Abílio
On Wednesday 23 July 2008 11:21, José Matos wrote:
There may be things wrong with awking, seding and perling data into
submission, but the age of these tools is not one of them.
If you add there the coreutils, like tail, cut, paste, merge and so on we
can do things that spreadsheet
On Wednesday 23 July 2008 11:05, José Matos wrote:
On Wednesday 23 July 2008 15:33:16 Steve Litt wrote:
The trouble is, XML tags can be anywhere -- spacing and linefeeds are
immaterial. That means you can no longer parse based on position, such
as:
/^begin_layout/
because
Perhaps our best hope of continuing tweakability of native LyX is to create
1.5.x to XML and XML to 1.5.x converters. Then all the parsing/tweaking can
continue to be done in the 1.5.x format.
as have written others 1.6 is still ok. for lyx files assembly you can still
make what you want in
The next question is why do we need to manipulate lyx files with awk and
friends? Is not there something that can should be done by lyx?
search and replace is one of the weak lyx parts and even if we get Tommaso
one day to put his stuff in there are so many place where its of no help.
just
On Wed, Jul 23, 2008 at 10:33:16AM -0400, Steve Litt wrote:
On Wednesday 23 July 2008 07:00, José Matos wrote:
XML will not change the current status.
grep 'style name=Section' somefile.lyx
will still work and it not so different from what we have now. You need the
'' already if you
Steve Litt wrote:
On Wednesday 23 July 2008 07:00, José Matos wrote:
XML will not change the current status.
grep 'style name=Section' somefile.lyx
will still work and it not so different from what we have now. You need the
'' already if you have spaces in your expression...
The
Steve Litt wrote:
Perhaps our best hope of continuing tweakability of native LyX is to create
1.5.x to XML and XML to 1.5.x converters. Then all the parsing/tweaking can
continue to be done in the 1.5.x format.
As always, LyX will have such converters, so old formats can be
José Matos wrote:
That is also the reason why lyx2lyx is nowadays mostly a python library
(LyX.py) and the script lyx2lyx is just a wrapper around the library.
And let me add that anyone who wants to process LyX files on a regular
basis using external scripts would be well served to learn
Steve Litt wrote:
At first I'll do them in Ruby because Ruby has all that stuff built in and
easy to do. Later, depending on performance and the percent of people who
have Ruby installed, I can convert them to C. There's a C implementation of
the same YAML parser/emitter that Ruby uses --
On Tuesday 22 July 2008 19:24, Pavel Sanda wrote:
Pavel Sanda wrote:
Moreover, if you're editing by hand, you can use
something that recognizes XML.
of course it will work, but it will take x-times more time.
quite difference to write sed one-liner or start doing some
xslt templating.
On Wednesday 23 July 2008 00:19:09 Pavel Sanda wrote:
by 'outside' i mean tweakings which i regularly do and watching users list
power users do that too _and_ are happy about the current simplicity of
format.
tweaks like assembling of the whole file for various datasets, global
changes of
On Wednesday 23 July 2008 00:19:09 Pavel Sanda wrote:
while you are right that xml could be better technology for internal
lyx parsing (and i can understand your viewpoint as lyx2lyx fan:)
this was not my mail about.
It is funny to see all this nostalgia around something that is/was a
On Wednesday 23 July 2008 12:19:16 Pavel Sanda wrote:
i've done incorrect file, it's my fault if lyx crashes. i take my
responsibility, no problem.
trial method is the fastest if you want something quickly.
If LyX crashes that is a bug. LyX should not ever crash, it can refused to
load a file
Guys,
Have you even looked at TinyXML?
I have a project once where we use XML as a message passing protocol and we
were using XSLT as C++ code generator for classes handling XML and
converting them to data structures handling all data we need. This freed us
from portability problems (Litte
On Tuesday 22 July 2008 18:21, José Matos wrote:
Clearly you did not had to deal with the lyx file format like I did. :-)
If your idea of a parser is a set of regexp's that is so 80's. ;-)
[clip]
It is funny to see all this nostalgia around something that is/was a
nightmare. If the syntax was
On Wednesday 23 July 2008 07:00, José Matos wrote:
XML will not change the current status.
grep 'style name=Section' somefile.lyx
will still work and it not so different from what we have now. You need the
'' already if you have spaces in your expression...
The trouble is, XML tags can be
On Tuesday 22 July 2008 19:24, Pavel Sanda wrote:
Pavel Sanda wrote:
Moreover, if you're editing by hand, you can use
something that recognizes XML.
of course it will work, but it will take x-times more time.
quite difference to write sed one-liner or start doing some
xslt templating.
Steve Litt wrote:
Perhaps our best hope of continuing tweakability of native LyX is to create
1.5.x to XML and XML to 1.5.x converters. Then all the parsing/tweaking can
continue to be done in the 1.5.x format.
I'm presuming that the LyX developers will create the 1.5.x to XML converter
so
On Wednesday 23 July 2008 15:33:16 Steve Litt wrote:
The trouble is, XML tags can be anywhere -- spacing and linefeeds are
immaterial. That means you can no longer parse based on position, such as:
/^begin_layout/
because technically the whole XML file could be in a single line. Or a
single
On Wednesday 23 July 2008 15:20:59 Steve Litt wrote:
When the discussion reverts to your thingamabob is from another
decade/century so it must not be good by today's standards, you know that
thingamabob is pretty darn good, or else there would have been a more
powerful argument against it.
On Wednesday 23 July 2008 15:58:56 Steve Litt wrote:
Hi Pavel,
Perhaps our best hope of continuing tweakability of native LyX is to create
1.5.x to XML and XML to 1.5.x converters. Then all the parsing/tweaking can
continue to be done in the 1.5.x format.
I will advise against such practice.
On Wednesday 23 July 2008 14:49:12 Manveru wrote:
Guys,
Have you even looked at TinyXML?
Thanks for the link. :-)
--
José Abílio
On Wednesday 23 July 2008 11:21, José Matos wrote:
There may be things wrong with awking, seding and perling data into
submission, but the age of these tools is not one of them.
If you add there the coreutils, like tail, cut, paste, merge and so on we
can do things that spreadsheet
On Wednesday 23 July 2008 11:05, José Matos wrote:
On Wednesday 23 July 2008 15:33:16 Steve Litt wrote:
The trouble is, XML tags can be anywhere -- spacing and linefeeds are
immaterial. That means you can no longer parse based on position, such
as:
/^begin_layout/
because
Perhaps our best hope of continuing tweakability of native LyX is to create
1.5.x to XML and XML to 1.5.x converters. Then all the parsing/tweaking can
continue to be done in the 1.5.x format.
as have written others 1.6 is still ok. for lyx files assembly you can still
make what you want in
The next question is why do we need to manipulate lyx files with awk and
friends? Is not there something that can should be done by lyx?
search and replace is one of the weak lyx parts and even if we get Tommaso
one day to put his stuff in there are so many place where its of no help.
just
On Wed, Jul 23, 2008 at 10:33:16AM -0400, Steve Litt wrote:
On Wednesday 23 July 2008 07:00, José Matos wrote:
XML will not change the current status.
grep 'style name=Section' somefile.lyx
will still work and it not so different from what we have now. You need the
'' already if you
Steve Litt wrote:
On Wednesday 23 July 2008 07:00, José Matos wrote:
XML will not change the current status.
grep 'style name=Section' somefile.lyx
will still work and it not so different from what we have now. You need the
'' already if you have spaces in your expression...
The
Steve Litt wrote:
Perhaps our best hope of continuing tweakability of native LyX is to create
1.5.x to XML and XML to 1.5.x converters. Then all the parsing/tweaking can
continue to be done in the 1.5.x format.
As always, LyX will have such converters, so old formats can be
José Matos wrote:
That is also the reason why lyx2lyx is nowadays mostly a python library
(LyX.py) and the script lyx2lyx is just a wrapper around the library.
And let me add that anyone who wants to process LyX files on a regular
basis using external scripts would be well served to learn
Steve Litt wrote:
At first I'll do them in Ruby because Ruby has all that stuff built in and
easy to do. Later, depending on performance and the percent of people who
have Ruby installed, I can convert them to C. There's a C implementation of
the same YAML parser/emitter that Ruby uses --
On Tuesday 22 July 2008 19:24, Pavel Sanda wrote:
> > Pavel Sanda wrote:
> > Moreover, if you're editing by hand, you can use
> > something that recognizes XML.
>
> of course it will work, but it will take x-times more time.
> quite difference to write sed one-liner or start doing some
> xslt
On Wednesday 23 July 2008 00:19:09 Pavel Sanda wrote:
> by 'outside' i mean tweakings which i regularly do and watching users list
> power users do that too _and_ are happy about the current simplicity of
> format.
>
> tweaks like assembling of the whole file for various datasets, global
> changes
> On Wednesday 23 July 2008 00:19:09 Pavel Sanda wrote:
> > while you are right that xml could be better technology for internal
> > lyx parsing (and i can understand your viewpoint as lyx2lyx fan:)
> > this was not my mail about.
> >
> > > It is funny to see all this nostalgia around something
On Wednesday 23 July 2008 12:19:16 Pavel Sanda wrote:
> i've done incorrect file, it's my fault if lyx crashes. i take my
> responsibility, no problem.
> trial method is the fastest if you want something quickly.
If LyX crashes that is a bug. LyX should not ever crash, it can refused to
load a
Guys,
Have you even looked at TinyXML?
I have a project once where we use XML as a message passing protocol and we
were using XSLT as C++ code generator for classes handling XML and
converting them to data structures handling all data we need. This freed us
from portability problems (Litte
On Tuesday 22 July 2008 18:21, José Matos wrote:
> Clearly you did not had to deal with the lyx file format like I did. :-)
> If your idea of a parser is a set of regexp's that is so 80's. ;-)
[clip]
> It is funny to see all this nostalgia around something that is/was a
> nightmare. If the syntax
On Wednesday 23 July 2008 07:00, José Matos wrote:
> XML will not change the current status.
>
> grep
On Tuesday 22 July 2008 19:24, Pavel Sanda wrote:
> > Pavel Sanda wrote:
> > Moreover, if you're editing by hand, you can use
> > something that recognizes XML.
>
> of course it will work, but it will take x-times more time.
> quite difference to write sed one-liner or start doing some
> xslt
Steve Litt wrote:
Perhaps our best hope of continuing tweakability of native LyX is to create
1.5.x to XML and XML to 1.5.x converters. Then all the parsing/tweaking can
continue to be done in the 1.5.x format.
I'm presuming that the LyX developers will create the 1.5.x to XML converter
so
On Wednesday 23 July 2008 15:33:16 Steve Litt wrote:
> The trouble is, XML tags can be anywhere -- spacing and linefeeds are
> immaterial. That means you can no longer parse based on position, such as:
>
> /^begin_layout/
>
> because technically the whole XML file could be in a single line. Or a
>
On Wednesday 23 July 2008 15:20:59 Steve Litt wrote:
> When the discussion reverts to "your thingamabob is from another
> decade/century so it must not be good by today's standards", you know that
> thingamabob is pretty darn good, or else there would have been a more
> powerful argument against
On Wednesday 23 July 2008 15:58:56 Steve Litt wrote:
> Hi Pavel,
>
> Perhaps our best hope of continuing tweakability of native LyX is to create
> 1.5.x to XML and XML to 1.5.x converters. Then all the parsing/tweaking can
> continue to be done in the 1.5.x format.
I will advise against such
On Wednesday 23 July 2008 14:49:12 Manveru wrote:
> Guys,
>
> Have you even looked at TinyXML?
Thanks for the link. :-)
--
José Abílio
On Wednesday 23 July 2008 11:21, José Matos wrote:
> > There may be things wrong with awking, seding and perling data into
> > submission, but the age of these tools is not one of them.
>
> If you add there the coreutils, like tail, cut, paste, merge and so on we
> can do things that spreadsheet
1 - 100 of 126 matches
Mail list logo
