Fresh CVS lyx compile.
1. Start lyx
2. C-n (New buffer)
3. C-m (Math inset)
lyx crashes
Here is the output on the console:
[EMAIL PROTECTED] ~] lyx
*** workAreaDispatch: request: action: 216 arg: '' x: 325 y: 217
*** workAreaDispatch: request: action: 217 arg: '' x: 325 y: 217
*** workAreaDispa
Jose' Matos wrote:
>> some time ago you fixed some python encoding warnings in lyx2lyx.
>> However, it seems that the encoding needs to be specified not only in the
>> main file, but also in the imported modules.
>> The attached patch adds the encoding to every python file in lyx2lyx.
>> The patch
See http://bugzilla.lyx.org/show_bug.cgi?id=605,
http://bugzilla.lyx.org/show_bug.cgi?id=1231 and
http://bugzilla.lyx.org/show_bug.cgi?id=1244 for details of these bugs.
With help from discussion on this list and using Jean-Marcs old patch for
bug 605 I believe I have fixed bugs 605, 1231, and
Index: lyxfind.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxfind.C,v
retrieving revision 1.72
diff -u -p -u -r1.72 lyxfind.C
--- lyxfind.C 31 Jan 2004 15:30:21 - 1.72
+++ lyxfind.C 2 Feb 2004 20:40:58 -
@@ -
it has been removed for some reason.
Don't know if this is the correct place to put it though...
Alfredo
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.496
diff
Juergen Spitzmueller wrote:
> > I saw it too late! Could you experiment with those variables (also
> > LC_MONETARY, maybe)? I cannot find any reference about what
> > LC_MEASUREMENT does...
>
> Not very much ATM.
Well I did it nevertheless. LC_NUMERIC is to blame AFAICS. Setting this
variable to
Am Montag, 02. Februar 2004 17:36 schrieb Jean-Marc Lasgouttes:
> Juergen> Yes, see my previous mail (i guess either LC_NUMERIC or
> Juergen> LC_MEASUREMENT are to blame).
>
> I saw it too late! Could you experiment with those variables (also
> LC_MONETARY, maybe)? I cannot find any reference about
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Jean-Marc Lasgouttes wrote:
>> Do you have any LC_* variables set?
Juergen> Yes, see my previous mail (i guess either LC_NUMERIC or
Juergen> LC_MEASUREMENT are to blame).
I saw it too late! Could you experiment with tho
Jean-Marc Lasgouttes wrote:
> Do you have any LC_* variables set?
Yes, see my previous mail (i guess either LC_NUMERIC or LC_MEASUREMENT are to
blame).
Jürgen
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Jean-Marc Lasgouttes wrote:
>> What are the environment variables that are set when you change
>> your environment?
Juergen> Which ones? Default LANG is [EMAIL PROTECTED]
Do you have any LC_* variables set?
>> I do not
Am Montag, 02. Februar 2004 15:57 schrieb Juergen Spitzmueller:
> > What are the environment variables that are set when you change your
> > environment?
>
> Which ones?
OK, this is the output of locale before switching LANG to en_US:
[EMAIL PROTECTED]
LC_CTYPE="[EMAIL PROTECTED]"
LC_NUMERIC="[EM
Jean-Marc Lasgouttes wrote:
> What are the environment variables that are set when you change your
> environment?
Which ones? Default LANG is [EMAIL PROTECTED]
> I do not understand how LANG can change the writing of
> numbers?
Me neither. Note that this is an xforms specific problem.
> What
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Alfredo Braunstein wrote:
>> Could it be a locale problem?
Juergen> Yes, seems so. The problem disappears when I switch LANG to
Juergen> en_US.
What are the environment variables that are set when you change your
enviro
The graphics cache decompresses zipped files in place for preview, that
means it will overwrite a.eps without warning if a.eps.gz is included in
the LyX file.
The attached patch changes that: The unzipped file is put into the temp dir.
The patch is against 1.4, but a similar one should work for 1.3
Alfredo Braunstein wrote:
> Could it be a locale problem?
Yes, seems so. The problem disappears when I switch LANG to en_US.
Jürgen.
This replaces findText with BOOST_ASSERTs and even survives File->New.
Btw, is there a nicer way to write
+ if (this != bv()->cursor().text()) {
+ lyxerr << "cursor: " << bv()->cursor()
+ << "\ntext: " << bv()->cursor().text()
+ <
Andre Poenitz wrote:
> On Mon, Feb 02, 2004 at 12:02:22PM +0100, Georg Baum wrote:
>> The problem is that the mathed parser does not understand something like
>>
>> $a \displaystyle b$
>
> Well, it does (type it, mark it, press C-m).
That was from memory ;-)
> It does not understand $\begin{ar
On Mon, Feb 02, 2004 at 12:02:22PM +0100, Georg Baum wrote:
> Just to clarify:
> The problem is not tex2lyx, since it spits out latex in math mode 1:1 (modulo
> some space changes IIRC).
Given that the tex2lyx and the mathed parser are pretty much the same
code (at least historically) we are talk
Am Montag, 2. Februar 2004 11:55 schrieb Andre Poenitz:
> On Mon, Feb 02, 2004 at 11:43:56AM +0100, Georg Baum wrote:
> > Andre Poenitz wrote:
> > > On Fri, Jan 30, 2004 at 07:09:55PM +, Jose' Matos wrote:
> > >> Notice that the displaystyle there, it should probably be
> > >> {\displaystyle
Andre Poenitz wrote:
>> +void BufferView::setCursor(ParIterator const & par,
>> + lyx::pos_type pos)
>> +{
>> + LCursor & cur = cursor();
>> + cur.reset();
>> + ParIterator::PosHolder const & positions = par.positions();
>> + int const last = par.si
Juergen Spitzmueller wrote:
> More debugging showed that the problem is in
> updateWidgetsFromLengthString. This function passes a string const & str
> as LyXLength(str) to update WidgetsFromLength.
> But if I have a string str = 3.2cm, LyXLength(str).asString() returns 3cm.
> Now the question is:
On Mon, Feb 02, 2004 at 11:43:56AM +0100, Georg Baum wrote:
> Andre Poenitz wrote:
>
> > On Fri, Jan 30, 2004 at 07:09:55PM +, Jose' Matos wrote:
> >> Notice that the displaystyle there, it should probably be
> >> {\displaystyle ...}, but here I am just guessing. :-)
> >
> > No, this usage
Andre Poenitz wrote:
> On Fri, Jan 30, 2004 at 07:09:55PM +, Jose' Matos wrote:
>> Notice that the displaystyle there, it should probably be
>> {\displaystyle ...}, but here I am just guessing. :-)
>
> No, this usage is 'fine'. But a pain to get parsed right *sigh*.
>
> Georg, would you mi
On Mon, Feb 02, 2004 at 11:07:56AM +0100, Alfredo Braunstein wrote:
> in favour of BufferView::setCursor(ParIterator &, lyx::pos_type)
>
> The lockPath name is really out of context now (remember *lock* ;-) ? ) and
> it doesn't belong really to ParIterator.
>
> Ok to go in?
Looks good.
> +void
Juergen Spitzmueller wrote:
> OK, this is a bug in the xforms frontend. The problem is that the length
> widgets in the xforms frontend strip all values behind the dot (while
> applying). I suspect that the bug is in xforms_helpers.C
> (getLengthFromWidgets), but it didn't find it.
> Any ideas?
Mo
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> My personal opinion is to change nothing in 1.3 that requires a
Georg> file format change. The time needed for adjusting lyx2lyx is
Georg> better spent with fixing 1.4 bugs.
Not only that, but the policy is to make sure that all 1.3.x
in favour of BufferView::setCursor(ParIterator &, lyx::pos_type)
The lockPath name is really out of context now (remember *lock* ;-) ? ) and
it doesn't belong really to ParIterator.
Ok to go in?
Alfredo
Index: BufferView.C
===
RCS
On Mon, Feb 02, 2004 at 10:05:11AM +0100, Andre' Poenitz wrote:
> > (btw, why is that ::findText needed at all, didn't we agree that the
> > current() slice is what is needed there? IMO for debugging wouldn't be
> > enough to assert on current().text() == text)
>
> Sort of leftover from the transi
On Sun, Feb 01, 2004 at 01:08:37PM +0100, Alfredo Braunstein wrote:
> the problem seems to consist in the following:
>
> - the click is dispatched through a temporary cursor cur to which this
> collapsable's CUrsorSlice is pushed (the real cursor is still elsewhere);
> so
Yes. That's to raise th
On Monday 02 February 2004 09:25, Andre Poenitz wrote:
> > 2) eliminating some (bogus) redundant cursor positioning code in
> > undo
>
> Ah good. This was a _really_ old hack in undo as far as I can tell.
I know... hopefully we can remove this ugly sort of things in more that one
place thanks to
On Fri, Jan 30, 2004 at 07:09:55PM +, Jose' Matos wrote:
> On Friday 30 January 2004 10:55, Paul Stansell wrote:
> > >I will take a look into it, it shouldn't be too difficult to fix.
> >
> > Thanks!
> >
> > >Do you know what is the purpose of the displaystyle in the file? How
> > > wou
On Sunday 01 February 2004 19:45, Georg Baum wrote:
> José,
>
> some time ago you fixed some python encoding warnings in lyx2lyx.
> However, it seems that the encoding needs to be specified not only in the
> main file, but also in the imported modules.
> The attached patch adds the encoding to ever
On Saturday 31 January 2004 12:32, Lars Gullik Bjønnes wrote:
> It it works it works.
Seems to ;-)
> As long as it does not introduce more errors go for it.
okeydokey.
Alfredo
On Sat, Jan 31, 2004 at 11:50:19AM +0100, Alfredo Braunstein wrote:
> zz
>
> gives a crash.
>
> This patch solves that by 1) fixing lockPath (the CursorSlice at level 0 was
> missing)
Thanks.
> 2) eliminating some (bogus) redundant cursor positioning code in
> undo
Ah good. This was a _really_
On Fri, Jan 30, 2004 at 01:30:59PM -0800, Kayvan A. Sylvan wrote:
> The lyx crashes situation is better. Thanks.
>
> Lyx still crashes on:
>
> 1. C-N (New document)
> 2. C-M (Insert math inset)
> 3. type X^Y in the math inset
>
> The "^" causes the crash on some of my machines, but the C-m cause
On Fri, Jan 30, 2004 at 01:54:37PM +0100, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | This intention of this 'nucleus/operator->' pair instead of the usual
> | 'nucleus/nucleus' pair was to be able to find the non-const accesses
> | with grep. [They are sort of 'un
36 matches
Mail list logo
