[EMAIL PROTECTED] wrote:
> Attached is an example I cut down to something simple.
> I hope you accept attachments otherwise I will put it on one of my sites.
Attachments are fine, as long as they aren't too big.
There seem to be several problems in your file, the most severe is that the
paragrap
See
http://bugzilla.lyx.org/show_bug.cgi?id=3921
José, OK?
Jürgen
Index: INSTALL
===
--- INSTALL (Revision 19069)
+++ INSTALL (Arbeitskopie)
@@ -7,12 +7,12 @@
These four steps will compile, test and install LyX:
0) Linux users b
Bo Peng wrote:
> > 3. Rather TeX question - when typewriter font family is set, keywords are
> > no more bold (maybe it is not possible to typeset this font in bold,
> > dunno)
>
> This is quite likely.
You have to use a typewriter font that actually provides bold faces.
Jürgen
Pavel Sanda wrote:
> > Known problems... nobody has paid enough attention on them though.
>
> should i file new bug ?
No, this is bug 3582, I think.
Jürgen
> Known problems... nobody has paid enough attention on them though.
should i file new bug ?
> fillcolor=\color{red}
aha! '=' was the missing letter :))
> This is also a known bug (have to check bugzilla for bug number) that
> is, however, nontrivial to fix. My suggestion would be writing code
First thing - the box around inset has not length of the whole line.
Second - try to write some text and delete it - the box is not correctly
repainted
and the deleted letters remain displayed.
Known problems... nobody has paid enough attention on them though.
2. I would like to diff
You could disable the command window with the linker option /SUBSYSTEM:WINDOWS
Then, as far as I know, a command window will jump out whenever I run
some external command such as python that needs stdin/out.
Joost's lyx.exe/lyxc.exe solution is good enough.
BO
Hello,
I started to work with listings and some questions/problems appeared:
1. Wrong displaying
Launch LyX,
New File,
Help->Embedded Objects,
New File
Insert->Program Listing
First thing - the box around inset has not length of the whole line.
Second - try to write some text and delete it - the
Bo Peng wrote:
> On 7/13/07, Bo Peng <[EMAIL PROTECTED]> wrote:
>> Kind of randomly, but frequently, when lyx exists, a dialog shows up
>> and says:
>>
>> The instruction at )x0190f7b0 referenced memory at 0x6d729b1. The
>> memory could not be written. Click OK to terminate the program.
>
> Have n
On 7/13/07, Bo Peng <[EMAIL PROTECTED]> wrote:
Kind of randomly, but frequently, when lyx exists, a dialog shows up and says:
The instruction at )x0190f7b0 referenced memory at 0x6d729b1. The
memory could not be written. Click OK to terminate the program.
Have not finally confirmed, but this m
Sure it can, one time I had a command sequence that launched LyX, opened
the UserGuide, scrolled it to the end, and exit LyX at the end. You can
put any LFUN in this command-sequence.
and check if lyx crashes, and if the pasted text is what you cut? I
guess the long term goal (?) is having eithe
Bo Peng wrote:
LyX can be scripted too thanks to the LFUNs...
Then we need to write a bunch of scripts to convert back and forth,
move, select, cut, paste, save/load, new/close window although I
do not think lyx can be manipulated like that externally.
Sure it can, one time I had a comma
Attached is an example I cut down to something simple.
I hope you accept attachments otherwise I will put it on one of my sites.
Overview:
Older versions of LyX can create a DVI file of this example.
Newer versions such as 1.4.4 and later cannot and output a lot of
missing delimiters.
I am ver
LyX can be scripted too thanks to the LFUNs...
Then we need to write a bunch of scripts to convert back and forth,
move, select, cut, paste, save/load, new/close window although I
do not think lyx can be manipulated like that externally.
Bo
Bo Peng wrote:
On 7/13/07, Jürgen Spitzmüller
<[EMAIL PROTECTED]> wrote:
Abdelrazak Younes wrote:
> No, my patch is the right fix and I am responsible for this: in rev
> 19040, I eagerly erased two lines (++cur.pit() and --cur.pit()).
Well, then put it in again, before I'll release the dogs ;-)
Bo Peng wrote:
Just let me the time to switch my repository to trunk :-)
Just to confirm that your patch works. Please put it in.
It's in already :-)
Abdel.
Just let me the time to switch my repository to trunk :-)
Just to confirm that your patch works. Please put it in.
Bo
Dov Feldstern wrote:
Hi!
I have to stop working now, I'm going to be offline until tomorrow night.
Attached find the latest additions to the patch. Enrico, I think these
will solve the samples you sent me, and it seems to still work for the
RTL stuff. But I haven't had time to clean up the pa
On 7/13/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
Abdelrazak Younes wrote:
> No, my patch is the right fix and I am responsible for this: in rev
> 19040, I eagerly erased two lines (++cur.pit() and --cur.pit()).
Well, then put it in again, before I'll release the dogs ;-)
This makes me
Dov Feldstern wrote:
Enrico Forestieri wrote:
On Fri, Jul 13, 2007 at 02:48:49AM +0300, Dov Feldstern wrote:
I realized that with the partial solution, which fixed some cases,
other cases which used to work stopped working. So the only way to go
is to provide a complete solution for all cases
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
No, my patch is the right fix and I am responsible for this: in rev
19040, I eagerly erased two lines (++cur.pit() and --cur.pit()).
Well, then put it in again, before I'll release the dogs ;-)
Just let me the time to switch my repository to
> fix attached.
No, my patch is the right fix and I am responsible for this: in rev
19040, I eagerly erased two lines (++cur.pit() and --cur.pit()).
I produced exactly the same patch (5s later than you :-) ... please
commit if it works.
Cheers,
Bo
Abdelrazak Younes wrote:
> No, my patch is the right fix and I am responsible for this: in rev
> 19040, I eagerly erased two lines (++cur.pit() and --cur.pit()).
Well, then put it in again, before I'll release the dogs ;-)
Jürgen
Jürgen Spitzmüller wrote:
Bo Peng wrote:
Open the attached lyx file, move cursor to the end of the second line
(actually anywhere with pos > length of previous line). Edit ->
paragraph up, lyx crashes.
fix attached.
No, my patch is the right fix and I am responsible for this: in rev
19040,
Bo Peng wrote:
> > fix attached.
>
> This fixes the crash but I think the correct behavior should be
> keeping the cursor in its original paragraph and location, right?
That would be Abdel's patch.
Jürgen
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Obvious candidates for the brown paper bag:
http://www.lyx.org/trac/changeset/19057
Unlikely (this affects only LaTeX output).
http://www.lyx.org/trac/changeset/19046
Reverting this does not fix the crash.
I was wrong, see my other post
On 7/13/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
Bo Peng wrote:
> Open the attached lyx file, move cursor to the end of the second line
> (actually anywhere with pos > length of previous line). Edit ->
> paragraph up, lyx crashes.
fix attached.
This fixes the crash but I think the cor
I am investigating if there is a quick fix,... and Pavel says it is
introduced after rc2.
I guess it is something like:
P1: len 8
P2: len 20
Cursor: par = 2, pos = 20
after paragraph up
P1: len 20
P2: len 8
Cursor: par = 2, pos = 20
Fitcursor fails because pos > len. Looks like cursor needs
Bo Peng wrote:
> Open the attached lyx file, move cursor to the end of the second line
> (actually anywhere with pos > length of previous line). Edit ->
> paragraph up, lyx crashes.
fix attached.
Jürgen
Index: src/Text3.cpp
===
--- s
Abdelrazak Younes wrote:
> Obvious candidates for the brown paper bag:
>
> http://www.lyx.org/trac/changeset/19057
Unlikely (this affects only LaTeX output).
> http://www.lyx.org/trac/changeset/19046
Reverting this does not fix the crash.
Jürgen
Abdelrazak Younes wrote:
Bo Peng wrote:
Open the attached lyx file, move cursor to the end of the second line
(actually anywhere with pos > length of previous line). Edit ->
paragraph up, lyx crashes.
Can any one confirm?
Works fine with rev. 19044.
Wrong, I was using a release build with a
Jürgen Spitzmüller wrote:
Bo Peng wrote:
Open the attached lyx file, move cursor to the end of the second line
(actually anywhere with pos > length of previous line). Edit ->
paragraph up, lyx crashes.
Can any one confirm?
Yes. Please file a bug report.
With the frequency of crashes I am ex
> Can any one confirm?
Yes. Please file a bug report.
I am investigating if there is a quick fix,... and Pavel says it is
introduced after rc2.
Well, obviously, nobody used this function until now. I'm confident that more
crashes will come to our attention once 1.5.0 is released.
It is not
Bo Peng wrote:
Can any one confirm?
Confirmed under linux as well.
Obvious candidates for the brown paper bag:
http://www.lyx.org/trac/changeset/19057
http://www.lyx.org/trac/changeset/19046
#0 0x003dcd22e21d in raise () from /lib64/tls/libc.so.6
#1 0x003dcd22fa1e in abort () fr
Bo Peng wrote:
Open the attached lyx file, move cursor to the end of the second line
(actually anywhere with pos > length of previous line). Edit ->
paragraph up, lyx crashes.
Can any one confirm?
Works fine with rev. 19044.
Abdel.
Can any one confirm?
Confirmed under linux as well.
#0 0x003dcd22e21d in raise () from /lib64/tls/libc.so.6
#1 0x003dcd22fa1e in abort () from /lib64/tls/libc.so.6
#2 0x0096aee1 in lyx::support::abort () at src/support/abort.cpp:25
#3 0x004eda7b in boost::assertion_f
> Revision 19044 was perfect for me so it anything happened this must be
> after this revision. Could it be related to the recent locale/language
> problems?
recent locale/language patches were reverted from tree.
pavel
> Can any one confirm?
cant confirm with rc2.
can confirm with svn.
pavel
Bo Peng wrote:
> Open the attached lyx file, move cursor to the end of the second line
> (actually anywhere with pos > length of previous line). Edit ->
> paragraph up, lyx crashes.
>
> Can any one confirm?
Yes. Please file a bug report.
> With the frequency of crashes I am experiencing right now
Bo Peng wrote:
Kind of randomly, but frequently, when lyx exists, a dialog shows up and
says:
The instruction at )x0190f7b0 referenced memory at 0x6d729b1. The
memory could not be written. Click OK to terminate the program.
Revision 19044 was perfect for me so it anything happened this must b
Open the attached lyx file, move cursor to the end of the second line
(actually anywhere with pos > length of previous line). Edit ->
paragraph up, lyx crashes.
Can any one confirm?
With the frequency of crashes I am experiencing right now, I am
wondering if lyx 1.5.0 is really ready. :-(
Bo
Kind of randomly, but frequently, when lyx exists, a dialog shows up and says:
The instruction at )x0190f7b0 referenced memory at 0x6d729b1. The
memory could not be written. Click OK to terminate the program.
Cheers,
Bo
example.lyx
Description: application/lyx
José Matos wrote:
> This is not in the patch, is this already in?
> The patch only shows the addition of __FreeBSD_kernel__ test.
No, it replaces __FREEBSD__ with __FreeBSD__. I didn't know it is so (and
actually I didn't find a reference), but obviously the case matters.
> > José, can this
On Friday 13 July 2007 13:41:20 Jürgen Spitzmüller wrote:
> The attached patch seems to fix that bug finally, as Koji Yokota confirmed.
>
> Actually, I'm not sure defined(__FreeBSD_kernel__) is really needed -- this
> basically identifies GNU/kFreeBSD (that doesn't have __FreeBSD__ defined).
It
Enrico Forestieri wrote:
On Fri, Jul 13, 2007 at 02:48:49AM +0300, Dov Feldstern wrote:
I realized that with the partial solution, which fixed some cases, other
cases which used to work stopped working. So the only way to go is to
provide a complete solution for all cases (well, maybe not *all
[EMAIL PROTECTED] schrieb:
Modified: lyx-devel/trunk/po/POTFILES.in
URL: http://www.lyx.org/trac/file/lyx-devel/trunk/po/POTFILES.in?rev=19056
==
--- lyx-devel/trunk/po/POTFILES.in (original)
+++ lyx-devel/trunk/po/POTFIL
José Matos schrieb:
On Wednesday 11 July 2007 18:13:26 Michael Gerz wrote:
Hi,
once again, I would like to draw your attention to the attached patch.
It fixes a serious problem with change-tracked output (text inside
deleted insets appears as unchanged text).
Could someone please have a loo
The attached patch seems to fix that bug finally, as Koji Yokota confirmed.
Actually, I'm not sure defined(__FreeBSD_kernel__) is really needed -- this
basically identifies GNU/kFreeBSD (that doesn't have __FreeBSD__ defined).
The actual problem apparently was the casing of the macro.
José, can
I have tried to address Georg's and Juergen's comments.
To avoid data-loss, the function is only run if the encoding is auto
or default and there are no language changes (overly conservative,
but possible to work around, as commented in the code). Now, I
*assume* this should prevent any case
> The exception is thrown by the locale constructor, not when the
> ordering is performed.
are you sure this holds for all previous crashes ?
but even if this is not true, we can add one 'idle' call
of loc() inside try block which would catch it beforehead.
pavel
On Thu, Jul 12, 2007 at 05:15:38PM +0100, José Matos wrote:
> On Thursday 12 July 2007 13:59:08 Jean-Marc Lasgouttes wrote:
> > Java?
> >
> > JMarc
>
> Python is more likely. ;-)
Curses -- and that's not entirely a joke.
- Martin
On Thu, Jul 12, 2007 at 06:02:43PM +0200, Andre Poenitz wrote:
> On Thu, Jul 12, 2007 at 09:00:57AM +0300, Martin Vermeer wrote:
> > > > We have bedlinen and towels and all... but do bring as many
> > > > laptops as you can, with ethernet cables / wireless cards,
> > > > and a spare hub or ADSL mod
On Fri, Jul 13, 2007 at 02:48:49AM +0300, Dov Feldstern wrote:
> I realized that with the partial solution, which fixed some cases, other
> cases which used to work stopped working. So the only way to go is to
> provide a complete solution for all cases (well, maybe not *all*...).
> That's what
Hi,
On 12.07.2007, at 15:41, Jean-Marc Lasgouttes wrote:
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
OK, then here is the patch that I propose to apply. What it does:
I applied this patch.
JMarc
I get the following linker error when building with rev. 19063:
/bin/sh ../libtool --tag
Hi
w.r.t. bug 1820, I'm getting very confused about what constitutes a
format change and what does not.
Generally, I think, a format change is when given an existing file F, I
used to get latex output X, and due to a change in LyX I now get latex
output Y. In such a case, we normally have ly
Enrico Forestieri wrote:
On Fri, Jul 13, 2007 at 03:05:39AM +0300, Dov Feldstern wrote:
Enrico Forestieri wrote:
On Fri, Jul 13, 2007 at 02:31:05AM +0300, Dov Feldstern wrote:
Enrico Forestieri wrote:
With your patch applied, when I mark as english the footnote content
I correctly see a \sele
Enrico Forestieri wrote:
On Fri, Jul 13, 2007 at 03:21:42AM +0300, Dov Feldstern wrote:
Dov Feldstern wrote:
Enrico Forestieri wrote:
On Fri, Jul 13, 2007 at 02:31:05AM +0300, Dov Feldstern wrote:
Enrico Forestieri wrote:
With your patch applied, when I mark as english the footnote
content I
On Fri, 2007-07-13 at 11:37 +1000, Roger Mc Murtrie wrote:
> Intel Mac, Mac OS X 10.4.10
>
> Under latest lyx-1.5.0svn:
> Start LyX
> Open a Lyx file
> Select View>PDF (pdflatex)
>
> Spinning ball cursor appears for a while
> LyX crashes.
>
> This also occurs after LyX>Reconfigure.
I just tried
59 matches
Mail list logo
