Enrico Forestieri wrote:
On Thu, Nov 08, 2007 at 06:05:20AM -, [EMAIL PROTECTED] wrote:
Author: forenr
Date: Thu Nov 8 07:05:19 2007
New Revision: 21513
URL: http://www.lyx.org/trac/changeset/21513
Log:
Fix problems with odocstream on "exotic" systems caused by the strfwd gimmick.
Am 08.11.2007 um 01:07 schrieb Andre Poenitz:
On Thu, Nov 08, 2007 at 12:01:16AM +0100, Stefan Schimanski wrote:
Nope, that's Stefan's work...
Stefan?
- return QColor(v*minr+(1-v)*maxr, v*ming+(1-v)*maxg, v*minb+(1-
v)*maxb);
+ QColor c;
+ c.setRgbF(v*minr+(1-v)*maxr, v*ming+(1-v)*max
Enrico Forestieri wrote:
On Thu, Nov 08, 2007 at 06:05:20AM -, [EMAIL PROTECTED] wrote:
Author: forenr
Date: Thu Nov 8 07:05:19 2007
New Revision: 21513
URL: http://www.lyx.org/trac/changeset/21513
Log:
Fix problems with odocstream on "exotic" systems caused by the strfwd gimmick.
On Thu, Nov 08, 2007 at 07:57:58AM +0200, Martin Vermeer wrote:
> On Wed, Nov 07, 2007 at 11:38:08PM +0100, Michael Gerz wrote:
> >
> > FYI. Looking forward to a great 1.5.3 release!
> >
> > Regards, Michael
> >
>
> ...
>
> > http://www.lyx.org/trac/changeset/21460 - Fix bug 4329
>
> Looking
On Wed, Nov 07, 2007 at 08:41:46PM +0100, Andre Poenitz wrote:
> On Wed, Nov 07, 2007 at 11:53:06AM +0100, Enrico Forestieri wrote:
> > On Wed, Nov 07, 2007 at 10:55:23AM +0100, Stefan Schimanski wrote:
> >
> > > This commit breaks the MathStream class. You get plenty of ascii codes
> > > if you
On Thu, Nov 08, 2007 at 06:05:20AM -, [EMAIL PROTECTED] wrote:
> Author: forenr
> Date: Thu Nov 8 07:05:19 2007
> New Revision: 21513
>
> URL: http://www.lyx.org/trac/changeset/21513
> Log:
> Fix problems with odocstream on "exotic" systems caused by the strfwd gimmick.
>
> * src/suppo
On Wed, Nov 07, 2007 at 04:57:02PM +0100, Stefan Schimanski wrote:
>
> Am 07.11.2007 um 16:46 schrieb Jean-Marc Lasgouttes:
>
> > Stefan Schimanski <[EMAIL PROTECTED]> writes:
> >
> >> Hi!
> >>
> >> Is there a reason that behind every paragraph a "10" is put in the
> >> tex
> >> output? I guess
On Wed, Nov 07, 2007 at 10:55:23AM +0100, Stefan Schimanski wrote:
> This commit breaks the MathStream class. You get plenty of ascii codes
> if you copy a part of a formula and insert it, e.g. \frac becomes
> 92frac. Reverting the MathStream part of the commit fixes it.
Please, can you confi
On Wed, Nov 07, 2007 at 11:38:08PM +0100, Michael Gerz wrote:
>
> FYI. Looking forward to a great 1.5.3 release!
>
> Regards, Michael
>
...
> http://www.lyx.org/trac/changeset/21460 - Fix bug 4329
Looking at the code, I don't think this is needed. Should function OK.
Can someone confirm?
- M
On Wed, Nov 07, 2007 at 10:27:07PM +0100, Andre Poenitz wrote:
> On Wed, Nov 07, 2007 at 10:27:21PM +0200, Martin Vermeer wrote:
> > > > @@ -269,6 +272,12 @@
> > > >
> > > > void InsetBranch::validate(LaTeXFeatures & features) const
> > > > {
> > > > + string const name = to_utf8(params_.
On Wed, Nov 07, 2007 at 10:27:07PM +0100, Andre Poenitz wrote:
> On Wed, Nov 07, 2007 at 10:27:21PM +0200, Martin Vermeer wrote:
> > > > @@ -269,6 +272,12 @@
> > > >
> > > > void InsetBranch::validate(LaTeXFeatures & features) const
> > > > {
> > > > + string const name = to_utf8(params_.
Jean-Marc Lasgouttes wrote:
Koji Yokota <[EMAIL PROTECTED]> writes:
Yes, that's the problem. It should work well for a user who changed
the default converter of "latex -> DVI" to "platex" and writes only
Japanese exclusively. But once he begins to write French with the same
setting, he may
Andre,
Please format the attached file and send it back to me.
Questions:
1. Do we use space for alignment? When do we use tab?
2. Do we align to ( of function call and/or definition? Or do we only
use indentation?
3. How do we treat the format of nested function calls?
I will program your answ
Andre Poenitz ha scritto:
of use): #include pulls in 62000 lines of code.
Ok, I didn't know about such issue. this was definitively
persuading as a reason for not using that, thanx.
Any attempt to contact the library authors about why so
many lines of code are pulled in for a so simple (and
> FYI. Looking forward to a great 1.5.3 release!
i vaguely remember some incidental problems with the width of some insets when
working.
maybe it has something common with this:
InsetText.h: In copy constructor 'lyx::InsetText::InsetText(const
lyx::InsetText&)':
InsetText.h:162: warning: 'lyx::
On Thu, Nov 08, 2007 at 12:01:16AM +0100, Stefan Schimanski wrote:
>> Nope, that's Stefan's work...
>>
>> Stefan?
>>> - return QColor(v*minr+(1-v)*maxr, v*ming+(1-v)*maxg, v*minb+(1-v)*maxb);
>>> + QColor c;
>>> + c.setRgbF(v*minr+(1-v)*maxr, v*ming+(1-v)*maxg, v*minb+(1-v)*maxb);
>>> + ret
Am 07.11.2007 um 20:43 schrieb Andre Poenitz:
On Wed, Nov 07, 2007 at 10:55:23AM +0100, Stefan Schimanski wrote:
This commit breaks the MathStream class. You get plenty of ascii
codes if
you copy a part of a formula and insert it, e.g. \frac becomes
92frac.
Reverting the MathStream part of
Nope, that's Stefan's work...
Stefan?
- return QColor(v*minr+(1-v)*maxr, v*ming+(1-v)*maxg, v*minb+(1-
v)*maxb);
+ QColor c;
+ c.setRgbF(v*minr+(1-v)*maxr, v*ming+(1-v)*maxg, v*minb+(1-v)*maxb);
+ return c;
}
That was me most probably, yes. Is there an advantage in this chan
FYI. Looking forward to a great 1.5.3 release!
Regards, Michael
Approved by Jürgen
--
http://www.lyx.org/trac/changeset/20419 - GuiApplication::notify():
don't crash with abort() but exit gracefully when an exception is
caught. try to catch LyX specific exceptions.
http://
Andre Poenitz wrote:
There's some traits specific to your implementation missing.
Would #include "support/docstring.h" in TextClass.cpp help?
No, cause it's already included in TextClass.h.
Meanwhile I've committed a compil fix:
Author: younes
Date: Wed Nov 7 23:20:13 2007
New Revision: 21
Edwin Leuven wrote:
> perhaps someone can update the links to 1.5.2 here:
>
> http://wiki.lyx.org/Windows/Windows
Why not you?
Jürgen
On Wed, Nov 07, 2007 at 11:08:54PM +0100, Abdelrazak Younes wrote:
> Abdelrazak Younes wrote:
>> Andre Poenitz wrote:
>>> On Wed, Nov 07, 2007 at 11:53:06AM +0100, Enrico Forestieri wrote:
On Wed, Nov 07, 2007 at 10:55:23AM +0100, Stefan Schimanski wrote:
> This commit breaks the Math
Abdelrazak Younes wrote:
Andre Poenitz wrote:
On Wed, Nov 07, 2007 at 11:53:06AM +0100, Enrico Forestieri wrote:
On Wed, Nov 07, 2007 at 10:55:23AM +0100, Stefan Schimanski wrote:
This commit breaks the MathStream class. You get plenty of ascii
codes if you copy a part of a formula and inser
perhaps someone can update the links to 1.5.2 here:
http://wiki.lyx.org/Windows/Windows
On Wed, Nov 07, 2007 at 12:04:46AM +0100, Tommaso Cucinotta wrote:
> Any comments by anyone is welcome.
It does not apply to trunk:
patching file src/ParagraphMetrics.h
patching file src/insets/InsetInclude.cpp
patching file src/insets/InsetText.cpp
patching file src/BufferView.cpp
Hunk #1 FAILED
On Wed, Nov 07, 2007 at 10:27:21PM +0200, Martin Vermeer wrote:
> > > @@ -269,6 +272,12 @@
> > >
> > > void InsetBranch::validate(LaTeXFeatures & features) const
> > > {
> > > + string const name = to_utf8(params_.branch);
> > > + features.require(name);
> > > + if (selected_)
> > > + f
[EMAIL PROTECTED] wrote:
Author: poenitz
Date: Wed Nov 7 21:44:36 2007
New Revision: 21495
URL: http://www.lyx.org/trac/changeset/21495
Log:
Abdel?
Nope, that's Stefan's work...
Stefan?
Modified:
lyx-devel/trunk/src/frontends/qt4/GuiPainter.cpp
Modified: lyx-devel/trunk/src/frontends
On Wed, Nov 07, 2007 at 09:06:52PM +0100, Andre Poenitz wrote:
> On Wed, Nov 07, 2007 at 09:29:38PM +0200, Martin Vermeer wrote:
> >
> > Has anybody else noticed that the branches feature doesn't work inside
> > math and inside graphics?
>
> Not me ;-)
>
> > It would be especially nice to have i
Andre Poenitz wrote:
On Wed, Nov 07, 2007 at 11:53:06AM +0100, Enrico Forestieri wrote:
On Wed, Nov 07, 2007 at 10:55:23AM +0100, Stefan Schimanski wrote:
This commit breaks the MathStream class. You get plenty of ascii codes
if you copy a part of a formula and insert it, e.g. \frac becomes
On Wed, Nov 07, 2007 at 09:29:38PM +0200, Martin Vermeer wrote:
>
> Has anybody else noticed that the branches feature doesn't work inside
> math and inside graphics?
Not me ;-)
> It would be especially nice to have it in the
> "special" LaTeX strings inside XFig graphics. An in text phrases ins
On Wed, Nov 07, 2007 at 11:53:06AM +0100, Enrico Forestieri wrote:
> On Wed, Nov 07, 2007 at 10:55:23AM +0100, Stefan Schimanski wrote:
>
> > This commit breaks the MathStream class. You get plenty of ascii codes
> > if you copy a part of a formula and insert it, e.g. \frac becomes
> > 92frac.
On Wed, Nov 07, 2007 at 10:55:23AM +0100, Stefan Schimanski wrote:
> This commit breaks the MathStream class. You get plenty of ascii codes if
> you copy a part of a formula and insert it, e.g. \frac becomes 92frac.
> Reverting the MathStream part of the commit fixes it.
Hmm, seems to work for m
On Wed, Nov 07, 2007 at 11:53:06AM +0100, Enrico Forestieri wrote:
> On Wed, Nov 07, 2007 at 10:55:23AM +0100, Stefan Schimanski wrote:
>
> > This commit breaks the MathStream class. You get plenty of ascii codes
> > if you copy a part of a formula and insert it, e.g. \frac becomes
> > 92frac.
On Wed, Nov 07, 2007 at 01:15:45PM -0500, José Matos wrote:
> On Saturday 03 November 2007 05:44:44 Andre Poenitz wrote:
> > A solution for back-and-forward conversions in the final script would be
> > some 'obsoleted in format n' property. So lyx2lyx would skip parts
> > that are obsoleted if the
On Wed, Nov 07, 2007 at 06:54:39PM +0100, Tommaso Cucinotta wrote:
> Abdelrazak Younes ha scritto:
>>> Just as an example, now we have a Buffer::changed() method that
>>> uses a WorkArea pointer (wa_) in the Buffer::pimpl object,
>>
>> Not a WorkArea but a WorkAreaManager.
> Yes, infact, I found th
Has anybody else noticed that the branches feature doesn't work inside
math and inside graphics? It would be especially nice to have it in the
"special" LaTeX strings inside XFig graphics. An in text phrases inside
math, like
/ 0 if x > 0
f(x) = |
\ 1 if x <= 0
where you may w
On Wednesday 07 November 2007 19:11:42 Andre Poenitz wrote:
> A > B >> C.
>
> I think nesting #ifdef's is ok, but as we do not use the preprocessor
> heavily it probably does not make much of a difference.
+1
> Andre'
--
José Abílio
On Wed, Nov 07, 2007 at 06:07:19PM +0100, Tommaso Cucinotta wrote:
> Hi all,
Hi Tommaso.
> if I remember well, there has been a significant decrease in the
> use of boost::signal variables, in trunk w.r.t. previous revisions.
I even believe this was intentional.
> Just as an example, now we hav
On Wed, Nov 07, 2007 at 05:31:47PM +0100, Abdelrazak Younes wrote:
> [EMAIL PROTECTED] wrote:
>> Author: younes
>> Date: Wed Nov 7 16:55:59 2007
>> New Revision: 21490
>> URL: http://www.lyx.org/trac/changeset/21490
>> Log:
>> integrate lengthcommon.cpp into Length.cpp.
>> Removed:
>> lyx-deve
On Wed, Nov 07, 2007 at 12:12:49PM +0100, Jean-Marc Lasgouttes wrote:
> [EMAIL PROTECTED] writes:
>
> > Author: poenitz
> > Date: Tue Nov 6 22:45:24 2007
> > New Revision: 21482
> >
> > URL: http://www.lyx.org/trac/changeset/21482
> > Log:
> > we assume (more or less) conforming compilers nowaday
On Tue, Nov 06, 2007 at 09:29:57PM -0500, Richard Heck wrote:
> Bo Peng wrote:
>> Hi, Andre,
>>
>> What are our rules for preprocessor indentation? Please choose from A,
>> B, or C from the attache file. I personally prefer B.
>>
> I hereby declare that I have no preference. I vote with Andre. ;
On Wed, Nov 07, 2007 at 06:34:22PM +1800, Bo Peng wrote:
> Hi, Andre,
>
> What are our rules for preprocessor indentation? Please choose from A,
> B, or C from the attache file. I personally prefer B.
A > B >> C.
I think nesting #ifdef's is ok, but as we do not use the preprocessor
heavily it pr
> > You mean why system and added shortcuts are displayed separately?
All of us want to have one item per lfun. It is just that the logic
would be much more complicated than the current one, and I am not good
at qt programming at all. As I have said before, I am done with this
feature and people w
> please find attached a first attempt of fixing the non-uniform scrolling
> of LyX on trunk (21411).
it seems this patch breaks view of boxes. try e.g.
http://bugzilla.lyx.org/attachment.cgi?id=2218&action=view
in 1.5 and in patched trunk to see the difference. paragraph
does not respect width o
Bo Peng wrote:
On Nov 7, 2007 11:47 AM, Edwin Leuven <[EMAIL PROTECTED]> wrote:
Jean-Marc Lasgouttes wrote:
It looks good now. Congratulations.
although i don't understand why we have double entries when adding a
custom keybinding
You mean why system and added shortcuts are displayed separat
On Nov 7, 2007 11:47 AM, Edwin Leuven <[EMAIL PROTECTED]> wrote:
> Jean-Marc Lasgouttes wrote:
> > It looks good now. Congratulations.
>
> although i don't understand why we have double entries when adding a
> custom keybinding
You mean why system and added shortcuts are displayed separately?
Bo
On Saturday 03 November 2007 05:44:44 Andre Poenitz wrote:
> A solution for back-and-forward conversions in the final script would be
> some 'obsoleted in format n' property. So lyx2lyx would skip parts
> that are obsoleted if the target format has a higher version, yet in
> between it will do the
Abdelrazak Younes ha scritto:
Just as an example, now we have a Buffer::changed() method that
uses a WorkArea pointer (wa_) in the Buffer::pimpl object,
Not a WorkArea but a WorkAreaManager.
Yes, infact, I found this comment in WorkAreaManager.h:
"This is a helper class designed to avoid sign
Jean-Marc Lasgouttes wrote:
It looks good now. Congratulations.
although i don't understand why we have double entries when adding a
custom keybinding
Tommaso Cucinotta wrote:
Hi all,
if I remember well, there has been a significant decrease in the
use of boost::signal variables, in trunk w.r.t. previous revisions.
Just as an example, now we have a Buffer::changed() method that
uses a WorkArea pointer (wa_) in the Buffer::pimpl object,
Not
> It looks good now. Congratulations.
I am glad to hear that.
Note that there are some remaining problems such as 'save' and
'apply', and what if a user choose 'user.bind' as his master bind
file...
Bo
[EMAIL PROTECTED] wrote:
Author: younes
Date: Wed Nov 7 16:55:59 2007
New Revision: 21490
URL: http://www.lyx.org/trac/changeset/21490
Log:
integrate lengthcommon.cpp into Length.cpp.
Removed:
lyx-devel/trunk/src/lengthcommon.cpp
Oups, looks like I broke Tex2lyx, I'll revert, sorry.
Abd
Hi all,
if I remember well, there has been a significant decrease in the
use of boost::signal variables, in trunk w.r.t. previous revisions.
Just as an example, now we have a Buffer::changed() method that
uses a WorkArea pointer (wa_) in the Buffer::pimpl object, in order
to call redrawAll() and
Abdelrazak Younes ha scritto:
hope you won't let us down :-). The downside of your patch is that it
erases most of the optimisation I've worked hard to preserve.
Guess I can preserve such optimizations (i.e. the updateFlags
computation and management) -- see also my
previous msg. My aim is to r
Helge Hafting ha scritto:
6) I said that already but there's a number of optimisation that are
gone now because you basically do a full screen update at each
operation.
Please, note that the updateFlags are still correctly produced by the
various
(quite obscure) code segments around. Except th
"Bo Peng" <[EMAIL PROTECTED]> writes:
>> Is there a cross-out font?
>
> There is, so I removed all colors.
>
> I guess you should be happier with this dialog, with shortcuts
> displayed in ForGui format, and without color. If anyone wants to
> implement the one-lfun-multiple-shortcuts idea, please
Am 07.11.2007 um 16:46 schrieb Jean-Marc Lasgouttes:
Stefan Schimanski <[EMAIL PROTECTED]> writes:
Hi!
Is there a reason that behind every paragraph a "10" is put in the
tex
output? I guess it's some debugging output of the font size or so?
It look like a '\n' send to the stream in the
Jean-Marc Lasgouttes wrote:
>> I propose to apply my patch to fix the crash and to clear up the methods
>> later.
>
> OK.
Done.
Jürgen
Stefan Schimanski <[EMAIL PROTECTED]> writes:
> Hi!
>
> Is there a reason that behind every paragraph a "10" is put in the tex
> output? I guess it's some debugging output of the font size or so?
It look like a '\n' send to the stream in the wrong way. Do you still
see this?
JMarc
Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>
>> We have two different methods for insets: plaintext and textString.
>> They are called in different cases (I am not sure what the exact
>> contexts are, to be frank). If we managed to give them differetn and
>> cle
Jean-Marc Lasgouttes wrote:
> We have two different methods for insets: plaintext and textString.
> They are called in different cases (I am not sure what the exact
> contexts are, to be frank). If we managed to give them differetn and
> clear semantics, we would have the tool we need.
Yes. Howev
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
I don't think we should test for that anyway as I remember using
istream and ostream with gcc2.7 more than 10 years ago ;-)
Yes, but they did not have the same interface, did they?
I think they did. What was changing
On Wed, 07 Nov 2007 15:25:05 +0100
Helge Hafting <[EMAIL PROTECTED]> wrote:
> g++ -DHAVE_CONFIG_H -I. -I../../lyx-devel/src -I. -I../../lyx-devel/src
> -Wextra -Wall -g -O2 -MT lengthcommon.lo -MD -MP -MF
> .deps/lengthcommon.Tpo -c ../../lyx-devel/src/lengthcommon.cpp -o
> lengthcommon.o
> ..
g++ -DHAVE_CONFIG_H -I. -I../../lyx-devel/src -I. -I../../lyx-devel/src
-Wextra -Wall -g -O2 -MT lengthcommon.lo -MD -MP -MF
.deps/lengthcommon.Tpo -c ../../lyx-devel/src/lengthcommon.cpp -o
lengthcommon.o
../../lyx-devel/src/lengthcommon.cpp:39: error: expected
primary-expression before '<<' t
Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>
>> What about using subst (on docstring) to replace \n with space?
>
> I've done that, but it gives very ugly results (basically the whole matrix
> mangled in one line, including the LaTeX tags). I think we cannot pro
Darren Freeman <[EMAIL PROTECTED]> writes:
> Hi all,
>
> okay I finally worked out how to get formula numbering to work.. you
> have to toggle display mode first.
>
> Why doesn't this happen automatically?
Well, if an equation is not in display mode, there has to be a reason...
> Or if there is
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> I don't think we should test for that anyway as I remember using
> istream and ostream with gcc2.7 more than 10 years ago ;-)
Yes, but they did not have the same interface, did they?
JMarc
Abdelrazak Younes wrote:
Tommaso Cucinotta wrote:
Hi Abdel,
please find attached a first attempt of fixing the non-uniform scrolling
of LyX on trunk (21411).
6) I said that already but there's a number of optimisation that are
gone now because you basically do a full screen update at each op
Jean-Marc Lasgouttes wrote:
> What about using subst (on docstring) to replace \n with space?
I've done that, but it gives very ugly results (basically the whole matrix
mangled in one line, including the LaTeX tags). I think we cannot provide
anything useful for matrices anyway (it should return
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
True. But most LFUNs in Text::dispatch() do not really belong there.
This is part of your desire to redefine what Text is, if I understand
correctly. In this case, the handling should be moved to InsetText.
Yes, proba
Jean-Marc Lasgouttes wrote:
[EMAIL PROTECTED] writes:
Author: poenitz
Date: Tue Nov 6 22:45:24 2007
New Revision: 21482
URL: http://www.lyx.org/trac/changeset/21482
Log:
we assume (more or less) conforming compilers nowadays.
And do we test for that? We should.
Well, we require the availa
Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
> Juergen Spitzmueller wrote:
>
>> Quick fix attached.
>
> This one gives better label string proposals.
What about using subst (on docstring) to replace \n with space?
JMarc
"Bo Peng" <[EMAIL PROTECTED]> writes:
> Hi, Andre,
>
> What are our rules for preprocessor indentation? Please choose from A,
> B, or C from the attache file. I personally prefer B.
I am not sure which one I prefer (not C).
JMarc
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> True. But most LFUNs in Text::dispatch() do not really belong there.
This is part of your desire to redefine what Text is, if I understand
correctly. In this case, the handling should be moved to InsetText.
JMarc
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Because conceptually Text doesn't know where the cursor is, only
> Cursor itself knows. So Cursor should ask the current paragraph if it
> is a TOC type or not. Absolutely no property of Text is used during
> this decision process. This way, we won't
[EMAIL PROTECTED] writes:
> Author: poenitz
> Date: Tue Nov 6 22:45:24 2007
> New Revision: 21482
>
> URL: http://www.lyx.org/trac/changeset/21482
> Log:
> we assume (more or less) conforming compilers nowadays.
And do we test for that? We should.
JMarc
On Wed, Nov 07, 2007 at 10:55:23AM +0100, Stefan Schimanski wrote:
> This commit breaks the MathStream class. You get plenty of ascii codes
> if you copy a part of a formula and insert it, e.g. \frac becomes
> 92frac. Reverting the MathStream part of the commit fixes it.
This only happens whe
Juergen Spitzmueller wrote:
> Quick fix attached.
This one gives better label string proposals.
Jürgen
Index: src/Text.cpp
===
--- src/Text.cpp (Revision 21475)
+++ src/Text.cpp (Arbeitskopie)
@@ -90,6 +90,7 @@
using support::conta
Darren Freeman wrote:
> another mathed-related crash in branch.
>
> http://bugzilla.lyx.org/show_bug.cgi?id=4334
The problem is that the string which is returned by math matrix via
inset.asString() and which is used by getPossibleLabel contains linebreaks
that are not allowed in this context.
Q
This commit breaks the MathStream class. You get plenty of ascii codes
if you copy a part of a formula and insert it, e.g. \frac becomes
92frac. Reverting the MathStream part of the commit fixes it.
Stefan
Am 06.11.2007 um 00:46 schrieb [EMAIL PROTECTED]:
Author: poenitz
Date: Tue Nov 6 0
Tommaso Cucinotta wrote:
Hi Abdel,
please find attached a first attempt of fixing the non-uniform scrolling
of LyX on trunk (21411).
Very good Tommaso! I know this represents a lot of work but there's
still some things to improve in your patch. I hope you won't let us down
:-). The downside
81 matches
Mail list logo
