Alex Fernandez wrote: > > now this is nothing against you personally - its true for all devs here - > > when > > one is looks on the lyx project from a wider time range developers come and > > leave and you will have hard time to find most of devs which were 10 years > > before on this list. but the popularity reached a certain threshold so its > > quite probable other new people will contine and will have to handle the > > code > > we leave... from this point of view its no more question of "what is easier > > to do" but rather "is the code written in easy maintainable way?" > > It is a fair concern. Now I have tried to answer all of the points > raised by LyX developers: > - all parsing code is in a separate package, > - all parsed strings is configurable in a single file, > - configurabiliy and modularity have been prime concerns from day one, > - ease of adding features has not slowed down with time: > http://www.nongnu.org/elyxer/changelog.html > - eLyXer returns the maximum format number it supports, > - and there are user and developer guides. > But after all this is said and done, it seems that a small number of > people just go back to "converting HTML from .lyx files is wrong", > which is not very helpful when that is the basic premise of eLyXer. So > I don't really believe that "is the code written in easy maintainable > way?" is the obstacle here; we must have a deeper misunderstanding.
if its just a question of misunderstanding i can rephrase it clearly: the code which converts HTML directly from .lyx files is not easy maintainable in a sense that it needs manual checks/fixes any time we change output format, while producing output directly from internal lyx strucutures is not touched by this. > > thats why even if lyx internal html export wouldn't have all whistle and > > bells > > compared to elyxer once lyx 1.7 comes out i would still consider it more > > promising start from the long term view. > > I tried to explain above at length why this point of view is > incorrect. Could you elaborate? Where do you think my rant is wrong? it tries to defend architecture and details of code, which i'm not currently concerned about. my attack went on the whole premise of elyxer. > a couple of years it would inevitably decay and rot just like the > DocBook backend. Talk about "easy maintainable way"... and the point you missed completely is that docbook backend is basically _still_ working although nobody touched single bit of it for years. people are anoyed because there is no documentation and because it it produces old xml format, but thats unrelated. and yes it pefectly illustrates also the problem i have been talking in previous mail. we are regularly asked on users list for this issue. although neither me or Richard is original author of the code we feel somewhat responsible and because the code is written in a similar way as other internal tex/plain text export it wouldn't be so hard to fix the problems - if it was some python script i wouldn't even look into it. the fact that nobody from docbook-related users replied to my public offer to report the issues which could be fixed in next version would be the reason why it will remain rotten, but its not the code which prevented it. pavel
