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 'unwanted'
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 causes
the
On Sat, Jan 31, 2004 at 11:50:19AM +0100, Alfredo Braunstein wrote:
new doczenterzundo
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
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 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 every
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
would a present
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 your
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 the
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 transition.
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
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 versions
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?
More
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
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 mind to
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 is 'fine'.
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: why?
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.size() - 1;
+
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 ...}, but
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
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
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()
+\nthis: this
Alfredo Braunstein wrote:
Could it be a locale problem?
Yes, seems so. The problem disappears when I switch LANG to en_US.
Jürgen.
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
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
environment? I do
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
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=[EMAIL
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 understand how
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:
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 those variables
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 what
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 en_US
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
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 -
@@
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
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 is
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
***
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
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
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
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 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
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
> > >
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
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
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
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
> "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
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?
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
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
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
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
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 =
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
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
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
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()
+
Alfredo Braunstein wrote:
> Could it be a locale problem?
Yes, seems so. The problem disappears when I switch LANG to en_US.
Jürgen.
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
> "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
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
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]"
> "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
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:
>> 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
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
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
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
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 -
@@
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
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
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
***
72 matches
Mail list logo
