lyx farsi support??
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
Re: [patch] fixing segfault because of empty coord cache
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, but I'd wait for Andre's input. JMarc Hear, hear. This kind of analysis should be in the code, as comment. Do I understand correctly that this presupposes that 1) every mathinset must have an isActive method and 2) it should return true only if the inset has really accessible cells? - Martin
[patch] bug 3510: make IEEEtran template compilable
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 (besides not calling babel) is to define \markboth
before babel, i.e. do not use the MarkBoth paragraph style (which is somewhat
awkward anyway) but define \markboth in preamble.
I did this in the template, which compiles again here. Looks like the IEEEtran
layout would need some overhaul in general, but I won't do that.
OK to apply?
Jürgen
Index: lib/templates/IEEEtran.lyx
===
--- lib/templates/IEEEtran.lyx (Revision 18720)
+++ lib/templates/IEEEtran.lyx (Arbeitskopie)
@@ -1,18 +1,31 @@
#LyX 1.5.0svn created this file. For more info see http://www.lyx.org/
-\lyxformat 245
+\lyxformat 271
\begin_document
\begin_header
\textclass IEEEtran
+\begin_preamble
+% The following definition specifies the text on the headers:
+% Use this instead of the MarkBoth paragraph style
+\markboth{This is for left pages}{and this is for right pages}
+\end_preamble
\language english
\inputencoding default
-\fontscheme default
+\font_roman default
+\font_sans default
+\font_typewriter default
+\font_default_family default
+\font_sc false
+\font_osf false
+\font_sf_scale 100
+\font_tt_scale 100
\graphics default
-\float_placement hbt
+\float_placement tbh
\paperfontsize default
\spacing single
\papersize default
\use_geometry false
\use_amsmath 0
+\use_esint 0
\cite_engine basic
\use_bibtopic false
\paperorientation portrait
@@ -25,29 +38,44 @@
\papersides 1
\paperpagestyle default
\tracking_changes false
-\output_changes true
+\output_changes false
+\author Jürgen Spitzmüller
\end_header
\begin_body
-\begin_layout Title
+\begin_layout Standard
+\begin_inset Note Note
+status open
-Your Title: And maybe a bit extra
+\begin_layout Standard
+To specify the left and right header, go to
+\family sans
+Document\SpecialChar \menuseparator
+Settings\SpecialChar \menuseparator
+Preamble
+\family default
+ and change the definition there.
\end_layout
-\begin_layout Author
+\end_inset
+\end_layout
+
+\begin_layout Title
+Your Title: And maybe a bit extra
+\end_layout
+
+\begin_layout Author
\begin_inset Note Note
status collapsed
\begin_layout Standard
-
Remember that initial submissions don't show the authors
\end_layout
\begin_layout Standard
-
names so you'll need to make this a 'Comment'.
\end_layout
@@ -58,7 +86,6 @@
status collapsed
\begin_layout Standard
-
Your name is with xyz Department\SpecialChar \ldots{}
\end_layout
@@ -69,59 +96,36 @@
\end_layout
\begin_layout Abstract
-
This paper presents a simple template for IEEEtran documents.
\end_layout
\begin_layout Keywords
-
simplicity, beauty, elegance
\end_layout
-\begin_layout MarkBoth
-
-This is for left pages
-\begin_inset ERT
-status collapsed
-
-\begin_layout Standard
-}{
-\end_layout
-
-\end_inset
-
-and this is for right pages
-\end_layout
-
\begin_layout Section
-
Introduction
\begin_inset Note Note
status collapsed
\begin_layout Standard
-
Don't panic the section numbering may look different in
\end_layout
\begin_layout Standard
-
LyX but LaTeX uses the correct Roman numerals and
\end_layout
\begin_layout Standard
-
Alpha for section counters.
\end_layout
\begin_layout Standard
-
It's just that LyX doesn't handle counters other than arabic
\end_layout
\begin_layout Standard
-
numerals.
\end_layout
@@ -131,13 +135,12 @@
\end_layout
\begin_layout Standard
-
-
\begin_inset ERT
status collapsed
\begin_layout Standard
+
\backslash
PARstart{T}{here}
\end_layout
@@ -149,27 +152,23 @@
\end_layout
\begin_layout Section
-
Previous Work
\end_layout
\begin_layout Standard
-
This is only a template remember.
\end_layout
\begin_layout Section
-
Methodology
\end_layout
\begin_layout Theorem
-
-
\begin_inset ERT
status collapsed
\begin_layout Standard
+
[
\end_layout
@@ -180,6 +179,7 @@
status collapsed
\begin_layout Standard
+
]
\end_layout
@@ -190,23 +190,18 @@
\end_layout
\begin_layout Lemma
-
If you don't want a theorem or lemma name don't add one.
\end_layout
\begin_layout Proof
-
And here's the proof!
\end_layout
\begin_layout Section
-
Results
\end_layout
\begin_layout Standard
-
-
\begin_inset Float figure
placement htbp
wide false
@@ -220,8 +215,10 @@
A single column figure goes here
\end_layout
-\begin_layout Caption
+\begin_layout Standard
+\begin_inset Caption
+\begin_layout Standard
Captions go
\emph on
under
@@ -232,14 +229,21 @@
\end_inset
+\end_layout
+
+\end_inset
+
+
\begin_inset Float table
placement htbp
wide false
sideways false
status open
-\begin_layout Caption
+\begin_layout Standard
+\begin_inset Caption
Re: [patch] lyx crashes/mutilates document using math-delimiter ( ) in hebrew text
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 the cursor in the math inset with the keyboard). Jürgen
Re: Close tab button
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 choosing the tab to be active. it maybe not so neat, but is much more effective for work. Anyway, a button per tab is much more complicated than this solution. i would wait when trolltech include this feature to the qtabbar class. I agree with Pavel. Jürgen
Re: [patch] fixing segfault because of empty coord cache
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 say that the fix is correct, but I'd wait for Andre's input. JMarc Hear, hear. This kind of analysis should be in the code, as comment. Do I understand correctly that this presupposes that 1) every mathinset must have an isActive method and 2) it should return true only if the inset has really accessible cells? Not really. IIRC, the problem with mathed (as opposed to the other insets) is that the metrics are saved in the CoordCache at draw() time as opposed to updateMetrics() time. The real fix is to align this treatment for all insets. Abdel.
Crash with the new TOC widget
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 iterator from a singular iterator.
Objects involved in the operation:
iterator this @ 0x0xaf918fe0 {
type =
N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPKN3lyx7TocItemEN10__gnu_norm6vectorIS4_SaIS4_EN15__gnu_debug_def6vectorIS4_S9_
(constant iterator);
state = singular;
}
iterator other @ 0x0x92abed0 {
type =
N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPKN3lyx7TocItemEN10__gnu_norm6vectorIS4_SaIS4_EN15__gnu_debug_def6vectorIS4_S9_
(constant iterator);
state = singular;
}
Cheers,
Charles
Re: Close tab button
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 one click without choosing the tab to be active. it maybe not so neat, but is much more effective for work. Anyway, a button per tab is much more complicated than this solution. i would wait when trolltech include this feature to the qtabbar class. I agree with Pavel. I not, because I don't like such buttons. Jürgen Peter
Re: Crash with the new TOC widget
[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 47150429772400 (LWP 14733)]
0x005b9359 in lyx::ParConstIterator::operator- (this=0x18b0a48) at
CursorSlice.h:81
81 pit_type pit() const { return pit_; }
(gdb) bt
#0 0x005b9359 in lyx::ParConstIterator::operator- (this=0x18b0a48)
at CursorSlice.h:81
#1 0x0060a4ff in lyx::TocItem::id (this=0x18b0a48) at
TocBackend.cpp:80
#2 0x0092f1a2 in lyx::frontend::ControlToc::goTo (this=0x1b09bd0,
[EMAIL PROTECTED]) at ControlToc.cpp:83
#3 0x008d270c in lyx::frontend::QToc::goTo (this=0x1b09bc0,
type=value optimized out, [EMAIL PROTECTED])
at QToc.cpp:110
#4 0x008cdf00 in lyx::frontend::TocWidget::selectionChanged
(this=0x1b101b0, [EMAIL PROTECTED])
at TocWidget.cpp:88
#5 0x008ce9fc in lyx::frontend::TocWidget::qt_metacall
(this=0x1b101b0, _c=QMetaObject::InvokeMetaMethod,
_id=104, _a=0x7fff9eecf560) at TocWidget_moc.cpp:87
#6 0x2ae20df5ebcb in QMetaObject::activate (sender=0x1460e30,
from_signal_index=5, to_signal_index=5, argv=0x1)
at kernel/qobject.cpp:2940
#7 0x2ae20c2eb1fa in QItemSelectionModel::currentChanged (this=0x18b0a48,
_t1=value optimized out,
_t2=value optimized out)
at .moc/release-shared/moc_qitemselectionmodel.cpp:150
#8 0x2ae20c2eb534 in QItemSelectionModel::setCurrentIndex
(this=0x1460e30, index=value optimized out,
[EMAIL PROTECTED]) at itemviews/qitemselectionmodel.cpp:1057
#9 0x2ae20c2b57d1 in QAbstractItemView::mousePressEvent (this=0x1b100f0,
event=0x7fff9eed0040)
at itemviews/qabstractitemview.cpp:1306
#10 0x2ae20c2dfc2e in QTreeView::mousePressEvent (this=0x1b100f0,
event=0x7fff9eed0040)
at itemviews/qtreeview.cpp:1347
#11 0x2ae20bfa356a in QWidget::event (this=0x1b100f0,
event=0x7fff9eed0040) at kernel/qwidget.cpp:5714
#12 0x2ae20c1f4409 in QFrame::event (this=0x18b0a48, e=0x18b0a48) at
widgets/qframe.cpp:633
#13 0x2ae20c25bc8a in QAbstractScrollArea::viewportEvent (this=0x18b0a48,
e=0x18b0a48)
at widgets/qabstractscrollarea.cpp:854
---Type return to continue, or q return to quit---
#14 0x2ae20c2b0d41 in QAbstractItemView::viewportEvent (this=0x1b100f0,
event=0x7fff9eed0040)
at itemviews/qabstractitemview.cpp:1270
#15 0x2ae20c25df98 in QAbstractScrollAreaFilter::eventFilter (this=value
optimized out, o=value optimized out,
e=0x1b200e0) at widgets/qabstractscrollarea_p.h:78
#16 0x2ae20bf5eb73 in QApplicationPrivate::notify_helper (this=value
optimized out, receiver=0x1b12140,
e=0x7fff9eed0040) at kernel/qapplication.cpp:3431
#17 0x2ae20bf614a1 in QApplication::notify (this=0xe4e4d0,
receiver=0x1b12140, e=0x7fff9eed0040)
at kernel/qapplication.cpp:3138
#18 0x007d8668 in lyx::frontend::GuiApplication::notify
(this=0x18b0a48, receiver=0x18b0a48, event=0x1b200e0)
at GuiApplication.cpp:237
#19 0x2ae20bfb3406 in QETWidget::translateMouseEvent (this=0x1b12140,
event=value optimized out)
at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:186
#20 0x2ae20bfb22da in QApplication::x11ProcessEvent (this=0x136,
event=0x7fff9eed0510)
at kernel/qapplication_x11.cpp:2853
#21 0x2ae20bfd3ca5 in x11EventSourceDispatch (s=0xe564a0, callback=0,
user_data=0x0)
at kernel/qguieventdispatcher_glib.cpp:122
#22 0x2ae20e425f94 in g_main_context_dispatch ()
from /opt/gnome/lib64/libglib-2.0.so.0
#23 0x2ae20e428dc5 in g_main_context_prepare ()
from /opt/gnome/lib64/libglib-2.0.so.0
#24 0x2ae20e4292ee in g_main_context_iteration ()
from /opt/gnome/lib64/libglib-2.0.so.0
#25 0x2ae20df6f430 in QEventDispatcherGlib::processEvents (this=0xe529b0,
flags=value optimized out)
at kernel/qeventdispatcher_glib.cpp:366
#26 0x2ae20bfd3abf in QGuiEventDispatcherGlib::processEvents
(this=0x18b0a48, flags=value optimized out)
at kernel/qguieventdispatcher_glib.cpp:178
---Type return to continue, or q return to quit---
#27 0x2ae20df4dda8 in QEventLoop::processEvents (this=value optimized
out, flags=value optimized out)
at kernel/qeventloop.cpp:126
#28 0x2ae20df4deb9 in QEventLoop::exec (this=0x7fff9eed0890,
[EMAIL PROTECTED]) at kernel/qeventloop.cpp:172
#29 0x2ae20df50080 in QCoreApplication::exec () at
kernel/qcoreapplication.cpp:730
#30 0x007d85d9 in lyx::frontend::GuiApplication::exec (this=value
optimized out) at GuiApplication.cpp:158
#31 0x00550740 in lyx::LyX::exec (this=0x7fff9eed09c0, argc=value
optimized out, argv=value optimized out)
at LyX.cpp:463
#32 0x004288ff in main (argc=1, argv=0x7fff9eed0ad8) at main.cpp:48
Jürgen
Re: [patch] lyx crashes/mutilates document using math-delimiter ( ) in hebrew text
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 the testcase of bug 2446 (screen flickering whenever I move the cursor in the math inset with the keyboard). Which kind of flashing?! What is flashing? The whole bufferview? The math? Don't see any like that here. And btw, I checked again: the crash is there without the patch. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: Close tab button
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 the possibility to close different tabs just by one click without choosing the tab to be active. it maybe not so neat, but is much more effective for work. Anyway, a button per tab is much more complicated than this solution. i would wait when trolltech include this feature to the qtabbar class. 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. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [patch] LyX crashes with multiple views, #3785
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 go ahead and apply it. I tested it a few days without problems. I don't have svn rights ATM, could someone else do it for me? Last version is in the 'road to rc2' thread. A/
Re: [patch] lyx crashes/mutilates document using math-delimiter ( ) in hebrew text
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 flashes up shortly and disappears again. Also, the math inset itself flashes and something (which I cannot identify) pops up shortly. This is when I move the cursor with the arrow keys. Note, however, that I'm totally RTL ignorant, so I have no idea about how the cursor movement should be naturally. And btw, I checked again: the crash is there without the patch. I tried yesterday (without your patch) and I couldn't reproduce, so I thought it was cured by your Bidi work. Jürgen
Re: [patch] LyX crashes with multiple views, #3785
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. Jürgen
Re: [patch] LyX crashes with multiple views, #3785
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
Re: Road to rc2 - fixIfBroken
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 scary messages are already there in svn. Please apply. A/ PS: should I prepare another patch with the removal of the destroyed signals etc? fixifbroken2.diff Some small questions: Why don't you like comments? Why do you need this complicated logic to set the inset to 0 in many cases. Won't that end the loop anyway in the next round? 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. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [patch] LyX crashes with multiple views, #3785
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 version is in the 'road to rc2' thread. I'll do it. Please read my comment in the rc2 thread. Stefan PGP.sig Description: Signierter Teil der Nachricht
Window-independent dialogs
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 another window. Create a bug report for it: http://bugzilla.lyx.org/show_bug.cgi?id=3836 Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [patch] LyX crashes with multiple views, #3785
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. Create a new window, select the everything and delete (even less is enough) = crash because nargs is called on a 0 inset. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: Road to rc2 - fixIfBroken
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 the next round?
Yes, but cutting off the DocIterator.
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.
Oh yes I forgot (too much time passed). This patch is intended to work
*without* the signaling mechanism. So we should have no slice with inset ==
0. So if the patch is to be applied without removing/deactivating the
signaling mechanism, this slightly different version should do it, agreed?
A/
Index: DocIterator.cpp
===
--- DocIterator.cpp (revision 18720)
+++ DocIterator.cpp (working copy)
@@ -562,50 +562,48 @@
{
bool fixed = false;
- for (size_t i = slices_.size() - 1; i != 0; --i)
- if (!slices_[i].isValid()) {
- pop_back();
+ Inset * inset = slices_[0].inset();
+ for (size_t i = 0, n = slices_.size(); i != n; ++i) {
+ CursorSlice cs = slices_[i];
+ if (cs.inset() != inset || inset == 0) {
+ LYXERR(Debug::DEBUG)
+ fixIfBroken(): cursor chopped at
+ i because cs.inset()
+ != inset endl;
+ resize(i);
+ return true;
+ } else if (cs.idx() cs.lastidx()) {
+ cs.idx() = cs.lastidx();
+ cs.pit() = cs.lastpit();
+ cs.pos() = cs.lastpos();
+ inset = 0;
fixed = true;
+ LYXERR(Debug::DEBUG)
+ fixIfBroken(): idx fixed endl;
+ } else if (cs.pit() cs.lastpit()) {
+ cs.pit() = cs.lastpit();
+ cs.pos() = cs.lastpos();
+ inset = 0;
+ fixed = true;
+ LYXERR(Debug::DEBUG)
+ fixIfBroken(): pit fixed endl;
+ } else if (cs.pos() cs.lastpos()) {
+ cs.pos() = cs.lastpos();
+ inset = 0;
+ fixed = true;
+ LYXERR(Debug::DEBUG)
+ fixIfBroken(): pos fixed endl;
+ } else if (i != n - 1 cs.pos() != cs.lastpos()) {
+ if (cs.inset().inMathed()) {
+inset = (cs.cell().begin()
+ + cs.pos())-nucleus();
+ } else {
+inset = cs.paragraph().isInset(cs.pos()) ?
+ cs.paragraph().getInset(cs.pos()) : 0;
+ }
}
-
- // The top level CursorSlice should always be valid.
- BOOST_ASSERT(slices_[0].isValid());
-
- if (idx() lastidx()) {
- lyxerr wrong idx idx()
- , max is lastidx()
- at level depth()
- . Trying to correct this. endl;
- lyxerr old: *this endl;
- for (size_t i = idx(); i != lastidx(); --i)
- pop_back();
- idx() = lastidx();
- pit() = lastpit();
- pos() = lastpos();
- fixed = true;
}
- else if (pit() lastpit()) {
- lyxerr wrong pit pit()
- , max is lastpit()
- at level depth()
- . Trying to correct this. endl;
- lyxerr old: *this endl;
- pit() = lastpit();
- pos() = 0;
- fixed = true;
- }
- else if (pos() lastpos()) {
- lyxerr wrong pos pos()
- , max is lastpos()
- at level depth()
- . Trying to correct this. endl;
- lyxerr old: *this endl;
- pos() = lastpos();
- fixed = true;
- }
- if (fixed) {
- lyxerr new: *this endl;
- }
+
return fixed;
}
Index: CursorSlice.h
===
--- CursorSlice.h (revision 18720)
+++ CursorSlice.h (working copy)
@@ -81,6 +81,8 @@
pit_type pit() const { return pit_; }
/// set the offset of the paragraph this cursor is in
pit_type pit() { return pit_; }
+ /// return the last paragraph offset this cursor is in
+ pit_type lastpit() const;
/// increments the paragraph this cursor is in
void incrementPar();
/// decrements the paragraph this cursor is in
Index: CursorSlice.cpp
===
--- CursorSlice.cpp (revision 18720)
+++ CursorSlice.cpp (working copy)
@@ -112,6 +112,14 @@
}
+pit_type CursorSlice::lastpit() const
+{
+ if (inset().inMathed())
+ return 0;
+ return text()-paragraphs().size() - 1;
+}
+
+
CursorSlice::row_type CursorSlice::row() const
{
BOOST_ASSERT(asInsetMath());
Re: Road to rc2 - fixIfBroken
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 complicated logic to set the inset to 0 in many cases. Won't that end the loop anyway in the next round? Yes, but cutting off the DocIterator. 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. Oh yes I forgot (too much time passed). This patch is intended to work *without* the signaling mechanism. So we should have no slice with inset == 0. So if the patch is to be applied without removing/deactivating the signaling mechanism, this slightly different version should do it, agreed? 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 :) Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: Outline panel hidden at inappropriate times
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 it should remain visible: 1. Open several documents (e.g. User's guide and Introduction), show the outline, and close one of the documents; This has been fixed in current svn, or should have been: http:// www.lyx.org/trac/changeset/18651. This was bug 3701. I tested, its ok for me. Sorry, I didn't see the bug. No problem. There are a lot of them Another remark regarding the outline panel: wouldn't it be also appropriate to save its status (visible/hidden) into the session file? Anybody has feedback about this suggestion? May I file an enhancement request at bugzilla? Mael.
Re: Road to rc2 - fixIfBroken
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
Re: Outline panel hidden at inappropriate times
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
Re: Road to rc2 - fixIfBroken
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 :) Something like this? //At the end of this loop the DocIterator should be valid, we //ensure this by working out this condition from the bottom() //to the top() slices. I guess yes. Compiling right now. If it does, that would be great. Thanks Stefan. Signals in those CursorSlices, always feel in a strange way when thinking about it :) Yes, I don't like it either. I'm trying to code something to having edition-persistent iterators(*). I have a partial solution, that includes a MarkersList administrated by the InsetList inside every paragraph. (where markers are like insets, but they just don't take out editing space). The problem right now is what to do when the paragraph is removed completely; then we lose track completely and something else has to be considered. (*) this could have many uses: cursor in other window, bookmarks, error lists etc. A/
RE: SV: [PATCH] Change default mathbg and add mathhoverbg.
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 inset? I see two solutions: 1/ an _empty_ math inset (not $\ $!) is removed when leaving it with the cursor. This is already what happens with the script inset. 2/ an _empty_ math inset (not $\ $!) does not get a preview. None of these solve the problem for an inset containing a hard space, but those who ask for trouble deserve it. maybe we should disallow a space after a backslash in math? or are there situations where this makes sense?
Re: Road to rc2 - fixIfBroken
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: lyx-devel/src/CursorSlice.cpp
===
--- lyx-devel.orig/src/CursorSlice.cpp 2007-06-02 11:24:26.0
+0200
+++ lyx-devel/src/CursorSlice.cpp 2007-06-09 12:11:13.0 +0200
@@ -42,10 +42,6 @@
: inset_(p), idx_(0), pit_(0), pos_(0)
{
BOOST_ASSERT(inset_);
- boost::signalvoid() * destroyed_signal = inset_-destroyedSignal();
- if (destroyed_signal)
- inset_connection_ = destroyed_signal-connect(
- boost::bind(CursorSlice::invalidate, this));
}
@@ -55,22 +51,12 @@
}
-CursorSlice::~CursorSlice()
-{
- inset_connection_.disconnect();
-}
-
-
CursorSlice CursorSlice::operator=(CursorSlice const cs)
{
inset_ = cs.inset_;
idx_ = cs.idx_;
pit_ = cs.pit_;
pos_ = cs.pos_;
- if (inset_ inset_-destroyedSignal()) {
- inset_connection_ = inset_-destroyedSignal()-connect(
- boost::bind(CursorSlice::invalidate, this));
- }
return *this;
}
@@ -112,6 +98,14 @@
}
+pit_type CursorSlice::lastpit() const
+{
+ if (inset().inMathed())
+ return 0;
+ return text()-paragraphs().size() - 1;
+}
+
+
CursorSlice::row_type CursorSlice::row() const
{
BOOST_ASSERT(asInsetMath());
Index: lyx-devel/src/CursorSlice.h
===
--- lyx-devel.orig/src/CursorSlice.h2007-06-02 11:24:26.0 +0200
+++ lyx-devel/src/CursorSlice.h 2007-06-09 12:12:17.0 +0200
@@ -41,7 +41,7 @@
// that of MathData and Text should vanish. They are conceptually the
// same (now...)
-class CursorSlice : public boost::signals::trackable {
+class CursorSlice {
public:
/// Those needs inset_ access.
///@{
@@ -63,8 +63,6 @@
///
explicit CursorSlice(Inset );
///
- virtual ~CursorSlice();
- ///
CursorSlice operator=(CursorSlice const );
///
bool isValid() const;
@@ -81,6 +79,8 @@
pit_type pit() const { return pit_; }
/// set the offset of the paragraph this cursor is in
pit_type pit() { return pit_; }
+ /// return the last paragraph offset this cursor is in
+ pit_type lastpit() const;
/// increments the paragraph this cursor is in
void incrementPar();
/// decrements the paragraph this cursor is in
@@ -158,8 +158,6 @@
bool pit_valid_;
/// position in this cell
pos_type pos_;
- /// connection to referred \c inset_ destruction signal.
- boost::signals::connection inset_connection_;
};
/// test for equality
Index: lyx-devel/src/DocIterator.cpp
===
--- lyx-devel.orig/src/DocIterator.cpp 2007-06-08 22:20:09.0
+0200
+++ lyx-devel/src/DocIterator.cpp 2007-06-09 12:44:07.0 +0200
@@ -4,6 +4,7 @@
* Licence details can be found in the file COPYING.
*
* \author André Pönitz
+ * \author Alfredo Braunstein
*
* Full author contact details are available in file CREDITS.
*/
@@ -560,53 +561,55 @@
bool DocIterator::fixIfBroken()
{
- bool fixed = false;
-
- for (size_t i = slices_.size() - 1; i != 0; --i)
- if (!slices_[i].isValid()) {
- pop_back();
- fixed = true;
+ // Go through the slice stack from the bottom.
+ // Check that all coordinates (idx, pit, pos) are correct and
+ // that the inset is the one which is claimed to be there
+ Inset * inset = slices_[0].inset();
+ size_t i = 0;
+ size_t n = slices_.size();
+ for (; i != n; ++i) {
+ CursorSlice cs = slices_[i];
+ if (cs.inset() != inset) {
+ // the whole slice is wrong, chop off this as well
+ --i;
+ LYXERR(Debug::DEBUG) fixIfBroken(): inset changed
endl;
+ break;
+ } else if (cs.idx() cs.lastidx()) {
+ cs.idx() = cs.lastidx();
+ cs.pit() = cs.lastpit();
+ cs.pos() = cs.lastpos();
+ LYXERR(Debug::DEBUG) fixIfBroken(): idx fixed
endl;
+ break;
+ } else if (cs.pit() cs.lastpit()) {
+ cs.pit() = cs.lastpit();
+ cs.pos() = cs.lastpos();
+ LYXERR(Debug::DEBUG) fixIfBroken(): pit fixed
endl;
+ break;
+ } else if (cs.pos() cs.lastpos()) {
+ cs.pos() = cs.lastpos();
+
Re: Outline panel hidden at inappropriate times
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.
Re: Close tab button
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
Re: Road to rc2 - fixIfBroken
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 right now. Give me a couple of hours. A/
Re: Converter problem with Mac OS packages
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 Mac OS. Well, of course, we need to find a consensus on how updates should be done... At the end, will we use a timestamp alone or in conjunction with CRC? IMHO, the timestamp is sufficient and I didn't encounter inconsistencies while using the existing patch (in which the CRC isn't used for directories). In contrast, you (Andre and Jean-Marc) think a Timestap+CRC would be better. Andre said that some problems could arise when saving a file more than one time within a second. For my part, I think that this situation won't arise when dealing with external graphics. Perhaps you had a more general point of view and thought about other conversions such as in math previews, or anything else... But as I'm new to LyX sources, I don't know much about how the preview mechanism is led. I think we really need to clarify how an update should be triggered. We could start by describing the problem as follows: * Approach: Timestamp (i), Timestamp+CRC (ii) * Contents changed? Yes (1), no (2) * Timestamp changed? Yes (a), no (b) All possible situations are: * 1a: this case leads to an update in (i) and (ii). If we use (i) the test is cheaper; * 1b: this situation is inconsistent: the editor updated the contents but not the timestamp of the directory, or it updated the timestamp but didn't change it (less than 1 sec interval). If we use (i) this situation cannot be detected whereas it can if we use (ii); * 2a: this situation is inconsistent: the user updated the file without changing its contents. It cannot be reached if situation 1b can (excluding the 1 sec problem), and conversely. If we use (ii) the test is cheaper assuming that the conversion process is more expensive than the CRC; * 2b: no modification is made in both (i) and (ii). If we use (i), the test is cheaper. Recall: IMO 1a and 2b are the most frequently, 2a is rare and 1b never occurs when dealing with external graphics. That's why I would pitch on approach (i). The questions are mainly: should we consider that situation 1b can arise or not? And is it worthwhile to save time in 2a if we loose time in 1a and 2b? Could anyone give us more information/suggestions/ point of views about this? Finally, what kind of #ifdef should be used: Should we select Mac OS only, or should we create some variable for OSes providing graphics as directories (e.g. #ifdef HAVE_GRAPHICS_DIR)? Mael.
Re: Road to rc2 - fixIfBroken
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 the signals finally like this. Sure, but I cannot right now. Give me a couple of hours. Ok. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: Road to rc2 - fixIfBroken
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 it looks fine. Abdel.
Re: BufferView - tab
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 this point we will switch to a QTabWidget instead of the hand made widget with a QTabBar. 1.6 matter... A/ Ab/
Re: [PATCH] Bug 3711, add insets without valid ParConstIterator to TOC.
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 constructor like ParConstIterator(0) so I can not test special cases in update(). Per the use of exception, I think exception should be used more often in lyx. For example, counters are not updated immediately after, say, an caption is added to InsetInclude. It would be good to have something like try work on inset going on except updateCounter (+1, or -1) except updateScreen (partial or all) except kill me please Just some random thought. IMHO exceptions should only be used in _exceptional_ situation because they bypass the normal function to function communication. I think the way you want to use them is going to slow down the code significantly. This is reason why I don't like for example the way exceptions are misused in the listings code. Abdel.
Re: Road to rc2 - fixIfBroken
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 this. I am not Alfredo but it looks fine. I'd say shove it in. ;-) A/
[patch] sometimes only paragraph of cursor is visible, #3231
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 change in the patch, evaluate to true and the grey bars are drawn. Here is a backtrace of the issue: #0 lyx::paintText ([EMAIL PROTECTED], [EMAIL PROTECTED]) at /Users/sts/ Quellen/mac/lyx-devel/src/rowpainter.cpp:1065 #1 0x0023570a in lyx::frontend::GuiWorkArea::updateScreen (this=0x261a0e30) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/ qt4/GuiWorkArea.cpp:592 #2 0x0023574f in lyx::frontend::GuiWorkArea::expose (this=0x261a0e30, x=0, y=31, w=671, h=105) at /Users/sts/Quellen/mac/ lyx-devel/src/frontends/qt4/GuiWorkArea.cpp:575 #3 0x0022295a in lyx::frontend::WorkArea::redraw (this=0x261a0e44) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/WorkArea.cpp:159 #4 0x00223212 in lyx::frontend::WorkArea::dispatch (this=0x261a0e44, [EMAIL PROTECTED], k=none) at /Users/sts/Quellen/mac/lyx-devel/src/ frontends/WorkArea.cpp:218 #5 0x00237432 in lyx::frontend::GuiWorkArea::mouseMoveEvent (this=0x261a0e30, e=0xbfffefe0) at /Users/sts/Quellen/mac/lyx-devel/ src/frontends/qt4/GuiWorkArea.cpp:414 It happened with two footnote in the view, just moving the mouse around. So could it be related to the mouse hover maybe? I think though that the change in the patch is reasonable nevertheless. The comparison to SingleParUpdate is wrong. The drawText function must work with every update_strategy. Stefan Index: lyx-devel/src/rowpainter.cpp === --- lyx-devel.orig/src/rowpainter.cpp 2007-06-08 07:09:41.0 +0200 +++ lyx-devel/src/rowpainter.cpp2007-06-09 14:17:25.0 +0200 @@ -1061,12 +1061,12 @@ // and grey out above (should not happen later) // lyxerr par ascent: text.getPar(vi.p1).ascent() endl; - if (vi.y1 0 vi.update_strategy != SingleParUpdate) + if (vi.y1 0 vi.update_strategy == FullScreenUpdate) pain.fillRectangle(0, 0, bv.workWidth(), vi.y1, Color::bottomarea); // and possibly grey out below // lyxerr par descent: text.getPar(vi.p1).ascent() endl; - if (vi.y2 bv.workHeight() vi.update_strategy != SingleParUpdate) + if (vi.y2 bv.workHeight() vi.update_strategy == FullScreenUpdate) pain.fillRectangle(0, vi.y2, bv.workWidth(), bv.workHeight() - vi.y2, Color::bottomarea); } PGP.sig Description: Signierter Teil der Nachricht
Re: [PATCH] Part of Bug 3719 -- TOC out of sync
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 impossible to consider all cases and update Toc. Yes, you are absolutely right. It's too bad, really. I think Abdel was right to want it to update automatically, but there are too many cases. Wait, when you modify a section text, only the corresponding TocItem is updated, not the full TocBackend (Have a look at TocBackend::updateItem()). The item updating is done only for sections, not for captions because of the limitation of the Inset::addToToc() method. I see that you changed that now so we can synchronize the view and the TocBackend for captions and listings too in a very cheap way now. I don't have the time to read all the messages since last week but if you decided to deleted these update calls please give me a summary of the discussion. Abdel.
Re: Crash with the new TOC widget
Done #3843
Re: compile error
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': /Users/sts/Quellen/mac/lyx-devel/src/mathed/InsetMathMBox.cpp:73: error: 'drawMarkers' was not declared in this scope 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. Abdel.
Re: BufferView - tab
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 one BufferView per tab. At this point we will switch to a QTabWidget instead of the hand made widget with a QTabBar. 1.6 matter... Cool... I've been wanting this for ages, and now there's finally agreement! A/
Re: Road to rc2 - fixIfBroken
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 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 it looks fine. I'd say shove it in. ;-) A/ PGP.sig Description: Signierter Teil der Nachricht
Re: [PATCH] Part of Bug 3719 -- TOC out of sync
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 consider all cases and update Toc. Because TocBackend::update() is expansive, I even think we should remove all such calls triggered by, e.g., changing the environment of a paragraph to section. 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. Abdel.
Re: Crash with the new TOC widget
[EMAIL PROTECTED] wrote: Done Thanks. I confirmed it and targetted it to 1.5.0. Jürgen
Re: Road to rc2 - fixIfBroken
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.
Re: Road to rc2 - fixIfBroken
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 too. Right. But then we can also do it now and add it again if we need it? Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: Road to rc2 - fixIfBroken
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 should be deleted before RC2 too. Right. But then we can also do it now and add it again if we need it? Yep, as you feel. Abdel.
Re: [PATCH] Part of Bug 3719 -- TOC out of sync
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 are cheap as you described, it is perfectly fine to me to make TocUpdate automatic. Bo
Re: Road to rc2 - fixIfBroken
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 should be deleted before RC2 too. Right. But then we can also do it now and add it again if we need it? I'll do it. Abdel
Re: compile error
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
Re: [PATCH] Part of Bug 3719 -- TOC out of sync
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 the operators are cheap as you described, it is perfectly fine to me to make TocUpdate automatic. Good, thanks. Abdel.
Re: [PATCH] Part of Bug 3719 -- TOC out of sync
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 when we enter each character when editing a caption, but there is no proper way to know 'editing is done here'... Bo
Re: lyx farsi support??
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). In principle Farsi should be already supported in current svn (and since RC1 AFAIR). You are of course welcome to help us polishing it and more generally polishing Right-To-Left language support (which has seen a lot of activity recently) First thing to do is to test LyX-svn ;-) Abdel.
Re: Road to rc2 - fixIfBroken
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 don't need the Inset::destroyed() signal, this should be deleted before RC2 too. Right. But then we can also do it now and add it again if we need it? Nice, now it's even usable again with stdlib-debug enabled. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [PATCH] Allow parameters to bypass InsetListingsParams validation.
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
Re: [PATCH] Part of Bug 3719 -- TOC out of sync
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 discussed, the problem lies in 'when to update Toc'. It is unwise to update Toc when we enter each character when editing a caption, but there is no proper way to know 'editing is done here'... The proper way is to check the Buffer structure when you are editing the caption with a call to checkBufferStructure(), maybe this is already done. Then you also need to correct InsetCaption::addToToc(), the same way as you did with InsetListings. Finally, you'll have to make sure that TocBackend::updateItem() properly find the correct TocItem. Not a lot of work but a lot of testing is required. Abdel.
Re: [PATCH] Allow parameters to bypass InsetListingsParams validation.
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 upgradable. Abdel.
Re: r18728 - in /lyx-devel/trunk/src/insets: InsetListings.cp...
[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
Re: r18728 - in /lyx-devel/trunk/src/insets: InsetListings.cp...
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 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). Cheers, Bo
Re: Crash with the new TOC widget
[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
std::_Vector_const_iteratorlyx::TocItem,std::allocatorlyx::TocItem
it={par_it_={...} depth_=3 str_={...} }) Line 57 + 0x13 bytes C++
lyx-qt4.exe!lyx::frontend::QToc::getCurrentIndex(int type=2) Line 90
+ 0x44 bytes C++
lyx-qt4.exe!lyx::frontend::TocWidget::update() Line 235 + 0x25 bytes
C++
lyx-qt4.exe!lyx::frontend::DockViewlyx::frontend::QToc,lyx::frontend::TocWidget::update()
Line 62 C++
lyx-qt4.exe!lyx::frontend::Dialog::checkStatus() Line 192 + 0x1a
bytes C++
lyx-qt4.exe!lyx::Dialogs::checkStatus() Line 256 C++
lyx-qt4.exe!lyx::LyXView::updateToolbars() Line 347C++
lyx-qt4.exe!lyx::LyXFunc::dispatch(const lyx::FuncRequest
cmd={...}) Line 1817 C++
lyx-qt4.exe!lyx::dispatch(const lyx::FuncRequest action={...})
Line 1464 C++
lyx-qt4.exe!lyx::LyXView::dispatch(const lyx::FuncRequest
cmd={...}) Line 446 + 0x9 bytes C++
lyx-qt4.exe!lyx::frontend::Action::action() Line 91C++
Re: r18728 - in /lyx-devel/trunk/src/insets: InsetListings.cp...
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 opened by an older version (rc1, for instance)? I guess LyX will crash, no? Jürgen
Re: Close tab button
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 available. pavel 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. Peter
Re: Close tab button
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
Re: r18728 - in /lyx-devel/trunk/src/insets: InsetListings.cp...
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 course, to minimize the use of this feature, I will have to look through the parameters again, using the latest listings version. Bo
Re: [PATCH] 2697: SplitLayout environment.
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
LatexName dummy
ParIndent MM
Align Block
AlignPossible Block
LabelType Static
LabelString --- Split Layout ---
LabelFont
Family Roman
Series Medium
SizeNormal
Color Blue
EndFont
End
Jose, OK to commit?
Bo
Index: src/Buffer.cpp
===
--- src/Buffer.cpp (revision 18726)
+++ src/Buffer.cpp (working copy)
@@ -142,7 +142,7 @@
namespace {
-int const LYX_FORMAT = 271;
+int const LYX_FORMAT = 272;
} // namespace anon
Index: lib/lyx2lyx/LyX.py
===
--- lib/lyx2lyx/LyX.py (revision 18726)
+++ lib/lyx2lyx/LyX.py (working copy)
@@ -77,7 +77,7 @@
(1_2, [220], generate_minor_versions(1.2 , 4)),
(1_3, [221], generate_minor_versions(1.3 , 7)),
(1_4, range(222,246), generate_minor_versions(1.4 , 4)),
- (1_5, range(246,272), generate_minor_versions(1.5 , 0))]
+ (1_5, range(246,273), generate_minor_versions(1.5 , 0))]
def formats_list():
Index: lib/lyx2lyx/lyx_1_5.py
===
--- lib/lyx2lyx/lyx_1_5.py (revision 18726)
+++ lib/lyx2lyx/lyx_1_5.py (working copy)
@@ -1656,7 +1656,53 @@
else:
del document.header[i]
+def revert_splitlayout(document):
+r''' Revert SplitLayout to a lyx node
+From
+\begin_layout SplitLayout
+something
+\end_layout
+
+to
+
+\begin_layout Standard
+\begin_inset Note Note
+status open
+
+\begin_layout Standard
+end evironmnet
+\end_layout
+
+\end_inset
+something
+
+\end_layout
+
+'''
+
+i = 0
+while True:
+i = find_token(document.body, r'\begin_layout SplitLayout', i)
+if i == -1:
+break
+j = find_end_of_layout(document.body, i + 1)
+if j == -1:
+# this should not happen
+break
+document.body[i : j + 1] = [r'\begin_layout Standard',
+r'\begin_inset Note Note',
+'status open',
+'',
+r'\begin_layout Standard',
+'Split Layout',
+r'\end_layout',
+'',
+r'\end_inset'] + \
+document.body[ i + 1 : j] + \
+['',
+r'\end_layout'
+]
##
# Conversion hub
#
@@ -1687,10 +1733,12 @@
[268, []],
[269, []],
[270, []],
- [271, [convert_ext_font_sizes]]
+ [271, [convert_ext_font_sizes]],
+ [272, []],
]
revert = [
+ [271, [revert_splitlayout]],
[270, [revert_ext_font_sizes]],
[269, [revert_beamer_alert, revert_beamer_structure]],
[268, [revert_preamble_listings_params, revert_listings_inset, revert_include_listings]],
Index: lib/layouts/stdlayouts.inc
===
--- lib/layouts/stdlayouts.inc (revision 18726)
+++ lib/layouts/stdlayouts.inc (working copy)
@@ -61,5 +61,20 @@
End
-
-
+Style SplitLayout
+ KeepEmpty 1
+ MarginDynamic
+ LatexType Paragraph
+ LatexName dummy
+ ParIndent MM
+ Align Block
+ AlignPossible Block
+ LabelType Static
+ LabelString --- Split Layout ---
+ LabelFont
+ Family Roman
+ Series Medium
+ SizeNormal
+ Color Blue
+ EndFont
+End
Index: lib/doc/UserGuide.lyx
===
--- lib/doc/UserGuide.lyx (revision 18726)
+++ lib/doc/UserGuide.lyx (working copy)
@@ -1,5 +1,5 @@
#LyX 1.5.0svn created this file. For more info see http://www.lyx.org/
-\lyxformat 263
+\lyxformat 272
\begin_document
\begin_header
\textclass scrbook
@@ -91,8 +91,9 @@
\paperpagestyle default
\tracking_changes false
\output_changes false
-\author usti
-\author Uwe Stöhr
+\author Bo Peng
+\author usti
+\author Uwe Stöhr
\end_header
\begin_body
@@ -9278,6 +9279,28 @@
\end_layout
+\begin_layout Standard
+In case that you want to start a new list immediately
Re: EndEnvironment layout entry.
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 wrong to Richard force extra work in that case. Surely we'd get a lot more Richard complaints if the case at issue here were the more common Richard one. That is possible indeed. Inserting boxes for anything one wants to do is not a very exiting prospect either :) You don't want to make the easy case hard. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH] 2697: SplitLayout environment.
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 I've said, this comes up on the user list from time to time, too, and I even filed an enhancement request related to this. Bo's solution may not be perfect, but it works. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: r18728 - in /lyx-devel/trunk/src/insets: InsetListings.cp...
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 1.4 assured? I.e., will @extraparams be reverted to ERT correctly? IMHO , the only way to assure all this is to bump the file format _immediately_ and add a lyx2lyx reversion step that converts all listings insets that contain @extraparams to ERT. If not, the LyX backwards chain is corrupted. Of course, to minimize the use of this feature, I will have to look through the parameters again, using the latest listings version. This does not matter. Jürgen
Re: Change tracking and replace: unexpected behavior
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 text (such that it is gone) or reject a deletion and change the text afterwards. After all, the user is always able to edit his text. Nonetheless, I think even manual replace ought to skip deleted text. It's not expected behavior even on manual replace to replace deleted text with undeleted text (as the patch currently allows). And I don't think we should replace deleted text with deleted text either: that obscures the document history which is part of the point of change tracking. IMHO, find replace should always ignore deleted text, in CT mode as well as in non-CT mode. Michael
Re: r18728 - in /lyx-devel/trunk/src/insets: InsetListings.cp...
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 to assure all this is to bump the file format _immediately_ and add a lyx2lyx reversion step that converts all listings insets that contain @extraparams to ERT. We already have lyx2lyx entries to convert InsetListings to ERT so I will just modify them. Adding a separate entry will only benefit RC1 so I do not really want to do that. Sure, if you use RC1 to open a file with @para, @para will not pass validation. However, @para is supposed to be used when para can not pass validation, so removing @ through lyx2lyx will not help. Cheers, Bo
Re: Change tracking and replace: unexpected behavior
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. That's exactly what we do. IOW: There is no problem. Michael
Re: r18728 - in /lyx-devel/trunk/src/insets: InsetListings.cp...
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. No, that's wrong. IMHO , the only way to assure all this is to bump the file format _immediately_ and add a lyx2lyx reversion step that converts all listings insets that contain @extraparams to ERT. We already have lyx2lyx entries to convert InsetListings to ERT so I will just modify them. You have to create another one. And you'll have to change the file format for every new parameter you will add in the future (to add the '@'). Adding a separate entry will only benefit RC1 so I do not really want to do that. Sure, if you use RC1 to open a file with @para, @para will not pass validation. However, @para is supposed to be used when para can not pass validation, so removing @ through lyx2lyx will not help. I didn't say removing. When @para is used, you'll have to transfer the whole listing to ERT for rc1 and friends, and include para (without the @). There's no other possibility IMO. Cheers, Bo Jürgen
Re: Change tracking and replace: unexpected behavior
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
Bug #3812: Comments on patch
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 (Arbeitskopie)
@@ -101,20 +101,26 @@
};
-bool findForward(DocIterator cur, MatchString const match)
+bool findForward(DocIterator cur, MatchString const match,
+bool find_del = true)
{
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()))
return true;
return false;
}
AFAICS, you only check the deletion status of the first character. However, ALL matching characters shouldn't be marked as deleted.
-bool findBackwards(DocIterator cur, MatchString const match)
+bool findBackwards(DocIterator cur, MatchString const match,
+bool find_del = true)
{
while (cur) {
cur.backwardChar();
- if (cur.inTexted() match(cur.paragraph(), cur.pos()))
+ if (cur.inTexted()
+ (find_del || !cur.paragraph().isDeleted(cur.pos()))
+ match(cur.paragraph(), cur.pos()))
return true;
}
return false;
The same here. Maybe we should propagate find_del to match(...).
+ case LFUN_WORD_REPLACE:
+ flag.enabled(!cur.paragraph().isDeleted(cur.pos()));
+ break;
+
... and here (but I am willing to accept this minor bug) ...
*** The End ***
Re: Bug #3812: Comments on patch
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())) return true; return false; } AFAICS, you only check the deletion status of the first character. However, ALL matching characters shouldn't be marked as deleted. I don't understand. I just assure that a character is skipped on find if it is marked deleted. Since the loop moves ahead, this test applies to all characters of a word. And nothing will be marked anyway. Or do I miss something? Jürgen
[patch] Up/down cursor in math-macro jumps out of the macro, #3830
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
+++ lyx-devel/src/mathed/MathMacro.cpp 2007-06-09 18:24:35.0
+0200
@@ -254,6 +254,22 @@
}
+bool MathMacro::idxUpDown(Cursor cur, bool up) const
+{
+ if (up) {
+ if (cur.idx() == 0)
+ return false;
+ --cur.idx();
+ } else {
+ if (cur.idx() = nargs() - 1)
+ return false;
+ ++cur.idx();
+ }
+ cur.pos() = cell(cur.idx()).x2pos(cur.x_target());
+ return true;
+}
+
+
bool MathMacro::notifyCursorLeaves(Cursor cur)
{
cur.updateFlags(Update::Force);
Index: lyx-devel/src/mathed/MathMacro.h
===
--- lyx-devel.orig/src/mathed/MathMacro.h 2007-05-19
19:12:30.0 +0200
+++ lyx-devel/src/mathed/MathMacro.h2007-06-09 18:14:31.0 +0200
@@ -48,6 +48,8 @@
/// target pos when we enter the inset from the right by pressing
Left
bool idxLast(Cursor ) const;
///
+ bool MathMacro::idxUpDown(Cursor cur, bool up) const;
+ ///
virtual bool notifyCursorLeaves(Cursor );
///
docstring name() const;
PGP.sig
Description: Signierter Teil der Nachricht
Re: Bug #3812: Comments on patch
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())) + match(cur.paragraph(), cur.pos())) return true; return false; } AFAICS, you only check the deletion status of the first character. However, ALL matching characters shouldn't be marked as deleted. I don't understand. I just assure that a character is skipped on find if it is marked deleted. Since the loop moves ahead, this test applies to all characters of a word. And nothing will be marked anyway. Or do I miss something? Maybe I was talking nonsense. I just looked at the patch (without the surrounding code). It looked like you check for the first character and then match(...) tries to match the complete string. If this isn't true, please ingore my comment and ask for another OK. (I have to leave in a few seconds.) Michael
Re: r18728 - in /lyx-devel/trunk/src/insets: InsetListings.cp...
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? Bo
Re: [PATCH] 2697: SplitLayout environment.
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
Re: [PATCH] 2697: SplitLayout environment.
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
[PATCH] Add bypass validation checkboxes to dialogs that enter listings parameters
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 format is changed so no lyx2lyx is needed.
There has been a lot of underlying changes. exception invalidParam is
removed and validation is no longer triggered automatically.
Transmission of parameters will not be checked. An error message is
returned explicitly when InsetListingsParams::validate() is called
from GUI dialogs.
Please test.
Cheers,
Bo
Index: src/insets/InsetListingsParams.h
===
--- src/insets/InsetListingsParams.h (revision 18729)
+++ src/insets/InsetListingsParams.h (working copy)
@@ -74,6 +74,9 @@
///
void clear() { params_.clear(); }
+
+ /// validate parameter, return an error message
+ docstring validate() const;
private:
/// inline or normal listings
@@ -87,22 +90,6 @@
};
-class invalidParam : public std::exception {
-public:
- invalidParam(docstring const details)
- : details_(to_utf8(details))
- {}
-
- virtual const char * what() const throw() {
- return details_.c_str();
- }
-
- virtual ~invalidParam() throw() {}
-private:
- std::string const details_;
-};
-
-
} // namespace lyx
#endif
Index: src/insets/InsetListingsParams.cpp
===
--- src/insets/InsetListingsParams.cpp (revision 18729)
+++ src/insets/InsetListingsParams.cpp (working copy)
@@ -271,15 +271,13 @@
public:
ParValidator();
- /// \return the associated \c ListingsParam.
- /// \warning an \c invalidParamexception will be thrown
- /// if the key is not found.
- ListingsParam const param(string const key) const;
+ /// validate a parameter for a given name.
+ /// return an error message if \c par is an invalid parameter.
+ docstring validate(string const name, string const par) const;
- /// validate a parameter for a given key.
- /// \warning an \c invalidParam exception will be thrown if
- /// \c par is an invalid parameter.
- ListingsParam const validate(string const key, string const par) const;
+ /// return the onoff status of a parameter \c key, if \c key is not found
+ /// return false
+ bool onoff(string const key) const;
private:
/// key is the name of the parameter
@@ -584,21 +582,11 @@
}
-ListingsParam const ParValidator::validate(string const key,
+docstring ParValidator::validate(string const name,
string const par) const
{
- ListingsParam const lparam = param(key);
- docstring s = lparam.validate(par);
- if (!s.empty())
- throw invalidParam(bformat(_(Parameter %1$s: ), from_utf8(key)) + s);
- return lparam;
-}
-
-
-ListingsParam const ParValidator::param(string const name) const
-{
if (name.empty())
- throw invalidParam(_(Invalid (empty) listing parameter name.));
+ return _(Invalid (empty) listing parameter name.);
if (name[0] == '?') {
string suffix = trim(string(name, 1));
@@ -613,39 +601,59 @@
}
}
if (suffix.empty())
- throw invalidParam(bformat(
- _(Available listing parameters are %1$s), from_ascii(param_names)));
+ return bformat(
+ _(Available listing parameters are %1$s), from_ascii(param_names));
else
- throw invalidParam(bformat(
+ return bformat(
_(Available listings parameters containing string \%1$s\ are %2$s),
- from_utf8(suffix), from_utf8(param_names)));
+ from_utf8(suffix), from_utf8(param_names));
}
// locate name in parameter table
ListingsParams::const_iterator it = all_params_.find(name);
- if (it != all_params_.end())
- return it-second;
-
- // otherwise, produce a meaningful error message.
- string matching_names;
- ListingsParams::const_iterator end = all_params_.end();
- for (it = all_params_.begin(); it != end; ++it) {
- if (prefixIs(it-first, name)) {
- if (!matching_names.empty())
-matching_names += , ;
- matching_names += it-first;
+ if (it != all_params_.end()) {
+ docstring msg = it-second.validate(par);
+ if (msg.empty())
+ return msg;
+ else
+ return bformat(_(Parameter %1$s: ), from_utf8(name)) + msg;
+ } else {
+ // otherwise, produce a meaningful error message.
+ string matching_names;
+ ListingsParams::const_iterator end = all_params_.end();
+ for (it = all_params_.begin(); it != end; ++it) {
+ if (prefixIs(it-first, name)) {
+if (!matching_names.empty())
+ matching_names += , ;
+matching_names += it-first;
+ }
}
+ if (matching_names.empty())
+ return bformat(_(Unknown listing parameter name: %1$s),
+from_utf8(name));
+ else
+ return bformat(_(Parameters starting with '%1$s': %2$s),
+from_utf8(name), from_utf8(matching_names));
}
- if (matching_names.empty())
- throw invalidParam(bformat(_(Unknown listing parameter name: %1$s),
- from_utf8(name)));
Re: [patch] fixing segfault because of empty coord cache
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 analysis! I would say that the fix is correct, but I'd wait for Andre's input. JMarc Hear, hear. This kind of analysis should be in the code, as comment. Do I understand correctly that this presupposes that 1) every mathinset must have an isActive method and 2) it should return true only if the inset has really accessible cells? 1) You get it for free if you derive from InsetMathNest. It returns true if you have at least one cell. Any inset just derived from InsetMath, but not from InsetMathNest do not need it. 2) Yes, if you use a InsetMathNest with cells you better do not return true if you do not draw the cells. Stefan PGP.sig Description: Signierter Teil der Nachricht
serious bug
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 presume you know already that the math panel does not toggle in this version (it did in beta 3). best bm. -- - W. Bentley MacLeod Professor and Co-Director, Program for Economic Research Columbia University 420 West 118th, Mail Code 3308 New York, NY 10027-7296 Email: [EMAIL PROTECTED]
Re: serious bug
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
Re: serious bug
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 confirmed. i filed the bug http://bugzilla.lyx.org/show_bug.cgi?id=3844 . thank you for reporting. pavel
Re: Crash with the new TOC widget
[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 copy- construct an iterator from a singular iterator. The problem has been introduced at revision 18693 URL: http://www.lyx.org/trac/changeset/18693 Log: Update Toc when navigation menu is trigged. This is fixed now. Abdel. Author: younes Date: Sun Jun 10 00:21:21 2007 New Revision: 18730 URL: http://www.lyx.org/trac/changeset/18730 Log: Fix missing signal emission following revision 18693. Modified: lyx-devel/trunk/src/MenuBackend.cpp Modified: lyx-devel/trunk/src/MenuBackend.cpp URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/MenuBackend.cpp?rev=18730 == --- lyx-devel/trunk/src/MenuBackend.cpp (original) +++ lyx-devel/trunk/src/MenuBackend.cpp Sun Jun 10 00:21:21 2007 @@ -705,7 +705,9 @@ return; } - const_castBuffer*(buf)-tocBackend().update(); + Buffer* cbuf = const_castBuffer*(buf); + cbuf-tocBackend().update(); + cbuf-structureChanged(); // Add an entry for the master doc if this is a child doc Buffer const * const master = buf-getMasterBuffer();
Re: serious bug
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 confirmed. i filed the bug http://bugzilla.lyx.org/show_bug.cgi?id=3844 . Strange, I cannot reproduce. A/
Re: serious bug
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 on XP service pack 2. I can't reproduce the crash with current svn. I presume you know already that the math panel does not toggle in this version (it did in beta 3). This neither. Abdel.
Re: serious bug
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. - W. Bentley MacLeod confirmed. i filed the bug http://bugzilla.lyx.org/show_bug.cgi?id=3844 . Strange, I cannot reproduce. linux, btw. A/
Re: serious bug
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
Re: [patch] sometimes only paragraph of cursor is visible, #3231
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, but the ViewMetric.update_strategy is set to NoScreenUpdate. The two condition, that I change in the patch, evaluate to true and the grey bars are drawn. Here is a backtrace of the issue: #0 lyx::paintText ([EMAIL PROTECTED], [EMAIL PROTECTED]) at /Users/sts/Quellen/mac/lyx-devel/src/rowpainter.cpp:1065 #1 0x0023570a in lyx::frontend::GuiWorkArea::updateScreen (this=0x261a0e30) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/qt4/GuiWorkArea.cpp:592 #2 0x0023574f in lyx::frontend::GuiWorkArea::expose (this=0x261a0e30, x=0, y=31, w=671, h=105) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/qt4/GuiWorkArea.cpp:575 #3 0x0022295a in lyx::frontend::WorkArea::redraw (this=0x261a0e44) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/WorkArea.cpp:159 #4 0x00223212 in lyx::frontend::WorkArea::dispatch (this=0x261a0e44, [EMAIL PROTECTED], k=none) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/WorkArea.cpp:218 #5 0x00237432 in lyx::frontend::GuiWorkArea::mouseMoveEvent (this=0x261a0e30, e=0xbfffefe0) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/qt4/GuiWorkArea.cpp:414 It happened with two footnote in the view, just moving the mouse around. So could it be related to the mouse hover maybe? I think though that the change in the patch is reasonable nevertheless. The comparison to SingleParUpdate is wrong. The drawText function must work with every update_strategy. Stefan Index: lyx-devel/src/rowpainter.cpp === --- lyx-devel.orig/src/rowpainter.cpp2007-06-08 07:09:41.0 +0200 +++ lyx-devel/src/rowpainter.cpp2007-06-09 14:17:25.0 +0200 @@ -1061,12 +1061,12 @@ // and grey out above (should not happen later) //lyxerr par ascent: text.getPar(vi.p1).ascent() endl; -if (vi.y1 0 vi.update_strategy != SingleParUpdate) +if (vi.y1 0 vi.update_strategy == FullScreenUpdate) pain.fillRectangle(0, 0, bv.workWidth(), vi.y1, Color::bottomarea); // and possibly grey out below //lyxerr par descent: text.getPar(vi.p1).ascent() endl; -if (vi.y2 bv.workHeight() vi.update_strategy != SingleParUpdate) +if (vi.y2 bv.workHeight() vi.update_strategy == FullScreenUpdate) pain.fillRectangle(0, vi.y2, bv.workWidth(), bv.workHeight() - vi.y2, Color::bottomarea); } -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Spaces on RTL boundaries
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 today and the last days...
That depends on the format when the change happened. If it was during the
1.5 development cycle I would introduce a new file format now and declare
all 1.5svn versions between the original change and this new format
buggy.
We did this for example with format 261.
If it was earlier you can't simply declare stable versions buggy (and
people
will have corrected the wrong spaces by hand if they noticed), so it is
better to put the conversion between the old formats. Then it will at
least
help people who now convert old documents.
Georg
Hi!
Georg, there never was a format change of this issue, but their *should*
have been, because although the format of the lyx file was not changed,
its interpretation *was* (not by us now, but back when the original
change in the latex generation occurred, see below; as Stefan pointed
out, all we did now was to bring the GUI up to date with the change
which already occurred then in the latex generation).
The change I'm talking about occurred somewhere between 17143 and 17158
(I think it's 17144, but there are other changes in the above range
which may be somewhat related, and format change 259 is somewhere in the
middle there, too...).
This is the issue: until 17143 (including), abc[FED ] ghi was output
to latex as abc \R{DEF} ghi; but starting with 17144, the output for
the same text (no change in the .lyx file at all!) became abc\R{ DEF}
ghi. So a format change is needed which explicitly changes the .lyx
file: any occurrence of abc[FED ] ghi should be changed to abc [FED]
ghi, in order that the same latex output be generated. (Note that there
is no need for doing anything when downgrading: both forms will be
interpreted identically in the old LyX versions, so we can just as
easily use the new format, in this respect. It's just that there are
some things which couldn't be typeset before 17144, so the explicit
differentiation wasn't needed.)
I think that in order to deal with this cleanly, what we have to do is
this: we create a new file format *now* (at first I was thinking we
should use version 259 to tag these differences, because it was so close
to when the changes were actually made; but then I realized the
following: if someone has already converted from pre-259 to post-259,
then if we now make this lyx2lyx change as part of 259, then that file
will never get fixed; so we need to do it now, so that already-converted
files will also get fixed. I'm not so worried about post-259 files where
the above construct now exists on purpose, because it's very very rare
for someone to really want it; in fact, I assume that even now it's just
an oversight on the part of the user). This new file format doesn't have
any real format changes associated with it, except that the version
number gets incremented. Besides that, what the conversion does is to
find occurrences of space which appear between LTR and RTL sections,
and makes sure that they are in the language which has the same
direction as the language of the paragraph.
So:
1) Does this sound right?
2) How do I do it in lyx2lyx? I looked at normalize_font_whitespace() ---
*** I now see what the problem is! What we need is *exactly* the change
of format 259; but in lyx2lyx, the \\lang property wasn't included for
some reason! The attached patch fixes this, and the output is now OK
(i.e., with this patch, a file created from before the change (also
attached), and in which the problem occurs, is output correctly and
displays correctly in the GUI even now!). But anyway, for the reasons
outlined above, I still think it's more correct to do this is a
separate, new file format, effective as of now. I guess that means
duplicating normalize_font_whitespace(), but having it now act *only* on
the lang property (Georg, you may want to make sure there aren't any
other forgotten properties, once we're at it...), and applying the new
function as the converter to a new file format...
So Georg, does all this make sense? And if so, could you please take
care of it? I guess we also need Jose's OK for this...
Thanks!
Dov
Index: lib/lyx2lyx/lyx_1_5.py
===
--- lib/lyx2lyx/lyx_1_5.py (revision 17158)
+++ lib/lyx2lyx/lyx_1_5.py (working copy)
@@ -1101,6 +1101,7 @@
\\color: none,
\\shape: default,
\\bar: default,
+ \\lang: default,
\\family: default}
changes = {}
Re: lyx farsi support??
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 a lot of work in order to get Farsi working in LyX. I think most of what he has done is already in the main trunk, so the latest development version (and RC2, which is supposed to be released soon) should work pretty well for Farsi. Have you tried this? Are there any other issues that you see which are not yet working for Farsi in LyX? In any case, Mostafa probably knows best what the current situation is, and what still needs to be done... Dov
Re: Spaces on RTL boundaries
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 the
1.5 development cycle I would introduce a new file format now and declare
all 1.5svn versions between the original change and this new format buggy.
We did this for example with format 261.
If it was earlier you can't simply declare stable versions buggy (and people
will have corrected the wrong spaces by hand if they noticed), so it is
better to put the conversion between the old formats. Then it will at least
help people who now convert old documents.
Georg
Hi!
Georg, there never was a format change of this issue, but their *should*
have been, because although the format of the lyx file was not changed,
its interpretation *was* (not by us now, but back when the original
change in the latex generation occurred, see below; as Stefan pointed
out, all we did now was to bring the GUI up to date with the change
which already occurred then in the latex generation).
The change I'm talking about occurred somewhere between 17143 and 17158
(I think it's 17144, but there are other changes in the above range
which may be somewhat related, and format change 259 is somewhere in the
middle there, too...).
This is the issue: until 17143 (including), abc[FED ] ghi was output
to latex as abc \R{DEF} ghi; but starting with 17144, the output for
the same text (no change in the .lyx file at all!) became abc\R{ DEF}
ghi. So a format change is needed which explicitly changes the .lyx
file: any occurrence of abc[FED ] ghi should be changed to abc [FED]
ghi, in order that the same latex output be generated. (Note that there
is no need for doing anything when downgrading: both forms will be
interpreted identically in the old LyX versions, so we can just as
easily use the new format, in this respect. It's just that there are
some things which couldn't be typeset before 17144, so the explicit
differentiation wasn't needed.)
I think that in order to deal with this cleanly, what we have to do is
this: we create a new file format *now* (at first I was thinking we
should use version 259 to tag these differences, because it was so close
to when the changes were actually made; but then I realized the
following: if someone has already converted from pre-259 to post-259,
then if we now make this lyx2lyx change as part of 259, then that file
will never get fixed; so we need to do it now, so that already-converted
files will also get fixed. I'm not so worried about post-259 files where
the above construct now exists on purpose, because it's very very rare
for someone to really want it; in fact, I assume that even now it's just
an oversight on the part of the user). This new file format doesn't have
any real format changes associated with it, except that the version
number gets incremented. Besides that, what the conversion does is to
find occurrences of space which appear between LTR and RTL sections,
and makes sure that they are in the language which has the same
direction as the language of the paragraph.
So:
1) Does this sound right?
2) How do I do it in lyx2lyx? I looked at normalize_font_whitespace() ---
*** I now see what the problem is! What we need is *exactly* the change
of format 259; but in lyx2lyx, the \\lang property wasn't included for
some reason! The attached patch fixes this, and the output is now OK
(i.e., with this patch, a file created from before the change (also
attached), and in which the problem occurs, is output correctly and
displays correctly in the GUI even now!). But anyway, for the reasons
outlined above, I still think it's more correct to do this is a
separate, new file format, effective as of now. I guess that means
duplicating normalize_font_whitespace(), but having it now act *only* on
the lang property (Georg, you may want to make sure there aren't any
other forgotten properties, once we're at it...), and applying the new
function as the converter to a new file format...
So Georg, does all this make sense? And if so, could you please take
care of it? I guess we also need Jose's OK for this...
Thanks!
Dov
more_heb_problems.lyx
Description: application/lyx
Index: lyx-devel/src/Bidi.cpp
===
--- lyx-devel.orig/src/Bidi.cpp 2007-06-08 08:42:47.0 +0200
+++ lyx-devel/src/Bidi.cpp 2007-06-08 08:43:30.0 +0200
@@ -95,7 +95,11 @@
pos_type const body_pos = par.beginOfBody();
for (pos_type lpos = start_; lpos = end_; ++lpos) {
- bool is_space = par.isLineSeparator(lpos);
+ bool is_space = false;
+ // We do not handle spaces around an RTL segment in a special
way anymore.
+ // Neither does LaTeX, so
Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE
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 boost/format.hpp
using namespace std;
main()
{
cout boost::basic_formatchar (test %1$s \n) % OK;
}
which prints out
test OK
And what is the value of *start? And how does the whole format string look
like?
They are as follows:
(gdb) p *start
$38 = (const wchar_t ) @0x8b1e9c0: 49
(gdb) p start
$39 = (
__gnu_cxx::__normal_iteratorconst
wchar_t*,std::basic_stringwchar_t, std::char_traitswchar_t,
std::allocatorwchar_t ) @0xbfbfe2cc: {
_M_current = 0x8b1e9c0}
(gdb) x/25s 0xbfbfe2cc
0xbfbfe2cc: \300\351\261\b\030\033\177)\r
0xbfbfe2d6:
0xbfbfe2d7:
0xbfbfe2d8: \214\351\261\bp\352\261\b
0xbfbfe2e1:
0xbfbfe2e2:
0xbfbfe2e3:
0xbfbfe2e4:
0xbfbfe2e5:
0xbfbfe2e6:
0xbfbfe2e7:
0xbfbfe2e8:
0xbfbfe2e9:
0xbfbfe2ea:
0xbfbfe2eb:
0xbfbfe2ec:
\234\v\177)\314;\177)8\344\277\277(\343\277\277f|v)\354;\177)\001
0xbfbfe306:
0xbfbfe307:
0xbfbfe308:
([EMAIL PROTECTED]
\037\177)%
0xbfbfe32a:
0xbfbfe32b:
0xbfbfe32c: \016\312\023\001\377\377\377\377
0xbfbfe335:
0xbfbfe336:
0xbfbfe337:
I am now pretty sure that the
problem is not in any locale stuff, but in boost::format itself, because
normally this part of the code should only be reached with valid format
characters (and signed -65 == unsigned 191 == 0277 == 0xbf is not a valid
format character).
I'm not quite sure about the data structure used here, but arguments fmt
and arg1 in bformat() seem to contain no data fields:
src/support/lstrings.cpp line 875
template
docstring bformatdocstring(docstring const fmt, docstring arg1)
{
return (boost::basic_formatchar_type(fmt) % arg1).str();
}
Data:
fmt = $26 = (const docstring ) @0xbfbfe588: {static npos = 4294967295,
_M_dataplus = {std::allocatorwchar_t = {__gnu_cxx::new_allocatorwchar_t = {No data fields}, No data fields}, _M_p = 0x8b1e98c}}
arg1 = $27 = (docstring ) @0xbfbfe580: {static npos = 4294967295,
_M_dataplus = {std::allocatorwchar_t = {__gnu_cxx::new_allocatorwchar_t = {No data fields}, No data fields}, _M_p = 0x8b1e70c}}
And, subsequently call in boost/format/format_implementation.hpp line 60
template class Ch, class Tr, class Alloc
basic_formatCh, Tr, Alloc:: basic_format(const string_type s)
: style_(0), cur_arg_(0), num_args_(0), dumped_(false),
exceptions_(io::all_error_bits)
{
parse(s);
}
Data:
s = $28 = (
const std::basic_stringwchar_t,std::char_traitswchar_t,std::allocatorwchar_t ) @0xbfbfe588: {static npos = 4294967295,
_M_dataplus = {std::allocatorwchar_t = {__gnu_cxx::new_allocatorwchar_t = {No data fields}, No data fields}, _M_p = 0x8b1e98c}}
I also attach the data of arguments passed to parse_printf_directive()
in boost/format/parsing.hpp which is called later:
boost/format/parsing.hpp line 437
bool parse_ok = io::detail::parse_printf_directive(
it, buf.end(), items_[cur_item], fac, i1, exceptions());
(gdb) p it
$29 = {_M_current = 0x8b1e9c0}
(gdb) p buf.end()
$30 = {_M_current = 0x8b1ea70}
(gdb) p items_[cur_item]
$31 = (
const class
boost::io::detail::format_itemwchar_t,std::char_traitswchar_t,std::allocatorwchar_t
*) 0x8af4a80
(gdb) p items_[cur_item]
$35 = (
const
boost::io::detail::format_itemwchar_t,std::char_traitswchar_t,std::allocatorwchar_t
) @0x8af4a80: {argN_ = -1, res_ = {
static npos = 4294967295,
_M_dataplus = {std::allocatorwchar_t = {__gnu_cxx::new_allocatorwchar_t = {No data fields}, No data fields}, _M_p = 0x8a5a7a8}},
appendix_ = {static npos = 4294967295,
_M_dataplus = {std::allocatorwchar_t = {__gnu_cxx::new_allocatorwchar_t = {No data fields}, No data fields}, _M_p = 0x8a5a7a8}},
fmtstate_ = {width_ = 0, precision_ = 6, fill_ = 32, flags_ = 4098,
rdstate_ = std::_S_goodbit, exceptions_ = std::_S_goodbit,
loc_ = {boost::optional_detail::optional_basestd::locale = {boost::optional_detail::optional_tag = {No data fields}, m_initialized = false,
m_storage = {dummy_ = {data = \000\000\000,
aligner_ = incomplete type}}}, No data fields}},
truncate_ = 2147483647, pad_scheme_ = 0}
(gdb) p fac
$32 = (const struct std::ctypewchar_t ) @0x297f1f20: incomplete type
(gdb) p i1
$33 = 13
(gdb) p exceptions()
$34 = 255 '\377'
Are these passed data OK?
Thank you,
Koji
lyx farsi support??
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
Re: [patch] fixing segfault because of empty coord cache
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, but I'd wait for Andre's input. > > JMarc Hear, hear. This kind of analysis should be in the code, as comment. Do I understand correctly that this presupposes that 1) every mathinset must have an isActive method and 2) it should return true only if the inset has really accessible cells? - Martin
[patch] bug 3510: make IEEEtran template compilable
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 (besides not calling babel) is to define \markboth
before babel, i.e. do not use the MarkBoth paragraph style (which is somewhat
awkward anyway) but define \markboth in preamble.
I did this in the template, which compiles again here. Looks like the IEEEtran
layout would need some overhaul in general, but I won't do that.
OK to apply?
Jürgen
Index: lib/templates/IEEEtran.lyx
===
--- lib/templates/IEEEtran.lyx (Revision 18720)
+++ lib/templates/IEEEtran.lyx (Arbeitskopie)
@@ -1,18 +1,31 @@
#LyX 1.5.0svn created this file. For more info see http://www.lyx.org/
-\lyxformat 245
+\lyxformat 271
\begin_document
\begin_header
\textclass IEEEtran
+\begin_preamble
+% The following definition specifies the text on the headers:
+% Use this instead of the "MarkBoth" paragraph style
+\markboth{This is for left pages}{and this is for right pages}
+\end_preamble
\language english
\inputencoding default
-\fontscheme default
+\font_roman default
+\font_sans default
+\font_typewriter default
+\font_default_family default
+\font_sc false
+\font_osf false
+\font_sf_scale 100
+\font_tt_scale 100
\graphics default
-\float_placement hbt
+\float_placement tbh
\paperfontsize default
\spacing single
\papersize default
\use_geometry false
\use_amsmath 0
+\use_esint 0
\cite_engine basic
\use_bibtopic false
\paperorientation portrait
@@ -25,29 +38,44 @@
\papersides 1
\paperpagestyle default
\tracking_changes false
-\output_changes true
+\output_changes false
+\author "Jürgen Spitzmüller"
\end_header
\begin_body
-\begin_layout Title
+\begin_layout Standard
+\begin_inset Note Note
+status open
-Your Title: And maybe a bit extra
+\begin_layout Standard
+To specify the left and right header, go to
+\family sans
+Document\SpecialChar \menuseparator
+Settings\SpecialChar \menuseparator
+Preamble
+\family default
+ and change the definition there.
\end_layout
-\begin_layout Author
+\end_inset
+\end_layout
+
+\begin_layout Title
+Your Title: And maybe a bit extra
+\end_layout
+
+\begin_layout Author
\begin_inset Note Note
status collapsed
\begin_layout Standard
-
Remember that initial submissions don't show the authors
\end_layout
\begin_layout Standard
-
names so you'll need to make this a 'Comment'.
\end_layout
@@ -58,7 +86,6 @@
status collapsed
\begin_layout Standard
-
Your name is with xyz Department\SpecialChar \ldots{}
\end_layout
@@ -69,59 +96,36 @@
\end_layout
\begin_layout Abstract
-
This paper presents a simple template for IEEEtran documents.
\end_layout
\begin_layout Keywords
-
simplicity, beauty, elegance
\end_layout
-\begin_layout MarkBoth
-
-This is for left pages
-\begin_inset ERT
-status collapsed
-
-\begin_layout Standard
-}{
-\end_layout
-
-\end_inset
-
-and this is for right pages
-\end_layout
-
\begin_layout Section
-
Introduction
\begin_inset Note Note
status collapsed
\begin_layout Standard
-
Don't panic the section numbering may look different in
\end_layout
\begin_layout Standard
-
LyX but LaTeX uses the correct Roman numerals and
\end_layout
\begin_layout Standard
-
Alpha for section counters.
\end_layout
\begin_layout Standard
-
It's just that LyX doesn't handle counters other than arabic
\end_layout
\begin_layout Standard
-
numerals.
\end_layout
@@ -131,13 +135,12 @@
\end_layout
\begin_layout Standard
-
-
\begin_inset ERT
status collapsed
\begin_layout Standard
+
\backslash
PARstart{T}{here}
\end_layout
@@ -149,27 +152,23 @@
\end_layout
\begin_layout Section
-
Previous Work
\end_layout
\begin_layout Standard
-
This is only a template remember.
\end_layout
\begin_layout Section
-
Methodology
\end_layout
\begin_layout Theorem
-
-
\begin_inset ERT
status collapsed
\begin_layout Standard
+
[
\end_layout
@@ -180,6 +179,7 @@
status collapsed
\begin_layout Standard
+
]
\end_layout
@@ -190,23 +190,18 @@
\end_layout
\begin_layout Lemma
-
If you don't want a theorem or lemma name don't add one.
\end_layout
\begin_layout Proof
-
And here's the proof!
\end_layout
\begin_layout Section
-
Results
\end_layout
\begin_layout Standard
-
-
\begin_inset Float figure
placement htbp
wide false
@@ -220,8 +215,10 @@
A single column figure goes here
\end_layout
-\begin_layout Caption
+\begin_layout Standard
+\begin_inset Caption
+\begin_layout Standard
Captions go
\emph on
under
@@ -232,14 +229,21 @@
\end_inset
+\end_layout
+
+\end_inset
+
+
\begin_inset Float table
placement htbp
wide false
sideways false
status open
-\begin_layout Caption
+\begin_layout Standard
+\begin_inset Caption
Re: [patch] lyx crashes/mutilates document using math-delimiter ( ) in hebrew text
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 the cursor in the math inset with the keyboard). Jürgen
Re: Close tab button
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 choosing the tab to be > active. it maybe not so neat, but is much more effective for work. > > > Anyway, a button per tab is much more complicated than this solution. > > i would wait when trolltech include this feature to the qtabbar class. I agree with Pavel. Jürgen
