hi
I want to do some coding help. My language is persian(farsi) and I
want to help Lyx support farsi.But I don't have experience coding for
multi-lingual documents.Can anyone help me where to start?
regards behzad
On Fri, Jun 08, 2007 at 08:22:42PM +0200, Jean-Marc Lasgouttes wrote:
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes:
Stefan Critical bugs don't get less critical by ignorance. If anybody
Stefan wants to know more:
[snip]
Great analysis!
I would say that the fix is correct,
http://bugzilla.lyx.org/show_bug.cgi?id=3510
The problem is an interference of newer babel bundles with the way \markboth
is defined (if \markboth is defined after babel, babel somehow gets the
language in uppercase and complains about an unknown language ENGLISH).
The only solution I know
Stefan Schimanski wrote:
The bug: http://bugzilla.lyx.org/show_bug.cgi?id=2446
The patch:
It seems to improve the situation (besides the crash, which is gone also
without your patch), but I still get some flashing effects when trying the
testcase of bug 2446 (screen flickering whenever I move
Pavel Sanda wrote:
Firefox also had only one button in the 1.5 series. And I don't like
the 2.x UI with the button per tab.
please dont close the bug for close button on tab.
the main advantage of one button per tab is the possibility to close
different tabs just by one click without
Martin Vermeer wrote:
On Fri, Jun 08, 2007 at 08:22:42PM +0200, Jean-Marc Lasgouttes wrote:
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes:
Stefan Critical bugs don't get less critical by ignorance. If anybody
Stefan wants to know more:
[snip]
Great analysis!
I would
Hello,
I've compiled LyX 5.0 svn.
1) Open User Guide
2) Tools - outline
3) Document - Next cross-reference
4) Click in the Toc Widget on the second section
5) Boum with this (rather unhelpful message)
/usr/include/c++/4.1.3/debug/safe_iterator.h:130:error: attempt to copy-
construct an
Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
Firefox also had only one button in the 1.5 series. And I don't like
the 2.x UI with the button per tab.
please dont close the bug for close button on tab.
the main advantage of one button per tab is the possibility to close
different tabs just by
[EMAIL PROTECTED] wrote:
1) Open User Guide
2) Tools - outline
3) Document - Next cross-reference
4) Click in the Toc Widget on the second section
5) Boum
Confirmed (backtrace below).
Please file a bug report.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread
Am 09.06.2007 um 09:22 schrieb Jürgen Spitzmüller:
Stefan Schimanski wrote:
The bug: http://bugzilla.lyx.org/show_bug.cgi?id=2446
The patch:
It seems to improve the situation (besides the crash, which is gone
also
without your patch), but I still get some flashing effects when
trying
Am 09.06.2007 um 09:52 schrieb Peter Kümmel:
Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
Firefox also had only one button in the 1.5 series. And I don't
like
the 2.x UI with the button per tab.
please dont close the bug for close button on tab.
the main advantage of one button per tab is
Jürgen Spitzmüller wrote:
Alfredo Braunstein wrote:
I was hoping for the patch to be applied sooner, as
it was discussed enough, fixed a crash, and had some good side effects
(removal of the destroyed signals etc)...
But you wrote it's completely untested. If this is no more true, I'd say
Stefan Schimanski wrote:
Which kind of flashing?! What is flashing? The whole bufferview? The
math? Don't see any like that here.
rather the math.
it looks like the cursor is very rapidly put inside the inset and back
outside. If I have the math panel toolbar opened (in auto mode), it
Alfredo Braunstein wrote:
I tested it a few days without problems. I don't have svn rights ATM,
you should get them back as soon as possible IMHO. Then you're indebted to
contribute again ;-)
could someone else do it for me? Last version is in the 'road to rc2'
thread.
I'll do it.
Am Samstag, 9. Juni 2007 schrieb Jürgen Spitzmüller:
could someone else do it for me? Last version is in the 'road to rc2'
thread.
I'll do it.
But please write a log message.
Jürgen
Am 09.06.2007 um 00:28 schrieb Alfredo Braunstein:
Jean-Marc Lasgouttes wrote:
Yes, the patch looks good, except that the messages are not very
informative (but as a usr I would be scared to see all these messages
in normal operation). And there is a very long line.
Fixed. Note that the
Am 09.06.2007 um 11:07 schrieb Jürgen Spitzmüller:
Alfredo Braunstein wrote:
I tested it a few days without problems. I don't have svn rights ATM,
you should get them back as soon as possible IMHO. Then you're
indebted to
contribute again ;-)
could someone else do it for me? Last
Hi!
Is there a reason that the non-modal dialogs (like to edit tables,
change text styles etc.) depend on the LyX window? You can open
another one for every window which is open. It's somehow strange and
confusing to have a text style dialog, but it doesn't work because
it belongs to
And, if the inset = 0 it's a broken cursor in any way, no? So take
a wrong idx, hence inset=0. In the next loop with inset()==inset
will not cut if off. I think it's wrong.
I was right. You can crash it like this: abcde, insert ERT inset,
type inside fgh. Place the cursor behind the h.
Stefan Schimanski wrote:
Some small questions:
Why don't you like comments?
? Be more specific. OTOH, I would have like some comment of yours when I
asked for them a week ago... ;-)
Why do you need this complicated logic to set the inset to 0 in many
cases. Won't that end the loop anyway in
Some small questions:
Why don't you like comments?
? Be more specific. OTOH, I would have like some comment of yours
when I
asked for them a week ago... ;-)
Sorry, meant something like two lines describing what the big loop is
doing. Not the comments here :)
Why do you need this
Le 8 juin 07 à 12:15, Mael Hilléreau a écrit :
Le 6 juin 07 à 16:58, Richard Heck a écrit :
Mael Hilléreau wrote:
Le 6 juin 07 à 15:54, Richard Heck a écrit :
Mael Hilléreau wrote:
I'm on Mac OS 10.4.9, with 1.5.0rc1. In the two following
situations, the outline panel is hidden whereas
Stefan Schimanski wrote:
I guess yes. Compiling right now. If it does, that would be great.
Signals in those CursorSlices, always feel in a strange way when
thinking about it :)
Since you are at it, could you please just commit if you think it is correct?
Jürgen
Mael Hilléreau wrote:
May I file an enhancement request at bugzilla?
Yes, please do so (this is something for post-1.5.0).
Jürgen
Stefan Schimanski wrote:
Some small questions:
Why don't you like comments?
? Be more specific. OTOH, I would have like some comment of yours
when I
asked for them a week ago... ;-)
Sorry, meant something like two lines describing what the big loop is
doing. Not the comments here :)
Jean-Marc Lasgouttes wrote:
It is completely different: dEPM disallows things that have _no_
meaning to LaTeX (like double space). And empty math inset is
acceptable, even if it is most of the times not wanted.
sure, perhaps latex permits this but when would you want to create an empty
math
It works fine (as far as I can judge after 2 minutes testing). I
added some comments and pulled apart the loop to make the control
flow easier. Alfredo, can you check please? I would be happy if we
could get rid of the signals finally like this.
Stefan
Index:
Le 9 juin 07 à 12:30, Jürgen Spitzmüller a écrit :
Mael Hilléreau wrote:
May I file an enhancement request at bugzilla?
Yes, please do so (this is something for post-1.5.0).
Done: http://bugzilla.lyx.org/show_bug.cgi?id=3842
Mael.
I agree with Pavel.
I not, because I don't like such buttons.
I like the patch like it is. Single tab buttons take screen space and
clutter the appearance.
i suppose it wont be problem to make switch between these two appearances in
preferences when the second is available.
pavel
Stefan Schimanski wrote:
It works fine (as far as I can judge after 2 minutes testing). I
added some comments and pulled apart the loop to make the control
flow easier. Alfredo, can you check please? I would be happy if we
could get rid of the signals finally like this.
Sure, but I cannot
Le 8 juin 07 à 10:28, Mael Hilléreau a écrit :
What is the status of this patch?
What do you mean by status exactly? I don't know if it was tested
by others than me. But to be integrated, it is clear that the code
needs more testing, and then some #ifdefs in order to be applied
only to
Am 09.06.2007 um 13:09 schrieb Alfredo Braunstein:
Stefan Schimanski wrote:
It works fine (as far as I can judge after 2 minutes testing). I
added some comments and pulled apart the loop to make the control
flow easier. Alfredo, can you check please? I would be happy if we
could get rid of
Stefan Schimanski wrote:
It works fine (as far as I can judge after 2 minutes testing). I added
some comments and pulled apart the loop to make the control flow easier.
Alfredo, can you check please? I would be happy if we could get rid of
the signals finally like this.
I am not Alfredo but
Alfredo Braunstein wrote:
Why do we have a BufferView for every window instead of one for every tab?
The latter would be a much simpler scheme...
The plan is to have one BufferView per Buffer for a given window. The
plan is also to have one WorkArea per tab, thus one BufferView per tab.
At
Bo Peng wrote:
Bo Fixed in the attached patch. Jose, OK to apply?
I am not very pleased with the use of an exception there, but on the
other hand I do not have (yet) a better idea.
I though of returning TocItem and let update() add the labels.
However, ParConstIterator does not have a default
Abdelrazak Younes wrote:
Stefan Schimanski wrote:
It works fine (as far as I can judge after 2 minutes testing). I added
some comments and pulled apart the loop to make the control flow easier.
Alfredo, can you check please? I would be happy if we could get rid of
the signals finally like
Here is a fix for the grey-bar bug, i.e. randomly only the current
paragraph is drawn and everything else is greyed out.
I think it is related to synthetic mouse event. Somehow a redraw is
triggered, but the ViewMetric.update_strategy is set to
NoScreenUpdate. The two condition, that I
Richard Heck wrote:
Bo Peng wrote:
The way to solve this might be to put some appropriate code into
InsetCaption::notifyCursorLeaves().
I do not think it is a good idea to update Toc during editing, because
simple add/remove of sections, change of environment will break Toc,
so it is close to
Done
#3843
Stefan Schimanski wrote:
drawMarkers moved to InsetMathNest?! See r18701. Please revert or fix that.
/Users/sts/Quellen/mac/lyx-devel/src/mathed/InsetMathMBox.cpp: In member
function 'virtual void lyx::InsetMathMBox::draw(lyx::PainterInfo, int,
int) const':
Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Why do we have a BufferView for every window instead of one for every
tab? The latter would be a much simpler scheme...
The plan is to have one BufferView per Buffer for a given window. The
plan is also to have one WorkArea per tab, thus
Ok, committed. So let's see if everything is alright now. We still
have some days to the RC2 for testing.
Stefan
Am 09.06.2007 um 14:32 schrieb Alfredo Braunstein:
Abdelrazak Younes wrote:
Stefan Schimanski wrote:
It works fine (as far as I can judge after 2 minutes testing). I
added
Bo Peng wrote:
The way to solve this might be to put some appropriate code into
InsetCaption::notifyCursorLeaves().
I do not think it is a good idea to update Toc during editing, because
simple add/remove of sections, change of environment will break Toc,
so it is close to impossible to
[EMAIL PROTECTED] wrote:
Done
Thanks. I confirmed it and targetted it to 1.5.0.
Jürgen
Stefan Schimanski wrote:
Ok, committed. So let's see if everything is alright now. We still have
some days to the RC2 for testing.
If the testing reveals that we don't need the Inset::destroyed() signal,
this should be deleted before RC2 too.
Abdel.
Am 09.06.2007 um 14:46 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Ok, committed. So let's see if everything is alright now. We still
have some days to the RC2 for testing.
If the testing reveals that we don't need the Inset::destroyed()
signal, this should be deleted before RC2
Stefan Schimanski wrote:
Am 09.06.2007 um 14:46 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Ok, committed. So let's see if everything is alright now. We still
have some days to the RC2 for testing.
If the testing reveals that we don't need the Inset::destroyed()
signal, this
Please don't touch at that. When you change a section depth, the full
renumbering is done (in updateLabels()). It is only natural to update
also the TocBackend at the same time. Actually this update is much
quicker than the section renumbering.
We have not done anything, and if the operators
Stefan Schimanski wrote:
Am 09.06.2007 um 14:46 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Ok, committed. So let's see if everything is alright now. We still
have some days to the RC2 for testing.
If the testing reveals that we don't need the Inset::destroyed()
signal, this
InsetMathMBox is compiled only with CMake. That's because I wanted to
make sure that it stays compilable until it's time to use it.
I was thinking that scons (or worse, gcc) is broken. :-)
Bo
Bo Peng wrote:
Please don't touch at that. When you change a section depth, the full
renumbering is done (in updateLabels()). It is only natural to update
also the TocBackend at the same time. Actually this update is much
quicker than the section renumbering.
We have not done anything, and if
We have not done anything, and if the operators are cheap as you
described, it is perfectly fine to me to make TocUpdate automatic.
Good, thanks.
But then it is your job to get it done. :-)
Seriously, as we have discussed, the problem lies in 'when to update
Toc'. It is unwise to update Toc
behzad maha wrote:
hi
I want to do some coding help. My language is persian(farsi) and I
want to help Lyx support farsi.But I don't have experience coding for
multi-lingual documents.Can anyone help me where to start?
Hello Behzad,
We have already a Farsi developper around (Mostafa Vahedi).
Am 09.06.2007 um 15:05 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Am 09.06.2007 um 14:46 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Ok, committed. So let's see if everything is alright now. We
still have some days to the RC2 for testing.
If the testing reveals that we
I see no comment on this patch. Because this is within my field, I
will commit tomorrow if there is no objection.
No objection, so it is in.
Cheers,
Bo
Bo Peng wrote:
We have not done anything, and if the operators are cheap as you
described, it is perfectly fine to me to make TocUpdate automatic.
Good, thanks.
But then it is your job to get it done. :-)
I am slowly coming back, don't ask me too much ;-)
Seriously, as we have
Bo Peng wrote:
I see no comment on this patch. Because this is within my field, I
will commit tomorrow if there is no objection.
No objection, so it is in.
I think the proper way to solve any option would have been to outsource
the option definitions in a text file which is easily
[EMAIL PROTECTED] wrote:
Allow prefixing a listings parameter with @ to bypass validation, useful
when new parameters are added in a new listings version
Isn't this a file format change?
Jürgen
On 6/9/07, Jürgen Spitzmüller [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Allow prefixing a listings parameter with @ to bypass validation, useful
when new parameters are added in a new listings version
Isn't this a file format change?
No. Previously, only valid parameter strings such
[EMAIL PROTECTED] wrote:
Hello,
I've compiled LyX 5.0 svn.
1) Open User Guide
2) Tools - outline
3) Document - Next cross-reference
Here (Win/MSVC) it crashes at point 3 with this backtrace:
lyx-qt4.exe!lyx::frontend::TocModel::modelIndex(const
Bo Peng wrote:
No. Previously, only valid parameter strings such as 'firstline=5' are
allowed. Now, trashes like '@IamTrash,firstline=5' can also be
entered, although in this particular case latex will not compile
(wrong parameter IamTrash).
But what happens if a file with such a parameter is
Pavel Sanda wrote:
I agree with Pavel.
I not, because I don't like such buttons.
I like the patch like it is. Single tab buttons take screen space and
clutter the appearance.
i suppose it wont be problem to make switch between these two appearances in
preferences when the second is
Yes, in the long term this is a solution. But currently we rely on Qt 4.1,
so I hope it could go in for 1.5.
i hope so :)
pavel
But what happens if a file with such a parameter is opened by an older version
(rc1, for instance)? I guess LyX will crash, no?
I would not consider rc1 because it is a temporary release. After
1.5.0, @para will always be accepted and will compile if a user's
listings package supports para.
Of
I prefer normalsize roman font and red (like beamer pause/endFrame) or blue
(like pagebreak).
That will be the attached, which has the following style entry:
Style SplitLayout
KeepEmpty 1
MarginDynamic
LatexType Paragraph
Jean-Marc Lasgouttes wrote:
Another solution is to remove this special handling for
environments and force to use depth when several paragraphs are in
a same env.
Richard But the many-paragraphs case isn't that exceptional and, in
Richard some cases, is even the most common. So it seems
Bo Peng wrote:
Herbert The current behaviour is easy!
But not so easy for lyx newbies. The question is: what to insert that
do not show up in the screen output (better latex output), yet split
the environment? I remember that it took me 10 minutes to figure that
out a few years ago.
And, as
Bo Peng wrote:
I would not consider rc1 because it is a temporary release. After
1.5.0, @para will always be accepted and will compile if a user's
listings package supports para.
But we have to maintain backwards compatibility also within the 1.5 cycle.
And is the backwards compatibility to
Bennett Helm schrieb:
I agree with the last sentence, but notice that the patch doesn't do
this! When change tracking is turned off, it is entirely possible to
delete -- remove from the file -- text that is marked as deleted.
Right. Even if we prohibited it, the user may always accept deleted
But we have to maintain backwards compatibility also within the 1.5 cycle.
And is the backwards compatibility to 1.4 assured? I.e., will @extraparams be
reverted to ERT correctly?
I see a point here. When reverting to ERT, @ needs to be removed. I
will commit a patch soon.
IMHO , the only way
Helge Hafting schrieb:
If you turn off change tracking and edit, then surely all new stuff
should
be without the change tracking markings. (i.e. not deleted or marked
as inserted by someone.) You may be able to add inside a deleted region,
but that should split the deleted region in two.
Bo Peng wrote:
But we have to maintain backwards compatibility also within the 1.5
cycle. And is the backwards compatibility to 1.4 assured? I.e., will
@extraparams be reverted to ERT correctly?
I see a point here. When reverting to ERT, @ needs to be removed. I
will commit a patch soon.
Michael Gerz wrote:
IMHO, find replace should always ignore deleted text, in CT mode as
well as in non-CT mode.
That's what my patch does. I'm just waiting for your testing.
Jürgen
Jürgen,
your patch looks nice in general. I can imagine that it even fixes #3160. Below
please find some additional comments.
Michael
Index: src/lyxfind.cpp
===
--- src/lyxfind.cpp (Revision 18711)
+++ src/lyxfind.cpp
Michael Gerz wrote:
for (; cur; cur.forwardChar())
- if (cur.inTexted() match(cur.paragraph(), cur.pos()))
+ if (cur.inTexted()
+ (find_del || !cur.paragraph().isDeleted(cur.pos()))
+ match(cur.paragraph(), cur.pos()))
Bug: http://bugzilla.lyx.org/show_bug.cgi?id=3830
The patch should be obvious.
Stefan
Index: lyx-devel/src/mathed/MathMacro.cpp
===
--- lyx-devel.orig/src/mathed/MathMacro.cpp 2007-06-02
11:24:05.0 +0200
+++
Jürgen Spitzmüller schrieb:
Michael Gerz wrote:
for (; cur; cur.forwardChar())
- if (cur.inTexted() match(cur.paragraph(), cur.pos()))
+ if (cur.inTexted()
+ (find_del || !cur.paragraph().isDeleted(cur.pos()))
+
There's no other possibility IMO.
That is *too much* work!
I will propose, instead,
1. revert my @ idea
2. add a checkbox like 'bypass validation', 'use what I have inputted'.
3. if this checkbox is clicked, the parameter is allowed.
In this way, there will be no lyx2lyx problem.
Agreed?
On Sat, Jun 09, 2007 at 10:49:13AM -0500, Bo Peng wrote:
...
+def revert_splitlayout(document):
+r''' Revert SplitLayout to a lyx node
+From
That would be 'note'
...
- Martin
On 6/9/07, Martin Vermeer [EMAIL PROTECTED] wrote:
On Sat, Jun 09, 2007 at 10:49:13AM -0500, Bo Peng wrote:
...
+def revert_splitlayout(document):
+r''' Revert SplitLayout to a lyx node
+From
That would be 'note'
Will be corrected when applied.
Thanks.
Bo
Dear all,
I reverted my previous patch that add @para to allow para to bypass
validation. The major problem is the handling @ in lyx2lyx.
In this patch, I add a check box 'bypass validation' that will allow
any listings parameters to be passed to lyx/latex if this checkboz is
checked. No file
Am 09.06.2007 um 08:37 schrieb Martin Vermeer:
On Fri, Jun 08, 2007 at 08:22:42PM +0200, Jean-Marc Lasgouttes wrote:
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes:
Stefan Critical bugs don't get less critical by ignorance. If
anybody
Stefan wants to know more:
[snip]
Great
When editing, and doing a carriage return, then backspace on the old
paragraph, carriage return, results in lyx 1.5.0rc1 crashing - 1.5 is
so much better than 1.4.4 in many respects I am trying to use it, but
this bug keeps occurring. I am using the windows version on XP service
pack 2.
I
When editing, and doing a carriage return, then backspace on the old
paragraph, carriage return, results in lyx 1.5.0rc1 crashing - 1.5 is
i'm not able to reproduce it. can you provide exact steps how to achive
this crash ?
pavel
I just reproduced it on this file.
Move cursor to the end of paragraph, then to start of work tasks do CR
Move cursor to start of words seller biased, then CR
Move cursor to the start of that for then CR at that point lyx crashes.
[EMAIL PROTECTED] wrote:
Hello,
I've compiled LyX 5.0 svn.
1) Open User Guide
2) Tools - outline
3) Document - Next cross-reference
4) Click in the Toc Widget on the second section
5) Boum with this (rather unhelpful message)
/usr/include/c++/4.1.3/debug/safe_iterator.h:130:error: attempt to
Pavel Sanda wrote:
I just reproduced it on this file.
Move cursor to the end of paragraph, then to start of work tasks do CR
Move cursor to start of words seller biased, then CR
Move cursor to the start of that for then CR at that point lyx crashes.
W. Bentley MacLeod wrote:
When editing, and doing a carriage return, then backspace on the old
paragraph, carriage return, results in lyx 1.5.0rc1 crashing - 1.5 is
so much better than 1.4.4 in many respects I am trying to use it, but
this bug keeps occurring. I am using the windows version
Alfredo Braunstein wrote:
Pavel Sanda wrote:
I just reproduced it on this file.
Move cursor to the end of paragraph, then to start of work tasks do CR
Move cursor to start of words seller biased, then CR
Move cursor to the start of that for then CR at that point lyx
crashes.
confirmed. i filed the bug http://bugzilla.lyx.org/show_bug.cgi?id=3844 .
Strange, I cannot reproduce.
svn up did the trick. current trunk is ok.
pavel
Stefan Schimanski wrote:
Here is a fix for the grey-bar bug, i.e. randomly only the current
paragraph is drawn and everything else is greyed out.
It'd be great if this fixed this bug. It's very annoying.
Richard
I think it is related to synthetic mouse event. Somehow a redraw is
triggered,
Sorry --- wrong patch attached! Here's the correct one (rather shorter ;) )
Dov Feldstern wrote:
Georg Baum wrote:
Stefan Schimanski wrote:
Then the question is only from which file format revision we start
with a lyx2lyx filter: from the change of the exporting behavior or
from the fix from
behzad maha wrote:
hi
I want to do some coding help. My language is persian(farsi) and I
want to help Lyx support farsi.But I don't have experience coding for
multi-lingual documents.Can anyone help me where to start?
regards behzad
Hi, Behzad!
Mostafa Vahedi has recently done
Georg Baum wrote:
Stefan Schimanski wrote:
Then the question is only from which file format revision we start
with a lyx2lyx filter: from the change of the exporting behavior or
from the fix from today and the last days...
That depends on the format when the change happened. If it was during
Georg Baum wrote:
If you want to debug this fdurther it might be a good idea to write a small
standalone program that simply calls boost::format with the problematic
input.
boost::basic_format() itself seems working if it is called with
ordinary strings:
#include iostream
#include
hi
I want to do some coding help. My language is persian(farsi) and I
want to help Lyx support farsi.But I don't have experience coding for
multi-lingual documents.Can anyone help me where to start?
regards behzad
On Fri, Jun 08, 2007 at 08:22:42PM +0200, Jean-Marc Lasgouttes wrote:
> > "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
>
> Stefan> Critical bugs don't get less critical by ignorance. If anybody
> Stefan> wants to know more:
>
> [snip]
>
> Great analysis!
>
> I would say that
http://bugzilla.lyx.org/show_bug.cgi?id=3510
The problem is an interference of newer babel bundles with the way \markboth
is defined (if \markboth is defined after babel, babel somehow gets the
language in uppercase and complains about an unknown language ENGLISH).
The only solution I know
Stefan Schimanski wrote:
> The bug: http://bugzilla.lyx.org/show_bug.cgi?id=2446
> The patch:
It seems to improve the situation (besides the crash, which is gone also
without your patch), but I still get some flashing effects when trying the
testcase of bug 2446 (screen flickering whenever I
Pavel Sanda wrote:
> > Firefox also had only one button in the 1.5 series. And I don't like
> > the 2.x UI with the button per tab.
>
> please dont close the bug for close button on tab.
> the main advantage of one button per tab is the possibility to close
> different tabs just by one click
1 - 100 of 190 matches
Mail list logo
