can someone confirm?
- open new doc
- choose document-class-book(koma class)
- choose document-language-spanish
- write a word
- dvi-view gives an error
the command
\addto\extrasspanish{\bbl@deactivate{~}}
is unknown
Herbert
--
http://www.lyx.org/help/
-BEGIN PGP SIGNED MESSAGE-
On Thursday 16 May 2002 18:53, Herbert Voss wrote:
can someone confirm?
No, working here.
Kornel
- --
Kornel Benko
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: PGP 6.5.8
iQCVAwUBPOQRZbewfbDGmeqhAQGD0AQAiWs0Vcrb+9Z2qSkkFirMDidcToKfnNyt
Kornel Benko wrote:
-BEGIN PGP SIGNED MESSAGE-
On Thursday 16 May 2002 18:53, Herbert Voss wrote:
can someone confirm?
No, working here.
ok, I see,
thanks
Herbert
--
http://www.lyx.org/help/
can someone confirm?
- open new doc
- choose document->class->book(koma class)
- choose document->language->spanish
- write a word
-> dvi-view gives an error
the command
\addto\extrasspanish{\bbl@deactivate{~}}
is unknown
Herbert
--
http://www.lyx.org/help/
-BEGIN PGP SIGNED MESSAGE-
On Thursday 16 May 2002 18:53, Herbert Voss wrote:
> can someone confirm?
No, working here.
Kornel
- --
Kornel Benko
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: PGP 6.5.8
iQCVAwUBPOQRZbewfbDGmeqhAQGD0AQAiWs0Vcrb+9Z2qSkkFirMDidcToKfnNyt
Kornel Benko wrote:
> -BEGIN PGP SIGNED MESSAGE-
>
> On Thursday 16 May 2002 18:53, Herbert Voss wrote:
>
>>can someone confirm?
>>
>
> No, working here.
ok, I see,
thanks
Herbert
--
http://www.lyx.org/help/
On 09-Apr-2002 Jean-Marc Lasgouttes wrote:
Would having prepareFile return RemoveExtension(filename_) fix this?
Of course the converted files should be generated in /tmp in this
case. However this gives rise to the same complications as in
insetinclude. So this is more work.
I think we
Juergen == Juergen Vigna [EMAIL PROTECTED] writes:
Juergen I think we should generate files always in the tmp dir. We
Juergen never should generate temporary files in another dir (also if
Juergen use_tempdir is false). I understand that someone could wish
Juergen to have all it's LaTeX
On 10-Apr-2002 Jean-Marc Lasgouttes wrote:
Juergen == Juergen Vigna [EMAIL PROTECTED] writes:
Juergen I think we should generate files always in the tmp dir. We
Juergen never should generate temporary files in another dir (also if
Juergen use_tempdir is false). I understand that someone
Juergen == Juergen Vigna [EMAIL PROTECTED] writes:
Juergen On 10-Apr-2002 Jean-Marc Lasgouttes wrote:
Juergen == Juergen Vigna [EMAIL PROTECTED] writes:
Juergen I think we should generate files always in the tmp dir. We
Juergen never should generate temporary files in another dir (also if
On 10-Apr-2002 Jean-Marc Lasgouttes wrote:
Juergen Is it possible to add a search path as a LaTeX command to the
Juergen single LaTeX file? So that for example all external filenames
Juergen inside the LaTeX file are without path.
This is what the \input@path macro does, if I understand
Juergen == Juergen Vigna [EMAIL PROTECTED] writes:
Juergen On 10-Apr-2002 Jean-Marc Lasgouttes wrote:
Juergen Is it possible to add a search path as a LaTeX command to the
Juergen single LaTeX file? So that for example all external filenames
Juergen inside the LaTeX file are without path.
On 09-Apr-2002 Jean-Marc Lasgouttes wrote:
> Would having prepareFile return RemoveExtension(filename_) fix this?
>
> Of course the converted files should be generated in /tmp in this
> case. However this gives rise to the same complications as in
> insetinclude. So this is more work.
I think
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
Juergen> I think we should generate files always in the tmp dir. We
Juergen> never should generate temporary files in another dir (also if
Juergen> use_tempdir is false). I understand that someone could wish
Juergen> to have all it's
On 10-Apr-2002 Jean-Marc Lasgouttes wrote:
>> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
>
> Juergen> I think we should generate files always in the tmp dir. We
> Juergen> never should generate temporary files in another dir (also if
> Juergen> use_tempdir is false). I
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
Juergen> On 10-Apr-2002 Jean-Marc Lasgouttes wrote:
>>> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
>>
Juergen> I think we should generate files always in the tmp dir. We
Juergen> never should generate temporary files in
On 10-Apr-2002 Jean-Marc Lasgouttes wrote:
> Juergen> Is it possible to add a search path as a LaTeX command to the
> Juergen> single LaTeX file? So that for example all external filenames
> Juergen> inside the LaTeX file are without path.
>
> This is what the \input@path macro does, if I
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
Juergen> On 10-Apr-2002 Jean-Marc Lasgouttes wrote:
Juergen> Is it possible to add a search path as a LaTeX command to the
Juergen> single LaTeX file? So that for example all external filenames
Juergen> inside the LaTeX file are
Herbert == Herbert Voss [EMAIL PROTECTED] writes:
Herbert the patch
Herbert http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg35477.html
Herbert is buggy when you insert a graphic file which is in a deeper
Herbert dir than the one from the doc. In this case the absolut path
Herbert is
Jean-Marc Lasgouttes wrote:
Herbert == Herbert Voss [EMAIL PROTECTED] writes:
Herbert the patch
Herbert http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg35477.html
Herbert is buggy when you insert a graphic file which is in a deeper
Herbert dir than the one from the doc. In this
Herbert == Herbert Voss [EMAIL PROTECTED] writes:
But why does latex search in the tmp dir? We give it a nice
\input@path to tell that it should also look in the doc dir.
Herbert this belongs to non-(e)ps-files which were converted.
Could you explain a bit more?
JMarc
Jean-Marc Lasgouttes wrote:
Herbert == Herbert Voss [EMAIL PROTECTED] writes:
But why does latex search in the tmp dir? We give it a nice
\input@path to tell that it should also look in the doc dir.
Herbert this belongs to non-(e)ps-files which were converted.
Could you explain a bit
Herbert == Herbert Voss [EMAIL PROTECTED] writes:
Herbert open a new doc and insert a graphic which is two dirs deeper
Herbert than the doc dir.
[...]
Herbert hope, this helps
I guess it does, but I do not know when I will have time to
investigate this.
JMarc
Jean-Marc Lasgouttes wrote:
Herbert == Herbert Voss [EMAIL PROTECTED] writes:
Herbert open a new doc and insert a graphic which is two dirs deeper
Herbert than the doc dir.
[...]
Herbert hope, this helps
I guess it does, but I do not know when I will have time to
investigate this.
Herbert == Herbert Voss [EMAIL PROTECTED] writes:
Herbert Jean-Marc Lasgouttes wrote:
Herbert == Herbert Voss [EMAIL PROTECTED]
writes:
But why does latex search in the tmp dir? We give it a nice
\input@path to tell that it should also look in the doc dir.
Herbert this belongs to
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
Herbert> the patch
Herbert> http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg35477.html
Herbert> is buggy when you insert a graphic file which is in a deeper
Herbert> dir than the one from the doc. In this case the absolut path
Jean-Marc Lasgouttes wrote:
>>"Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
>>
>
> Herbert> the patch
> Herbert> http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg35477.html
>
> Herbert> is buggy when you insert a graphic file which is in a deeper
> Herbert> dir than the
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
>> But why does latex search in the tmp dir? We give it a nice
>> \input@path to tell that it should also look in the doc dir.
Herbert> this belongs to non-(e)ps-files which were converted.
Could you explain a bit more?
JMarc
Jean-Marc Lasgouttes wrote:
>>"Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
>>
>
>>>But why does latex search in the tmp dir? We give it a nice
>>>\input@path to tell that it should also look in the doc dir.
>>>
>
>
> Herbert> this belongs to non-(e)ps-files which were
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
Herbert> open a new doc and insert a graphic which is two dirs deeper
Herbert> than the doc dir.
[...]
Herbert> hope, this helps
I guess it does, but I do not know when I will have time to
investigate this.
JMarc
Jean-Marc Lasgouttes wrote:
>>"Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
>>
>
> Herbert> open a new doc and insert a graphic which is two dirs deeper
> Herbert> than the doc dir.
> [...]
> Herbert> hope, this helps
>
> I guess it does, but I do not know when I will have time
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
Herbert> Jean-Marc Lasgouttes wrote:
>>> "Herbert" == Herbert Voss <[EMAIL PROTECTED]>
>>> writes:
>>>
>>
But why does latex search in the tmp dir? We give it a nice
\input@path to tell that it should also look in
the patch
http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg35477.html
is buggy when you insert a graphic file which is in a deeper dir
than the one from the doc. In this case the absolut path is missing,
the converted image is written into the doc dir and latex fails,
because it searchs
the patch
http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg35477.html
is buggy when you insert a graphic file which is in a deeper dir
than the one from the doc. In this case the absolut path is missing,
the converted image is written into the doc dir and latex fails,
because it searchs
can anybody confirm?
- insert float
- insert into the float a graphic
- and insert a caption
- save and close
- reopen
--- the caption is outside the float
this happens only for graphic insets.
Herbert
--
http://www.lyx.org/help/
On Sat, Mar 23, 2002 at 06:23:38PM +0100, Herbert Voss wrote:
- insert float
- insert into the float a graphic
- and insert a caption
- save and close
- reopen
--- the caption is outside the float
no, I can't spot any problems like this ...
john
--
Way back at the beginning of time
John Levon wrote:
On Sat, Mar 23, 2002 at 06:23:38PM +0100, Herbert Voss wrote:
- insert float
- insert into the float a graphic
- and insert a caption
- save and close
- reopen
--- the caption is outside the float
no, I can't spot any problems like this ...
thanks, than it's my own
can anybody confirm?
- insert float
- insert into the float a graphic
- and insert a caption
- save and close
- reopen
---> the caption is outside the float
this happens only for graphic insets.
Herbert
--
http://www.lyx.org/help/
On Sat, Mar 23, 2002 at 06:23:38PM +0100, Herbert Voss wrote:
> - insert float
> - insert into the float a graphic
> - and insert a caption
> - save and close
> - reopen
> ---> the caption is outside the float
no, I can't spot any problems like this ...
john
--
"Way back at the beginning of
John Levon wrote:
> On Sat, Mar 23, 2002 at 06:23:38PM +0100, Herbert Voss wrote:
>
>
>>- insert float
>>- insert into the float a graphic
>>- and insert a caption
>>- save and close
>>- reopen
>>---> the caption is outside the float
>>
>
> no, I can't spot any problems like this ...
/tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.dvi
9 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.log
3144 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.ps
21 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.tex
3 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.tex.dep
Is this problem due to a bug in CVS
It would seem that another latex run may be needed to fill in the
labels. Check the latex log file to see if there are any error
messages in the log. Also check to see if a warning line exists that
says something like need another latex run as this is also used to
trigger additional latex
R. Lahaye wrote:
the references themselves appear as question-marks in the text [?]
Sorry, my mistake. I had a look at the LaTeX log file and two equations
were labeled with exactly the same label. For some reason that skrewed
up the referencing table (why?).
Removing one of the equation
On Wed, 13 Feb 2002, R. Lahaye wrote:
R. Lahaye wrote:
the references themselves appear as question-marks in the text [?]
Sorry, my mistake. I had a look at the LaTeX log file and two equations
were labeled with exactly the same label. For some reason that skrewed
up the referencing
A.blg
29 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.dvi
9 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.log
3144 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.ps
21 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.tex
3 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.tex.dep
Is this problem du
It would seem that another latex run may be needed to fill in the
labels. Check the latex log file to see if there are any error
messages in the log. Also check to see if a warning line exists that
says something like "need another latex run" as this is also used to
trigger additional latex
R. Lahaye wrote:
>
> the references themselves appear as question-marks in the text [?]
Sorry, my mistake. I had a look at the LaTeX log file and two equations
were labeled with exactly the same label. For some reason that skrewed
up the referencing table (why?).
Removing one of the equation
On Wed, 13 Feb 2002, R. Lahaye wrote:
> R. Lahaye wrote:
> >
> > the references themselves appear as question-marks in the text [?]
>
> Sorry, my mistake. I had a look at the LaTeX log file and two equations
> were labeled with exactly the same label. For some reason that skrewed
> up the
This constructor passes an un-initialised pos to insertStringAsLines. I
presume it should be initialised to 0?
This causes an assert failure down in Pragraph::pimpl::insertChar().
// This constructor is used for reading old InsetInfo
InsetNote::InsetNote(Buffer const * buf, string const
On Thu, Nov 29, 2001 at 03:47:50AM +1100, Ben Stanley wrote:
This constructor passes an un-initialised pos to insertStringAsLines. I
presume it should be initialised to 0?
Gasp! Yes. Certainly. And it used to be. My fault.
I can even explain how this evolved... but I'll try to fix it first.
On Thu, Nov 29, 2001 at 03:47:50AM +1100, Ben Stanley wrote:
This constructor passes an un-initialised pos to insertStringAsLines. I
presume it should be initialised to 0?
And now to the explanation: I saw the useless variable, removed it. Then
noticed that the parameter was passed by
Andre Poenitz wrote:
On Thu, Nov 29, 2001 at 03:47:50AM +1100, Ben Stanley wrote:
This constructor passes an un-initialised pos to insertStringAsLines. I
presume it should be initialised to 0?
And now to the explanation: I saw the useless variable, removed it. Then
noticed that the parameter
On Thu, Nov 29, 2001 at 04:15:29AM +1100, Ben Stanley wrote:
I propose a grep for lyx::pos_type and a double check...
Guess what I did the last ten minutes...
Andre'
--
André Pönitz .. [EMAIL PROTECTED]
This constructor passes an un-initialised pos to insertStringAsLines. I
presume it should be initialised to 0?
This causes an assert failure down in Pragraph::pimpl::insertChar().
// This constructor is used for reading old InsetInfo
InsetNote::InsetNote(Buffer const * buf, string const &
On Thu, Nov 29, 2001 at 03:47:50AM +1100, Ben Stanley wrote:
> This constructor passes an un-initialised pos to insertStringAsLines. I
> presume it should be initialised to 0?
Gasp! Yes. Certainly. And it used to be. My fault.
I can even explain how this evolved... but I'll try to fix it
On Thu, Nov 29, 2001 at 03:47:50AM +1100, Ben Stanley wrote:
> This constructor passes an un-initialised pos to insertStringAsLines. I
> presume it should be initialised to 0?
And now to the explanation: I saw the "useless" variable, removed it. Then
noticed that the parameter was passed by
Andre Poenitz wrote:
>On Thu, Nov 29, 2001 at 03:47:50AM +1100, Ben Stanley wrote:
>
>>This constructor passes an un-initialised pos to insertStringAsLines. I
>>presume it should be initialised to 0?
>>
>
>And now to the explanation: I saw the "useless" variable, removed it. Then
>noticed that
On Thu, Nov 29, 2001 at 04:15:29AM +1100, Ben Stanley wrote:
> I propose a grep for lyx::pos_type and a double check...
Guess what I did the last ten minutes...
Andre'
--
André Pönitz .. [EMAIL PROTECTED]
On Sat, Sep 08, 2001 at 07:02:44AM +0200, Herbert Voss wrote:
in a displayed formula a fraction should be in displaystyle,
but it's in scriptstyle in dvi output.
This is nigh to impossible... This would mean I'd explicitly write a
\scriptstyle on output which I certainly don't.
How does the
On Sat, Sep 08, 2001 at 07:02:44AM +0200, Herbert Voss wrote:
> in a displayed formula a fraction should be in displaystyle,
> but it's in scriptstyle in dvi output.
This is nigh to impossible... This would mean I'd explicitly write a
\scriptstyle on output which I certainly don't.
How does the
in a displayed formula a fraction should be in displaystyle,
but it's in scriptstyle in dvi output. on screen the
charactersize is correct.
Herbert
--
http://www.educat.hu-berlin.de/~voss/lyx/
in a displayed formula a fraction should be in displaystyle,
but it's in scriptstyle in dvi output. on screen the
charactersize is correct.
Herbert
--
http://www.educat.hu-berlin.de/~voss/lyx/
1.1.6fix3:
in an equnarray you can delete the lower right cell.
the formula than looks like
\begin_inset Formula \begin{eqnarray*}
11 21 31\\
21 22 23\\
31 32 - missing cell!
\end{eqnarray*}
\end_inset
in 1.1.6 this doesn't matter, the lyxfile is always
read well.
reading
Andre Poenitz wrote:
1.1.6fix3:
in an equnarray you can delete the lower right cell.
the formula than looks like
\begin_inset Formula \begin{eqnarray*}
11 21 31\\
21 22 23\\
31 32 - missing cell!
\end{eqnarray*}
\end_inset
But that's no well formed
sure! but it was lyx which allowed the user to do that!
and btw: it's no problem to run this with latex! means
it's allowed latex stuff ...
Ok. I did not know that, so this has to be fixed indeed.
It would be pretty difficult to parse bad input, given that it's already a
pain to parse
| reading this formula with 1.2.0 gives always the message
| that the file may be corrupted (truncated).
| so far so good, but lyx ignores all the text behind
| this formula.
so the formula parser does not read (and remove) the \end_inset...
It ignores after its own end everything up to
(if I understands this correctly)... yes why not.
...but to avoid rewriting anything in the parser, output it into a
ostringstream and pass that to the parser just as usual.
That would be the simple solution. Indeed.
Andre'
--
André Pönitz .
1.1.6fix3:
in an equnarray you can delete the lower right cell.
the formula than looks like
\begin_inset Formula \begin{eqnarray*}
11 & 21 & 31\\
21 & 22 & 23\\
31 & 32 <- missing cell!
\end{eqnarray*}
\end_inset
in 1.1.6 this doesn't matter, the lyxfile is always
read well.
Andre Poenitz wrote:
>
> > 1.1.6fix3:
> > in an equnarray you can delete the lower right cell.
> > the formula than looks like
> >
> > \begin_inset Formula \begin{eqnarray*}
> > 11 & 21 & 31\\
> > 21 & 22 & 23\\
> > 31 & 32 <- missing cell!
> > \end{eqnarray*}
> >
> > \end_inset
> >
> sure! but it was lyx which allowed the user to do that!
> and btw: it's no problem to run this with latex! means
> it's allowed latex stuff ...
Ok. I did not know that, so this has to be fixed indeed.
> > It would be pretty difficult to parse bad input, given that it's already a
> > pain to
> | reading this formula with 1.2.0 gives always the message
> | that the file may be corrupted (truncated).
> | so far so good, but lyx ignores all the text behind
> | this formula.
>
> so the formula parser does not read (and remove) the \end_inset...
It ignores after its own end everything
> (if I understands this correctly)... yes why not.
>
> ...but to avoid rewriting anything in the parser, output it into a
> ostringstream and pass that to the parser just as usual.
That would be the simple solution. Indeed.
Andre'
--
André Pönitz
On Monday 28 May 2001 08:52, Kayvan A. Sylvan wrote:
I can't add/modify converters using the Edit-Preferences screens,
I had to add them by hand into my .lyx/preferences.
Fixed now!
Angus
On Tue, Jun 12, 2001 at 12:36:36PM +0100, Angus Leeming wrote:
On Monday 28 May 2001 08:52, Kayvan A. Sylvan wrote:
I can't add/modify converters using the Edit-Preferences screens,
I had to add them by hand into my .lyx/preferences.
Fixed now!
Angus
while we're on this, we need
On Monday 28 May 2001 08:52, Kayvan A. Sylvan wrote:
> I can't add/modify converters using the Edit->Preferences screens,
> I had to add them by hand into my .lyx/preferences.
Fixed now!
Angus
On Tue, Jun 12, 2001 at 12:36:36PM +0100, Angus Leeming wrote:
> On Monday 28 May 2001 08:52, Kayvan A. Sylvan wrote:
> > I can't add/modify converters using the Edit->Preferences screens,
> > I had to add them by hand into my .lyx/preferences.
>
> Fixed now!
> Angus
while we're on this, we
I can't add/modify converters using the Edit-Preferences screens,
I had to add them by hand into my .lyx/preferences.
---Kayvan
--
Kayvan A. Sylvan | Proud husband of | Father to my kids:
Sylvan Associates, Inc.| Laura Isabella Sylvan |
I can't add/modify converters using the Edit->Preferences screens,
I had to add them by hand into my .lyx/preferences.
---Kayvan
--
Kayvan A. Sylvan | Proud husband of | Father to my kids:
Sylvan Associates, Inc.| Laura Isabella Sylvan
On Thu, Sep 28, 2000 at 11:40:22PM +0300, Dekel Tsur wrote:
The problem is in Intl::InitKeyMapper: Since the "default" language is
removed, n should be initialized to 0.
This reminds me that I plan to add automatic keymap switching according to
the current language (this is currently done with
On Thu, Sep 28, 2000 at 11:40:22PM +0300, Dekel Tsur wrote:
> The problem is in Intl::InitKeyMapper: Since the "default" language is
> removed, n should be initialized to 0.
This reminds me that I plan to add automatic keymap switching according to
the current language (this is currently done
"Dekel" == Dekel Tsur [EMAIL PROTECTED] writes:
Dekel But why sel is 0 ? The problem is in Intl::InitKeyMapper: Since
Dekel the "default" language is removed, n should be initialized to
Dekel 0. I've attached a patch that does both fixes.
Applied.
JMarc
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes:
Dekel> But why sel is 0 ? The problem is in Intl::InitKeyMapper: Since
Dekel> the "default" language is removed, n should be initialized to
Dekel> 0. I've attached a patch that does both fixes.
Applied.
JMarc
Andre Poenitz [EMAIL PROTECTED] writes:
| #3 0x815ec58 in lyx::abort () at abort.C:9
| #4 0x8163b0c in lyxstring::lyxstring (this=0xba4c, s=0x0) at LAssert.h:24
| ^ This causes
|
On Thu, Sep 28, 2000 at 05:49:02PM +0200, Lars Gullik Bjnnes wrote:
| The actual problem is here:
|
| #5 0x8088589 in Intl::KeyMapPrim (this=0x81fb8a0) at combox.h:224
|
| This line should read:
|
| return browser ? fl_get_browser_line(browser, sel) : string();
|
| instead
Andre Poenitz <[EMAIL PROTECTED]> writes:
| > #3 0x815ec58 in lyx::abort () at abort.C:9
| > #4 0x8163b0c in lyxstring::lyxstring (this=0xba4c, s=0x0) at LAssert.h:24
| > ^ This causes
| >
On Thu, Sep 28, 2000 at 05:49:02PM +0200, Lars Gullik Bjnnes wrote:
> | The actual problem is here:
> |
> | > #5 0x8088589 in Intl::KeyMapPrim (this=0x81fb8a0) at combox.h:224
> |
> | This line should read:
> |
> | return browser ? fl_get_browser_line(browser, sel) : string();
> |
> |
When \kbmap is true, LyX crashes on startup. This bug is very recent (last day
or two).
The backtrace:
#0 0x401e1a01 in kill ()
#1 0x401e1863 in gsignal ()
#2 0x401e28c5 in abort ()
#3 0x815ec58 in lyx::abort () at abort.C:9
#4 0x8163b0c in lyxstring::lyxstring (this=0xba4c, s=0x0) at
#3 0x815ec58 in lyx::abort () at abort.C:9
#4 0x8163b0c in lyxstring::lyxstring (this=0xba4c, s=0x0) at LAssert.h:24
^ This causes
the crash
If lyxstring really
When \kbmap is true, LyX crashes on startup. This bug is very recent (last day
or two).
The backtrace:
#0 0x401e1a01 in kill ()
#1 0x401e1863 in gsignal ()
#2 0x401e28c5 in abort ()
#3 0x815ec58 in lyx::abort () at abort.C:9
#4 0x8163b0c in lyxstring::lyxstring (this=0xba4c, s=0x0) at
> #3 0x815ec58 in lyx::abort () at abort.C:9
> #4 0x8163b0c in lyxstring::lyxstring (this=0xba4c, s=0x0) at LAssert.h:24
> ^ This causes
> the crash
If lyxstring really
Michael Schmitt [EMAIL PROTECTED] writes:
| I opened a couple of files (it seems like two are not sufficient), made
| _no_ changes, then opened one of them again (reloaded).
Is this repeatable?
And this is the the cvs version, right?
| FMR: Free memory read
| This is occurring
Michael Schmitt [EMAIL PROTECTED] writes:
| Hi,
|
| yet another bug report.
Can you have a look at this Jürgen?
Lgb
Michael Schmitt [EMAIL PROTECTED] writes:
| UMR: Uninitialized memory read (2 times)
| This is occurring while in:
| bool MathedXIter::Next() [math_iter.C:632]
Ok, should be fixed now.
Lgb
Michael Schmitt [EMAIL PROTECTED] writes:
| I got another warning when clicking at the end of the loaded document:
|
| UMR: Uninitialized memory read
| This is occurring while in:
| int
| WorkArea::work_area_handler(flobjs_*,int,int,int,int,void*)
| [WorkArea.C:299]
Michael Schmitt <[EMAIL PROTECTED]> writes:
| I opened a couple of files (it seems like two are not sufficient), made
| _no_ changes, then opened one of them again (reloaded).
Is this repeatable?
And this is the the cvs version, right?
| FMR: Free memory read
| This is occurring
Michael Schmitt <[EMAIL PROTECTED]> writes:
| Hi,
|
| yet another bug report.
Can you have a look at this Jürgen?
Lgb
Michael Schmitt <[EMAIL PROTECTED]> writes:
| UMR: Uninitialized memory read (2 times)
| This is occurring while in:
| bool MathedXIter::Next() [math_iter.C:632]
Ok, should be fixed now.
Lgb
Michael Schmitt <[EMAIL PROTECTED]> writes:
| I got another warning when clicking at the end of the loaded document:
|
| UMR: Uninitialized memory read
| This is occurring while in:
| int
| WorkArea::work_area_handler(flobjs_*,int,int,int,int,void*)
| [WorkArea.C:299]
Hi,
despite the most recent fixes there is still a problem with cutting a
region covering two paragraphs:
FMR: Free memory read
This is occurring while in:
LyXParagraph*LyXParagraph::Next() [paragraph.C:1197]
void LyXText::CutSelection(bool) [text2.C:2227]
Hi,
importing the ascii file README (from lyx) results in the following
message:
UMR: Uninitialized memory read
This is occurring while in:
void LyXText::SetSelection() [text2.C:1024]
int BufferView::Pimpl::resizeCurrentBuffer()
[BufferView_pimpl.C:260]
1 - 100 of 140 matches
Mail list logo
