Re: lyxrow
Jose' Matos wrote: > On Friday 24 October 2003 03:25, Lars Gullik Bjønnes wrote: >> Alfredo Braunstein <[EMAIL PROTECTED]> writes: >> | + >> | + int minfill = ; >> >> This is not acceptable. > > How about: > > #include > int minfill = std::numeric_limits::max(); > > Is this what you want? > No. As I've said my post, I don't know what are the correct values (for minfill, for x etc) to return when the list is empty. I don't understand what the code does. I'm only pointing where the problem is, i.e. int minfill = rit->fill(); is not right if the list is empty. Said that, I suspect that it doesn't matter what you put there, as the UserGuide loads perfectly with the obviously wrong 99. Probably the function doesn't need to be called at all in that case. In any case, I'll leave it to someone that minimally understands the code. Alfredo
Re: lyxrow
On Friday 24 October 2003 03:25, Lars Gullik Bjønnes wrote: > Alfredo Braunstein <[EMAIL PROTECTED]> writes: > | + > | + int minfill = ; > > This is not acceptable. How about: #include int minfill = std::numeric_limits::max(); Is this what you want? -- José Abílio LyX and docbook, a perfect match. :-)
Re: lyxrow
Lars Gullik Bjønnes wrote: > Alfredo Braunstein <[EMAIL PROTECTED]> writes: > > | + > | + int minfill = ; > > This is not acceptable. Do tell. Have you read the post you are answering? Alfredo
Re: lyxrow
Andre Poenitz <[EMAIL PROTECTED]> writes: | | -typedef std::list RowList; | +typedef std::vector RowList; And you really want me to belive that this is the whole patch? -- Lgb
Re: lyxrow
Alfredo Braunstein <[EMAIL PROTECTED]> writes: | + | + int minfill = ; This is not acceptable. -- Lgb
Re: [patch] rit -> row, spare cycles
John Levon <[EMAIL PROTECTED]> writes: | On Thu, Oct 23, 2003 at 10:46:45AM +0200, Lars Gullik Bj?nnes wrote: > >> When doing a change, albeit trivial, just send the patch to the list >> and then just commit it. It is a lot easier to comment on a >> monolithic patch than to scourge through viewcvs. > | Then I feel I must ask again why we don't have lyx-commits mailing list. | I forget why you refused it when I asked before ... you mean a "lyx-patches" lyx commits is the lyx-cvs list. -- Lgb
Re: lyxrow
Alfredo Braunstein wrote: > Index: text.C > === > RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text.C,v Loading time seems to be more or less similar. I have done a little profiling by loading lyx and the Userguide and then time (i=0; while [ $i -lt 500 ]; do i=$[ $i + 1 ]; echo "down"; done; echo BYE:) | ~/lyxclient -a $SOCKETNAME; (Thanks João!) Unfortunately, one has to look at the real time, because the user/sys time refers to lyxclient of course. But they were tested under similar conditions one after the other. The results are not spectacular, but not bad: old 0m3.264s 0m3.139s 0m3.133s new 0m2.781s 0m2.760s 0m2.742s so, something like a 13% time improvement Regards, Alfredo
Re: LyX Archaeology
On Thursday 23 October 2003 17:21, Angus Leeming wrote: > What happened to that web page, José? > > I looked here: > http://www.lyx.org/archaeology > http://www.devel.lyx.org/archaeology http://www.lyx.org/~jamatos/archaeology > Did you ever commit it? I had a Conference after that period. I did not forgot the project also, but I was slowdown because I need to convert it to php and I have been working on more important issues at moment. (Read, fixing bugs :-) Tomorrow I will give a talk, and the same in two weeks, so I am trying to manage my time for lyx, using the cvs version to write the documents. :-) I do intend to commit, for sure. :-) I did not saw Asger's message saying to commit, only after some time visiting gmane archive because the network guys here goofed... -- José Abílio LyX and docbook, a perfect match. :-)
Re: lyxrow
Andre Poenitz wrote: >> I don't expect them to be hard to solve... (probably the culprit is >> redoParagraph) >> >> I'll have a look tomorrow if you don't do it. > > I think I'll leave it to you. Ok, this seems a bug that it's already here. As I don't know what exactly does this quantities are, I don't know what is the correct values (or even if this function has to be called at all) when the rowlist is empty. But with this patch the UserGuide loads perfectly and I don't get any visible problem. Comments? (and the right solution? :-) ) Index: text.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text.C,v retrieving revision 1.479 diff -u -p -u -r1.479 text.C --- text.C 23 Oct 2003 15:38:47 - 1.479 +++ text.C 23 Oct 2003 16:33:52 - @@ -364,11 +364,12 @@ int LyXText::leftMargin(ParagraphList::i // row in this paragraph. RowList::iterator rit = pit->rows.begin(); RowList::iterator end = pit->rows.end(); - int minfill = rit->fill(); + + int minfill = ; for ( ; rit != end; ++rit) if (rit->fill() < minfill) minfill = rit->fill(); - + x += font_metrics::signedWidth(layout->leftmargin, tclass.defaultfont()); x += minfill; Index: RowList_fwd.h === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/RowList_fwd.h,v retrieving revision 1.3 diff -u -p -u -r1.3 RowList_fwd.h --- RowList_fwd.h 23 Oct 2003 15:09:04 - 1.3 +++ RowList_fwd.h 23 Oct 2003 16:33:52 - @@ -12,10 +12,10 @@ #ifndef ROW_LIST_FWD_H #define ROW_LIST_FWD_H -#include +#include class Row; -typedef std::list RowList; +typedef std::vector RowList; #endif
LyX Archaeology
What happened to that web page, José? I looked here: http://www.lyx.org/archaeology http://www.devel.lyx.org/archaeology Did you ever commit it? -- Angus
Re: LyX programming assignment in class of 200 3rd year SE students
On October 23, 2003 07:57 am, John Levon wrote: > On Thu, Oct 23, 2003 at 11:52:07AM +0200, Andre Poenitz wrote: > > Everything else would leave us with the need of forward-porting 50 new > > features. If we stick to 1.3.xcvs we'd end up in the same situation as > > the change tracking patch. Works for some ancient version only. > > Change tracking worked almost perfectly in 1.4.0cvs some time ago > > john Change tracking is working very well in 1.3.2-patched as well. I don't think 1.3.2 is so "ancient" a version. Cheers, JB -- Johnathan K. Burchill, Ph.D. Department of Physics and Astronomy University of Calgary 2500 University Drive N.W. Calgary, AB T2N 1N4 Canada (403) 217-4286 [EMAIL PROTECTED]
Re: lyxrow
On Thu, Oct 23, 2003 at 06:00:22PM +0200, Alfredo Braunstein wrote: > Andre Poenitz wrote: > > > To quick. > > > > There seems to be a place or two that relies on stable > > RowList::iterators. > > But the profiling was ok or it was shorter because it crashed? Probably the latter. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: lyxrow
Andre Poenitz wrote: > To quick. > > There seems to be a place or two that relies on stable > RowList::iterators. But the profiling was ok or it was shorter because it crashed? Alfredo
Re: [patch] fix a don't like 3
Andre Poenitz wrote: >> Mmm.. we got a strange clash in text3.C. I thought that cvs was supposed >> to take care of that? > > Me too. I got no conflict in cvs up. Probably my fault, I got no conflict but your change seems to have entered first and I didn't check. Anyway, I've removed it. Alfredo
Re: [patch] fix a don't like 3
On Thu, Oct 23, 2003 at 05:53:54PM +0200, Alfredo Braunstein wrote: > Alfredo Braunstein wrote: > > > Andre Poenitz wrote: > > > >> Well spotted. > >> > >> Patch is ok. > > > > Commited both (the other is similar). Thanks, Alfredo > > Mmm.. we got a strange clash in text3.C. I thought that cvs was supposed to > take care of that? Me too. I got no conflict in cvs up. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: [patch] fix a don't like 3
Alfredo Braunstein wrote: > Andre Poenitz wrote: > >> Well spotted. >> >> Patch is ok. > > Commited both (the other is similar). Thanks, Alfredo Mmm.. we got a strange clash in text3.C. I thought that cvs was supposed to take care of that? There is an extra rit = cursorRow() in text.3:previousRow Alfredo
[Patch] Re: Bug: Problem with "Navigate" menu and Branches
On Thu, Oct 23, 2003 at 12:42:43AM -0700, Kayvan A. Sylvan spake thusly:
BTW it seems my patch of this morning never made it to the list.
Attached, fixes at least the error message caused by the menu shortcuts.
The problem that my other post refers to, it that LyX still freezes
(endless loop, apparently in text.C:2122 std::distance()) if you click
on one of the sectioning headers in the Nav menu, if it is within a
branch inset. *Very* unpleasant.
- Martin
Index: MenuBackend.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/MenuBackend.C,v
retrieving revision 1.91
diff -u -p -r1.91 MenuBackend.C
--- MenuBackend.C 14 Oct 2003 21:30:19 - 1.91
+++ MenuBackend.C 23 Oct 2003 08:54:47 -
@@ -536,8 +536,9 @@ void expandToc2(Menu & tomenu,
string label(4 * max(0, toc_list[i].depth - depth),' ');
label += limit_string_length(toc_list[i].str);
if (toc_list[i].depth == depth
- && ++shortcut_count <= 9) {
- label += '|' + tostr(shortcut_count);
+ && shortcut_count < 9) {
+ if (label.find(tostr(shortcut_count + 1)) !=
string::npos)
+ label += '|' + tostr(++shortcut_count);
}
tomenu.add(MenuItem(MenuItem::Command, label,
FuncRequest(toc_list[i].action(;
@@ -553,9 +554,10 @@ void expandToc2(Menu & tomenu,
string label(4 * max(0, toc_list[pos].depth - depth), ' ');
label += limit_string_length(toc_list[pos].str);
if (toc_list[pos].depth == depth &&
- ++shortcut_count <= 9)
- label += '|' + tostr(shortcut_count);
-
+ shortcut_count < 9) {
+ if (label.find(tostr(shortcut_count + 1)) !=
string::npos)
+ label += '|' + tostr(++shortcut_count);
+ }
if (new_pos == pos + 1) {
tomenu.add(MenuItem(MenuItem::Command,
label,
FuncRequest(toc_list[pos].action(;
pgp0.pgp
Description: PGP signature
Re: [patch] fix a don't like 3
Andre Poenitz wrote: > Well spotted. > > Patch is ok. Commited both (the other is similar). Thanks, Alfredo
Re: Bug: Problem with "Navigate" menu and Branches
On Thu, Oct 23, 2003 at 12:42:43AM -0700, Kayvan A. Sylvan spake thusly:
> Do not let your heart be troubled. It is a step in the right direction.
> You've done good work! The one remaining issue is with the Navigate menu
> when a branch encloses a Chapter or Section.
Kayvan,
I tried to analyse the problem of going to a sectioning header inside
a branch by clicking on it in the Nav menu (and LyX freezing up), and
the problem seems to be located here in text.C:
2120 int LyXText::parOffset(ParagraphList::iterator pit) const
2121 {
2122 return std::distance(ownerParagraphs().begin(), pit);
2123 }
which is called from text2.C:
1263 void LyXText::setCursor(ParagraphList::iterator pit, pos_type pos)
1264 {
1265 setCursor(parOffset(pit), pos);
1266 }
...from lyxfunc.C:
1400 ParIterator par = owner->buffer()->getParFromID(id);
...
1416 // Set the cursor
1417 view()->getLyXText()->setCursor(par.pit(), 0);
...setting the cursor.
The std::distance function doesn't seem to go anywhere when pit (I
assume pointing to the sectioning header) is inside an inset, and
ownerParagraphs pointing... where? The start of the main text? Are
these even iterators on the same container?
Experts, HELP!
- Martin
pgp0.pgp
Description: PGP signature
Counters for docbook, a new tail.
Hi, One of the most visible problems for docbook in 1.3 and 1.4 are the absence of counters for section ( and those from family). It looks like the counters expect the style name to be the same as LaTeXName. I add a new file to layouts like this: # This include file contains all the counters that are defined as standard # in docbook LyX layouts. Counter Name sect1 Within chapter End Counter Name sect2 Within sect1 End Counter Name sect3 Within sect2 End Counter Name sect4 Within sect3 End Counter Name sect5 Within sect4 End I do this after inserting the latex counters and all is well, but without the definition of section, subsection, subsubsection (...) counters LyX complains. Adding this file this makes LyX 1.4 happy, but for 1.3 although it doen't complain anymore it doesn't display the counters. Any hint for 1.3? -- José Abílio LyX and docbook, a perfect match. :-)
Re: [patch] fix a don't like 3
Alfredo Braunstein wrote: > This seems to solve it. As I haven't looked carefully at the code, it > would be nice if someone else could test it as well. A similar fix for previousRow. I cannot fire donlikes anymore by playing with the UserGuide. Alfredo Index: text3.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text3.C,v retrieving revision 1.155 diff -u -p -u -r1.155 text3.C --- text3.C 18 Oct 2003 14:43:54 - 1.155 +++ text3.C 23 Oct 2003 15:32:52 - @@ -284,6 +284,7 @@ void LyXText::cursorPrevious() } LyXCursor cur; + rit = cursorRow(); ParagraphList::iterator pit = cursorPar(); previousRow(pit, rit); setCursor(cur, parOffset(pit), rit->pos(), false); @@ -342,6 +343,7 @@ void LyXText::cursorNext() } ParagraphList::iterator pit = cursorPar(); + rit = cursorRow(); nextRow(pit, rit); LyXCursor cur; setCursor(cur, parOffset(pit), rit->pos(), false);
Re: [patch] fix a don't like 3
On Thu, Oct 23, 2003 at 05:19:31PM +0200, Alfredo Braunstein wrote: > open the userguide, a press page down. You get a don't like 3, a.k.a > "row.pos() < pos when the row should contain the pos". > > The problem resides in cursorNext(), where a rit and a pit get out-of sync > and then nextRow(pit,rit) is called. > > This seems to solve it. As I haven't looked carefully at the code, it would > be nice if someone else could test it as well. Well spotted. Patch is ok. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: lyxrow
On Thu, Oct 23, 2003 at 05:16:55PM +0200, Alfredo Braunstein wrote: > Andre Poenitz wrote: > > > To quick. > > > > There seems to be a place or two that relies on stable > > RowList::iterators. > > I don't expect them to be hard to solve... (probably the culprit is > redoParagraph) > > I'll have a look tomorrow if you don't do it. I think I'll leave it to you. Andre'
[patch] fix a don't like 3
open the userguide, a press page down. You get a don't like 3, a.k.a "row.pos() < pos when the row should contain the pos". The problem resides in cursorNext(), where a rit and a pit get out-of sync and then nextRow(pit,rit) is called. This seems to solve it. As I haven't looked carefully at the code, it would be nice if someone else could test it as well. Regards, Alfredo Index: text3.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text3.C,v retrieving revision 1.155 diff -u -p -u -r1.155 text3.C --- text3.C 18 Oct 2003 14:43:54 - 1.155 +++ text3.C 23 Oct 2003 15:11:38 - @@ -342,6 +342,7 @@ void LyXText::cursorNext() } ParagraphList::iterator pit = cursorPar(); + rit = cursorRow(); nextRow(pit, rit); LyXCursor cur; setCursor(cur, parOffset(pit), rit->pos(), false);
Re: lyxrow
Andre Poenitz wrote: > To quick. > > There seems to be a place or two that relies on stable > RowList::iterators. I don't expect them to be hard to solve... (probably the culprit is redoParagraph) I'll have a look tomorrow if you don't do it. Alfredo
Re: lyxrow
On Thu, Oct 23, 2003 at 04:10:53PM +0100, John Levon wrote: > On Thu, Oct 23, 2003 at 05:07:18PM +0200, Andre Poenitz wrote: > > > Whohey: > > That's my kind of patch ! :) Very kind to take the brown paper bag off from me ;-) Andre'
Re: lyxrow
On Thu, Oct 23, 2003 at 05:07:18PM +0200, Andre' Poenitz wrote: > On Thu, Oct 23, 2003 at 04:32:17PM +0200, Alfredo Braunstein wrote: > > Andre Poenitz wrote: > > > > >> But it won't be expensive anymore, as rowlist are per-paragraph, right? > > > > > > But the paragraph data needs to be shifted down as well. > > > > Huh? What paragraph data? Why are you talking about ParagraphList? I'm > > talking about the RowList member of a Paragraph. They have ~5 element each. > > Whohey: To quick. There seems to be a place or two that relies on stable RowList::iterators. Andre'
Re: lyxrow
On Thu, Oct 23, 2003 at 05:07:18PM +0200, Andre Poenitz wrote: > Whohey: That's my kind of patch ! :) john
Re: lyxrow
Andre Poenitz wrote: > Whohey: > > > old: > > 'command-sequence file-open UserGuide.lyx ; lyx-quit ; ' > > real0m1.882s > user0m0.860s > sys 0m0.020s > > > new: > > real0m1.043s > user0m0.440s > sys 0m0.000s Not bad for a 2 lines patch ;-) Alfredo
Re: lyxrow
On Thu, Oct 23, 2003 at 04:32:17PM +0200, Alfredo Braunstein wrote: > Andre Poenitz wrote: > > >> But it won't be expensive anymore, as rowlist are per-paragraph, right? > > > > But the paragraph data needs to be shifted down as well. > > Huh? What paragraph data? Why are you talking about ParagraphList? I'm > talking about the RowList member of a Paragraph. They have ~5 element each. Whohey: old: 'command-sequence file-open UserGuide.lyx ; lyx-quit ; ' real0m1.882s user0m0.860s sys 0m0.020s new: real0m1.043s user0m0.440s sys 0m0.000s patch: Index: RowList_fwd.h === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/RowList_fwd.h,v retrieving revision 1.1 diff -u -p -r1.1 RowList_fwd.h --- RowList_fwd.h 6 Sep 2003 11:01:46 - 1.1 +++ RowList_fwd.h 23 Oct 2003 15:04:20 - @@ -12,10 +12,10 @@ #ifndef ROW_LIST_FWD_H #define ROW_LIST_FWD_H -#include +#include class Row; -typedef std::list RowList; +typedef std::vector RowList; #endif I guess I'll simply commit. Andre'
Re: LyX programming assignment in class of 200 3rd year SE students
On Thu, Oct 23, 2003 at 04:12:57PM +0200, Andre Poenitz wrote: > > Change tracking worked almost perfectly in 1.4.0cvs some time ago > > What's missing nowadays? It's not a matter of missing, more that most things are broken. regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: lyxrow
On Thu, Oct 23, 2003 at 04:32:17PM +0200, Alfredo Braunstein wrote: > Andre Poenitz wrote: > > >> But it won't be expensive anymore, as rowlist are per-paragraph, right? > > > > But the paragraph data needs to be shifted down as well. > > Huh? What paragraph data? Why are you talking about ParagraphList? Don't know. Maybe because I prefered thinking about paragraphlists ... > I'm talking about the RowList member of a Paragraph. They have ~5 > element each. Ah yes. Should be a vector ;-) Andre'
Re: lyxrow
Andre Poenitz wrote: >> But it won't be expensive anymore, as rowlist are per-paragraph, right? > > But the paragraph data needs to be shifted down as well. Huh? What paragraph data? Why are you talking about ParagraphList? I'm talking about the RowList member of a Paragraph. They have ~5 element each. >> I don't see the tradeoff: it seems to me that we can only win. > > See above. See above as well. ;-) Alfredo
Re: lyxrow
On Thu, Oct 23, 2003 at 04:15:57PM +0200, Alfredo Braunstein wrote: > Andre Poenitz wrote: > > > On Thu, Oct 23, 2003 at 03:57:25PM +0200, Alfredo Braunstein wrote: > >> Is there any particular reason that make us have RowList as a std::list? > >> Now that we pretty much redo it from the beginning every time (as it is > >> per-paragraph), shouldn't we use a std::vector? We can probably gain a > >> bit of speed. > > > > We could try. > > > > The problem used to be insertion or deletion of a paragraph in the > > middle of the doc. This is theoretically expensive and I don't have any > > gut feeling how it would turn out in practice. > > But it won't be expensive anymore, as rowlist are per-paragraph, right? But the paragraph data needs to be shifted down as well. [Some pet project of mine uses 'swap' in some std::vector<> to shift down stuff to mae room for new items. This is pretty effective under certain circumstances (like the ones we have here) but I don't know of any official implementation of it. So it would be possible to use some hand-made ParagraphList container with an interface exactly like std::vector<> and the same performance guarantees _plus_ 'decent insert' (still O(n), but will really small constant factor...)] > > Note that e.g. LyXText::getPar() would benefit from such a change > > speed-wise, so it may well be neutral or even an improvement. > > I don't see the tradeoff: it seems to me that we can only win. See above. Andre'
Re: lyxrow
Andre Poenitz wrote: > On Thu, Oct 23, 2003 at 03:57:25PM +0200, Alfredo Braunstein wrote: >> Is there any particular reason that make us have RowList as a std::list? >> Now that we pretty much redo it from the beginning every time (as it is >> per-paragraph), shouldn't we use a std::vector? We can probably gain a >> bit of speed. > > We could try. > > The problem used to be insertion or deletion of a paragraph in the > middle of the doc. This is theoretically expensive and I don't have any > gut feeling how it would turn out in practice. But it won't be expensive anymore, as rowlist are per-paragraph, right? > Note that e.g. LyXText::getPar() would benefit from such a change > speed-wise, so it may well be neutral or even an improvement. I don't see the tradeoff: it seems to me that we can only win. Alfredo
Re: LyX programming assignment in class of 200 3rd year SE students
On Thu, Oct 23, 2003 at 02:57:36PM +0100, John Levon wrote: > On Thu, Oct 23, 2003 at 11:52:07AM +0200, Andre Poenitz wrote: > > > Everything else would leave us with the need of forward-porting 50 new > > features. If we stick to 1.3.xcvs we'd end up in the same situation as > > the change tracking patch. Works for some ancient version only. > > Change tracking worked almost perfectly in 1.4.0cvs some time ago What's missing nowadays? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: lyxrow
On Thu, Oct 23, 2003 at 03:57:25PM +0200, Alfredo Braunstein wrote: > Is there any particular reason that make us have RowList as a std::list? > Now that we pretty much redo it from the beginning every time (as it is > per-paragraph), shouldn't we use a std::vector? We can probably gain a bit > of speed. We could try. The problem used to be insertion or deletion of a paragraph in the middle of the doc. This is theoretically expensive and I don't have any gut feeling how it would turn out in practice. Note that e.g. LyXText::getPar() would benefit from such a change speed-wise, so it may well be neutral or even an improvement. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: Compiling Qt-version on RH 7.3
On Thu, 23 Oct 2003, Lars Gullik Bjønnes wrote: > Christian Ridderström <[EMAIL PROTECTED]> writes: > > | This leaves me with the option to compile Qt myself. Sigh... maybe I'll > | get around to that someday, or when I absolutely have to. > > Is it _that_ bad to use the xforms version? No, of course not... my latest compile attempt was so that I could help with testing the speed of rebreaking without cache (or something). And today I wanted to test if the external inset works on Qt (didn't work on Xforms). Actually, I'm only using LyX for developing these days since I'm not writing anything. > And upgrade to newer RH is always an option. Not in my case unfortunately (or I'll have to compile on a 300MHz machine instead of one with 2.2Ghz and two CPUs). /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: LyX programming assignment in class of 200 3rd year SE students
On Thu, Oct 23, 2003 at 11:52:07AM +0200, Andre Poenitz wrote: > Everything else would leave us with the need of forward-porting 50 new > features. If we stick to 1.3.xcvs we'd end up in the same situation as > the change tracking patch. Works for some ancient version only. Change tracking worked almost perfectly in 1.4.0cvs some time ago john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
lyxrow
Is there any particular reason that make us have RowList as a std::list? Now that we pretty much redo it from the beginning every time (as it is per-paragraph), shouldn't we use a std::vector? We can probably gain a bit of speed. Regards, Alfredo
Re: LyX programming assignment in class of 200 3rd year SE students
On Thu, Oct 23, 2003 at 11:33:59AM +0200, Christian Ridderstr?m wrote: > In my experience, some filtering would definitely be needed... > some (most?) students can be lazy and ask the most silly questions > rather than think for themselves... So why doesn't the standard open source method of filtering work ? i.e. silly questions get ignored :) I think a lyx-students list or whatever would be a fine idea. regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: [patch] rit -> row, spare cycles
On Thu, Oct 23, 2003 at 10:46:45AM +0200, Lars Gullik Bj?nnes wrote: > When doing a change, albeit trivial, just send the patch to the list > and then just commit it. It is a lot easier to comment on a > monolithic patch than to scourge through viewcvs. Then I feel I must ask again why we don't have lyx-commits mailing list. I forget why you refused it when I asked before ... regards john
Re: row.end
On Thu, Oct 23, 2003 at 09:50:49AM +0200, Andre Poenitz wrote: > John. We are not talking about -1. That's what I took from your first post ... if lastPos() doesn't exist, or never returns -1, then I'm happy with whatever. > Yes. You might want to fix that. Let he who is without sin ... regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: Compiling Qt-version on RH 7.3
On Thu, 23 Oct 2003, Lars Gullik Bjønnes wrote: > >> Note that when I do this I do it blind, I do not have gcc 2.96 > >> available nor 2.95 I'll be happy to be your eyes and hands, i.e. let me know what to do and I'll try it. /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: Compiling Qt-version on RH 7.3
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> | I understand that. What kind of info would be useful? It seems
Lars> that | some pointer somewhere points to nothing instead of a
Lars> stream.
Lars> Hmm... your are unable to debug the LyX you got as well?
I can debug, have a backtrace, and then I am not sure what it means.
Lars> what pointer?
I'll send as many gory details as I can, but not before next tuesday
unfortunately... In the meantime, look at the backtrace here:
http://marc.theaimsgroup.com/?l=lyx-devel&m=106640107014154&w=2
in frame #0, it seems that it is the 'this' which is wrong. frame #1
corresponds to the code below, where I highlighted line 265 with
<==. So a guess is that rdbuf() does not return a sane value.
Hope this helps.
JMarc
template
void basic_ostream<_CharT, _Traits>::_M_put_nowiden(const _CharT* __s)
{
sentry __sentry(*this);
if (__sentry) {
bool __failed = true;
streamsize __n = _Traits::length(__s);
streamsize __npad = this->width() > __n ? this->width() - __n : 0;
_STLP_TRY {
if (__npad == 0)
__failed = this->rdbuf()->sputn(__s, __n) != __n; // <=
else if ((this->flags() & ios_base::adjustfield) == ios_base::left) {
__failed = this->rdbuf()->sputn(__s, __n) != __n;
__failed = __failed ||
this->rdbuf()->_M_sputnc(this->fill(), __npad) != __npad;
}
else {
__failed = this->rdbuf()->_M_sputnc(this->fill(), __npad) != __npad;
__failed = __failed || this->rdbuf()->sputn(__s, __n) != __n;
}
this->width(0);
}
_STLP_CATCH_ALL {
this->_M_handle_exception(ios_base::badbit);
}
if (__failed)
this->setstate(ios_base::failbit);
}
}
Re: LyX programming assignment in class of 200 3rd year SE students
On Thu, 23 Oct 2003, Christian Ridderström wrote: > On Thu, 23 Oct 2003, Lars Gullik Bjønnes wrote: > > > Christian Ridderström <[EMAIL PROTECTED]> writes: > > > > >> [I'd be a bit happier with the whole idea if there were just 30 or 50 > > >> students or so...] > > > > > | You don't say... > > > > but of course this is a bit of an experiment for us as well... so > > bring it on! > > Famous last words... ? > though I agree with lars, it is an experiment that could be fun, but definitely will be interesting. /C -- Dr. Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: LyX programming assignment in class of 200 3rd year SE students
On Thu, 23 Oct 2003, Lars Gullik Bjønnes wrote: > Christian Ridderström <[EMAIL PROTECTED]> writes: > > >> [I'd be a bit happier with the whole idea if there were just 30 or 50 > >> students or so...] > > > | You don't say... > > but of course this is a bit of an experiment for us as well... so > bring it on! Famous last words... ? /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: Latin1 in strings (was: Re: updated sl.po for LyX 1.3.3)
Jean-Marc Lasgouttes wrote: > and these ones which come from the math panel > Û >± ´ >£ @ >S ò >!(£ @) > (can these be replaced with real icons?) Can't we make these non-translatable at all? I know there was a reason, but I can't remember. Alfredo
Re: LyX programming assignment in class of 200 3rd year SE students
Christian Ridderström <[EMAIL PROTECTED]> writes: >> [I'd be a bit happier with the whole idea if there were just 30 or 50 >> students or so...] > | You don't say... but of course this is a bit of an experiment for us as well... so bring it on! -- Lgb
Re: Compiling Qt-version on RH 7.3
On Thu, 23 Oct 2003, Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > > | Christian Ridderström wrote: > >> I wouldn't say I've been quiet (see > >> http://marc.theaimsgroup.com/?l=lyx-devel&m=106638664600359&w=2 > >> > >> Initially the problem was that gcc 2.96 couldn't be used anymore. > > > | Which is crap. Ie, a bad state of affairs. > > We (I) might eventually do something with this... better would of course > to get all useres to use newer compilers. which is when I got into problems since my Qt was compiled with gcc 2.96... /Christian PS. I can use these versions of gcc: $ module avail gcc /usr/local/lib/module/modules -- gcc/2.95.2 gcc/2.96 gcc/3.0.4 gcc/3.2.3 gcc/3.3.1 gcc/3.3.2 if that helps. -- Christian Ridderström http://www.md.kth.se/~chr
Re: Latin1 in strings
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Is that doable? We have several strings that cause grief to msgfmt: > |Rotate 90°|#9 |Rotate the table by 90° |Rotate this cell by 90° | (where does this  come from? Has some unicode sneaked in?) utf-8 we should in lyx use only ascii in strings so instead of ° we should f.ex. just write degrees. (deg.) |«text» |»text« <<>> >><< | ``text'' | ''text'' | ,,text`` | ,,text'' | «text» | »text« | (I guess we can use << >> and >> << without too much harm here) | and these ones which come from the math panel | Û |± ´ |£ @ |S ò |!(£ @) These are worst. | (can these be replaced with real icons?) > | Who has ideas on how to handle this mess? Not the math ones. -- Lgb
Re: [patch] tex2lyx improvements
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> I would rather like it the other way round: Make tex2lyx <
Georg> infile > outfile work.
You can do both, like gzip does.
Georg> - output minipages with latex lengths as ERT, since lyx cannot
Georg> handle them
>> Could you be more specific?
Georg> I mean this: \begin{minipage}{\mylength}
But this should be done for all things that contain lenghts, then?
What a pain...
Georg> I did not know that extra_stuff was intended for this. I will
Georg> try if it works.
Thanks.
Georg> - handle optional arg to \item as ERT in itemize environment,
Georg> since LyX does not support it directly
>> I do not like the way this one is implemented. You have all the
>> information you need in the layout file. Instead of testing against
>> "itemize", you need something like (untested) if
>> (context.layout->labeltype != LABEL_MANUAL) {
Georg> I don't really know how the layout files work, but it sounds
Georg> sensible.
Let me know is it does not work.
JMarc
Re: LyX programming assignment in class of 200 3rd year SE students
On Thu, 23 Oct 2003, Andre Poenitz wrote: > On Thu, Oct 23, 2003 at 06:12:36AM -0700, Kayvan A. Sylvan wrote: > > > How will the list communicate with lyx-devel? One idea is for them to send > > their patches to their professor for review before sending it over to this > > list. > > The professor can't handle that any better than people reading here. True, however, it's the professors job to evaluate the projects for grading, so he has to look at the patches sometime. Actually, with 200 students, there's got to be a several teaching assistants around as well. > Actually, simple coding question could be answered from most regulars > here with 'yes' or 'no' without browsing LyX sources, so direct contact > should be more effective. > > We should set up a separate mailing list 'lyx-whatever' and the students > should read them regularly (and even could use it to discuss problems, > not just for submitting patches). How about 'lyx-student' (sounds weird in Swedish btw, "luxury-student"). I think the simple questions should go to the student's list, some of the really simple questions should be answerable by the other students. For tougher questions, we could either subscribe to the student's list, or ask them to send it to the devel-list. > [I'd be a bit happier with the whole idea if there were just 30 or 50 > students or so...] You don't say... /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: Compiling Qt-version on RH 7.3
Angus Leeming <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: > >> Angus Leeming <[EMAIL PROTECTED]> writes: >> >> | Lars Gullik Bjønnes wrote: We (I) might eventually do something with this... better would of course to get all useres to use newer compilers. >>> >> | Sooner rather than later would be good too. I think we all value >> | Jean-Marc's contributions... >> >> Note that when I do this I do it blind, I do not have gcc 2.96 >> available nor 2.95 > | So, do your best and leave it to the protagonists to make it work. | At least give them a picture of what they need. > >> | Just have a support/detail directory, á la boost. Then you'll >> | never be offended by the contents of support/detail/gcc29x >>> >> | ;-) >> >> There are make and configure issues. >> (dirty stuff) > | Really? Because _we_ use autoconf/automake. (and we already have the machinery for this, it must only be applied in a slightly different way than before.) -- Lgb
Latin1 in strings (was: Re: updated sl.po for LyX 1.3.3)
I the course of a private e-mail exchange, Roman said > "Roman" == Roman Maurer <[EMAIL PROTECTED]> writes: Roman> IMHO it is a bad idea to have 8-bit ISO-8859-1 characters in Roman> those msgid's. I don't think there's a way for non-Latin-1 Roman> users to really translate those strings. This was also the Roman> cause of silent errors after conversion from Unicode. Roman> IMHO there should only be ASCII characters in msgid's. English Roman> "translator" can then create his own en.po and put ISO-8859-1 Roman> characters there if he wants, but other translators can have Roman> their own encodings. Roman> For example this is how en.po would look like: Roman> #: ../src/frontends/xforms/forms/form_tabular.fd:284 Roman> #: ../src/frontends/xforms/forms/form_tabular.fd:1200 Roman> # TRANSLATORS NOTE: o is the degree sign Roman> msgid "Rotate 90o#9" Roman> msgstr "Rotate 90°#9" Is that doable? We have several strings that cause grief to msgfmt: Rotate 90°|#9 Rotate the table by 90° Rotate this cell by 90° (where does this  come from? Has some unicode sneaked in?) «text» »text« ``text'' | ''text'' | ,,text`` | ,,text'' | «text» | »text« (I guess we can use << >> and >> << without too much harm here) and these ones which come from the math panel Û ± ´ £ @ S ò !(£ @) (can these be replaced with real icons?) Who has ideas on how to handle this mess? JMarc
Re: LyX programming assignment in class of 200 3rd year SE students
On Thu, 23 Oct 2003, Kayvan A. Sylvan wrote: > On Thu, Oct 23, 2003 at 11:33:59AM +0200, Christian Ridderström wrote: > > > > Another question is what version of LyX the students should work with... > > it could be frustrating working with the CVS version since it's in a very > > fluctuating state (e.g. sometimes it doesn't even compile). > > I disagree. I think the CVS version is perfect for them to work on. > > It's perfectly valid for them to fix compilation problems as they arise. I agree that it's realistic, but it seems we have different opinions on how difficult we should make it for them. Or maybe it depends on what the goal of the assignment? - Should they learn to work with OSS? - Do a C++ programming project? - Do software development (including CVS, patches etc) > How will the list communicate with lyx-devel? One idea is for them to send > their patches to their professor for review before sending it over to this > list. Poor bastard ;-) /Christian -- Dr. Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: [patch] bidi
Lars Gullik Bjønnes wrote: > Ok to me. > (as long as only bidi suffers if it is not correct) > Oh, I don't know about that. In fact, I don't even understand (nor tried to) the code inside. I've made only canonical changes. I.e., if it compiles (and it does), it should work as before. I'll commit it. Alfredo
Re: LyX programming assignment in class of 200 3rd year SE students
On Thu, Oct 23, 2003 at 06:12:36AM -0700, Kayvan A. Sylvan wrote: > On Thu, Oct 23, 2003 at 11:33:59AM +0200, Christian Ridderström wrote: > > > > Another question is what version of LyX the students should work with... > > it could be frustrating working with the CVS version since it's in a very > > fluctuating state (e.g. sometimes it doesn't even compile). > > I disagree. I think the CVS version is perfect for them to work on. > > It's perfectly valid for them to fix compilation problems as they arise. > > How will the list communicate with lyx-devel? One idea is for them to send > their patches to their professor for review before sending it over to this > list. The professor can't handle that any better than people reading here. Actually, simple coding question could be answered from most regulars here with 'yes' or 'no' without browsing LyX sources, so direct contact should be more effective. We should set up a separate mailing list 'lyx-whatever' and the students should read them regularly (and even could use it to discuss problems, not just for submitting patches). [I'd be a bit happier with the whole idea if there were just 30 or 50 students or so...] Andre'
Re: [patch] bidi
Alfredo Braunstein <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: > >> | Who should I blame for Bidi.[Ch]? Dekel Tsur? >> >> I guess so. > > | Ok to commit this? Ok to me. (as long as only bidi suffers if it is not correct) -- Lgb
Re: [patch] tex2lyx improvements
Jean-Marc Lasgouttes wrote:
> Georg> - allow parsing of partial documents (for inclusion with \input).
> Georg> - steal commandline switches -c and -f from reLyX to support
> Georg> the previous point
>
> Good ideas. It would be nice to chenge the semantics of tex2lyx to
> match those of reLyX (for example have file.lyx as default output file
> instead of std output, and investigate what other flags may be useful).
I would rather like it the other way round: Make tex2lyx < infile > outfile
work.
> Georg> - output minipages with latex lengths as ERT, since lyx cannot
> Georg> handle them
>
> Could you be more specific?
I mean this:
\begin{minipage}{\mylength}
> Georg> - recognize start of appendix
>
> This code is a bit strange IMO. I have added a feature in Context that
> is intended for these kind of cases. I would think that adding
> context.extra_stuff += "\\start_of_appendix\n";
> at the right place should do what you want. The extra_stuff
> functionality is not very well thought admittedly, but it is designed
> for these kind of cases where one wants to save data to add to the
> _next_ paragraph. Could you check whether it works for you?
I did not know that extra_stuff was intended for this. I will try if it
works.
> Georg> - handle optional arg to \item as ERT in itemize environment,
> Georg> since LyX does not support it directly
>
> I do not like the way this one is implemented. You have all the
> information you need in the layout file. Instead of testing against
> "itemize", you need something like (untested)
> if (context.layout->labeltype != LABEL_MANUAL) {
I don't really know how the layout files work, but it sounds sensible.
Georg
Re: [patch] tex2lyx improvements
Andre Poenitz wrote: > Rather try to fix converting the UserGuide. It currently produce a > reasonable LyX which translates to invalid .tex in chapter 3.3: I know. I have a fix, but it touches the "Through away all whitespace after \command and add a space later" rule, and it is not finished. I'll ask for comments when I am content with it. Georg
Re: LyX programming assignment in class of 200 3rd year SE students
On Thu, Oct 23, 2003 at 11:33:59AM +0200, Christian Ridderström wrote: > > Another question is what version of LyX the students should work with... > it could be frustrating working with the CVS version since it's in a very > fluctuating state (e.g. sometimes it doesn't even compile). I disagree. I think the CVS version is perfect for them to work on. It's perfectly valid for them to fix compilation problems as they arise. How will the list communicate with lyx-devel? One idea is for them to send their patches to their professor for review before sending it over to this list. ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
Re: Compiling Qt-version on RH 7.3
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: >> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: > | Lars> Angus Leeming <[EMAIL PROTECTED]> writes: | Lars> | Lars Gullik Bjønnes wrote: We (I) might eventually do something with this... better would of course to get all useres to use newer compilers. >>> | Lars> | Sooner rather than later would be good too. I think we all | Lars> value | Jean-Marc's contributions... > | Lars> Note that when I do this I do it blind, I do not have gcc 2.96 | Lars> available nor 2.95 > | I understand that. What kind of info would be useful? It seems that | some pointer somewhere points to nothing instead of a stream. Hmm... your are unable to debug the LyX you got as well? what pointer? -- Lgb
Re: [patch] tex2lyx improvements
On Thu, Oct 23, 2003 at 02:56:21PM +0200, Jean-Marc Lasgouttes wrote: > Andre> The TeXbook. > > I see... I was surprised that the LaTeX manual did not mention it. Maybe because Mr Lamport figured out that too much freedom is bad for your health. > Andre> Note that the real fun starts with 4,5cM. > > what happens then? It should work, too. And so should \newskip\a \a10,5cM Plus, there is some fun with a few special words. but not \newskip\a \a10,5cM Plus, there is some fun with a few special words. It's really ugly to get all acceptable versions right. Andre'
Re: [patch] bidi
Lars Gullik Bjønnes wrote:
> | Who should I blame for Bidi.[Ch]? Dekel Tsur?
>
> I guess so.
Ok to commit this?
Alfredo
Index: Bidi.C
===
RCS file: Bidi.C
diff -N Bidi.C
--- /dev/null 1 Jan 1970 00:00:00 -
+++ Bidi.C 23 Oct 2003 13:02:10 -
@@ -0,0 +1,212 @@
+/**
+ * \file Bidi.C
+ * This file is part of LyX, the document processor.
+ * Licence details can be found in the file COPYING.
+ *
+ * \author Dekel Tsur
+ *
+ * Full author contact details are available in file CREDITS.
+ */
+
+
+#include "Bidi.h"
+#include "buffer.h"
+#include "insets/updatableinset.h"
+#include "lyxfont.h"
+#include "lyxrow.h"
+#include "lyxrow_funcs.h"
+#include "lyxrc.h"
+#include "paragraph.h"
+
+
+using lyx::pos_type;
+
+
+lyx::pos_type Bidi::log2vis(lyx::pos_type pos) const
+{
+ return (start_ == -1) ? pos : log2vis_list_[pos - start_];
+}
+
+
+lyx::pos_type Bidi::vis2log(lyx::pos_type pos) const
+{
+ return (start_ == -1) ? pos : vis2log_list_[pos - start_];
+}
+
+
+lyx::pos_type Bidi::level(lyx::pos_type pos) const
+{
+ return (start_ == -1) ? 0 : levels_[pos - start_];
+}
+
+
+bool Bidi::inRange(lyx::pos_type pos) const
+{
+ return start_ == -1 || (start_ <= pos && pos <= end_);
+}
+
+bool Bidi::same_direction() const
+{
+ return same_direction_;
+}
+
+
+void Bidi::computeTables(Paragraph const & par,
+ Buffer const & buf, Row & row)
+{
+ same_direction_ = true;
+ if (!lyxrc.rtl_support) {
+ start_ = -1;
+ return;
+ }
+
+ InsetOld * inset = par.inInset();
+ if (inset && inset->owner() &&
+ inset->owner()->lyxCode() == InsetOld::ERT_CODE) {
+ start_ = -1;
+ return;
+ }
+
+ start_ = row.pos();
+ end_ = lastPos(par, row);
+
+ if (start_ > end_) {
+ start_ = -1;
+ return;
+ }
+
+ if (end_ + 2 - start_ >
+ static_cast(log2vis_list_.size())) {
+ pos_type new_size =
+ (end_ + 2 - start_ < 500) ?
+ 500 : 2 * (end_ + 2 - start_);
+ log2vis_list_.resize(new_size);
+ vis2log_list_.resize(new_size);
+ levels_.resize(new_size);
+ }
+
+ vis2log_list_[end_ + 1 - start_] = -1;
+ log2vis_list_[end_ + 1 - start_] = -1;
+
+ BufferParams const & bufparams = buf.params();
+ pos_type stack[2];
+ bool const rtl_par = par.isRightToLeftPar(bufparams);
+ int lev = 0;
+ bool rtl = false;
+ bool rtl0 = false;
+ pos_type const body_pos = par.beginningOfBody();
+
+ for (pos_type lpos = start_; lpos <= end_; ++lpos) {
+ bool is_space = par.isLineSeparator(lpos);
+ pos_type const pos =
+ (is_space && lpos + 1 <= end_ &&
+!par.isLineSeparator(lpos + 1) &&
+!par.isNewline(lpos + 1))
+ ? lpos + 1 : lpos;
+ LyXFont font = par.getFontSettings(bufparams, pos);
+ if (pos != lpos && 0 < lpos && rtl0 && font.isRightToLeft() &&
+ font.number() == LyXFont::ON &&
+ par.getFontSettings(bufparams, lpos - 1).number()
+ == LyXFont::ON) {
+ font = par.getFontSettings(bufparams, lpos);
+ is_space = false;
+ }
+
+ bool new_rtl = font.isVisibleRightToLeft();
+ bool new_rtl0 = font.isRightToLeft();
+ int new_level;
+
+ if (lpos == body_pos - 1
+ && row.pos() < body_pos - 1
+ && is_space) {
+ new_level = rtl_par ? 1 : 0;
+ new_rtl0 = rtl_par;
+ new_rtl = rtl_par;
+ } else if (new_rtl0)
+ new_level = new_rtl ? 1 : 2;
+ else
+ new_level = rtl_par ? 2 : 0;
+
+ if (is_space && new_level >= lev) {
+ new_level = lev;
+ new_rtl = rtl;
+ new_rtl0 = rtl0;
+ }
+
+ int new_level2 = new_level;
+
+ if (lev == new_level && rtl0 != new_rtl0) {
+ --new_level2;
+ log2vis_list_[lpos - start_] = rtl ? 1 : -1;
+ } else if (lev < new_level) {
+ log2vis_list_[lpos - start_] = rtl ? -1 : 1;
+ if (new_level > rtl_par)
+ same_direction_ = false;
+ } else
+ log2vis_list_[lpos - start_] = new_rtl ? -1 : 1;
+ rtl = new_rtl;
+ rtl0 = new_rtl0;
+ levels_[lpos - start_] = new_level;
+
+ while (lev > new_level2) {
+ p
Re: [patch] tex2lyx improvements
Andre Poenitz <[EMAIL PROTECTED]> writes: >> Good ideas. It would be nice to chenge the semantics of tex2lyx to >> match those of reLyX (for example have file.lyx as default output file >> instead of std output, and investigate what other flags may be useful). > | Please not. Fixed output files a real pain. tex2lyx should just convert | one file into another. Filter semantics id just fine here. If we are to call this directly from LyX we need to be able to output to a temporary file, if not we will get the same problem Garst had with lyx2lyx. -- Lgb
Re: Compiling Qt-version on RH 7.3
Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > > | Lars Gullik Bjønnes wrote: >>> We (I) might eventually do something with this... better would of >>> course to get all useres to use newer compilers. >> > | Sooner rather than later would be good too. I think we all value > | Jean-Marc's contributions... > > Note that when I do this I do it blind, I do not have gcc 2.96 > available nor 2.95 So, do your best and leave it to the protagonists to make it work. At least give them a picture of what they need. > | Just have a support/detail directory, á la boost. Then you'll > | never be offended by the contents of support/detail/gcc29x >> > | ;-) > > There are make and configure issues. > (dirty stuff) Really? Why not support/debug.h #ifndef DEBUG_H #define DEBUG_H #if defined(__GNUC__) && (__GNUC__ < 3) #include detail/gcc29x/debug.h #else #include detail/fully_compliant/debug.h #endif #endif // NOT DEBUG_H -- Angus
Re: Compiling Qt-version on RH 7.3
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Angus Leeming <[EMAIL PROTECTED]> writes: Lars> | Lars Gullik Bjønnes wrote: >>> We (I) might eventually do something with this... better would of >>> course to get all useres to use newer compilers. >> Lars> | Sooner rather than later would be good too. I think we all Lars> value | Jean-Marc's contributions... Lars> Note that when I do this I do it blind, I do not have gcc 2.96 Lars> available nor 2.95 I understand that. What kind of info would be useful? It seems that some pointer somewhere points to nothing instead of a stream. JMarc
Re: [patch] tex2lyx improvements
Andre Poenitz wrote:
>> Georg> - add support for lengths with comma (4,5cm instead of
>> 4.5cm) Georg> to minipage environments.
>>
>> I have to admit that my first feeling was to say ``this is wrong''
>> but now I tried it and indeed it works... Where is this documented?
>
> The TeXbook.
>
> Note that the real fun starts with 4,5cM.
I wrote a perl subroutine for reLyX that I think captured
all the possibilities. Why note just port that to c++?
I can do the porting if you would like, as I'm pretty
comfortable with boost::regex.
Angus
sub regularizeLatexLength {
my $LatexLength = shift;
# Remove any whitespace
$LatexLength =~ s/\s//g;
# Remove a leading '+' as unnecessary
$LatexLength =~ s/^\+?(\d)/$1/;
# Split into value and unit parts
my $val;
my $unit;
if ($LatexLength =~ /(-?\d+[.,]?\d*)(\\?[a-zA-Z]*)$/) {
$val = $1;
$unit = $2;
}
# If the input is invalid, return what we have.
return $LatexLength if ($val eq '' || $unit eq '');
# '4,5' is a valid LaTeX number. Change it to '4.5'
$val =~ s/,/./;
# If the unit is not a LaTeX macro, then ensure it is lower case
if (!($unit =~ /^\\/)) {
$unit =~ s/([a-z]*)/\L$1/i;
}
$LatexLength = $val . $unit;
return $LatexLength;
}
sub getAsLyXLength {
# Straight translation of LaTeX lengths to LyX ones.
my %lengthAsLyXString = ('\textwidth' => 'text%',
'\columnwidth' => 'col%',
'\paperwidth' => 'page%',
'\linewidth' => 'line%',
'\paperheight' => 'pheight%',
'\textheight' => 'theight%');
my $LatexLength = shift;
$LatexLength = regularizeLatexLength($LatexLength);
my $LyXLength = $LatexLength;
# If $LatexLength is something like '4.5\columnwidth', translate into
# LyXese.
if ($LatexLength =~ /([+-]?\d+\.?\d*)(\\[a-z]*)/) {
if (defined($lengthAsLyXString{$2})) {
$LyXLength = ($1 * 100) . $lengthAsLyXString{$2};
}
}
return $LyXLength;
}
--
Angus
Re: [patch] tex2lyx improvements
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>> Good ideas. It would be nice to chenge the semantics of tex2lyx to
>> match those of reLyX (for example have file.lyx as default output
>> file instead of std output, and investigate what other flags may be
>> useful).
Andre> Please not. Fixed output files a real pain.
-o would of course be needed.
Andre> tex2lyx should just convert one file into another. Filter
Andre> semantics id just fine here.
What fiter? It does not read std input, does it? I would agree to do
what gzip does, for example (filter when it makes sense).
Georg> - add support for lengths with comma (4,5cm instead of 4.5cm)
Georg> to minipage environments.
>> I have to admit that my first feeling was to say ``this is wrong''
>> but now I tried it and indeed it works... Where is this documented?
Andre> The TeXbook.
I see... I was surprised that the LaTeX manual did not mention it.
Andre> Note that the real fun starts with 4,5cM.
what happens then?
>> Also, the idea of handling \begin{appendix}...\end{appendix} makes
>> sense, but it would be better to generalize this to handling of
>> \begin{command}...\end{command}, which works for any latex macro
>> \command as far as I know. The code would probably be even simpler.
Andre> Care to come up with a patch? ;-)
Sure, when I can run 1.4.0cvs! ;)
JMarc
Re: Compiling Qt-version on RH 7.3
Angus Leeming <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: >> We (I) might eventually do something with this... better would of >> course to get all useres to use newer compilers. > | Sooner rather than later would be good too. I think we all value | Jean-Marc's contributions... Note that when I do this I do it blind, I do not have gcc 2.96 available nor 2.95 | Just have a support/detail directory, á la boost. Then you'll never | be offended by the contents of support/detail/gcc29x > | ;-) There are make and configure issues. (dirty stuff) -- Lgb
Re: [patch] tex2lyx improvements
On Thu, Oct 23, 2003 at 02:41:01PM +0200, Jean-Marc Lasgouttes wrote:
> > "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>
> Georg> I am still in the process of converting a 220 page document
> Georg> with tex2lyx. There are still some issues left, but in the
> Georg> attached patch you will find some improvemnts that accumulated
> Georg> so far. A short summary:
>
> I am a little late in the game, but I'll give some comments
> nevertheless. First, the patch looks very good!
Modulo whitepsace *cough* ;-)
> Georg> - allow parsing of partial documents (for inclusion with \input).
> Georg> - steal commandline switches -c and -f from reLyX to support
> Georg> the previous point
>
> Good ideas. It would be nice to chenge the semantics of tex2lyx to
> match those of reLyX (for example have file.lyx as default output file
> instead of std output, and investigate what other flags may be useful).
Please not. Fixed output files a real pain. tex2lyx should just convert
one file into another. Filter semantics id just fine here.
> Georg> - add support for lengths with comma (4,5cm instead of 4.5cm)
> Georg> to minipage environments.
>
> I have to admit that my first feeling was to say ``this is wrong'' but
> now I tried it and indeed it works... Where is this documented?
The TeXbook.
Note that the real fun starts with 4,5cM.
> Also, the idea of handling \begin{appendix}...\end{appendix} makes
> sense, but it would be better to generalize this to handling of
> \begin{command}...\end{command}, which works for any latex macro
> \command as far as I know. The code would probably be even simpler.
Care to come up with a patch? ;-)
Andre'
Re: [patch] tex2lyx improvements
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> I am still in the process of converting a 220 page document
Georg> with tex2lyx. There are still some issues left, but in the
Georg> attached patch you will find some improvemnts that accumulated
Georg> so far. A short summary:
I am a little late in the game, but I'll give some comments
nevertheless. First, the patch looks very good!
Georg> - allow parsing of partial documents (for inclusion with \input).
Georg> - steal commandline switches -c and -f from reLyX to support
Georg> the previous point
Good ideas. It would be nice to chenge the semantics of tex2lyx to
match those of reLyX (for example have file.lyx as default output file
instead of std output, and investigate what other flags may be useful).
Georg> - add support for lengths with comma (4,5cm instead of 4.5cm)
Georg> to minipage environments.
I have to admit that my first feeling was to say ``this is wrong'' but
now I tried it and indeed it works... Where is this documented?
Georg> Handle \textwidth etc. without factor
Sure. I have been a bit lazy :)
[snip good stuff]
Georg> - output minipages with latex lengths as ERT, since lyx cannot
Georg> handle them
Could you be more specific?
Georg> - recognize start of appendix
This code is a bit strange IMO. I have added a feature in Context that
is intended for these kind of cases. I would think that adding
context.extra_stuff += "\\start_of_appendix\n";
at the right place should do what you want. The extra_stuff
functionality is not very well thought admittedly, but it is designed
for these kind of cases where one wants to save data to add to the
_next_ paragraph. Could you check whether it works for you?
Also, the idea of handling \begin{appendix}...\end{appendix} makes
sense, but it would be better to generalize this to handling of
\begin{command}...\end{command}, which works for any latex macro
\command as far as I know. The code would probably be even simpler.
Georg> - handle optional arg to \item as ERT in itemize environment,
Georg> since LyX does not support it directly
I do not like the way this one is implemented. You have all the
information you need in the layout file. Instead of testing against
"itemize", you need something like (untested)
if (context.layout->labeltype != LABEL_MANUAL) {
As a bonus, it will also work with enumerate...
Thanks for the patch.
JMarc
Re: Compiling Qt-version on RH 7.3
Christian Ridderström <[EMAIL PROTECTED]> writes: | This leaves me with the option to compile Qt myself. Sigh... maybe I'll | get around to that someday, or when I absolutely have to. Is it _that_ bad to use the xforms version? And upgrade to newer RH is always an option. -- Lgb
Re: Compiling Qt-version on RH 7.3
Lars Gullik Bjønnes wrote: > We (I) might eventually do something with this... better would of > course to get all useres to use newer compilers. Sooner rather than later would be good too. I think we all value Jean-Marc's contributions... Just have a support/detail directory, á la boost. Then you'll never be offended by the contents of support/detail/gcc29x ;-) -- Angus
Re: [patch] bidi
Alfredo Braunstein <[EMAIL PROTECTED]> writes: | Andre Poenitz wrote: > >>> now bidi is a public variable with all private members. >>> It is straightforward to take out the whole thing from LyXText now. >>> >>> Should I do that? >> >> Why not. > | Who should I blame for Bidi.[Ch]? Dekel Tsur? I guess so. -- Lgb
Re: Compiling Qt-version on RH 7.3
Angus Leeming <[EMAIL PROTECTED]> writes: | Christian Ridderström wrote: >> I wouldn't say I've been quiet (see >> http://marc.theaimsgroup.com/?l=lyx-devel&m=106638664600359&w=2 >> >> Initially the problem was that gcc 2.96 couldn't be used anymore. > | Which is crap. Ie, a bad state of affairs. We (I) might eventually do something with this... better would of course to get all useres to use newer compilers. -- Lgb
Re: Compiling Qt-version on RH 7.3 (was Re: LyX programming...)
On Thu, 23 Oct 2003, Angus Leeming wrote: > Christian Ridderström wrote: > > I wouldn't say I've been quiet (see > > http://marc.theaimsgroup.com/?l=lyx-devel&m=106638664600359&w=2 > > > > Initially the problem was that gcc 2.96 couldn't be used anymore. > > Which is crap. Ie, a bad state of affairs. :-) I'll remember that quote: "crap, i.e. a bad state of affairs" > > The compiler that is part of the RH 7.3 distro of course. duh... which is gcc 2.96 of course... This leaves me with the option to compile Qt myself. Sigh... maybe I'll get around to that someday, or when I absolutely have to. /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: [patch] bidi
Andre Poenitz wrote: >> now bidi is a public variable with all private members. >> It is straightforward to take out the whole thing from LyXText now. >> >> Should I do that? > > Why not. Who should I blame for Bidi.[Ch]? Dekel Tsur? Alfredo
Re: Rules
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Index: Rules
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/development/Code_rules/Rules,v
| retrieving revision 1.14
| diff -u -p -r1.14 Rules
| --- Rules 25 Sep 2002 14:26:09 - 1.14
| +++ Rules 23 Oct 2003 11:10:44 -
| @@ -293,12 +279,9 @@ Formatting
|
| * Formatting
|
| - - Please adapt the formatting of your code to the setting in LyX in that
| -particular file. Lars and Asger are slowly, but surely moving the source
| -towards Linux kernel style formatting, aka K&R style. We suggest that you
| -also do this, but this is NOT something that has been decided generally.
| -(a pity - jbl)
| -
| + - Adapt the formatting of your code to the one used in the
| +other parts of LyX. In case there is different formatting for
| +the same construct, use the one used more often.
agree.
| * Use existing structures
|
>
| Moreover I'd like to replace the comment on braces to explicitly allow
| short single statement bodys of the innermost 'if', 'else', 'for' etc
| to go without braces. I.e.
>
| if (pos == par.size())
| --pos;
>
| and
>
| if (first) {
| while (first < last && par.isHfill(first))
| ++first;
| }
>
| and
>
| if (pos >= row.endpos()) {
| for (pos_type i = row.pos(); i < pos && !par.isHfill(i); ++i)
| return false;
| }
>
| should be 'legal'.
ok.
| [Note that this is already _much_ weaker than my favourite 'drop braces
| where not necessary']
I know.
--
Lgb
Re: LyX programming assignment in class of 200 3rd year SE students
On Thu, 23 Oct 2003, Angus Leeming wrote: > Christian Ridderström wrote: > > > and that's why I've decide to initially work > > (listings) against 1.3.3 and then port it to latest cvs. > > As you choose, but you're doubling your work and nobody will try out > preliminary versions of your code. Moreover, if this work involves > the core structures in any significant way then s/port/rewrite/. It's more work, but also more practical from a newbies point of view. Working against latest-cvs means a risk that my work breaks because of what someone else is doing... I have enough problems with my bugs ;-) You're right about nobody else testing _my_ preliminary versions though. However, this doesn't have to be the case when there are many students working against the same "release". In fact, it could (should?) be a part of the assignment to apply a patch from another group and test it. I didn't chose the method to minimize the work, but to make it easier for me to get something working. And frankly, I _am_ expecting to have to rewrite the result, but I also expect that rewriting it will give me insight into the code base of lyx-cvs. /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: LyX programming assignment in class of 200 3rd year SE students
On Thu, 23 Oct 2003, Andre Poenitz wrote: > > But why assume that the students work will be in one large patch? > > Shouldn't we demand that each student project results in a separate patch? > > The results of a student's project should be incremental. > > If the projects lasts for three months I'd expect a series of small > patches instead of 100 monsters after that time. Ok... thought you were speaking of one patch for all students rather than one patch/project. My thought was that it'd be easier to keep track of the purpose of the project/patch if came in one set of files... Numbers might be a problem here... with 100 projects and 5 patches/project, we're talking about total of 500 patches. And most of these will arrive at the end of their project as well (when they have something that works). When should these patches be comitted? As they come in and have been reviewed, but without full functionality and some flaws? Hmm.. someone have to test the new functionality (or bug fix etc). It would be a nice help if the patch from project A could be tested by project B and so on. > > Please note that I'm not suggesting that they should work against 1.3.3 > > here, that's probably to old, but against some "frozen" version of > > latest-cvs that's known to compile for Xforms/Qt on whatever platform(s) > > the students will work on. > > As current 1.4.0cvs is not really good but slowly improves, letting the > students start with ? > > Finally, speaking from my experience on actually using the results of what > > students produce, you often end up redoing their work... > > Whom are you telling... :-) /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: Compiling Qt-version on RH 7.3 (was Re: LyX programming...)
Christian Ridderström wrote: > I wouldn't say I've been quiet (see > http://marc.theaimsgroup.com/?l=lyx-devel&m=106638664600359&w=2 > > Initially the problem was that gcc 2.96 couldn't be used anymore. Which is crap. Ie, a bad state of affairs. > Changing to gcc 3.3.1, the problem is probably (Lars' guess) that my > qt-libs have been compiled with a different compiler, resulting in > loads of linking errors: > > http://marc.theaimsgroup.com/?l=lyx-devel&m=106635102008778&w=2 > > How can I find out what compiler was used to compile my qt? (RH 7.3) The compiler that is part of the RH 7.3 distro of course. > Hmm.. Should it matter that I'm using Qt3? No. -- Angus
Re: [PATCH] qt branches
Angus Leeming wrote: > Send the patch to the list. > If you feel it is not controversial, just commit it at the same time. > Otherwise, wait a bit. If nobody makes any noise, then just commit it > and post a mail to this effect. All right, done so. Jürgen.
Re: LyX programming assignment in class of 200 3rd year SE students
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Thu, Oct 23, 2003 at 12:25:13PM +0200, Christian Ridderström wrote: >> On Thu, 23 Oct 2003, Andre Poenitz wrote: >> >> > > Another question is what version of LyX the students should work with... >> > > it could be frustrating working with the CVS version since it's in a very >> > > fluctuating state (e.g. sometimes it doesn't even compile). >> > >> > Everything else would leave us with the need of forward-porting 50 new >> > features. If we stick to 1.3.xcvs we'd end up in the same situation as >> > the change tracking patch. Works for some ancient version only. >> > >> > 1.4.0cvs is stable enough for this kind of work. >> >> I was thinking more along the lines of giving the students a branch to >> work on... > | Merging small chunks is _much_ simpler than larger. each group of students should have their own tree/branch to work on. | LyX has a bad history with branches (so far only one successful | 'large' merge IIRC) depends... | I see no benefit over a regualr 'cvs up'. If you are more than one person the branch approach is a lot easier... -- Lgb
Re: [patch] tex2lyx improvements
On Wed, Oct 22, 2003 at 10:52:46PM +0200, Georg Baum wrote:
> It would be nice if somebody could review this and apply.
Done.
> If necessary, I can split it apart.
Rather try to fix converting the UserGuide. It currently produce a
reasonable LyX which translates to invalid .tex in chapter 3.3:
The offending original .tex is:
\vspace{-2ex} \parbox[t]{3cm}{
\begin{itemize}
\item \textsf{Quote}
\item \textsf{Quotation}
\end{itemize}
}\parbox[t]{3cm}{
\begin{itemize}
\item \textsf{Verse}
\item \textsf{Itemize}
\end{itemize}
}\parbox[t]{3cm}{
\begin{itemize}
\item \textsf{Enumerate}
\item \textsf{Description}
\end{itemize}
}\parbox[t]{3cm}{
\begin{itemize}
\item \textsf{List}
\end{itemize}
}
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Compiling Qt-version on RH 7.3 (was Re: LyX programming...)
On Thu, 23 Oct 2003, Angus Leeming wrote: > Christian Ridderström wrote: > > > You can revert your code and know that it will work (I can't compile > > Qt any more...) > > What's not working for you. No progress is made by keeping silent > about such things. I wouldn't say I've been quiet (see http://marc.theaimsgroup.com/?l=lyx-devel&m=106638664600359&w=2 Initially the problem was that gcc 2.96 couldn't be used anymore. Changing to gcc 3.3.1, the problem is probably (Lars' guess) that my qt-libs have been compiled with a different compiler, resulting in loads of linking errors: http://marc.theaimsgroup.com/?l=lyx-devel&m=106635102008778&w=2 How can I find out what compiler was used to compile my qt? (RH 7.3) Hmm.. Should it matter that I'm using Qt3? /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: [patch] bidi
On Thu, Oct 23, 2003 at 01:15:06PM +0200, Alfredo Braunstein wrote: > Alfredo Braunstein wrote: > > > Yep. I'll send an update. > > A bit harder than I though, but I feel quite satisfied. > > now bidi is a public variable with all private members. > It is straightforward to take out the whole thing from LyXText now. > > Should I do that? Why not. [I don't see the reason for renaming 'level' to 'lev', but I don't care either] Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: LyX programming assignment in class of 200 3rd year SE students
Christian Ridderström wrote: > > You can revert your code and know that it will work (I can't compile > Qt any more...) What's not working for you. No progress is made by keeping silent about such things. > and that's why I've decide to initially work > (listings) against 1.3.3 and then port it to latest cvs. As you choose, but you're doubling your work and nobody will try out preliminary versions of your code. Moreover, if this work involves the core structures in any significant way then s/port/rewrite/. -- Angus
Re: LyX programming assignment in class of 200 3rd year SE students
On Thu, Oct 23, 2003 at 01:13:55PM +0200, Christian Ridderström wrote: > On Thu, 23 Oct 2003, Andre Poenitz wrote: > > > > > Everything else would leave us with the need of forward-porting 50 new > > > > features. If we stick to 1.3.xcvs we'd end up in the same situation as > > > > the change tracking patch. Works for some ancient version only. > > > > > > > > 1.4.0cvs is stable enough for this kind of work. > > > > > > I was thinking more along the lines of giving the students a branch to > > > work on... > > > > Merging small chunks is _much_ simpler than larger. > > True. > > But why assume that the students work will be in one large patch? > Shouldn't we demand that each student project results in a separate patch? The results of a student's project should be incremental. If the projects lasts for three months I'd expect a series of small patches instead of 100 monsters after that time. > > I see no benefit over a regualr 'cvs up'. > > You can revert your code and know that it _will_ work (I can't compile Qt > any more...) and that's why I've decide to initially work (listings) > against 1.3.3 and then port it to latest cvs. CVS head gets into a compilable state within hours if not minutes after a problem emerges. I don't see this as a real problem. > Please note that I'm not suggesting that they should work against 1.3.3 > here, that's probably to old, but against some "frozen" version of > latest-cvs that's known to compile for Xforms/Qt on whatever platform(s) > the students will work on. As current 1.4.0cvs is not really good but slowly improves, letting the students start with > Finally, speaking from my experience on actually using the results of what > students produce, you often end up redoing their work... Whom are you telling... But if the students get only a reward for their coursework if they manage to get something in, they learn how to stick to the rules pretty quickly. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: [PATCH] qt branches
Juergen Spitzmueller wrote: > Juergen Spitzmueller wrote: >> Please let me know, if there are any objections or if I can apply >> this. > > err, can I apply what I have? I think the chance that the color > cache issues get solved would raise dramastically then. I think that you should use the policy espoused by Lars Send the patch to the list. If you feel it is not controversial, just commit it at the same time. Otherwise, wait a bit. If nobody makes any noise, then just commit it and post a mail to this effect. That way nobody will get frustrated if nobody else expresses an opinion about there latest wunder-patch ;-) -- Angus
Re: LyX programming assignment in class of 200 3rd year SE students
> > I see no benefit over a regualr 'cvs up'. > > You can revert your code and know that it _will_ work (You can do: cvs up -r of course, but then we might as well give them a tag. /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Rules
Index: Rules
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/development/Code_rules/Rules,v
retrieving revision 1.14
diff -u -p -r1.14 Rules
--- Rules 25 Sep 2002 14:26:09 - 1.14
+++ Rules 23 Oct 2003 11:10:44 -
@@ -293,12 +279,9 @@ Formatting
* Formatting
- - Please adapt the formatting of your code to the setting in LyX in that
-particular file. Lars and Asger are slowly, but surely moving the source
-towards Linux kernel style formatting, aka K&R style. We suggest that you
-also do this, but this is NOT something that has been decided generally.
-(a pity - jbl)
-
+ - Adapt the formatting of your code to the one used in the
+other parts of LyX. In case there is different formatting for
+the same construct, use the one used more often.
* Use existing structures
Moreover I'd like to replace the comment on braces to explicitly allow
short single statement bodys of the innermost 'if', 'else', 'for' etc
to go without braces. I.e.
if (pos == par.size())
--pos;
and
if (first) {
while (first < last && par.isHfill(first))
++first;
}
and
if (pos >= row.endpos()) {
for (pos_type i = row.pos(); i < pos && !par.isHfill(i); ++i)
return false;
}
should be 'legal'.
[Note that this is already _much_ weaker than my favourite 'drop braces
where not necessary']
Andre'
Re: [patch] bidi
Alfredo Braunstein wrote:
> Yep. I'll send an update.
A bit harder than I though, but I feel quite satisfied.
now bidi is a public variable with all private members.
It is straightforward to take out the whole thing from LyXText now.
Should I do that?
Alfredo
Index: bufferview_funcs.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/bufferview_funcs.C,v
retrieving revision 1.116
diff -u -p -u -r1.116 bufferview_funcs.C
--- bufferview_funcs.C 22 Oct 2003 16:30:56 - 1.116
+++ bufferview_funcs.C 23 Oct 2003 11:12:31 -
@@ -399,11 +399,12 @@ void toggleAndShow(BufferView * bv, LyXF
if (font.language() != ignore_language ||
font.number() != LyXFont::IGNORE) {
LyXCursor & cursor = text->cursor;
- text->computeBidiTables(*text->cursorPar(), *bv->buffer(),
+ text->bidi.computeTables(*text->cursorPar(), *bv->buffer(),
*text->cursorRow());
if (cursor.boundary() !=
- text->isBoundary(*bv->buffer(), *text->cursorPar(), cursor.pos(),
-text->real_current_font))
+ text->bidi.isBoundary(*bv->buffer(), *text->cursorPar(),
+ cursor.pos(),
+ text->real_current_font))
text->setCursor(cursor.par(), cursor.pos(),
false, !cursor.boundary());
}
Index: lyxtext.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxtext.h,v
retrieving revision 1.242
diff -u -p -u -r1.242 lyxtext.h
--- lyxtext.h 23 Oct 2003 08:15:55 - 1.242
+++ lyxtext.h 23 Oct 2003 11:12:32 -
@@ -238,13 +238,6 @@ public:
void setCurrentFont();
///
- bool isBoundary(Buffer const &, Paragraph const & par,
- lyx::pos_type pos) const;
- ///
- bool isBoundary(Buffer const &, Paragraph const & par,
-lyx::pos_type pos, LyXFont const & font) const;
-
- ///
void recUndo(lyx::paroffset_type first, lyx::paroffset_type last) const;
///
void recUndo(lyx::paroffset_type first) const;
@@ -352,17 +345,6 @@ public:
///
int workWidth() const;
- ///
- void computeBidiTables(Paragraph const & par,
- Buffer const &, Row & row) const;
- /// Maps positions in the visual string to positions in logical string.
- lyx::pos_type log2vis(lyx::pos_type pos) const;
- /// Maps positions in the logical string to positions in visual string.
- lyx::pos_type vis2log(lyx::pos_type pos) const;
- ///
- lyx::pos_type bidi_level(lyx::pos_type pos) const;
- ///
- bool bidi_InRange(lyx::pos_type pos) const;
private:
///
float getCursorX(ParagraphList::iterator pit,
@@ -400,8 +382,6 @@ public:
/// return the color of the canvas
LColor_color backgroundColor() const;
- ///
- mutable bool bidi_same_direction;
unsigned char transformChar(unsigned char c, Paragraph const & par,
lyx::pos_type pos) const;
@@ -446,21 +426,53 @@ private:
/// FIXME
int labelEnd(ParagraphList::iterator pit, Row const & row) const;
-
- ///
- mutable std::vector log2vis_list;
- ///
- mutable std::vector vis2log_list;
- ///
- mutable std::vector bidi_levels;
- ///
- mutable lyx::pos_type bidi_start;
- ///
- mutable lyx::pos_type bidi_end;
-
+
///
void charInserted();
+
public:
+ /// bidi stuff
+ struct Bidi {
+ ///
+ bool isBoundary(Buffer const &, Paragraph const & par,
+ lyx::pos_type pos) const;
+ ///
+ bool isBoundary(Buffer const &, Paragraph const & par,
+ lyx::pos_type pos, LyXFont const & font) const;
+ ///
+ lyx::pos_type log2vis(lyx::pos_type pos) const;
+ /** Maps positions in the logical string to positions
+* in visual string.
+*/
+ lyx::pos_type vis2log(lyx::pos_type pos) const;
+ ///
+ lyx::pos_type level(lyx::pos_type pos) const;
+ ///
+ bool inRange(lyx::pos_type pos) const;
+ /// same_direction?
+ bool same_direction() const;
+ ///
+ void computeTables(Paragraph const & par,
+ Buffer const &, Row & row);
+ private:
+ ///
+ bool same_direction_;
+ ///
+ std::vector log2vis_list_;
+ /** Maps positions in the visu
Re: LyX programming assignment in class of 200 3rd year SE students
On Thu, 23 Oct 2003, Andre Poenitz wrote: > > > Everything else would leave us with the need of forward-porting 50 new > > > features. If we stick to 1.3.xcvs we'd end up in the same situation as > > > the change tracking patch. Works for some ancient version only. > > > > > > 1.4.0cvs is stable enough for this kind of work. > > > > I was thinking more along the lines of giving the students a branch to > > work on... > > Merging small chunks is _much_ simpler than larger. True. But why assume that the students work will be in one large patch? Shouldn't we demand that each student project results in a separate patch? > LyX has a bad history with branches (so far only one successful > 'large' merge IIRC) *shrug* > I see no benefit over a regualr 'cvs up'. You can revert your code and know that it _will_ work (I can't compile Qt any more...) and that's why I've decide to initially work (listings) against 1.3.3 and then port it to latest cvs. Please note that I'm not suggesting that they should work against 1.3.3 here, that's probably to old, but against some "frozen" version of latest-cvs that's known to compile for Xforms/Qt on whatever platform(s) the students will work on. Finally, speaking from my experience on actually using the results of what students produce, you often end up redoing their work... so let's be aware of that. /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: InseetExternal can now preview stuff too
Christian Ridderström wrote:
>> $ cd ${SOURCE_TREE}/src
>> $ (cd insets && touch render_*.C insetexternal.C External*.C)
>> $ (cd frontends/xforms && touch FormExternal.C
>> forms/form_external.fd) $ (cd frontends/qt2 && touch QExternal.C
>> ui/QExternal*.ui) $ make CXXFLAGS='-g -W -Wall'
>
> Ok, I did the above, below is the backtrace (have fun):
Thanks. I'll dig into it this evening.
--
Angus
Re: [PATCH] qt branches
Juergen Spitzmueller wrote: > Please let me know, if there are any objections or if I can apply this. err, can I apply what I have? I think the chance that the color cache issues get solved would raise dramastically then. Jürgen.
Re: Producing backtrace
Lars Gullik Bjønnes wrote: > | The instructions above works... but I thought I could also get it from > | the core-file? > > Yes, but the information then is usually not as good. The difference being like in "autopsy" vs. "live dissection" ;^) Alfredo
Re: Producing backtrace
Christian Ridderström <[EMAIL PROTECTED]> writes: | I've put these instructions here as well: > | http://wiki.lyx.org/pmwiki.php/DevelTips/ProducingBacktrace > | The instructions above works... but I thought I could also get it from | the core-file? Yes, but the information then is usually not as good. -- Lgb
Re: InseetExternal can now preview stuff too
Christian Ridderström wrote:
> On Thu, 23 Oct 2003, Angus Leeming wrote:
>
>> Christian Ridderström wrote:
>> >
>> > Hmm... lyx-xforms crashes by just trying to insert an External
>> > Xfig template (i.e. regardless of preview settings etc).
>>
>> Then I've f**ked up. Apologies for that. Does the same happen with
>> the Qt frontend? Do you have bt?
>
> Last time I tried building Qt it failed, so I haven't tested with
> Qt. Here's the backtrace:
>
> (gdb) r
> Starting program: /space/lyx-devel/HEAD/build-xforms/src/lyx-xforms
> text not available!
> no text in cache!
> getChar() on pos 0 in par id 1 of size 0 is a bit silly !
> Redraw screen
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x083dd04c in _ZNSs20_S_empty_rep_storageE@@GLIBCPP_3.2 ()
> (gdb) bt
> #0 0x083dd04c in _ZNSs20_S_empty_rep_storageE@@GLIBCPP_3.2 ()
> #1 0x08376a4d in __dynamic_cast (from=0x85b01a0,
> to=0x8392080 ,
> require_public=138001960, address=0x0, sub=0x83dd04c
> <_ZNSs20_S_empty_rep_storageE@@GLIBCPP_3.2+12>,
> subptr=0xbfffd4c0)
> #2 0x081c716a in InsetExternal::setParams(InsetExternalParams
> #const&,
> Buffer const&) ()
Bollocks. dynamic_cast works for me :( Maybe I should go the mathed
route and use virtual functions?
class RenderButton;
class RenderGraphic;
class RenderPreview;
class RenderMonitoredPreview;
class RenderBase {
public:
virtual RenderButton * asRenderButton() { return 0; }
virtual RenderGraphic * asRenderGraphic() { return 0; }
virtual RenderPreview * asRenderPreview() { return 0; }
virtual RenderMonitoredPreview * asRenderMonitoredPreview()
{ return 0; }
};
class RenderButton {
public:
virtual RenderButton * asRenderButton() { return this; }
};
etc.
--
Angus
