On Thu, 2006-02-02 at 00:35 +0100, Helge Hafting wrote:
...
Try the above, works for me. Or wait for a *really* carefully produced
patch Real Soon Now.
Think I have to wait for that patch, for this didn't change anything at all.
footnotes, margin notes and table cells still believe they
Activate math mode. Type 2^Q. Select it, then use the math panel and
change the font to normal text mode \textrm
Note that view-dvi fails, as lyx now generates invalid latex.
The bug exists in lyx 1.3 too, where it also happen when you
write 2^Q as text and then selects it and converts it to
Georg Baum wrote:
This patch adds removal of branch insets to lyx2lyx. It is not very
sophisticated (it would probably not be too difficult to replace branches
with booleans and the ifthen package), and it can produce empty
paragraphs, but it is good enough for 1.4.0 IMO.
Please test.
Do
Michael Gerz wrote:
Do it mean there is a need for LyX 1.3.8?
Please don't even think about a 1.3.8 release unless a really critical bug
is discovered. We should rather have bug 2174 fixed in 1.4.0.
Georg
Martin Vermeer wrote:
Attached. Hopefully more luck this time.
This is much better!
I have tested with text, footnote, marginal note, branch, ERT, float,
table and minipage.
All of them uses correct language now, there are no wrong blue lines or L-
cursors.
There is still the smaller
Georg Baum wrote:
Does it work if you put the lyx backend in the first position
Yes, it works then.
Couldn't we do something like: use the first backend available (as it is
now), BUT if the from format is equal to any other backend, then use that?
Jürgen
Juergen Spitzmueller wrote:
Georg Baum wrote:
Does it work if you put the lyx backend in the first position
Yes, it works then.
Fine.
Couldn't we do something like: use the first backend available (as it is
now), BUT if the from format is equal to any other backend, then use
that?
The
Georg Baum wrote:
The problem is that we don't know from at that point :-(
I see.
I have implemented an experimental getShortestPath() method that could be
used instead of getPath() and the loop. The problem is that this might
influence other conversions, so it is too risky to do it now.
I
samar j. singh wrote:
I know exactly what I was doing when it crashed. That was putting the
cursor on the scroll bars to move up the document. At the point when I
attempted to move the scroll bar up with the mouse, Lyx immediately crashed
providing the followiing output.
Seems that the cursor
Georg Baum wrote:
Please test.
It works for me except for one drawback: the content of branches is always
placed in a new paragraph, even if the branch was inline. If it is easy to
fix, I'd appreciate that, since I use branches almost always inline.
Thanks,
Jürgen
On Thursday 02 February 2006 16:25, Juergen Spitzmueller wrote:
samar j. singh wrote:
I know exactly what I was doing when it crashed. That was putting the
cursor on the scroll bars to move up the document. At the point when I
attempted to move the scroll bar up with the mouse, Lyx
samar j. singh wrote:
Yes, indeed, I have. Have undone it now. I think your hypothesis may be
consistent with the previous correlation with the pageup/down use as that
would also cause the cursor to be repositioned. However, how come this
cannot be replicated consistently. That probably
On Thu, 2006-02-02 at 11:13 +0100, Helge Hafting wrote:
Martin Vermeer wrote:
Attached. Hopefully more luck this time.
This is much better!
I have tested with text, footnote, marginal note, branch, ERT, float,
table and minipage.
All of them uses correct language now, there are no
Martin Vermeer wrote:
Hmmm. Actually this is straightforwardly fixable. It's just a policy
choice, how we understand noFontChange(). See attached. Only text.C and
rowpainter.C were changed. Works for me... 1.3 does it this way too (in
fact, it has *only* noFontChange-type insets; but language
On Thu, 2006-02-02 at 13:47 +0100, Helge Hafting wrote:
Martin Vermeer wrote:
Hmmm. Actually this is straightforwardly fixable. It's just a policy
choice, how we understand noFontChange(). See attached. Only text.C and
rowpainter.C were changed. Works for me... 1.3 does it this way too (in
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin Jean-Marc, I think this is the version of reference to review.
Martin (Do we still make 1.4.0, or shall we play safe? But it's quite
Martin irritating as it is. Do we want the possible embarrassment or
Martin the certain annoyance?)
On Thursday 02 February 2006 17:00, Juergen Spitzmueller wrote:
samar j. singh wrote:
Yes, indeed, I have. Have undone it now. I think your hypothesis may be
consistent with the previous correlation with the pageup/down use as that
would also cause the cursor to be repositioned. However,
samar j. singh wrote:
If you can explain the characteristics of a closed collapsible inset I
might get an idea of the type of thing to target in the document that
would create this.
A collapsable inset is one that you can open or close, e.g. a minipage/box,
a float, or ERT. In closed form it
On Thu, Feb 02, 2006 at 04:56:39PM +0100, Jean-Marc Lasgouttes wrote:
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin Jean-Marc, I think this is the version of reference to review.
Martin (Do we still make 1.4.0, or shall we play safe? But it's quite
Martin irritating as it is. Do
Am Donnerstag, 2. Februar 2006 12:09 schrieb Juergen Spitzmueller:
It works for me except for one drawback: the content of branches is
always
placed in a new paragraph, even if the branch was inline. If it is easy
to
fix, I'd appreciate that, since I use branches almost always inline.
This
samar j. singh wrote:
If you can explain the characteristics of a closed collapsible inset I
might get an idea of the type of thing to target in the document that would
create this.
collapsable insets are the things you can open and close: footnotes, floats,
note insets etc. We had crashes
Georg Baum wrote:
This was an oversight by me. The attached patch does not create these new
paragraphs, and it also does not create empty new paragraphs. The reason
for both problems was the line '\layout' that is always at the beginning
of a branch inset but does not correspond to a paragraph
Am Donnerstag, 2. Februar 2006 11:35 schrieb Juergen Spitzmueller:
Georg Baum wrote:
I think the safest solution right now is simply to make a special case
for
the lyx13 format. I'll send an updated patch this evening.
I agree.
Here it is. It works for me, could you please test it, too?
Georg Baum [EMAIL PROTECTED] writes:
| Am Donnerstag, 2. Februar 2006 12:09 schrieb Juergen Spitzmueller:
| It works for me except for one drawback: the content of branches is
| always
| placed in a new paragraph, even if the branch was inline. If it is easy
| to
| fix, I'd appreciate
Am Mittwoch, 1. Februar 2006 23:20 schrieb Beck, Andrew Thomas - BECAT001:
Here is a patch to fix bug 2060 - again.
It looks sensible. Are you sure that nothing needs to be done in
cursorPos
and drawSelection?
Nope, I have no idea. I looked at your original patch which mentioned
Am Donnerstag, 2. Februar 2006 21:47 schrieb Lars Gullik Bjønnes:
Georg Baum [EMAIL PROTECTED] writes:
| Lars, Jean-Marc: Can this go in?
yes
OK, done. Having a closer look at the language problem now.
Georg
I just noticed this bug was targeted to 1.4.0. Is
the intention to get this new patch in?
andrew
Am Donnerstag, 2. Februar 2006 22:31 schrieb Beck, Andrew Thomas -
BECAT001:
I just noticed this bug was targeted to 1.4.0. Is
the intention to get this new patch in?
It was not now targetted to 1.4.0, it was targetted to 1.4.0 a long time
ago. I only reopened it today, because you found out
I want to add a section in LyX's configure script to check for viewers
of LaTeX-files. I used the following code:
-
# Search something to view LaTeX-files
echo $ac_n checking for an editor to view LaTeX-files... $ac_c
echo $ac_t(jEdit WinShell TeXnicCenter WinEdt WinTeX)
TEX_VIEWER=
for
Ok, I see now. Unfortunately your patch is not correct IMHO: If I click on
argument 3 I expect the cursor to appear in argument 3, not in the first
one as your patch does. In perinciple it is ok to call
Of course you tested your original patch to ensure it met this requirement?
I suspect lyx
On Thursday 02 February 2006 23:18, Juergen Spitzmueller wrote:
samar j. singh wrote:
If you can explain the characteristics of a closed collapsible inset I
might get an idea of the type of thing to target in the document that
would create this.
collapsable insets are the things you can
I actually don't know anything about autoconf/automake etc, so
can't really help you. sorry.
However, I have noticed the following when linking the main executable
on mingw (this is the output from 'time make lyx-qt.exe'):
standard link time:
real3m31.984s
user0m15.507s
sys 0m11.529s
On Thu, 2006-02-02 at 00:35 +0100, Helge Hafting wrote:
...
> > Try the above, works for me. Or wait for a *really* carefully produced
> > patch Real Soon Now.
>
> Think I have to wait for that patch, for this didn't change anything at all.
> footnotes, margin notes and table cells still
Activate math mode. Type 2^Q. Select it, then use the math panel and
change the font to "normal text mode \textrm"
Note that view->dvi fails, as lyx now generates invalid latex.
The bug exists in lyx 1.3 too, where it also happen when you
write 2^Q as text and then selects it and converts it to
Georg Baum wrote:
This patch adds removal of branch insets to lyx2lyx. It is not very
sophisticated (it would probably not be too difficult to replace branches
with booleans and the ifthen package), and it can produce empty
paragraphs, but it is good enough for 1.4.0 IMO.
Please test.
Do
Michael Gerz wrote:
> Do it mean there is a need for LyX 1.3.8?
Please don't even think about a 1.3.8 release unless a really critical bug
is discovered. We should rather have bug 2174 fixed in 1.4.0.
Georg
Martin Vermeer wrote:
Attached. Hopefully more luck this time.
This is much better!
I have tested with text, footnote, marginal note, branch, ERT, float,
table and minipage.
All of them uses correct language now, there are no wrong blue lines or L-
cursors.
There is still the smaller
Georg Baum wrote:
> Does it work if you put the lyx backend in the first position
Yes, it works then.
Couldn't we do something like: "use the first backend available (as it is
now), BUT if the "from" format is equal to any other backend, then use that"?
Jürgen
Juergen Spitzmueller wrote:
> Georg Baum wrote:
>> Does it work if you put the lyx backend in the first position
>
> Yes, it works then.
Fine.
> Couldn't we do something like: "use the first backend available (as it is
> now), BUT if the "from" format is equal to any other backend, then use
>
Georg Baum wrote:
> The problem is that we don't know "from" at that point :-(
I see.
> I have implemented an experimental getShortestPath() method that could be
> used instead of getPath() and the loop. The problem is that this might
> influence other conversions, so it is too risky to do it
samar j. singh wrote:
> I know exactly what I was doing when it crashed. That was putting the
> cursor on the scroll bars to move up the document. At the point when I
> attempted to move the scroll bar up with the mouse, Lyx immediately crashed
> providing the followiing output.
Seems that the
Georg Baum wrote:
> Please test.
It works for me except for one drawback: the content of branches is always
placed in a new paragraph, even if the branch was inline. If it is easy to
fix, I'd appreciate that, since I use branches almost always inline.
Thanks,
Jürgen
On Thursday 02 February 2006 16:25, Juergen Spitzmueller wrote:
> samar j. singh wrote:
> > I know exactly what I was doing when it crashed. That was putting the
> > cursor on the scroll bars to move up the document. At the point when I
> > attempted to move the scroll bar up with the mouse, Lyx
samar j. singh wrote:
> Yes, indeed, I have. Have undone it now. I think your hypothesis may be
> consistent with the previous correlation with the pageup/down use as that
> would also cause the cursor to be repositioned. However, how come this
> cannot be replicated consistently. That probably
On Thu, 2006-02-02 at 11:13 +0100, Helge Hafting wrote:
> Martin Vermeer wrote:
>
> >Attached. Hopefully more luck this time.
> >
> >
> This is much better!
> I have tested with text, footnote, marginal note, branch, ERT, float,
> table and minipage.
> All of them uses correct language now,
Martin Vermeer wrote:
Hmmm. Actually this is straightforwardly fixable. It's just a policy
choice, how we understand noFontChange(). See attached. Only text.C and
rowpainter.C were changed. Works for me... 1.3 does it this way too (in
fact, it has *only* noFontChange-type insets; but language
On Thu, 2006-02-02 at 13:47 +0100, Helge Hafting wrote:
> Martin Vermeer wrote:
>
> >Hmmm. Actually this is straightforwardly fixable. It's just a policy
> >choice, how we understand noFontChange(). See attached. Only text.C and
> >rowpainter.C were changed. Works for me... 1.3 does it this way
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Jean-Marc, I think this is the version of reference to review.
Martin> (Do we still make 1.4.0, or shall we play safe? But it's quite
Martin> irritating as it is. Do we want the possible embarrassment or
Martin> the certain
On Thursday 02 February 2006 17:00, Juergen Spitzmueller wrote:
> samar j. singh wrote:
> > Yes, indeed, I have. Have undone it now. I think your hypothesis may be
> > consistent with the previous correlation with the pageup/down use as that
> > would also cause the cursor to be repositioned.
samar j. singh wrote:
> If you can explain the characteristics of a "closed collapsible inset" I
> might get an idea of the type of thing to target in the document that
> would create this.
A collapsable inset is one that you can open or close, e.g. a minipage/box,
a float, or ERT. In closed
On Thu, Feb 02, 2006 at 04:56:39PM +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Jean-Marc, I think this is the version of reference to review.
> Martin> (Do we still make 1.4.0, or shall we play safe? But it's quite
> Martin>
Am Donnerstag, 2. Februar 2006 12:09 schrieb Juergen Spitzmueller:
> It works for me except for one drawback: the content of branches is
always
> placed in a new paragraph, even if the branch was inline. If it is easy
to
> fix, I'd appreciate that, since I use branches almost always inline.
samar j. singh wrote:
> If you can explain the characteristics of a "closed collapsible inset" I
> might get an idea of the type of thing to target in the document that would
> create this.
"collapsable insets" are the things you can open and close: footnotes, floats,
note insets etc. We had
Georg Baum wrote:
> This was an oversight by me. The attached patch does not create these new
> paragraphs, and it also does not create empty new paragraphs. The reason
> for both problems was the line '\layout' that is always at the beginning
> of a branch inset but does not correspond to a
Am Donnerstag, 2. Februar 2006 11:35 schrieb Juergen Spitzmueller:
> Georg Baum wrote:
> > I think the safest solution right now is simply to make a special case
for
> > the "lyx13" format. I'll send an updated patch this evening.
>
> I agree.
Here it is. It works for me, could you please test
Georg Baum <[EMAIL PROTECTED]> writes:
| Am Donnerstag, 2. Februar 2006 12:09 schrieb Juergen Spitzmueller:
| > It works for me except for one drawback: the content of branches is
| always
| > placed in a new paragraph, even if the branch was inline. If it is easy
| to
| > fix, I'd appreciate
Am Mittwoch, 1. Februar 2006 23:20 schrieb Beck, Andrew Thomas - BECAT001:
> >
> >> Here is a patch to fix bug 2060 - again.
> >
> >It looks sensible. Are you sure that nothing needs to be done in
cursorPos
> >and drawSelection?
>
> Nope, I have no idea. I looked at your original patch which
Am Donnerstag, 2. Februar 2006 21:47 schrieb Lars Gullik Bjønnes:
> Georg Baum <[EMAIL PROTECTED]> writes:
> | Lars, Jean-Marc: Can this go in?
>
> yes
OK, done. Having a closer look at the language problem now.
Georg
I just noticed this bug was targeted to 1.4.0. Is
the intention to get this new patch in?
andrew
Am Donnerstag, 2. Februar 2006 22:31 schrieb Beck, Andrew Thomas -
BECAT001:
> I just noticed this bug was targeted to 1.4.0. Is
> the intention to get this new patch in?
It was not now targetted to 1.4.0, it was targetted to 1.4.0 a long time
ago. I only reopened it today, because you found
I want to add a section in LyX's configure script to check for viewers
of LaTeX-files. I used the following code:
-
# Search something to view LaTeX-files
echo $ac_n "checking for an editor to view LaTeX-files""... $ac_c"
echo "$ac_t""(jEdit WinShell TeXnicCenter WinEdt WinTeX)"
TEX_VIEWER=
>Ok, I see now. Unfortunately your patch is not correct IMHO: If I click on
>argument 3 I expect the cursor to appear in argument 3, not in the first
>one as your patch does. In perinciple it is ok to call
Of course you tested your original patch to ensure it met this requirement?
I suspect
On Thursday 02 February 2006 23:18, Juergen Spitzmueller wrote:
> samar j. singh wrote:
> > If you can explain the characteristics of a "closed collapsible inset" I
> > might get an idea of the type of thing to target in the document that
> > would create this.
>
> "collapsable insets" are the
I actually don't know anything about autoconf/automake etc, so
can't really help you. sorry.
However, I have noticed the following when linking the main executable
on mingw (this is the output from 'time make lyx-qt.exe'):
standard link time:
real3m31.984s
user0m15.507s
sys 0m11.529s
64 matches
Mail list logo
