Re: The case for human parsable LyX native format
Steve Litt schrieb: Hi all, I just solved two very difficult LyX problems using Vim, and it reminded me just how lucky we are that the current LyX native format is easily readable and parsable by a normally intelligent human. In the first case, LyX would crash about 3 seconds after opening a document in 1.6.3. For various reasons I suspected it was the overly large .eps cover art, but I encountered a buried shovel. If only I could get LyX to work, I could change the cover art, and if only I could change the cover art, I could get LyX to work. Vim to the rescue: I changed cover.eps to cover.pdf to work around the problem (which I suspect is a LyX ungraceful handling of a too large graphic). In the second case, I had an indexing problem preventing making the PDF. Using diagnostics like the ilg, ind and idx files, I narrowed it down to five possible culprit index entries. I got it down to one error, but the .ind file was showing a backslash that didn't exist in the LyX index entry. When I opened the LyX file in Vim, the problem stuck out like a sore thumb -- there was an extra inset and some other garbage within the index structure. I removed it with Vim and bang, the document compiled perfectly to PDF. There have been a lot of discussions about changing the LyX native formula. I'd like to ask that whatever the new format turns out to be, it be at least as easy for a normal intelligence human to manually edit, parse and modify as the current format. XML has been discussed, and the point has been made that if XML is done with an eye toward manual parsing and editing, it can be as easy to parse and edit in Vim as the current native format. While that's obviously true, we all know that from a human parsing viewpoint, XML can quickly get out of control. One look at any OpenOffice file confirms this. XML has the capability to make one paragraph depend on several different XML subtrees. If authored that way, for all practical purposes human manual parsability and editability is destroyed. Also, the XML spec itself does not recognize lines, so it would be up to the LyX tools to properly assign lines to nodes and vice versa. Otherwise it would be impossible to write LyX creation and modification scripts, at least without a big, ugly XML parser. I'm pretty sure all the current developers understand all this because you regularly tweak LyX from editors yourselves. I am concerned, however, that future LyX developers will say Hey, LyX is XML and to do our jobs correctly we need to just worry about valid XML, not linefeeds. On that day, a great deal of user power is lost. So, as usual, Im pleading that as you decide on future native formats, you make the new formats as human parsable and editable as the current version. Thanks SteveT Hi LyX developpers, I would like to strongly support Steve's point of view ! Quite often I have to create documents which contain mostly images and nearly no text at all. So I put in one of the images manually using the GUI, give it a look and the rest is done using gvim and/or bash scripting and the like. For me this is a great gain in productivity compared to the inclusion of maybe 80 images via the GUI. And this procedure is possible exactly because the actual LyX internal format is very readable (even rather suggestive ;-) So, me too I would like to beg you all: Keep this in mind when deciding on any change of the internal format. For the rest LyX is THE mosdt important tool for all my work with a computer, working (still at 66) as management consultant. Best regards Hellmut -- Dr. Hellmut Weber m...@hellmutweber.de Degenfeldstraße 2 tel +49-89-3081172 D-80803 München-Schwabing mobil +49-172-8450321 please: No DOCs, no PPTs. why: tinyurl.com/cbgq
Re: The case for human parsable LyX native format
Hellmut Weber wrote: Steve Litt schrieb: So, as usual, Im pleading that as you decide on future native formats, you make the new formats as human parsable and editable as the current version. Thanks SteveT Hi LyX developpers, I would like to strongly support Steve's point of view ! Don't worry, as was explained many times to Steve, this point is well understood and this opinion is shared among the majority of developpers if not all of them. The switch to XML, if that ever happens, will *never* be at the expense of readability. So there is actually no need to do any lobbying on that front :-) Abdel.
Re: The case for human parsable LyX native format
Abdelrazak Younes wrote: Hellmut Weber wrote: Steve Litt schrieb: So, as usual, Im pleading that as you decide on future native formats, you make the new formats as human parsable and editable as the current version. Thanks SteveT Hi LyX developpers, I would like to strongly support Steve's point of view ! Don't worry, as was explained many times to Steve, this point is well understood and this opinion is shared among the majority of developpers if not all of them. The switch to XML, if that ever happens, will *never* be at the expense of readability. So there is actually no need to do any lobbying on that front :-) Abdel. Good, now I can sleep better. Script creation of LyX documents from sql database exports using PHP and Bash is very important to me. RAD for computer generated documents is LyX. -- LyX: http://www.lyx.org/ OpenOffice: http://www.openoffice.org/ Inkscape: http://www.inkscape.org/ Scribus: http://www.scribus.net/ GIMP: http://www.gimp.org/ PDF: http://www.pdfforge.org/ signature.asc Description: OpenPGP digital signature
Re: The case for human parsable LyX native format
Steve Litt schrieb: Hi all, I just solved two very difficult LyX problems using Vim, and it reminded me just how lucky we are that the current LyX native format is easily readable and parsable by a normally intelligent human. In the first case, LyX would crash about 3 seconds after opening a document in 1.6.3. For various reasons I suspected it was the overly large .eps cover art, but I encountered a buried shovel. If only I could get LyX to work, I could change the cover art, and if only I could change the cover art, I could get LyX to work. Vim to the rescue: I changed cover.eps to cover.pdf to work around the problem (which I suspect is a LyX ungraceful handling of a too large graphic). In the second case, I had an indexing problem preventing making the PDF. Using diagnostics like the ilg, ind and idx files, I narrowed it down to five possible culprit index entries. I got it down to one error, but the .ind file was showing a backslash that didn't exist in the LyX index entry. When I opened the LyX file in Vim, the problem stuck out like a sore thumb -- there was an extra inset and some other garbage within the index structure. I removed it with Vim and bang, the document compiled perfectly to PDF. There have been a lot of discussions about changing the LyX native formula. I'd like to ask that whatever the new format turns out to be, it be at least as easy for a normal intelligence human to manually edit, parse and modify as the current format. XML has been discussed, and the point has been made that if XML is done with an eye toward manual parsing and editing, it can be as easy to parse and edit in Vim as the current native format. While that's obviously true, we all know that from a human parsing viewpoint, XML can quickly get out of control. One look at any OpenOffice file confirms this. XML has the capability to make one paragraph depend on several different XML subtrees. If authored that way, for all practical purposes human manual parsability and editability is destroyed. Also, the XML spec itself does not recognize lines, so it would be up to the LyX tools to properly assign lines to nodes and vice versa. Otherwise it would be impossible to write LyX creation and modification scripts, at least without a big, ugly XML parser. I'm pretty sure all the current developers understand all this because you regularly tweak LyX from editors yourselves. I am concerned, however, that future LyX developers will say Hey, LyX is XML and to do our jobs correctly we need to just worry about valid XML, not linefeeds. On that day, a great deal of user power is lost. So, as usual, Im pleading that as you decide on future native formats, you make the new formats as human parsable and editable as the current version. Thanks SteveT Hi LyX developpers, I would like to strongly support Steve's point of view ! Quite often I have to create documents which contain mostly images and nearly no text at all. So I put in one of the images manually using the GUI, give it a look and the rest is done using gvim and/or bash scripting and the like. For me this is a great gain in productivity compared to the inclusion of maybe 80 images via the GUI. And this procedure is possible exactly because the actual LyX internal format is very readable (even rather suggestive ;-) So, me too I would like to beg you all: Keep this in mind when deciding on any change of the internal format. For the rest LyX is THE mosdt important tool for all my work with a computer, working (still at 66) as management consultant. Best regards Hellmut -- Dr. Hellmut Weber m...@hellmutweber.de Degenfeldstraße 2 tel +49-89-3081172 D-80803 München-Schwabing mobil +49-172-8450321 please: No DOCs, no PPTs. why: tinyurl.com/cbgq
Re: The case for human parsable LyX native format
Hellmut Weber wrote: Steve Litt schrieb: So, as usual, Im pleading that as you decide on future native formats, you make the new formats as human parsable and editable as the current version. Thanks SteveT Hi LyX developpers, I would like to strongly support Steve's point of view ! Don't worry, as was explained many times to Steve, this point is well understood and this opinion is shared among the majority of developpers if not all of them. The switch to XML, if that ever happens, will *never* be at the expense of readability. So there is actually no need to do any lobbying on that front :-) Abdel.
Re: The case for human parsable LyX native format
Abdelrazak Younes wrote: Hellmut Weber wrote: Steve Litt schrieb: So, as usual, Im pleading that as you decide on future native formats, you make the new formats as human parsable and editable as the current version. Thanks SteveT Hi LyX developpers, I would like to strongly support Steve's point of view ! Don't worry, as was explained many times to Steve, this point is well understood and this opinion is shared among the majority of developpers if not all of them. The switch to XML, if that ever happens, will *never* be at the expense of readability. So there is actually no need to do any lobbying on that front :-) Abdel. Good, now I can sleep better. Script creation of LyX documents from sql database exports using PHP and Bash is very important to me. RAD for computer generated documents is LyX. -- LyX: http://www.lyx.org/ OpenOffice: http://www.openoffice.org/ Inkscape: http://www.inkscape.org/ Scribus: http://www.scribus.net/ GIMP: http://www.gimp.org/ PDF: http://www.pdfforge.org/ signature.asc Description: OpenPGP digital signature
Re: The case for human parsable LyX native format
Steve Litt schrieb: Hi all, I just solved two very difficult LyX problems using Vim, and it reminded me just how lucky we are that the current LyX native format is easily readable and parsable by a normally intelligent human. In the first case, LyX would crash about 3 seconds after opening a document in 1.6.3. For various reasons I suspected it was the overly large .eps cover art, but I encountered a buried shovel. If only I could get LyX to work, I could change the cover art, and if only I could change the cover art, I could get LyX to work. Vim to the rescue: I changed cover.eps to cover.pdf to work around the problem (which I suspect is a LyX ungraceful handling of a too large graphic). In the second case, I had an indexing problem preventing making the PDF. Using diagnostics like the ilg, ind and idx files, I narrowed it down to five possible culprit index entries. I got it down to one error, but the .ind file was showing a backslash that didn't exist in the LyX index entry. When I opened the LyX file in Vim, the problem stuck out like a sore thumb -- there was an extra inset and some other garbage within the index structure. I removed it with Vim and bang, the document compiled perfectly to PDF. There have been a lot of discussions about changing the LyX native formula. I'd like to ask that whatever the new format turns out to be, it be at least as easy for a normal intelligence human to manually edit, parse and modify as the current format. XML has been discussed, and the point has been made that if XML is done with an eye toward manual parsing and editing, it can be as easy to parse and edit in Vim as the current native format. While that's obviously true, we all know that from a human parsing viewpoint, XML can quickly get out of control. One look at any OpenOffice file confirms this. XML has the capability to make one paragraph depend on several different XML subtrees. If authored that way, for all practical purposes human manual parsability and editability is destroyed. Also, the XML spec itself does not recognize lines, so it would be up to the LyX tools to properly assign lines to nodes and vice versa. Otherwise it would be impossible to write LyX creation and modification scripts, at least without a big, ugly XML parser. I'm pretty sure all the current developers understand all this because you regularly tweak LyX from editors yourselves. I am concerned, however, that future LyX developers will say "Hey, LyX is XML and to do our jobs correctly we need to just worry about valid XML, not linefeeds. On that day, a great deal of user power is lost. So, as usual, I"m pleading that as you decide on future native formats, you make the new formats as human parsable and editable as the current version. Thanks SteveT Hi LyX developpers, I would like to strongly support Steve's point of view ! Quite often I have to create documents which contain mostly images and nearly no text at all. So I put in one of the images manually using the GUI, give it a look and the rest is done using gvim and/or bash scripting and the like. For me this is a great gain in productivity compared to the inclusion of maybe 80 images via the GUI. And this procedure is possible exactly because the actual LyX internal format is very readable (even rather suggestive ;-) So, me too I would like to beg you all: Keep this in mind when deciding on any change of the internal format. For the rest LyX is THE mosdt important tool for all my work with a computer, working (still at 66) as management consultant. Best regards Hellmut -- Dr. Hellmut Weber m...@hellmutweber.de Degenfeldstraße 2 tel +49-89-3081172 D-80803 München-Schwabing mobil +49-172-8450321 please: No DOCs, no PPTs. why: tinyurl.com/cbgq
Re: The case for human parsable LyX native format
Hellmut Weber wrote: Steve Litt schrieb: So, as usual, I"m pleading that as you decide on future native formats, you make the new formats as human parsable and editable as the current version. Thanks SteveT Hi LyX developpers, I would like to strongly support Steve's point of view ! Don't worry, as was explained many times to Steve, this point is well understood and this opinion is shared among the majority of developpers if not all of them. The switch to XML, if that ever happens, will *never* be at the expense of readability. So there is actually no need to do any lobbying on that front :-) Abdel.
Re: The case for human parsable LyX native format
Abdelrazak Younes wrote: > Hellmut Weber wrote: >> Steve Litt schrieb: >>> So, as usual, I"m pleading that as you decide on future native >>> formats, you make the new formats as human parsable and editable as >>> the current version. >>> >>> Thanks >>> >>> SteveT >>> >>> >> >> Hi LyX developpers, >> I would like to strongly support Steve's point of view ! > > Don't worry, as was explained many times to Steve, this point is well > understood and this opinion is shared among the majority of > developpers if not all of them. The switch to XML, if that ever > happens, will *never* be at the expense of readability. So there is > actually no need to do any lobbying on that front :-) > > Abdel. > Good, now I can sleep better. Script creation of LyX documents from sql database exports using PHP and Bash is very important to me. RAD for computer generated documents is LyX. -- LyX: http://www.lyx.org/ OpenOffice: http://www.openoffice.org/ Inkscape: http://www.inkscape.org/ Scribus: http://www.scribus.net/ GIMP: http://www.gimp.org/ PDF: http://www.pdfforge.org/ signature.asc Description: OpenPGP digital signature
