Re: CVS build error on windows
On Mon, 2006-02-27 at 02:15 +, Paul Langevin wrote: > Paul Langevin <[EMAIL PROTECTED]> writes: > > > > > I get the following error building on MS Visual C++ 2005: > > > > forkedcall.C > > ..\..\src\support\forkedcall.C(170) : error C2065: 'ESRCH' : undeclared > > identifier > > > > Well, according to Google there is supposed to be an "#include " at > top > of the file. That worked, but I got a new error: > > > Linking... > math_factory.obj : error LNK2019: unresolved external symbol "public: > __thiscall > MathXYMatrixInset::MathXYMatrixInset(void)" (??0MathXYMatrixInset@@[EMAIL > PROTECTED]) > referenced in function "class MathAtom __cdecl createMathInset(class > std::basic_string,class > std::allocator > > const &)" (?createMathInset@@YA?AVMathAtom@@[EMAIL PROTECTED]@ > [EMAIL PROTECTED]@@[EMAIL PROTECTED]@2@@std@@@Z) > > Release/lyx.exe : fatal error LNK1120: 1 unresolved externals This was recently reintroduced. I expect you can fix the error by going through the autogen-configure-make cycle again (to re-generate the makefiles) HTH Martin signature.asc Description: This is a digitally signed message part
Re: Problem with INSTALL.Win32 -
I've never used automake before (I don't do much in the way of programming) but I noticed that version 1.9.4 is available here: http://gnuwin32.sourceforge.net/packages/automake.htm The website says: The GnuWin32 project provides Win32-versions of GNU tools, or tools with a similar open source licence. The ports are native ports, that is they rely only on libraries provided with any standard 32-bits MS-Windows operating system, such as MS-Windows 95 / 98 / ME / NT / 2000 / XP. Native ports do not rely on some kind of Unix emulation, such as CygWin or Msys, so that there is no need to install additional emulation libraries. At present, all developments have been done under MS-Windows 98 and XP, using the Mingw port of the GNU C and C++ (GCC) compilers.
Re: CVS build error on windows
Paul Langevin <[EMAIL PROTECTED]> writes: > > I get the following error building on MS Visual C++ 2005: > > forkedcall.C > ..\..\src\support\forkedcall.C(170) : error C2065: 'ESRCH' : undeclared > identifier > Well, according to Google there is supposed to be an "#include " at top of the file. That worked, but I got a new error: Linking... math_factory.obj : error LNK2019: unresolved external symbol "public: __thiscall MathXYMatrixInset::MathXYMatrixInset(void)" (??0MathXYMatrixInset@@[EMAIL PROTECTED]) referenced in function "class MathAtom __cdecl createMathInset(class std::basic_string,class std::allocator > const &)" (?createMathInset@@YA?AVMathAtom@@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@@[EMAIL PROTECTED]@2@@std@@@Z) Release/lyx.exe : fatal error LNK1120: 1 unresolved externals
CVS build error on windows
I get the following error building on MS Visual C++ 2005:
forkedcall.C
..\..\src\support\forkedcall.C(170) : error C2065: 'ESRCH' : undeclared
identifier
I am no programmer, but looked up the offending code out of curiosity:
bool ForkedProcess::running() const
{
if (!pid())
return false;
#if !defined (_WIN32)
// Un-UNIX like, but we don't have much use for
// knowing if a zombie exists, so just reap it first.
int waitstatus;
waitpid(pid(), &waitstatus, WNOHANG);
#endif
// Racy of course, but it will do.
if (lyx::support::kill(pid(), 0) && errno == ESRCH)
return false;
return true;
}
This is only the second time I have tried compiling Lyx on Windows. The first
was around 1.4.0pre1. I didn't try the post-compilation build scripts (I think
there are some, right?), but the program seemed to run without any major errors.
At that time I wanted to experiment with the change tracking. (It seemed to
work, but I abandaned it due to the slow interface.)
Re: Problem with INSTALL.Win32 -
Michael Gerz <[EMAIL PROTECTED]> writes: > > Joost Verburg wrote: > > > INSTALL.Win32 is indeed outdated. It also points to the old kde-cygwin. > > > > However, the Windows build scripts also do not work in the current > > state. The reason is that automake 1.9 is not yet available for > > Windows. Currently I can only get it to compile using automake in a > > Cygwin environment and a modified build script that doesn't call > > automake. > > Angus, do you have any plans to work on the Win32 build scripts? IIRC > the 1.3.7 and 1.4.0 files are not in sync. I don't think that the 1.4 stuff has ever worked, because I never ever could build LyX 1.4 with mingw/msys. Angus
Re: Source cosmetics
John Spray <[EMAIL PROTECTED]> writes:
> On Sun, 2006-02-26 at 15:50 +0100, Lars Gullik Bjønnes wrote:
> > Sometime ago we even agreed on *.C -> *.cxx change. But today to aim
> > for a what seems to be commonly used I'd use *.C -> *.cpp instead.
> I can't find this in the list archive - why was it thought a good idea?
I guess that one sensible reason is that it's hard to differentiate between .c
and .C files on Windows and on MacOSX.
> I personally like being able to do "foo.[Ch]".
Use the csh-ism: foo.{cpp,h}. Works also under bash.
Angus
Re: Source cosmetics
John Spray wrote: On Sun, 2006-02-26 at 15:50 +0100, Lars Gullik Bjønnes wrote: Sometime ago we even agreed on *.C -> *.cxx change. But today to aim for a what seems to be commonly used I'd use *.C -> *.cpp instead. I can't find this in the list archive - why was it thought a good idea? I personally like being able to do "foo.[Ch]". Yes, this is very convenient. File names and class names should also be identical (following Java conventions). Michael
Re: Lyx 1.4 matbb/mathcal/mathrm issue
Martin Vermeer wrote: Attached the best I can come up with for now. (...) I propose this as the patch for 1.4.1 (not 1.4.0 I think; it's cosmetic and there's a workaround). But what about only the math panel issue? I think there should be at least a patch to fix that in 1.4.0 since it is a major regression. If this is really impossible it would even be better to remove all broken symbols (mathbb, mathcal and mathrm) from the panel. Joost
Re: Lyx 1.4 matbb/mathcal/mathrm issue
On Sun, Feb 26, 2006 at 07:25:51PM +0100, Georg Baum wrote:
> Am Sonntag, 26. Februar 2006 17:53 schrieb Martin Vermeer:
> > Yes... but now insertion of a decoration "around" selected math text
> > fails. The problem which this patch originally tried to fix.
>
> Of course. The patch was only meant to show where the problem is, it was
> by no means a finished fix.
>
> > The assumption here appears to be that the argument to give to the
> > LFUN_PASTE call is the _text_ to be pasted into the doc. Checking the
> > places where LFUN_PASTE is executed (i.e., text2.C and
> > math_nestinset.C), however, shows that the text to be pasted comes from
> > _buffer number_ n, an integer contained in the cmd.argument transferred.
> >
> > So I believe there is a "thinko" here, which explains why the
> > selection disappears into the black hole and is never inserted -- at
> > least for math.
>
> That is indeed a problem, but unrelated, because LCursor::paste() is not
> invoked for \mathbb. I filed it at
> http://bugzilla.lyx.org/show_bug.cgi?id=2327 and attached also a possible
> fix.
>
> There seems to be a different thinko involved in the \mathbb problem:
> LCursor::handleNest() operates on a selection, but the selection may be
> empty if you insert '\mathbb R' from the math panel (and its contents
> will be wrong even if it is not empty).
> The attached patch improves the situation a bit by invoking handleNest()
> only if there is a selection. That makes '\mathbb R' work again for the
> case where nothing is selected.
> If you try to insert '\mathbb R' over a selection, you'll convert the
> selection to \mathbb font. That is also the case in 1.3, but in 1.3
> you'll get additionally the roginila mathbb argument, which is missing
> with the patch, so some more work needs to be done.
Attached the best I can come up with for now. Working are:
1) fonts from the panel around selection
2) decorations from the panel over/under selection
3) compound symbols from the panel, type \mathbb R, without sel
4) same with sel: result [sel|R] in mathbb font. I say we can live with
that.
I propose this as the patch for 1.4.1 (not 1.4.0 I think; it's cosmetic
and there's a workaround).
- Martin
PS There's one other call to cur.paste(data) in nestinset, which tries to
do something that won't work anyway in this way, and that I propose to
dump together with the whole sorry cur.paste method. Later
PS2 Is my impression right and is 1.4.0 ready for release once the 2316
fix is in? With luck, we'll have a February release...
Index: cursor.C
===
--- cursor.C(revision 13276)
+++ cursor.C(working copy)
@@ -379,6 +390,8 @@
}
+// Don't use this routine. It is erroneous: LFUN_PASTE should be called with
+// buffer number, not data to be inserted -- MV 26.02.2006
void LCursor::paste(string const & data)
{
if (!data.empty())
@@ -707,12 +720,12 @@
string const safe = lyx::cap::grabAndEraseSelection(*this);
plainInsert(t);
// enter the new inset and move the contents of the selection if
possible
- if (t->isActive()) {
+ if (t->isActive() && !safe.empty()) {
posLeft();
// be careful here: don't use 'pushLeft(t)' as this we need to
// push the clone, not the original
pushLeft(*nextInset());
- paste(safe);
+ insert(safe);
}
}
Index: mathed/math_nestinset.C
===
--- mathed/math_nestinset.C (revision 13276)
+++ mathed/math_nestinset.C (working copy)
@@ -888,13 +888,7 @@
int cell(0);
if (cmd.argument == "\\root")
cell = 1;
- // math macros are nest insets and may have 0 cells.
- // handleNest would crash in this case.
- if (ar.size() == 1 && (ar[0].nucleus()->asNestInset()) &&
- ar[0].nucleus()->nargs() > MathInset::idx_type(cell)) {
- cur.handleNest(ar[0], cell);
- } else
- cur.niceInsert(cmd.argument);
+ cur.niceInsert(cmd.argument);
break;
}
pgpKbk3zWx9G9.pgp
Description: PGP signature
Re: Source cosmetics
Martin Vermeer a écrit :
On Sun, Feb 26, 2006 at 12:23:46PM +0100, Andre Poenitz wrote:
This would be 1.5.0 stuff and at least the file renamings should be done
immediately after openening 1.5.0svn for work to prevent conflicts (even
svn has no real file moves...)
Opinions?
Good idea.
What to do with the lyxtext/text/1/2 mess?
My take:
1) Split LyxText into logical classes. This class is simply too big.
2) There are some cleanup to do. For example, interface like this:
/// read-only access to individual paragraph
Paragraph const & getPar(pit_type pit) const { return pars_[pit]; }
should be erased. Just use 'paragraph()[pit]' if this info is really
needed outside the class (which it shouldn't).
3) move non member support functions to their respective class. Ex: the
functions dealing with LCursor in text3.
4) move member functions that have nothing to do with Lyxtext to their
respective class. Ex in text2:
LyXFont LyXText::getFont(Paragraph const & par, pos_type const pos) const
This function use should be split in the font retrieval and the cosmetic
improvement in the font. I can see some performance problem in this
function that would be cured by this cleanup (get rid of the paragraph
searching).
That said, if you're talking about mess, CutAndPaste is the first thing
to cure. ;-)
IMHO should I precise...
Abdel
Re: Lyx 1.4 matbb/mathcal/mathrm issue
On Sun, Feb 26, 2006 at 07:25:51PM +0100, Georg Baum wrote: > Am Sonntag, 26. Februar 2006 17:53 schrieb Martin Vermeer: ... > > The assumption here appears to be that the argument to give to the > > LFUN_PASTE call is the _text_ to be pasted into the doc. Checking the > > places where LFUN_PASTE is executed (i.e., text2.C and > > math_nestinset.C), however, shows that the text to be pasted comes from > > _buffer number_ n, an integer contained in the cmd.argument transferred. > > > > So I believe there is a "thinko" here, which explains why the > > selection disappears into the black hole and is never inserted -- at > > least for math. > > That is indeed a problem, but unrelated, because LCursor::paste() is not > invoked for \mathbb. I filed it at > http://bugzilla.lyx.org/show_bug.cgi?id=2327 and attached also a possible > fix. > > There seems to be a different thinko involved in the \mathbb problem: > LCursor::handleNest() operates on a selection, but the selection may be > empty if you insert '\mathbb R' from the math panel (and its contents > will be wrong even if it is not empty). > The attached patch improves the situation a bit by invoking handleNest() > only if there is a selection. That makes '\mathbb R' work again for the > case where nothing is selected. No... this is a 'kludge' again. The attached works for both decorations and fonts, including mathbb. Try it! (This is must be used with your reversal of my patch to math_nestinset, i.e., use only niceInsert) - Martin Index: cursor.C === --- cursor.C(revision 13276) +++ cursor.C(working copy) @@ -712,7 +725,7 @@ // be careful here: don't use 'pushLeft(t)' as this we need to // push the clone, not the original pushLeft(*nextInset()); - paste(safe); + insert(safe); } } pgpvfW6NXIqdN.pgp Description: PGP signature
Re: Lyx 1.4 matbb/mathcal/mathrm issue
Am Sonntag, 26. Februar 2006 17:53 schrieb Martin Vermeer:
> Yes... but now insertion of a decoration "around" selected math text
> fails. The problem which this patch originally tried to fix.
Of course. The patch was only meant to show where the problem is, it was
by no means a finished fix.
> The assumption here appears to be that the argument to give to the
> LFUN_PASTE call is the _text_ to be pasted into the doc. Checking the
> places where LFUN_PASTE is executed (i.e., text2.C and
> math_nestinset.C), however, shows that the text to be pasted comes from
> _buffer number_ n, an integer contained in the cmd.argument transferred.
>
> So I believe there is a "thinko" here, which explains why the
> selection disappears into the black hole and is never inserted -- at
> least for math.
That is indeed a problem, but unrelated, because LCursor::paste() is not
invoked for \mathbb. I filed it at
http://bugzilla.lyx.org/show_bug.cgi?id=2327 and attached also a possible
fix.
There seems to be a different thinko involved in the \mathbb problem:
LCursor::handleNest() operates on a selection, but the selection may be
empty if you insert '\mathbb R' from the math panel (and its contents
will be wrong even if it is not empty).
The attached patch improves the situation a bit by invoking handleNest()
only if there is a selection. That makes '\mathbb R' work again for the
case where nothing is selected.
If you try to insert '\mathbb R' over a selection, you'll convert the
selection to \mathbb font. That is also the case in 1.3, but in 1.3
you'll get additionally the roginila mathbb argument, which is missing
with the patch, so some more work needs to be done.
Georg
Index: src/mathed/math_nestinset.C
===
--- src/mathed/math_nestinset.C (Revision 13276)
+++ src/mathed/math_nestinset.C (Arbeitskopie)
@@ -890,7 +890,8 @@ void MathNestInset::doDispatch(LCursor &
cell = 1;
// math macros are nest insets and may have 0 cells.
// handleNest would crash in this case.
- if (ar.size() == 1 && (ar[0].nucleus()->asNestInset()) &&
+ if (cur.selection() && ar.size() == 1 &&
+ ar[0].nucleus()->asNestInset() &&
ar[0].nucleus()->nargs() > MathInset::idx_type(cell)) {
cur.handleNest(ar[0], cell);
} else
Re: Source cosmetics
Lars Gullik Bjønnes a écrit :
Andre Poenitz <[EMAIL PROTECTED]> writes:
I have proposals coming, but I want 1.4.0 before we do anything.
| i.e. no {lyx,LyX,L}-prefix, instead everything in namespace lyx, usually one
| class per .h/.C combo, and files named the same way as the class.
I agree with the LyX prefix (or l or lyx) in general. We have too many
of them.
As to upper/lower case I think we should use lowercase only. But that
is purely IMHO.
Hum, me too but why is it that you asked me to rename it_vector into
RandomAccessList instead of random_access_list? ;-)
I would propose to use xx_yy syntax (filenames, classes _and_ public
method) for everything that is infrastructure and not directly lyx
related (like random_access_list). And of course I agree with Andre that
everything that is in 'frontend' subdir should use Qt style.
For the rest, I mean the backend, I think there is some benefit in
having a different style than Qt so that a frontend developer could see
from first glance that this or that is a support class. It would be too
complicated to create a third style so I'd propose to use the first one
also (STL style) for the backend.
While I am on it, I would recommend to put every little helper class or
function in a library outside of lyx.
All of this in my humble opinion of course :-)
Abdel.
Re: Lyx 1.4 matbb/mathcal/mathrm issue
On Sun, Feb 26, 2006 at 03:24:52PM +0100, Georg Baum wrote:
> Am Samstag, 25. Februar 2006 18:19 schrieb Martin Vermeer:
...
> > For blackboard bold R (real numbers) we have "\\mathbb R".
>
> which is BTW valid TeX syntax.
>
> > When you inspect the code handling this, more precisely
> > ControlMath::dispatchInsert, you see that there is no handling taking
> > place. And in math_nestinset's INSERT_MATH code, the R is silently
> > dropped.
>
> Yes. This dropping occurs since this patch from you:
> http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/src/mathed/math_nestinset.C.diff?r1=1.148&r2=1.149
>
> The attached file y.diff reverts the relevant part of the patch, so that
> mathbb works again.
Yes... but now insertion of a decoration "around" selected math text
fails. The problem which this patch originally tried to fix.
I did some more research, and it appears that the underlying problem is
the following. Look at cursor.C:
void LCursor::niceInsert(MathAtom const & t)
719 {
720 macroModeClose();
721 string const safe = lyx::cap::grabAndEraseSelection(*this);
...
730 paste(safe);
731 }
732 }
and
393 void LCursor::paste(string const & data)
394 {
396 if (!data.empty())
397 dispatch(FuncRequest(LFUN_PASTE, data));
398 }
The assumption here appears to be that the argument to give to the
LFUN_PASTE call is the _text_ to be pasted into the doc. Checking the
places where LFUN_PASTE is executed (i.e., text2.C and
math_nestinset.C), however, shows that the text to be pasted comes from
_buffer number_ n, an integer contained in the cmd.argument transferred.
So I believe there is a "thinko" here, which explains why the
selection disappears into the black hole and is never inserted -- at
least for math.
Do you agree?
- Martin
pgpEen9CLmfRC.pgp
Description: PGP signature
Re: Source cosmetics
On Sun, 2006-02-26 at 15:50 +0100, Lars Gullik Bjønnes wrote: > Sometime ago we even agreed on *.C -> *.cxx change. But today to aim > for a what seems to be commonly used I'd use *.C -> *.cpp instead. I can't find this in the list archive - why was it thought a good idea? I personally like being able to do "foo.[Ch]". John
[patch] Re: Lyx 1.4 matbb/mathcal/mathrm issue
Am Samstag, 25. Februar 2006 19:39 schrieb Andre Poenitz:
> On Sat, Feb 25, 2006 at 04:36:58PM +0100, Juergen Spitzmueller wrote:
> > math-insert is broken in general :-(
>
> Could this be related to somebody insisting on (a) doing clever things
> in text->math conversation (i.e. adding 'missing' '$') and/or (b)
> disallowing 'forbidden' things when in math-text mode?
No. (a) was never done AFAIK. (b) was partly implemented (where it made
sense), but it was well tested and works.
The problem is related to the changes a certain clever guy made two years
ago (removal of mathDispatchCreation):
http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/src/mathed/math_hullinset.C.diff?r1=1.116&r2=1.117
http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/src/text3.C.diff?r1=1.219&r2=1.220
The attached nearly untested patch fixes math-insert (bug 2315). 'fixes'
means revert to 1.3 behaviour: Require $...$ (or any other valid formula
delimiters). If no delimiters are present, create a black 'pseudo
formula'.
Please test.
Georg
Index: src/ChangeLog
===
--- src/ChangeLog (Revision 13276)
+++ src/ChangeLog (Arbeitskopie)
@@ -1,3 +1,7 @@
+2006-02-26 Georg Baum <[EMAIL PROTECTED]>
+
+ * text3.C (mathDispatch): fix math inset creation from string (bug 2315)
+
2006-02-24 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
* text3.C (mathDispatch): fix crash when selection is not empty
Index: src/text3.C
===
--- src/text3.C (Revision 13276)
+++ src/text3.C (Arbeitskopie)
@@ -158,16 +158,17 @@ namespace {
// create a macro if we see "\\newcommand"
// somewhere, and an ordinary formula
// otherwise
+ istringstream is(sel);
if (sel.find("\\newcommand") == string::npos
&& sel.find("\\def") == string::npos)
{
-cur.insert(new MathHullInset("simple"));
-cur.dispatch(FuncRequest(LFUN_RIGHT));
-cur.dispatch(FuncRequest(LFUN_INSERT_MATH, sel));
- } else {
-istringstream is(sel);
+MathHullInset * formula = new MathHullInset;
+LyXLex lex(0, 0);
+lex.setStream(is);
+formula->read(cur.buffer(), lex);
+cur.insert(formula);
+ } else
cur.insert(new MathMacroTemplate(is));
- }
}
cur.message(N_("Math editor mode"));
}
Re: project structure
Andre Poenitz <[EMAIL PROTECTED]> writes: | Could we please split off lib/doc into a repository of its own? We only just moved it into the same repo | Right now I am receiving trunk/lib/doc/hu_Intro.lyx and | trunk/lib/doc/fr_Extended.lyx, none of which I'll ever use | over a 56k modem line... But very seldom My initial feeling is "no", but there are local "changes" you can do to avoid updates of that dir at least. -- Lgb
Re: Source cosmetics
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Since LyX uses svn now and svn is a bit more forgiving when it comes
| to renaming files I thought it would be a good idea to talk a bit
| about 'source cosmetics', most notably renaming classes and files.
|
| This is no new idea, but I haven't seen any concrete proposals.
I have proposals coming, but I want 1.4.0 before we do anything.
| i.e. no {lyx,LyX,L}-prefix, instead everything in namespace lyx, usually one
| class per .h/.C combo, and files named the same way as the class.
I agree with the LyX prefix (or l or lyx) in general. We have too many
of them.
As to upper/lower case I think we should use lowercase only. But that
is purely IMHO. However what IMNSHO we need to require that files that
have the same name except for case differences are outlawed.
| I'd probaly also rename math_fooinset/MathFooInset to InsetFoo/InsetFoo.
|
| This would be 1.5.0 stuff and at least the file renamings should be done
| immediately after openening 1.5.0svn for work to prevent conflicts (even
| svn has no real file moves...)
I am not really afraid of confilicts, but we should perhaps wait with
renamings until we have some of the outstanding patches applied.
| Opinions?
Sometime ago we even agreed on *.C -> *.cxx change. But today to aim
for a what seems to be commonly used I'd use *.C -> *.cpp instead.
--
Lgb
Re: subversion
Andre Poenitz <[EMAIL PROTECTED]> writes: | Is there an equivalent to cvs's -z9 option (i.e. compressing the data | stream) in subversion or is it not possible or maybe not needed? You run it over ssh so you can do the compression there. With the upcoming subversion 1.4.0 a compressed diff format will be used so there you should get it for free. -- Lgb
Re: Lyx 1.4 matbb/mathcal/mathrm issue
Am Samstag, 25. Februar 2006 16:36 schrieb Juergen Spitzmueller:
> Joost Verburg wrote:
> > Typing the LaTeX command manually also gives weird behavior and not
the
> > expected result.
>
> you mean \mathbb{R}, then select and C-M?
> Typing \mathbbR gives the expected result to me.
The reason for '\mathbb{R}' not working is the same as for the broken math
panel, see my other mail.
Georg
Re: Lyx 1.4 matbb/mathcal/mathrm issue
Am Samstag, 25. Februar 2006 18:19 schrieb Martin Vermeer:
> First of all, the bug is unrelated to text->math conversion. You should
> look at ControlMath.C. There, the command texts associated with each
> symbol in the math symbol panels, executed when clicking on them, are
> defined.
>
> For blackboard bold R (real numbers) we have "\\mathbb R".
which is BTW valid TeX syntax.
> When you inspect the code handling this, more precisely
> ControlMath::dispatchInsert, you see that there is no handling taking
> place. And in math_nestinset's INSERT_MATH code, the R is silently
> dropped.
Yes. This dropping occurs since this patch from you:
http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/src/mathed/math_nestinset.C.diff?r1=1.148&r2=1.149
The attached file y.diff reverts the relevant part of the patch, so that
mathbb works again.
> I have a vivid recollection that there was code handling this kind of
> command string. Splitting up the string and submitting the two
> separately to dispatchFunc. Moreover, I have a strong recollection that
> I wrote both this code and introduced the command syntax it handles...
>
> Angus is marked as being to 'blame' for this part of the code, but that
> proves little for deletion of code. Somebody decided to do a little
> clean-up job on code he didn't understand... nice.
>
> The eerily familiar looking, reconstructed code that fixes the bug is
> attached.
I did search a bit, and AFAICS code that splits up stuff coming from the
frontend and creates two dispatch requests has never been in LyX.
Your fix is IMO wrong, since \mathbb R is valid TeX code and therefore
must be handled by LFUN_INSERT_MATH as is. No splitting should be
required.
The right fix is IMO to pass the whole MathArray to handleNest and not
only ar[0] in NathNestInset::doDispatch(), but I don't know how that
would look exactly or if it is possible at all.
Georg
Index: src/mathed/math_nestinset.C
===
--- src/mathed/math_nestinset.C (Revision 13276)
+++ src/mathed/math_nestinset.C (Arbeitskopie)
@@ -890,10 +890,12 @@ void MathNestInset::doDispatch(LCursor &
cell = 1;
// math macros are nest insets and may have 0 cells.
// handleNest would crash in this case.
+#if 0
if (ar.size() == 1 && (ar[0].nucleus()->asNestInset()) &&
ar[0].nucleus()->nargs() > MathInset::idx_type(cell)) {
cur.handleNest(ar[0], cell);
} else
+#endif
cur.niceInsert(cmd.argument);
break;
}
Re: Source cosmetics
On Sun, Feb 26, 2006 at 12:23:46PM +0100, Andre Poenitz wrote:
>
> Since LyX uses svn now and svn is a bit more forgiving when it comes
> to renaming files I thought it would be a good idea to talk a bit
> about 'source cosmetics', most notably renaming classes and files.
>
> This is no new idea, but I haven't seen any concrete proposals.
>
> So here it goes:
>
> Right now, both file and class names are a mess.
>
> For files we have underscore_style, plainstyle, lyxplain, CamelBumps,
> LyXCamelBump, CamelBump_pimpl, hyphenated-stuff and probably any other
> combination mankind came up with in the last five hundred years.
>
> For classes there is CamelBump, LyXCamelBump, LCamelBump, kp_underscore,
> Aux_Info, LColor_color, pushed_table and ...
>
> So (admittedly under the influence of latest and greatest Qt) I propose
> to use
>
>CamelBump.h
>CamelBump.C
>
> implementing
>
> namespace lyx {
>
> class CamelBump;
>
> }
>
> i.e. no {lyx,LyX,L}-prefix, instead everything in namespace lyx, usually one
> class per .h/.C combo, and files named the same way as the class.
>
> I'd probaly also rename math_fooinset/MathFooInset to InsetFoo/InsetFoo.
>
> This would be 1.5.0 stuff and at least the file renamings should be done
> immediately after openening 1.5.0svn for work to prevent conflicts (even
> svn has no real file moves...)
>
> Opinions?
Good idea.
What to do with the lyxtext/text/1/2 mess?
- Martin
pgpO772HOnqsV.pgp
Description: PGP signature
Re: Source cosmetics
On Sun, 26 Feb 2006, Andre Poenitz wrote:
> Since LyX uses svn now and svn is a bit more forgiving when it comes
> to renaming files I thought it would be a good idea to talk a bit
> about 'source cosmetics', most notably renaming classes and files.
Besides being "preittier", and that we all like to tweak, I think a change
like this would make it easier for a new developer to know what's what...
Wouldn't this be quite a lot of work?
> ... I propose to use
>
>CamelBump.h
>CamelBump.C
>
> implementing
>
> namespace lyx {
>
> class CamelBump;
>
> }
>
> i.e. no {lyx,LyX,L}-prefix, instead everything in namespace lyx, usually one
> class per .h/.C combo, and files named the same way as the class.
I'm not at all familiar with the code... is the majority of the classes in
the lyx namespace?
> I'd probaly also rename math_fooinset/MathFooInset to InsetFoo/InsetFoo.
Eh... also in the lyx namespace?
> Opinions?
I'd probably not notice that the lyx namespace is assumed as default when
there's nothing in the name that indicates this. I wouldn't mind having
something like 'lyx_' prepended to indicate the namespace.
/Christian
--
Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: [Patch] Bug 2316 fix
On Sun, Feb 26, 2006 at 12:26:52PM +0100, Georg Baum wrote: > Am Samstag, 25. Februar 2006 16:33 schrieb Martin Vermeer: > > > - entered multi-paragraph ERT, where empty paragraphs were created by > > two different methods: > > 1) press ENTER at end of paragraph > > 2) press ENTER at start of paragraph > > 2) is the only case I could find that would not work with my initial > version. Yes... that's because in that case it is Paragraph that initializes the font, either here 321 return LyXFont(LyXFont::ALL_INHERIT, getParLanguage(bparams)); with 1495 return bparams.language; or here 358 return LyXFont(LyXFont::ALL_INHERIT, bparams.language); depending. So, a "proper" fix would make Paragraph "sense" whether it is inside an ERT inset. Sounds ugly, doesn't it? Perhaps your original idea of using plaintext strings wasn't so bad... but not now. > > The patch may be a bit overkill, but it certainly works. > > It really does, I did some heavy testing, too. I added ChangeLog entries > and some comments. I also readded the font settings in init(). This > avoids problems if the brute force fix in doDispatch() gets removed. Not going to happen as long as ERT contains real paragraphs... > There are two changes that I did but that are not strictly necessary (but > do not harm either): > - remove unsed setFont declaration in insettext.h > - fix language handling in unused InsertERT constrcutor and comment it > out. One could as well remove the constructor completely. I changed it > because I wanted to make sure that it does not introduce language > problems again when it will be used later. OK, defensive thinking. > I think the patch is now ready for 1.4.0. Can it go in? I am happy with it. - Martin pgpbxBy5LwV3S.pgp Description: PGP signature
project structure
Could we please split off lib/doc into a repository of its own? Right now I am receiving trunk/lib/doc/hu_Intro.lyx and trunk/lib/doc/fr_Extended.lyx, none of which I'll ever use over a 56k modem line... Andre'
Source cosmetics
Since LyX uses svn now and svn is a bit more forgiving when it comes
to renaming files I thought it would be a good idea to talk a bit
about 'source cosmetics', most notably renaming classes and files.
This is no new idea, but I haven't seen any concrete proposals.
So here it goes:
Right now, both file and class names are a mess.
For files we have underscore_style, plainstyle, lyxplain, CamelBumps,
LyXCamelBump, CamelBump_pimpl, hyphenated-stuff and probably any other
combination mankind came up with in the last five hundred years.
For classes there is CamelBump, LyXCamelBump, LCamelBump, kp_underscore,
Aux_Info, LColor_color, pushed_table and ...
So (admittedly under the influence of latest and greatest Qt) I propose
to use
CamelBump.h
CamelBump.C
implementing
namespace lyx {
class CamelBump;
}
i.e. no {lyx,LyX,L}-prefix, instead everything in namespace lyx, usually one
class per .h/.C combo, and files named the same way as the class.
I'd probaly also rename math_fooinset/MathFooInset to InsetFoo/InsetFoo.
This would be 1.5.0 stuff and at least the file renamings should be done
immediately after openening 1.5.0svn for work to prevent conflicts (even
svn has no real file moves...)
Opinions?
Andre'
Re: [Patch] Bug 2316 fix
Am Samstag, 25. Februar 2006 16:33 schrieb Martin Vermeer:
> - entered multi-paragraph ERT, where empty paragraphs were created by
> two different methods:
> 1) press ENTER at end of paragraph
> 2) press ENTER at start of paragraph
2) is the only case I could find that would not work with my initial
version.
> The patch may be a bit overkill, but it certainly works.
It really does, I did some heavy testing, too. I added ChangeLog entries
and some comments. I also readded the font settings in init(). This
avoids problems if the brute force fix in doDispatch() gets removed.
There are two changes that I did but that are not strictly necessary (but
do not harm either):
- remove unsed setFont declaration in insettext.h
- fix language handling in unused InsertERT constrcutor and comment it
out. One could as well remove the constructor completely. I changed it
because I wanted to make sure that it does not introduce language
problems again when it will be used later.
I think the patch is now ready for 1.4.0. Can it go in?
Georg
Index: src/insets/insetert.h
===
--- src/insets/insetert.h (Revision 13276)
+++ src/insets/insetert.h (Arbeitskopie)
@@ -31,9 +31,11 @@ class InsetERT : public InsetCollapsable
public:
///
InsetERT(BufferParams const &, CollapseStatus status = Open);
+#if 0
///
InsetERT(BufferParams const &,
Language const *, std::string const & contents, CollapseStatus status);
+#endif
///
~InsetERT();
///
@@ -41,6 +43,8 @@ public:
///
void write(Buffer const & buf, std::ostream & os) const;
///
+ void read(Buffer const & buf, LyXLex & lex);
+ ///
std::string const editMessage() const;
///
bool insetAllowed(InsetBase::Code code) const;
Index: src/insets/insettext.h
===
--- src/insets/insettext.h (Revision 13276)
+++ src/insets/insettext.h (Arbeitskopie)
@@ -78,10 +78,6 @@ public:
///
Code lyxCode() const { return TEXT_CODE; }
///
- void setFont(BufferView *, LyXFont const &,
- bool toggleall = false,
- bool selectall = false);
- ///
void setText(std::string const &, LyXFont const &);
///
void setAutoBreakRows(bool);
Index: src/insets/ChangeLog
===
--- src/insets/ChangeLog (Revision 13276)
+++ src/insets/ChangeLog (Arbeitskopie)
@@ -1,3 +1,16 @@
+2005-02-25 Martin Vermeer <[EMAIL PROTECTED]>
+2006-02-25 Georg Baum <[EMAIL PROTECTED]>
+
+ * insetert.[Ch] (read): new, force all paragraphs to latex_language
+ * insetert.C (doDispatch): set latex_language, not buffer language
+ for copied text
+ * insetert.C (doDispatch): force latex_language for newly inserted
+ text
+ * insetert.C (draw): realize draw font
+ * insetert.[Ch] (InsetERT): use latex_language and comment out unused
+ constructor
+ * insettext.h (setFont): remove unused declaration
+
2006-02-22 Jürgen Spitzmüller <[EMAIL PROTECTED]>
* insetfootlike.C (metrics, draw): use buffer's default font (bug 2308).
Index: src/insets/insetert.C
===
--- src/insets/insetert.C (Revision 13276)
+++ src/insets/insetert.C (Arbeitskopie)
@@ -58,6 +58,8 @@ void InsetERT::init()
font.decSize();
font.setColor(LColor::latex);
setLabelFont(font);
+ text_.current_font.setLanguage(latex_language);
+ text_.real_current_font.setLanguage(latex_language);
setInsetName("ERT");
}
@@ -83,23 +85,19 @@ auto_ptr InsetERT::doClone()
}
+#if 0
InsetERT::InsetERT(BufferParams const & bp,
Language const *, string const & contents, CollapseStatus status)
: InsetCollapsable(bp, status)
{
- //LyXFont font(LyXFont::ALL_INHERIT, lang);
- LyXFont font;
- getDrawFont(font);
- string::const_iterator cit = contents.begin();
- string::const_iterator end = contents.end();
- pos_type pos = 0;
- for (; cit != end; ++cit)
- paragraphs().begin()->insertChar(pos++, *cit, font);
+ LyXFont font(LyXFont::ALL_INHERIT, latex_language);
+ paragraphs().begin()->insert(0, contents, font);
// the init has to be after the initialization of the paragraph
// because of the label settings (draw_label for ert insets).
init();
}
+#endif
InsetERT::~InsetERT()
@@ -115,6 +113,30 @@ void InsetERT::write(Buffer const & buf,
}
+void InsetERT::read(Buffer const & buf, LyXLex & lex)
+{
+ InsetCollapsable::read(buf, lex);
+
+ // Force default font
+ // This avoids paragraphs in buffer language that would have a
+ // foreign language after a document langauge change, and it ensures
+ // that all new text in ERT gets the "latex" language, since new text
+ // inherits the language from the last position of the existing text.
+ // As a side effect this makes us also robust against bugs in LyX
+ // that might lead to font changes in ERT in .lyx files.
+ LyXFont font(LyXFont::ALL_INHERIT, latex_language);
+ ParagraphList::iterator par = paragraphs().begin
Re: Lyx 1.4 matbb/mathcal/mathrm issue
On Sat, Feb 25, 2006 at 07:45:53PM +0100, Andre Poenitz wrote:
> On Sat, Feb 25, 2006 at 07:19:31PM +0200, Martin Vermeer wrote:
> > For blackboard bold R (real numbers) we have "\\mathbb R".
>
> Why doesn't it try \mathbb{R} or such? Shouldn't that be parsed
> better?
Perhaps... I tried that. It (1) doesn't work, and (2) doesn't find the
xpm file for display on the panel. So, good idea, but no.
> > [...]
> > Angus is marked as being to 'blame' for this part of the code, but that
> > proves little for deletion of code. Somebody decided to do a little
> > clean-up job on code he didn't understand... nice.
>
> I recognize this pattern, however I am not sure I've ever touched
> ControlMath.C.
I think it was earlier in FormsMath/QMath, before Angus moved it over.
- Martin
pgpXXWIx7ECeC.pgp
Description: PGP signature
