Re: I've been experimenting with the web site
On Wednesday 05 February 2003 18:12, Angus Leeming wrote: Don't worry. His default colour scheme is _really_ nasty ;-) It gives a new meaning to dark ages. ;-) -- José Abílio
Re: [patch]: pass $...$ and $$...$$ through reLyX unchanged
On Friday 07 February 2003 11:39, Angus Leeming wrote: This one has been in my tree for a while. It does not fix the '$ blah$$ foo $ problem, but it doesn't break anything either. It works by setting a switch, $inside_math, so that reLyX knows whether to enter or leave math mode when it receives a '$' or '$$' token. Ok to apply? And to 1.3.x? I would say apply it for 1.4.x. Regarding 1.3.x we should be paranoid. ;-) (by Jean:marc advice's) ;-) -- José Abílio
Re: lyx2lyx test suite?
On Thursday 06 February 2003 00:12, Angus Leeming wrote: Angus Leeming wrote: José, I seem to remember you saying that the hardest part of writing lyx2lyx was accumulating a set of test files. Do you still have them? I'm currently unable to generate any differences when upgrading the reLyX char styles data to lyxformat 2.17. However, I'm not convinced I've got a complete test file. Ditto, the tabular format changed totally between lyxformats 2.16 and 2.17. Anything you have would be a real bonus. Bahh! I've just worked out that the _only_ thing that changed from 2.16 to 2.17 was the table format. The char properties stuff applies to paragraphs inside the table. Dohhh! Better to go directly to 2.18, since the table format changed again. :-) Anyway, some lyx files of tables in the two formats would be a real help. here it goes: http://www.lyx.org/~jamatos/lyx-docs/user-guide.tgz http://www.lyx.org/~jamatos/lyx-docs/extended.tgz The .new files were saved with next version of lyx. I hope this helps, -- José Abílio
Re: [patch] Trivial lyx2lyx bug
On Thursday 06 February 2003 18:35, Angus Leeming wrote: Index: lib/lyx2lyx/lyx2lyx === RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/lyx2lyx/lyx2lyx,v retrieving revision 1.5 diff -u -p -r1.5 lyx2lyx --- lib/lyx2lyx/lyx2lyx 7 Jan 2003 17:03:59 - 1.5 +++ lib/lyx2lyx/lyx2lyx 6 Feb 2003 18:15:39 - @@ -55,9 +55,9 @@ Options: def parse_options(argv): -_options = [help, version, list, from=, to=, output=, quiet] +_options = [help, version, list, debug, from= Ok, it should be debug= to show that it takes an additional argument. to=, output=, quiet] try: - opts, args = getopt.getopt(argv[1:], f:hlo:qt:v, _options) + opts, args = getopt.getopt(argv[1:], d:f:hlo:qt:v, _options) except getopt.error: usage() sys.exit(2) -- José Abílio
Re: Table format question (for Jos?)
On Wednesday 05 February 2003 13:18, Angus Leeming wrote: José, two questions: lyxconvert_215.py converts from 215 format to 216 format, correct? Yes, at least that was my purpose. ;-) That being the case, I'm a bit confused by the codes in lyxconvert_215.py which talks about: # Update from tabular format 4 to 5 if necessary Do you want to hear the whole truth? There isn't any 215 format, that is a myth. ;-) Now serious (for those humour impaired). :-) The lyx file format has been a huge mess until recently, when we have started documenting our changes. We even had a file format change inside a stable version (bug fix). There were some files in the documentation with version 217 although there isn't any stable version able to write it. Those are just some examples of this case. There are lots of lessons to be learned from previous experience, so I propose to increment the number file format every time that we make a change. The alternative that table format implements is to have its own internal number. But this is not needed most of the time. Or we could have a major and minor file format version number. What do you (all of you, yes) think? I think that now is the right time to discuss this as we are soon entering a new development cycle. and in reLyX which outputs \LyXTable multicol5 Does this mean that reLyX is already outputting tables in 216 format? Nope, that is 215 format. But in reality 215 means several things, that is why we need to guess which one we are using. And that is also what I want to avoid. Regards, -- José Abílio
Re: Table format question (for Jos?)
On Wednesday 05 February 2003 15:10, Angus Leeming wrote: [...] Well, that wasn't my intention in asking the original question, but major and minor versions make sense since that would allow you to define your linear series of converters 215.py, 216.py and have special code within them to deal with odd ball cases. No need, when converting from x to y, to go by way of x.3 if you can go straight to y. Both solution, changing the number each time or major/minor numbers, are isomorphic. It is just a matter of being easier to read for us. Every major number would be identified uniquely with a lyx version. Does this mean that reLyX is already outputting tables in 216 format? Nope, that is 215 format. So to be clear: 215 format == multicol5 but I have to make sure that reLyX does the things in your 215.py:update_tabular routine in order to output tables in 216 format? No the case where the table file format is 4 is older than reLyX so you don't need to consider it. Do you have any example tables that get transformed by the code in 215.py:update_tabular? You shouldn't care with that case. I thought that I'd take your incremental approach in trying to get reLyX to output moderm LyX (albeit a limited subset of it). Ok. -- José Abílio
Re: python tutorial required
On Wednesday 05 February 2003 15:15, Angus Leeming wrote: def merge_formula_inset(lines): i=0 while 1: i = find_token(lines, \\begin_inset Formula, i) if i == -1: break if lines[i+1] in math_env: lines[i] = lines[i] + lines[i+1] del lines[i+1] i = i + 1 That's odd. Running the attached test case through $ lyx2lyx -t 216 test_215.lyx test_216.lyx changes only the file format. Because there is a blank space after the first \[ Is that a file created with reLyX? If yes I will trim the final space to test for it. -- José Abílio
Re: python tutorial required
On Wednesday 05 February 2003 16:07, Angus Leeming wrote: $ cat test_215.lyx | sed 's/\(.\)$/\1X/' On linux I use cat -E for it, although I could use cat -e and be portable (since you care ;-). So, I guess you don't need to do anything and nor do I in this case either. That is what I like to hear. :-) -- José Abílio
Re: lyxformat 216 and reLyX cont.
On Wednesday 05 February 2003 17:32, Angus Leeming wrote:
José,
reLyX doesn't know about these tokens. Should I therefore ignore them? Or
should I do as you do and remove the line?
def remove_cursor(lines):
i = find_token(lines, '\\cursor', 0)
if i != -1:
del lines[i]
def remove_vcid(lines):
i = find_token(lines, '\\lyxvcid', 0)
if i != -1:
del lines[i]
i = find_token(lines, '\\lyxrcsid', 0)
if i != -1:
del lines[i]
Ignore them. They were produced by lyx.
This is the last outstanding issue:
def update_toc(lines):
i = 0
while 1:
i = find_token(lines, '\\begin_inset LatexCommand
\\tableofcontents', i)
if i == -1:
break
lines[i] = lines[i] + '{}'
i = i + 1
Ok, this affects reLyX. It happily outputs:
\\begin_inset LatexCommand \\tableofcontents$
Here's the code. Shall I simply append a '{}' after $name for all of them?
Yes, that is all. :-)
# Things that LyX translates as LatexCommands
# E.g., \ref{foo} -'\begin_inset LatexCommand \ref{foo}\n\n\end_inset \n'
# (Some take arguments, others don't)
my @LatexCommands = map {\\$_} qw(ref pageref label cite bibliography
index printindex tableofcontents
listofalgorithms listoftables
listoffigures);
# Handle tokens that LyX translates as a LatexCommand inset
} elsif (grep {$_ eq $name} @LatexCommands) {
CheckForNewParagraph; #Start new paragraph if necessary
print OUTFILE $pre_space\n\\begin_inset LatexCommand ,
$name,
\n\n\\end_inset \n\n;
--
José Abílio
Re: (for Jos!) analysis of bug 16
On Saturday 01 February 2003 12:45, Angus Leeming wrote: However, if we can generate such a table then we should be able to convert an old lyx file with this info into the current format. In fact, going from lyxformat 217 Column alignment=8 valignment=0 leftline=1 rightline=2 width= special= Ok, now I understand what does it means that 2 that has intrigued me for quite some time. to today's column alignment=center valignment=top leftline=true rightline=true width=0pt special=|c No it is not difficult (line 92 of lyxconvert_217.py) should be trivial. Easy, but not trivial. ;-) What d'ya think José? Have we given you enough information to squash the bug? ;-) Yep. :-) -- José Abílio
Re: footnote numbering [was: Re: footnotes preview in lyx-1.3]
On Tuesday 21 January 2003 17:20, Moritz Moeller-Herrmann wrote: The argument goes like this: Mr. Moeller-Herrmann, in footnote 477, your argument is wrong and you have to cite XYZ. At the moment I have to compile the lyx document, check the dvi, find footnote 477, look for and remember some significant text part, go back to lyx, search for the remembered text part, check back with the dvi document to see if I am at the correct position, then start typing. Now with footnote numbering, I would scroll down until I see footnote 477, start typing. Then it would be easier to have the footnotes in navigate, or even better a function goto-footnote #n. Do you understand why it would be useful for me (and others)? It is easier to understand now. :-) -- José Abílio
