Re: Listings
Uwe Stöhr wrote: But this is then a bug. LyX currently swallows all author informations without confirmation. This is in my opinion a dataloss! I don't think so. The author information was introduced and currently is actually only there for change tracking purposes. Because of bug 3764, this privacy information leaked into documents without change tracking (without user confirmation). Furthermore it is a bug that I can set my identity in the preferences but still get an empty author field in the LyX files. Currently an author is only set when change tracking was used. That's how it's supposed to be. What I still miss is an option in the preferences to set this in every case. Right. But that would be a new feature. You can file an enhancement request on this. The policy should be: newer publish privacy information when the user didn't explicitly agreed on this. Jürgen
Re: [PATCH] Re: Current svn: Crash with pdfsync
José Matos wrote:
On Monday 16 July 2007 18:46:55 Abdelrazak Younes wrote:
OK, Jose shall I commit?
OK.
Done.
Please note that I have two other patches pending...
I know, I am a slow thinker. :-)
There's nothing much to think about IMO. The two patches are fixing
_real_ crashes:
* delete_hideSignal.patch:
1) create a doc
2) insert an ert inset
3) right-click the inset
4) new window
5) delete the ert inset: BOOM!
* crash_exit_multiview.patch:
With or without multiview, the crash happens randomly if the statusbar
timer times out after the view is closed. Two reason for that:
1) LyXFunc::lyx_view_ is not set to 0
2) quiting is not set to true.
Abdel.
Index: frontends/qt4/GuiView.cpp
===
--- frontends/qt4/GuiView.cpp (revision 19080)
+++ frontends/qt4/GuiView.cpp (working copy)
@@ -288,8 +288,14 @@
}
}
+ // Make sure that no LFUN use this close to be closed View.
+ theLyXFunc().setLyXView(0);
+ // Make sure the timer time out will not trigger a statusbar update.
+ statusbar_timer_.stop();
+
theApp()-gui().unregisterView(id());
if (!theApp()-gui().viewIds().empty()) {
+ quitting = true;
// Just close the window and do nothing else if this is not the
// last window.
close_event-accept();
Index: LyXFunc.cpp
===
--- LyXFunc.cpp (revision 19080)
+++ LyXFunc.cpp (working copy)
@@ -1841,7 +1841,7 @@
}
}
}
- if (!quitting) {
+ if (!quitting lyx_view_) {
lyx_view_-updateMenubar();
lyx_view_-updateToolbars();
// Some messages may already be translated, so we cannot use _()
Index: frontends/Dialogs.cpp
===
--- frontends/Dialogs.cpp (revision 19080)
+++ frontends/Dialogs.cpp (working copy)
@@ -21,63 +21,18 @@
#include boost/signal.hpp
#include boost/bind.hpp
+using std::string;
namespace lyx {
-
-using std::string;
using lyx::frontend::Dialog;
-// Note that static boost signals break some compilers, so this wrapper
-// initialises the signal dynamically when it is first invoked.
-templatetypename Signal
-class BugfixSignal {
-public:
- Signal operator()() { return thesignal(); }
- Signal const operator()() const { return thesignal(); }
-
-private:
- Signal thesignal() const
- {
- if (!signal_.get())
- signal_.reset(new Signal);
- return *signal_;
- }
-
- mutable boost::scoped_ptrSignal signal_;
-};
-
-
-namespace {
-
-BugfixSignalboost::signalvoid(string const , Inset*) hideSignal;
-
-}
-
-
-void Dialogs::hide(string const name, Inset* inset)
-{
- // Don't send the signal if we are quitting, because on MSVC it is
- // destructed before the cut stack in CutAndPaste.cpp, and this method
- // is called from some inset destructor if the cut stack is not empty
- // on exit.
- if (!quitting)
- hideSignal()(name, inset);
-}
-
-
Dialogs::Dialogs(LyXView lyxview)
: lyxview_(lyxview), in_show_(false)
{
- // Connect signals
- connection_ = hideSignal().connect(boost::bind(Dialogs::hideSlot,
this, _1, _2));
}
-Dialogs::~Dialogs()
-{
- connection_.disconnect();
-}
Dialog * Dialogs::find_or_build(string const name)
{
@@ -149,8 +104,15 @@
}
-void Dialogs::hideSlot(string const name, Inset * inset)
+void Dialogs::hide(string const name, Inset* inset)
{
+ // Don't send the signal if we are quitting, because on MSVC it is
+ // destructed before the cut stack in CutAndPaste.cpp, and this method
+ // is called from some inset destructor if the cut stack is not empty
+ // on exit.
+ if (quitting)
+ return;
+
std::mapstring, DialogPtr::const_iterator it =
dialogs_.find(name);
if (it == dialogs_.end())
Index: frontends/Dialogs.h
===
--- frontends/Dialogs.h (revision 19080)
+++ frontends/Dialogs.h (working copy)
@@ -31,8 +31,6 @@
public:
///
Dialogs(LyXView );
- ///
- ~Dialogs();
/** Check the status of all visible dialogs and disable or reenable
* them as appropriate.
@@ -89,15 +87,13 @@
/** All Dialogs of the given \param name will be closed if they are
connected to the given \param inset.
*/
- static void hide(std::string const name, Inset * inset);
+ void hide(std::string const name, Inset * inset);
///
void disconnect(std::string const name);
///
Inset * getOpenInset(std::string const name) const;
private:
///
-
Re: [PATCH] Re: Current svn: Crash with pdfsync
On Tuesday 17 July 2007 09:43:12 Abdelrazak Younes wrote: There's nothing much to think about IMO. The two patches are fixing _real_ crashes: Close to the final release any patch that is not a one line makes me nervous, no matter if they fix crashes or not. :-) * delete_hideSignal.patch: 1) create a doc 2) insert an ert inset 3) right-click the inset 4) new window 5) delete the ert inset: BOOM! There us some kind of poetic justice here. :-) * crash_exit_multiview.patch: With or without multiview, the crash happens randomly if the statusbar timer times out after the view is closed. Two reason for that: 1) LyXFunc::lyx_view_ is not set to 0 2) quiting is not set to true. OK to both. Abdel. -- José Abílio
Re: [PATCH] Re: Current svn: Crash with pdfsync
José Matos wrote: On Tuesday 17 July 2007 09:43:12 Abdelrazak Younes wrote: There's nothing much to think about IMO. The two patches are fixing _real_ crashes: Close to the final release any patch that is not a one line makes me nervous, no matter if they fix crashes or not. :-) I understand but those two are really simple and, this time, I actually made sure there was no brown paper bag possible. The first one remove some code which is always a good sign :-) * delete_hideSignal.patch: 1) create a doc 2) insert an ert inset 3) right-click the inset 4) new window 5) delete the ert inset: BOOM! There us some kind of poetic justice here. :-) I am a poet ;-) * crash_exit_multiview.patch: With or without multiview, the crash happens randomly if the statusbar timer times out after the view is closed. Two reason for that: 1) LyXFunc::lyx_view_ is not set to 0 2) quiting is not set to true. OK to both. OK, will commit in a minute, thanks! Abdel.
Re: [patch] Reversing numbers in arabic_arabi
On Monday 16 July 2007 20:17:44 Dov Feldstern wrote: This is technically a format change, though I would again argue that we should *not* create a lyx2lyx for it. However, if this is not acceptable, a lyx2lyx patch should be relatively simple; and that only underlines the need for applying this before 1.5.0. Who are our users of arabi? That is the main question to ask. :-) If the answer is developers then I do not have any problem letting this go without a file format change. Dov -- José Abílio
Re: [patch] Reversing numbers in arabic_arabi
José Matos wrote: On Monday 16 July 2007 20:17:44 Dov Feldstern wrote: This is technically a format change, though I would again argue that we should *not* create a lyx2lyx for it. However, if this is not acceptable, a lyx2lyx patch should be relatively simple; and that only underlines the need for applying this before 1.5.0. Who are our users of arabi? That is the main question to ask. :-) If the answer is developers then I do not have any problem letting this go without a file format change. arabi was not supported up until recently (1.5 only) so there was no users of it, only Mostafa recently for Farsi. Abdel.
Re: [patch] Reversing numbers in arabic_arabi
On Tuesday 17 July 2007 10:52:13 Abdelrazak Younes wrote: arabi was not supported up until recently (1.5 only) so there was no users of it, only Mostafa recently for Farsi. I know that. But we have already released pre-releases with the support on it and we want our users to take the pre-releases seriously. Abdel. -- José Abílio
Re: [patch] Reversing numbers in arabic_arabi
José Matos wrote: On Tuesday 17 July 2007 10:52:13 Abdelrazak Younes wrote: arabi was not supported up until recently (1.5 only) so there was no users of it, only Mostafa recently for Farsi. I know that. But we have already released pre-releases with the support on it and we want our users to take the pre-releases seriously. Then ask on the users list and ask to Mostafa too. Quite frankly, I don't think there's anybody but Mostafa. Even though there is other users the only difference with the patch is, AFAIU, that the number in the output will be in the correct order. This was clearly a bug in LyX latex export and not a format change IMHO. Abdel.
Re: [patch] Reversing numbers in arabic_arabi
On Tuesday 17 July 2007 11:28:26 Abdelrazak Younes wrote: Quite frankly, I don't think there's anybody but Mostafa. Even though there is other users the only difference with the patch is, AFAIU, that the number in the output will be in the correct order. This was clearly a bug in LyX latex export and not a format change IMHO. I don't disagree with I just want to be sure that this is the case. Abdel. -- José Abílio
Re: [updated PATCH] bugs 3958, 3313 and 3976 lyx2lyx and unicode characters
On Friday 13 July 2007 13:16:46 Anders Ekberg wrote:
I have tried to address Georg's and Juergen's comments.
To avoid data-loss, the function is only run if the encoding is auto
or default and there are no language changes (overly conservative,
but possible to work around, as commented in the code). Now, I
*assume* this should prevent any cases that can cause data-loss (i.e.
assuming unicode encoding when it is not), but I don't know the
format good enough to be sure, so please correct the code if I'm wrong.
We can extend the test to see if the included languages have the same
encoding...
To avoid the need for two unicodesymbols files, I have removed that
requirement by assuming any command that includes { and } and not any
of the exception tokens, to be an accented character. I also check
for combining characters and don't translate these (which allowed the
removal of an if-test in the end of the code). It is not pretty, but
works...
Details and an idea for a (hopefully) better solution are in bugzilla
http://bugzilla.lyx.org/show_bug.cgi?id=3958
As I said there the format change needs to be in lyx_1_5.py and not in
LyX.py.
Anders
--
José Abílio
Re: Search LyX Text Functionality.
Abdelrazak Younes ha scritto: I'll try to look at the Controller code tommorrow. Obviously, the controller was missing. Added a new patch. T.
[patch] fix drawing issue
This oneliner fixes some ugly drawing artefacts with insets in the appendix
(probably introduced with revision 19039).
Attached also a testcase where you can see the artefacts.
OK to apply?
Jürgen
Index: src/rowpainter.cpp
===
--- src/rowpainter.cpp (Revision 19092)
+++ src/rowpainter.cpp (Arbeitskopie)
@@ -471,7 +471,7 @@
void RowPainter::paintAppendix()
{
- if (!par_.params().appendix())
+ if (!par_.params().appendix() || !text_.isMainText(*bv_.buffer()))
return;
int y = yo_ - row_.ascent();
redraw.lyx
Description: application/lyx
Re: [patch] fix drawing issue
On Tuesday 17 July 2007 14:25:23 Jürgen Spitzmüller wrote: This oneliner fixes some ugly drawing artefacts with insets in the appendix (probably introduced with revision 19039). Attached also a testcase where you can see the artefacts. OK to apply? OK. Jürgen -- José Abílio
Re: lyx2lyx help
On Sunday 15 July 2007 18:02:46 Dov Feldstern wrote: Files from pre-249 are wrong, but post-249 don't have the problem. So my new stage (277) should only run on files which originated at pre-249... Currently, since I'm running on everything, I'm trying to fix things which aren't broken... Assuming I understand what you mean it seems that this fix should be made for the 248-249 step, this would solve that particular problem. Thanks! Dov -- José Abílio
Re: [patch] Reversing numbers in arabic_arabi
The patch sent by Dov is OK. I am really sorry for being late in replying to the emails. These days I have too many things TODO. Mostafa - Need a vacation? Get great deals to amazing places on Yahoo! Travel.
Re: Search LyX Text Functionality.
Tommaso Cucinotta wrote: Added a new patch. Hi Tommaso, this is just to let you know that we are actually noticing what you are doing :-) You might be aware that we are busy with getting 1.5.0 out (and in feature freeze), so you will have to be a bit patient. I have applied your patch and had a quick look (I had to add the Controllers to controllers/Makefile.am to make it compile). It looks very promising! Some things are not working yet (e.g. searching for special symbols like ligature breaks, replacing), but you might be aware of that. I also think you new input widget (i.e. the small work area) might be of general use for other dialogs, such as the url and index dialogs (which would fix the problems with non-escaped characters). Impressing stuff. Jürgen P.S. Some formal issues I've noticed with the patch: - our source files are encoded in latin 1 (your patch mangles names with special characters, such as Bjønnes) - please adapt the formatting (always tab for indendation, max line lenght ~75 chars) to the rest of the code. Have a look at development/code_rules for some hints. Jürgen
Re: [patch] fix drawing issue
On 7/17/07, Jürgen Spitzmüller [EMAIL PROTECTED] wrote: This oneliner fixes some ugly drawing artefacts with insets in the appendix (probably introduced with revision 19039). There is also a redraw problem when you delete in ERT or listings inset, do you also have an oneliner? :-) Bo
Convert source code to utf8? (was Re: Search LyX Text Functionality.
Jürgen Spitzmüller wrote: - our source files are encoded in latin 1 (your patch mangles names with special characters, such as Bjønnes) Shouldn't we convert that to utf8 before 1.5.0? I remind you that we need to do that for layouts too. Abdel.
Re: [patch] fix drawing issue
Bo Peng wrote: There is also a redraw problem when you delete in ERT or listings inset, do you also have an oneliner? :-) No, unfortunately not. Jürgen
Re: [patch] Reversing numbers in arabic_arabi
On Tuesday 17 July 2007 15:02:42 Mostafa Vahedi wrote: The patch sent by Dov is OK. I am really sorry for being late in replying to the emails. These days I have too many things TODO. OK then. Mostafa -- José Abílio
Bug parsing latex command
This bug was reported in the users list.
The problem was with the translation of the following piece:
\begin_inset LatexCommand
\url{http://www.worldscinet.com/ijmpc/mkt/guidelines.s
html}
\end_inset
lyx2lyx was expecting the whole command to be in the same line so it left that
html} alone in a single line.
\begin_inset LatexCommand url
target http://www.worldscinet.com/ijmpc/mkt/guidelines.s;
html}
\end_inset
This was enough to crash lyx.
Adding the following piece of code takes care about those cases and it works
so I will commit it.
Index: lyx_1_5.py
===
--- lyx_1_5.py (revision 19100)
+++ lyx_1_5.py (working copy)
@@ -444,6 +444,13 @@
i = i + 1
continue
+j = find_token(document.body, \\end_inset, i+1)
+if j == -1:
+document.warning(Malformed document)
+else:
+command += .join(document.body[i+1:j])
+document.body[i+1:j] = []
+
# The following parser is taken from the original
InsetCommandParams::scanCommand
name =
option1 =
--
José Abílio
crash while dissolving tabular
- New Document - Insert 1x1 tabular (one cell) - type foo inside cell - hit DEL = crash Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47819059702400 (LWP 29034)] 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x00a11d53 in lyx::InsetTabularMailer::params2string ([EMAIL PROTECTED]) at InsetTabular.cpp:4848 #2 0x00a11fc7 in lyx::InsetTabularMailer::inset2string (this=value optimized out) at InsetTabular.cpp:4813 #3 0x0091b751 in lyx::MailInset::updateDialog (this=0x7179c9a0, bv=0x1717dc0) at MailInset.cpp:38 #4 0x00a25bd4 in lyx::InsetTabular::doDispatch (this=0x19a0820, [EMAIL PROTECTED], [EMAIL PROTECTED]) at InsetTabular.cpp:3499 #5 0x0091dee6 in lyx::Inset::dispatch (this=0x19a0820, [EMAIL PROTECTED], [EMAIL PROTECTED]) at Inset.cpp:145 #6 0x0057960b in lyx::Cursor::dispatch (this=0x1718158, [EMAIL PROTECTED]) at Cursor.cpp:317 #7 0x006dc3ff in lyx::LyXFunc::dispatch (this=0x14b7040, [EMAIL PROTECTED]) at LyXFunc.cpp:1808 #8 0x006dde35 in lyx::LyXFunc::processKeySym (this=0x14b7040, [EMAIL PROTECTED], state=lyx::key_modifier::none) at LyXFunc.cpp:383 #9 0x00a9a3c8 in lyx::frontend::WorkArea::processKeySym (this=0x1612dd8, [EMAIL PROTECTED], state=lyx::key_modifier::none) at WorkArea.cpp:180 #10 0x00b08133 in lyx::frontend::GuiWorkArea::keyPressEvent (this=0x1612db0, e=0x7179f480) at GuiWorkArea.cpp:474 #11 0x2b7db96d4878 in QWidget::event (this=0x1612db0, event=0x7179f480) at kernel/qwidget.cpp:5753 ---Type return to continue, or q return to quit--- #12 0x2b7db9925409 in QFrame::event (this=0x19a0820, e=0x3) at widgets/qframe.cpp:633 #13 0x2b7db998e6eb in QAbstractScrollArea::event (this=0x1612db0, e=0x7179f480) at widgets/qabstractscrollarea.cpp:810 #14 0x2b7db968fbbc in QApplicationPrivate::notify_helper (this=0x0, receiver=0x1612db0, e=0x7179f480) at kernel/qapplication.cpp:3439 #15 0x2b7db96926db in QApplication::notify (this=value optimized out, receiver=0x1612db0, e=0x7179f480) at kernel/qapplication.cpp:3067 #16 0x00aee4c4 in lyx::frontend::GuiApplication::notify (this=0x19a0820, receiver=0x3, event=0x7179c3a0) at GuiApplication.cpp:237 #17 0x2b7db96d94fd in qt_sendSpontaneousEvent (receiver=0x6c757220, event=0x7179c3a0) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:186 #18 0x2b7db970194d in QKeyMapper::sendKeyEvent (keyWidget=0x1612db0, grab=value optimized out, type=QEvent::KeyPress, code=16777223, [EMAIL PROTECTED], [EMAIL PROTECTED], autorepeat=value optimized out, count=1, nativeScanCode=107, nativeVirtualKey=65535, nativeModifiers=16) at kernel/qkeymapper_x11.cpp:1580 #19 0x2b7db9703889 in QKeyMapperPrivate::translateKeyEvent (this=0x14f6f40, keyWidget=0x1612db0, event=0x7179fcf0, grab=3) at kernel/qkeymapper_x11.cpp:1560 #20 0x2b7db96e31e7 in QApplication::x11ProcessEvent (this=0x14bca00, event=0x7179fcf0) at kernel/qapplication_x11.cpp:2782 #21 0x2b7db9704ca5 in x11EventSourceDispatch (s=0x14c4b60, callback=0, user_data=0x0) at kernel/qguieventdispatcher_glib.cpp:122 #22 0x2b7dbbb56f94 in g_main_context_dispatch () from /opt/gnome/lib64/libglib-2.0.so.0 ---Type return to continue, or q return to quit--- #23 0x2b7dbbb59dc5 in g_main_context_prepare () from /opt/gnome/lib64/libglib-2.0.so.0 #24 0x2b7dbbb5a2ee in g_main_context_iteration () from /opt/gnome/lib64/libglib-2.0.so.0 #25 0x2b7dbb6a0430 in QEventDispatcherGlib::processEvents (this=0x14c1080, flags=value optimized out) at kernel/qeventdispatcher_glib.cpp:366 #26 0x2b7db9704abf in QGuiEventDispatcherGlib::processEvents (this=0x19a0820, flags=value optimized out) at kernel/qguieventdispatcher_glib.cpp:178 #27 0x2b7dbb67eda8 in QEventLoop::processEvents (this=value optimized out, flags=value optimized out) at kernel/qeventloop.cpp:126 #28 0x2b7dbb67eeb9 in QEventLoop::exec (this=0x717a0070, [EMAIL PROTECTED]) at kernel/qeventloop.cpp:172 #29 0x2b7dbb681080 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:730 #30 0x00aed749 in lyx::frontend::GuiApplication::exec (this=value optimized out) at GuiApplication.cpp:158 #31 0x006b4ca2 in lyx::LyX::exec (this=0x717a1290, argc=value optimized out, argv=value optimized out) at LyX.cpp:475 #32 0x0042b7af in main (argc=1, argv=0x717a13a8) at main.cpp:48 Jürgen
Re: crash while dissolving tabular
Jürgen Spitzmüller wrote: - New Document - Insert 1x1 tabular (one cell) - type foo inside cell - hit DEL = crash I cannot reproduce the crash under windows but this looks familiar to an old crash you had with the Toc if you remember. I just committed a fix in the std declaration, does that help? Abdel.
Re: crash while dissolving tabular
Abdelrazak Younes wrote: I just committed a fix in the std declaration, does that help? No. Jürgen
[PATCH] 3404: lyx2lyx adds too many \end_layout tokens
Jose:
The test case of bug 3404 has multiple consecutive
\begin_deeper
\begin_deeper
\end_deeper
\end_deeper
and an \end_layout is inserted before each \begin_deeper. This leads
to excessive \end_layout.
I am *not* familiar with lyx 1.3.x format and I do not know if there
are valid cases where multiple \begin_deeper should yield multiple
\end_layout. If you know the answer, the attached patch fixes bug
3404.
Cheers,
Bo
Index: lib/lyx2lyx/lyx_1_4.py
===
--- lib/lyx2lyx/lyx_1_4.py (revision 19100)
+++ lib/lyx2lyx/lyx_1_4.py (working copy)
@@ -466,6 +466,9 @@
document.body.insert(i,)
document.body.insert(i,\\end_layout)
i = i + 3
+# consecutive begin_deeper only insert one end_layout
+while document.body[i].startswith('\\begin_deeper'):
+i += 1
struct_stack.append(token)
continue
Index: lib/lyx2lyx/lyx_1_4.py
===
--- lib/lyx2lyx/lyx_1_4.py (revision 19100)
+++ lib/lyx2lyx/lyx_1_4.py (working copy)
@@ -466,6 +466,9 @@
document.body.insert(i,)
document.body.insert(i,\\end_layout)
i = i + 3
+# consecutive begin_deeper only insert one end_layout
+while document.body[i].startswith('\\begin_deeper'):
+i += 1
struct_stack.append(token)
continue
Re: crash while dissolving tabular
On 7/17/07, Jürgen Spitzmüller [EMAIL PROTECTED] wrote: - New Document - Insert 1x1 tabular (one cell) - type foo inside cell - hit DEL = crash I can confirm this. A really easy way to crash lyx. Bo
Re: [patch] fix drawing issue
Bo Peng wrote:
There is also a redraw problem when you delete in ERT or listings
inset, do you also have an oneliner? :-)
Try this (OK, a bit more than one line).
Jürgen
Index: src/rowpainter.cpp
===
--- src/rowpainter.cpp (Revision 19101)
+++ src/rowpainter.cpp (Arbeitskopie)
@@ -918,13 +918,21 @@
{
// check whether the current inset is nested in a non-wide inset
Cursor cur = pi.base.bv-cursor();
- for (int i = cur.depth() - 1; --i = 0; ) {
+ Inset const * cur_in = cur.inset();
+ // check all higher nested insets
+ for (size_type i = 1; i cur.depth(); ++i) {
Inset * const in = cur[i].inset();
- if (in) {
+ if (in == cur_in)
+ // we reached the level of the current inset, so stop
+ return false;
+ else if (in) {
+ if (in-hasFixedWidth())
+return true;
InsetText * t =
const_castInsetText *(in-asTextInset());
- if (t)
-return !t-wide();
+ if (t !t-wide())
+// OK, we are in a non-wide() inset
+return true;
}
}
return false;
@@ -1000,7 +1008,7 @@
// Clear background of this row
// (if paragraph background was not cleared)
if (!repaintAll
- (!(in_inset_alone_on_row leftEdgeFixed)
+ (!(in_inset_alone_on_row leftEdgeFixed !inNarrowIns)
|| row_has_changed)) {
pi.pain.fillRectangle(x, y - rit-ascent(),
rp.maxWidth(), rit-height(),
Re: crash while dissolving tabular
Abdelrazak Younes wrote: I cannot reproduce the crash under windows but this looks familiar to an old crash you had with the Toc if you remember. I rather think it's a remainder of bug 3258. Note that in the backtrace, line 3497 in InsetTabular::doDispatch is reached, if (!is_deleted_) InsetTabularMailer(*this).updateDialog(cur.bv()); // -- this one which means that is_deleted_ is false. AFAIU your fix in revision 17568, is_deleted_ should be true in this case. Jürgen
Re: [patch] fix drawing issue
On 7/17/07, Jürgen Spitzmüller [EMAIL PROTECTED] wrote: Bo Peng wrote: There is also a redraw problem when you delete in ERT or listings inset, do you also have an oneliner? :-) Try this (OK, a bit more than one line). The problem seems to be solved, but I can not figure out when an ERT inset will occupy the rest of the line during edition. E.g. Normal Listings: Usually [listings ] Edit [listings ] Inline listings and ERT: Always a[ERT] or [ERT]a if there is something before/after it, otherwise span to the end of line during edition. I think it makes sense to either 1. does not expand to the end of the line at all, or 2. only expand when there is nothing after it. I.e. remove the case of a[ERT]. Bo
Re: [patch] Reversing numbers in arabic_arabi
José Matos wrote: On Tuesday 17 July 2007 15:02:42 Mostafa Vahedi wrote: The patch sent by Dov is OK. I am really sorry for being late in replying to the emails. These days I have too many things TODO. OK then. Mostafa Committed as 19105. Dov
Re: [patch] fix drawing issue
Bo Peng wrote: The problem seems to be solved, but I can not figure out when an ERT inset will occupy the rest of the line during edition. E.g. This is the unsavoury wide() thing (TM). The rule is: an inset spans the whole line, if - it is the only thing in the row and - the cursor is inside. Normal Listings: Usually [listings ] Edit [listings ] Yes. Inline listings and ERT: Always a[ERT] or [ERT]a if there is something before/after it, otherwise span to the end of line during edition. Exactly. I think it makes sense to either 1. does not expand to the end of the line at all, or 2. only expand when there is nothing after it. I.e. remove the case of a[ERT]. I won't spend a single minute on improving it. IMO, the only reasonable goal is to remove the wide() thing altogether, once the speed problems are resolved (remember the wide() thing is just a hack to work around the speed issues). So if you think that bug 3582 is solved, I'd propose to put that into 1.5.0. Jürgen
Re: [patch] fix drawing issue
So if you think that bug 3582 is solved, I'd propose to put that into 1.5.0. It should, but you need another OK. Bo
Re: [patch] fix drawing issue
Bo Peng wrote: So if you think that bug 3582 is solved, I'd propose to put that into 1.5.0. It should, but you need another OK. OK from me. Abdel.
[patch] fix doc_toc.py documentation bug 3798
The attached documentation patch fixes http://bugzilla.lyx.org/show_bug.cgi?id=3798 It also converts depend.py to UTF-8 format that we use for all Python scripts in LyX 1.5. Can this go in José? regards Uwe Index: depend.py === --- depend.py (revision 19106) +++ depend.py (working copy) @@ -1,7 +1,7 @@ #! /usr/bin/env python -# -*- coding: iso-8859-1 -*- +# -*- coding: utf-8 -*- # This file is part of the LyX Documentation -# Copyright (C) 2004 José Matos [EMAIL PROTECTED] +# Copyright (C) 2004 José Matos [EMAIL PROTECTED] # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License @@ -21,6 +21,9 @@ # It does so by going through the files and printing out all of the # chapter, section, and sub(sub)section headings out. (It numbers the # sections sequentially; hopefully noone's using Section* in the docs.) +# It calls the script doc_toc.py using this syntax: +# depend.py doc_toc.py SetOfDocuments +# where SetOfDocuments is a set of documents import sys import os Index: doc_toc.py === --- doc_toc.py (revision 19106) +++ doc_toc.py (working copy) @@ -17,10 +17,14 @@ # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. -# This script creates a master table of contents for a set of LyX docs. +# This script is called by the script depend.py to create a master table of contents +# for a set of LyX docs. # It does so by going through the files and printing out all of the # chapter, section, and sub(sub)section headings out. (It numbers the # sections sequentially; hopefully noone's using Section* in the docs.) +# It is calledusing this syntax: +# depend.py doc_toc.py SetOfDocuments +# where SetOfDocuments is a set of documents import sys import os
[patch] remove linuxdoc from all doc files
Jürgen requested that I fix bug 2787:
http://bugzilla.lyx.org/show_bug.cgi?id=2787
for LyX 1.5.0.
I did this in the attached patch. (I can do the same for the translated manuals
when I get the OK.)
But when applying this, the generate hyperlink option in the URL dialog is then senseless (perhaps
this is already the case) and should be removed from this dialog. (Someone else should do this please.)
Opinions?
regards Uwe
Index: Customization.lyx
===
--- Customization.lyx (revision 19106)
+++ Customization.lyx (working copy)
@@ -1,5 +1,5 @@
#LyX 1.5.0svn created this file. For more info see http://www.lyx.org/
-\lyxformat 274
+\lyxformat 276
\begin_document
\begin_header
\textclass book
@@ -39,9 +39,10 @@
\paperpagestyle headings
\tracking_changes false
\output_changes false
-\author Richard Heck
-\author Jean-Marc Lasgouttes
-\author usti
+\author
+\author
+\author
+\author
\end_header
\begin_body
@@ -5967,7 +5968,7 @@
\begin_layout Standard
This indicates that your text class uses the foo.sty package.
- Finally, it is also possible to declare classes for SGML and DocBook code.
+ Finally, it is also possible to declare classes for DocBook code.
Typical declarations will look like
\end_layout
@@ -5982,20 +5983,6 @@
\size small
#
\backslash
-DeclareSGMLClass{SGML (LinuxDoc)}
-\end_layout
-
-\begin_layout Standard
-or
-\end_layout
-
-\begin_layout LyX-Code
-#% Do not delete the line below; configure depends on this
-\end_layout
-
-\begin_layout LyX-Code
-#
-\backslash
DeclareDocBookClass[article]{SGML (DocBook article)}
\end_layout
@@ -9473,10 +9460,6 @@
\end_layout
\begin_layout LyX-Code
-Format LinuxDoc
-\end_layout
-
-\begin_layout LyX-Code
Product [XFig: $$FName]
\end_layout
@@ -9666,7 +9649,7 @@
\family typewriter
\series medium
Format\InsetSpace ~
-LaTeX|PDFLaTeX|PlainText|DocBook|LinuxDoc
+LaTeX|PDFLaTeX|PlainText|DocBook
\family default
\series default
The primary document file format that this format definition is for.
@@ -9676,8 +9659,7 @@
Format
\family default
section for all formats.
- Use a dummy text when no representation is available (see the LinuxDoc
- format in the example above).
+ Use a dummy text when no representation is available.
Then you can at least see a reference to the external material in the exported
document.
\end_layout
Index: EmbeddedObjects.lyx
===
--- EmbeddedObjects.lyx (revision 19106)
+++ EmbeddedObjects.lyx (working copy)
@@ -201,7 +201,8 @@
\bullet 3 2 7 -1
\tracking_changes false
\output_changes false
-\author Uwe Stöhr
+\author
+\author
\end_header
\begin_body
@@ -26880,28 +26881,6 @@
\end_layout
\begin_layout Standard
-The option
-\family sans
-Generate\InsetSpace ~
-hyperlink
-\family default
- in the URL dialog has only an affect when you export your document to the
- format
-\begin_inset Quotes eld
-\end_inset
-
-
-\family sans
-LinuxDoc
-\family default
-
-\begin_inset Quotes erd
-\end_inset
-
-.
-\end_layout
-
-\begin_layout Standard
You cannot change the style of the link text.
The text of the
\family sans
Index: Extended.lyx
===
--- Extended.lyx (revision 19106)
+++ Extended.lyx (working copy)
@@ -1,5 +1,5 @@
#LyX 1.5.0svn created this file. For more info see http://www.lyx.org/
-\lyxformat 274
+\lyxformat 276
\begin_document
\begin_header
\textclass book
@@ -37,7 +37,8 @@
\paperpagestyle headings
\tracking_changes false
\output_changes false
-\author usti
+\author
+\author
\end_header
\begin_body
@@ -15404,675 +15405,6 @@
\end_layout
\begin_layout Section
-Using LyX with SGML-Tools (aka LinuxDoc)
-\end_layout
-
-\begin_layout Standard
-by
-\noun on
-Paul Evans
-\end_layout
-
-\begin_layout Subsection
-Overview
-\end_layout
-
-\begin_layout Standard
-LinuxDoc is a document class available in LyX if you have the
-\family typewriter
-sgml-tools
-\family default
- package installed.
- You can use it to produce documents in the so-called Standardized General
- Mark-up Language (SGML) in the particular format used by the Linux Documentatio
-n Project.
- That is obviously helpful if you are contributing to that project.
- You can use the SGML format with the
-\family typewriter
-sgml-tools
-\family default
- package of scripts and programs (to produce other formats, including LaTeX,
- HTML, plain text, man pages and\SpecialChar \ldots{}
-).
- You may therefore prefer to use this document class if you want to write
- something that can be easily translated into other formats.
-\end_layout
-
-\begin_layout Standard
-You will find that LinuxDoc has fewer layout options than the other text
- classes in LyX.
- This is mainly so that the translations into other formats have a chance
- of making some sense.
- In this section we describe:
-\end_layout
-
lyx2lyx for patch 1820
Hi! Attached find a lyx2lyx for patch 1820. It's not perfect, though --- it actually corrupts some files which shouldn't be changed at all; if anyone wants to try and fix that, be my guest, I've just spent the past six hours on this and I'm not sure that it's doable. Also, this has only convinced me even more that it's wrong to apply a lyx2lyx fix for this patch: this is a bug fix, there were previously .lyx files which were ok, but which lyx was generating incorrect latex for, and patch 1820 fixes that. If there are lyx documents out there which patch 1820 affects, it can only do them good. All this lyx2lyx patch does is to explicitly set the language to the wrong values in all kinds of situations. I would urge for what Martin suggested a few days ago: have an empty format change to go along with patch 1820, just to mark the fix, but not to apply any lyx2lyx for now. We have this patch in store, if anyone decides that it really *is* necessary, we'll always be able to apply it retroactively, since the format change was marked. Dov Index: lyx-devel/lib/lyx2lyx/lyx_1_5.py === --- lyx-devel.orig/lib/lyx2lyx/lyx_1_5.py 2007-07-17 22:38:36.0 +0300 +++ lyx-devel/lib/lyx2lyx/lyx_1_5.py2007-07-18 03:04:40.0 +0300 @@ -42,9 +42,122 @@ Find beginning of layout, where lines[i] is included. return find_beginning_of(lines, i, \\begin_layout, \\end_layout) +def isRTL(language): +from lyx2lyx_lang import lang +return lang[language][2] == true + # End of helper functions +def recreate_bug1820(document): + This function tries to undo the fix for bug 1820, so that documents +are displayed wrongly, as they were before the fix for that bug. + +Specifically, intra-paragraph language switches are closed before openning +an inset; and upon entering an inset, if in the new lyx the language is now +different than it would have been in the old lyx, then we now explicitly set +it to what it would have been in old lyx. + + lang_re = re.compile(r^\\lang\s(\S+)) + inset_re = re.compile(r^\\begin_inset\s(\S+)) + inset_end_re = re.compile(r^\\end_inset) + status_re = re.compile(r^status) + layout_re = re.compile(r^\\begin_layout) + layout_end_re = re.compile(r^\\end_layout) + + new_cur_lang = [document.language] + old_cur_lang = [document.language] + new_outer_lang = [document.language] + old_outer_lang = [document.language] + just_entered_inset = False + entered_inset_layout = False + + # we'll only insert the necessary lines at the end, in order not to + # interfere with the looping over the lines... + line_insertions = [] # (insert before line number, line to insert) + + for i in range(len(document.body)): + # determine the current language + result = lang_re.match(document.body[i]) + if result: + new_cur_lang[-1] = result.group(1) + old_cur_lang[-1] = result.group(1) + continue + result = layout_re.match(document.body[i]) + if result: + new_cur_lang[-1] = new_outer_lang[-1] + old_cur_lang[-1] = old_outer_lang[-1] + if not just_entered_inset: + continue + + # if we're openning an inset, and the current language is different + # than the paragraph language: + # old: close the current language + # new: close the current langauge, unless the RTL-ness of the two + # languages are different + if inset_re.match(document.body[i]): + par_language = get_paragraph_language(document, i) + + if old_cur_lang[-1] != par_language: + # write the closure to the file + line_insertions.insert(0, (i, \\lang %s%par_language)) + + # the second clause says that if we just closed the current + # language, then as far as the new lyx is concerned, we're + # back to the paragraph language + if isRTL(par_language) != isRTL(new_cur_lang[-1]) and \ + not old_cur_lang[-1] != par_language: + new_outer_lang.append(new_cur_lang[-1]) + new_cur_lang.append(new_cur_lang[-1]) + else: + new_outer_lang.append(par_language) + new_cur_lang.append(par_language) + +
Patches for 1820 and 3613
Hi! I've spent an enormous amount of time on getting these two bugs fixed for 1.5.0, since we realized that they involve format changes. I think I deserve to have them applied and tested, even if it means postponing the release for a week or two. I already suggested how we can do this without having to halt continued development (by branching now, but not yet releasing). Given that there have been a lot of little changes since the last RC, I also think it wouldn't be a bad idea to apply these patches, branch, and then release an RC, which would really be a release candidate this time: unless there are critical fixes / format changes, no more changes would be made to the 1.5.0 branch until the final release. So far, though, these two patches have mostly been ignored --- a few people have responded, but not many. It's not like anyone has shown that these patches are problematic, break things, etc. --- they've just been ignored. If these don't make it into the release for no good reason, and then have to wait until 1.6, I think that would be quite unfair. Dov
Re: Patches for 1820 and 3613
Dov Feldstern wrote: I've spent an enormous amount of time on getting these two bugs fixed for 1.5.0, since we realized that they involve format changes. I think I deserve to have them applied and tested, even if it means postponing the release for a week or two. I already suggested how we can do this without having to halt continued development (by branching now, but not yet releasing). Given that there have been a lot of little changes since the last RC, I also think it wouldn't be a bad idea to apply these patches, branch, and then release an RC, which would really be a release candidate this time: unless there are critical fixes / format changes, no more changes would be made to the 1.5.0 branch until the final release. So far, though, these two patches have mostly been ignored --- a few people have responded, but not many. It's not like anyone has shown that these patches are problematic, break things, etc. --- they've just been ignored. If these don't make it into the release for no good reason, and then have to wait until 1.6, I think that would be quite unfair. I agree with you: I'd like to see this fix go in for 1.5, as it seems important to some people, and this is ready. That said, however, I don't use the facilities that give rise to these bugs, and I'm not sure how many people do, at least in ways that will cause the very subtle problems to which you're responding. I think that's why there's been such silence---that, and the fact that so many people seem to have vanished, waiting for 1.5.0 to arrive so we can get back to work. So yes, there too, I agree that 1.5 should branch now, or near to now. I've got work myself that is waiting. 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] remove linuxdoc from all doc files
Uwe Stöhr wrote:
Jürgen requested that I fix bug 2787:
http://bugzilla.lyx.org/show_bug.cgi?id=2787
for LyX 1.5.0.
I did this in the attached patch. (I can do the same for the
translated manuals when I get the OK.)
But when applying this, the generate hyperlink option in the URL
dialog is then senseless (perhaps this is already the case) and should
be removed from this dialog. (Someone else should do this please.)
I've done this: patch attached. That said, just removing the option from
the dialog won't do anything one way or another about old files in which
it exists. Those files will still be loaded with that option, and it
won't be handled properly.
Maybe that's OK for now, but I'd have thought we should eliminate it
altogether, if we're removing it from the dialog. If so, this is a
format change, and appropriate lyx2lyx will presumably be needed (maybe
just to convert htmlurl insets into url insets). I haven't gone into
lyx2lyx, so someone else would need to do that. To eliminate this, we'd
need changes everywhere htmlurl is mentioned:
factory.cpp:430: || cmdName == htmlurl) {
insets/Inset.cpp:64:InsetName(htmlurl, Inset::HTMLURL_CODE),
insets/InsetCommandParams.cpp:166: if (name == htmlurl || name ==
url) {
Text3.cpp:1166: InsetCommandParams p(htmlurl);
But those changes are pretty obvious. It's the lyx2lyx stuff that I
don't understand.
Richard
Opinions?
regards Uwe
Index: Customization.lyx
===
--- Customization.lyx (revision 19106)
+++ Customization.lyx (working copy)
@@ -1,5 +1,5 @@
#LyX 1.5.0svn created this file. For more info see http://www.lyx.org/
-\lyxformat 274
+\lyxformat 276
\begin_document
\begin_header
\textclass book
@@ -39,9 +39,10 @@
\paperpagestyle headings
\tracking_changes false
\output_changes false
-\author Richard Heck
-\author Jean-Marc Lasgouttes
-\author usti
+\author
+\author
+\author
+\author
\end_header
\begin_body
@@ -5967,7 +5968,7 @@
\begin_layout Standard
This indicates that your text class uses the foo.sty package.
- Finally, it is also possible to declare classes for SGML and DocBook code.
+ Finally, it is also possible to declare classes for DocBook code.
Typical declarations will look like
\end_layout
@@ -5982,20 +5983,6 @@
\size small
#
\backslash
-DeclareSGMLClass{SGML (LinuxDoc)}
-\end_layout
-
-\begin_layout Standard
-or
-\end_layout
-
-\begin_layout LyX-Code
-#% Do not delete the line below; configure depends on this
-\end_layout
-
-\begin_layout LyX-Code
-#
-\backslash
DeclareDocBookClass[article]{SGML (DocBook article)}
\end_layout
@@ -9473,10 +9460,6 @@
\end_layout
\begin_layout LyX-Code
-Format LinuxDoc
-\end_layout
-
-\begin_layout LyX-Code
Product [XFig: $$FName]
\end_layout
@@ -9666,7 +9649,7 @@
\family typewriter
\series medium
Format\InsetSpace ~
-LaTeX|PDFLaTeX|PlainText|DocBook|LinuxDoc
+LaTeX|PDFLaTeX|PlainText|DocBook
\family default
\series default
The primary document file format that this format definition is for.
@@ -9676,8 +9659,7 @@
Format
\family default
section for all formats.
- Use a dummy text when no representation is available (see the LinuxDoc
- format in the example above).
+ Use a dummy text when no representation is available.
Then you can at least see a reference to the external material in the exported
document.
\end_layout
Index: EmbeddedObjects.lyx
===
--- EmbeddedObjects.lyx (revision 19106)
+++ EmbeddedObjects.lyx (working copy)
@@ -201,7 +201,8 @@
\bullet 3 2 7 -1
\tracking_changes false
\output_changes false
-\author Uwe Stöhr
+\author
+\author
\end_header
\begin_body
@@ -26880,28 +26881,6 @@
\end_layout
\begin_layout Standard
-The option
-\family sans
-Generate\InsetSpace ~
-hyperlink
-\family default
- in the URL dialog has only an affect when you export your document to the
- format
-\begin_inset Quotes eld
-\end_inset
-
-
-\family sans
-LinuxDoc
-\family default
-
-\begin_inset Quotes erd
-\end_inset
-
-.
-\end_layout
-
-\begin_layout Standard
You cannot change the style of the link text.
The text of the
\family sans
Index: Extended.lyx
===
--- Extended.lyx(revision 19106)
+++ Extended.lyx(working copy)
@@ -1,5 +1,5 @@
#LyX 1.5.0svn created this file. For more info see http://www.lyx.org/
-\lyxformat 274
+\lyxformat 276
\begin_document
\begin_header
\textclass book
@@ -37,7 +37,8 @@
\paperpagestyle headings
\tracking_changes false
\output_changes false
-\author usti
+\author
+\author
\end_header
\begin_body
@@ -15404,675 +15405,6 @@
\end_layout
\begin_layout Section
-Using LyX with SGML-Tools (aka LinuxDoc)
-\end_layout
-
-\begin_layout
Re: lyx2lyx for patch 1820
On Wed, Jul 18, 2007 at 03:21:52AM +0300, Dov Feldstern wrote: Hi! Attached find a lyx2lyx for patch 1820. It's not perfect, though --- it actually corrupts some files which shouldn't be changed at all; if anyone wants to try and fix that, be my guest, I've just spent the past six hours on this and I'm not sure that it's doable. Also, this has only convinced me even more that it's wrong to apply a lyx2lyx fix for this patch: this is a bug fix, there were previously .lyx files which were ok, but which lyx was generating incorrect latex for, and patch 1820 fixes that. If there are lyx documents out there which patch 1820 affects, it can only do them good. All this lyx2lyx patch does is to explicitly set the language to the wrong values in all kinds of situations. FWIW, I agree with you. LyX was generating wrong LaTeX code in those cases and this should be considered as bug fix. IMO, it is laughable requiring a lyx2lyx patch in order to perpetuate the bug. -- Enrico
Re: lyx2lyx for patch 1820
Enrico Forestieri wrote: On Wed, Jul 18, 2007 at 03:21:52AM +0300, Dov Feldstern wrote: Hi! Attached find a lyx2lyx for patch 1820. It's not perfect, though --- it actually corrupts some files which shouldn't be changed at all; if anyone wants to try and fix that, be my guest, I've just spent the past six hours on this and I'm not sure that it's doable. Also, this has only convinced me even more that it's wrong to apply a lyx2lyx fix for this patch: this is a bug fix, there were previously .lyx files which were ok, but which lyx was generating incorrect latex for, and patch 1820 fixes that. If there are lyx documents out there which patch 1820 affects, it can only do them good. All this lyx2lyx patch does is to explicitly set the language to the wrong values in all kinds of situations. FWIW, I agree with you. LyX was generating wrong LaTeX code in those cases and this should be considered as bug fix. IMO, it is laughable requiring a lyx2lyx patch in order to perpetuate the bug. + ALOT. rh -- == 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: Patches for 1820 and 3613
Dov Feldstern wrote: So far, though, these two patches have mostly been ignored --- a few people have responded, but not many. You're not ignored. I agree that these patches should be considered, but I don't understand the stuff enough to comment (and I'm too busy for testing). I think you should be patient and wait until José, who is the one who decides and also probably the one who understands the changes, finds time to look at it. Please accept that he is also quite busy with the lyx2lyx bugs currently. Jürgen
Re: [patch] fix drawing issue
Abdelrazak Younes wrote: It should, but you need another OK. OK from me. José? Jürgen
Text Settings Dialog [Beyond 1.5]
There are several large issues with this dialog collected in bug 3893.
It really doesn't work very well. Here is a radical suggestion: Get rid
of it in favor of character styles. So we'd have character styles like
Italic, SmallCaps, and the like, accessed via the EditText Styles menu,
rather than through a dialog. These could all be defined in a
StdCharStyles.inc file to be included in other layouts.
There are some issues with this. At present, nesting character styles
can lead to some ugly display, because the lines under the text nest and
create quite a mess. I'd suggest making these optional, via a Layout
setting. The attached patch gives some idea how this might work. It can
be tried with these character styles:
CharStyle Italic
LatexType Command
LatexName textit
ShowBox false
Font
Shape Italic
EndFont
End
CharStyle SmallCaps
LatexType Command
LatexName textsc
ShowBox false
Font
Shape SmallCaps
EndFont
End
But there are still some issues here with the behavior of the cursor, as
it seems to expect a border between the inset and the surrounding text,
which has been removed.
Another issue is that the EditText Style menu could become very
crowded. It'd be nice to be able to define character styles and put them
into submenus, perhaps via a setting that was something like:
Submenu Shape
Which would create and populate submenus.
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
Index: src/insets/InsetCharStyle.cpp
===
--- src/insets/InsetCharStyle.cpp (revision 19107)
+++ src/insets/InsetCharStyle.cpp (working copy)
@@ -102,6 +102,7 @@
params_.font = Font(Font::ALL_INHERIT);
params_.labelfont = Font(Font::ALL_INHERIT);
params_.labelfont.setColor(Color::error);
+ params_.showbox = true;
params_.show_label = true;
}
@@ -113,7 +114,8 @@
params_.latexparam = cs-latexparam;
params_.font = cs-font;
params_.labelfont = cs-labelfont;
- params_.show_label = true;
+ params_.showbox = cs-showbox;
+ params_.show_label = cs-showbox; //can't show label if no box
}
@@ -144,31 +146,34 @@
getDrawFont(mi.base.font);
mi.base.font.reduce(Font(Font::ALL_SANE));
mi.base.font.realize(tmpfont);
- mi.base.textwidth -= 2 * TEXT_TO_INSET_OFFSET;
+ if (params_.showbox)
+ mi.base.textwidth -= 2 * TEXT_TO_INSET_OFFSET;
InsetText::metrics(mi, dim);
mi.base.font = tmpfont;
- if (params_.show_label) {
- // consider width of the inset label
- Font font(params_.labelfont);
- font.realize(Font(Font::ALL_SANE));
- font.decSize();
- font.decSize();
- int w = 0;
- int a = 0;
- int d = 0;
- // FIXME UNICODE
- docstring s(from_utf8(params_.type));
- if (undefined())
- s = _(Undef: ) + s;
- theFontMetrics(font).rectText(s, w, a, d);
- dim.wid = max(dim.wid, w);
+ if (params_.showbox) {
+ if (params_.show_label) {
+ // consider width of the inset label
+ Font font(params_.labelfont);
+ font.realize(Font(Font::ALL_SANE));
+ font.decSize();
+ font.decSize();
+ int w = 0;
+ int a = 0;
+ int d = 0;
+ // FIXME UNICODE
+ docstring s(from_utf8(params_.type));
+ if (undefined())
+s = _(Undef: ) + s;
+ theFontMetrics(font).rectText(s, w, a, d);
+ dim.wid = max(dim.wid, w);
+ }
+ dim.asc += TEXT_TO_INSET_OFFSET;
+ dim.des += TEXT_TO_INSET_OFFSET;
+ dim.wid += 2 * TEXT_TO_INSET_OFFSET;
+ mi.base.textwidth += 2 * TEXT_TO_INSET_OFFSET;
+ if (params_.show_label)
+ dim.des += ascent();
}
- dim.asc += TEXT_TO_INSET_OFFSET;
- dim.des += TEXT_TO_INSET_OFFSET;
- dim.wid += 2 * TEXT_TO_INSET_OFFSET;
- mi.base.textwidth += 2 * TEXT_TO_INSET_OFFSET;
- if (params_.show_label)
- dim.des += ascent();
bool const changed = dim_ != dim;
dim_ = dim;
return changed;
@@ -183,40 +188,42 @@
getDrawFont(pi.base.font);
// I don't understand why the above .reduce and .realize aren't
//needed, or even wanted, here. It just works. -- MV 10.04.2005
- InsetText::draw(pi, x + TEXT_TO_INSET_OFFSET, y);
+ InsetText::draw(pi, x + (params_.showbox ? TEXT_TO_INSET_OFFSET : 0), y);
pi.base.font = tmpfont;
int desc = InsetText::descent();
- if (params_.show_label)
- desc -= ascent();
- pi.pain.line(x, y + desc - 4, x, y + desc, params_.labelfont.color());
- pi.pain.line(x, y + desc, x + dim_.wid - 3, y + desc,
- params_.labelfont.color());
- pi.pain.line(x + dim_.wid - 3, y + desc, x + dim_.wid - 3, y + desc - 4,
- params_.labelfont.color());
+ if (params_.showbox) {
+ if (params_.show_label)
+ desc -= ascent();
+ pi.pain.line(x, y + desc - 4, x, y + desc,
Re: Listings
Uwe Stöhr wrote: > But this is then a bug. LyX currently swallows all author informations > without confirmation. This is in my opinion a dataloss! I don't think so. The author information was introduced and currently is actually only there for change tracking purposes. Because of bug 3764, this privacy information leaked into documents without change tracking (without user confirmation). > Furthermore it is a bug that I can set my identity in the preferences but > still get an empty author field in the LyX files. Currently an author is > only set when change tracking was used. That's how it's supposed to be. > What I still miss is an option in > the preferences to set this in every case. Right. But that would be a new feature. You can file an enhancement request on this. The policy should be: newer publish privacy information when the user didn't explicitly agreed on this. Jürgen
Re: [PATCH] Re: Current svn: Crash with pdfsync
José Matos wrote:
On Monday 16 July 2007 18:46:55 Abdelrazak Younes wrote:
OK, Jose shall I commit?
OK.
Done.
Please note that I have two other patches pending...
I know, I am a slow thinker. :-)
There's nothing much to think about IMO. The two patches are fixing
_real_ crashes:
* delete_hideSignal.patch:
1) create a doc
2) insert an ert inset
3) right-click the inset
4) new window
5) delete the ert inset: BOOM!
* crash_exit_multiview.patch:
With or without multiview, the crash happens randomly if the statusbar
timer times out after the view is closed. Two reason for that:
1) LyXFunc::lyx_view_ is not set to 0
2) quiting is not set to true.
Abdel.
Index: frontends/qt4/GuiView.cpp
===
--- frontends/qt4/GuiView.cpp (revision 19080)
+++ frontends/qt4/GuiView.cpp (working copy)
@@ -288,8 +288,14 @@
}
}
+ // Make sure that no LFUN use this close to be closed View.
+ theLyXFunc().setLyXView(0);
+ // Make sure the timer time out will not trigger a statusbar update.
+ statusbar_timer_.stop();
+
theApp()->gui().unregisterView(id());
if (!theApp()->gui().viewIds().empty()) {
+ quitting = true;
// Just close the window and do nothing else if this is not the
// last window.
close_event->accept();
Index: LyXFunc.cpp
===
--- LyXFunc.cpp (revision 19080)
+++ LyXFunc.cpp (working copy)
@@ -1841,7 +1841,7 @@
}
}
}
- if (!quitting) {
+ if (!quitting && lyx_view_) {
lyx_view_->updateMenubar();
lyx_view_->updateToolbars();
// Some messages may already be translated, so we cannot use _()
Index: frontends/Dialogs.cpp
===
--- frontends/Dialogs.cpp (revision 19080)
+++ frontends/Dialogs.cpp (working copy)
@@ -21,63 +21,18 @@
#include
#include
+using std::string;
namespace lyx {
-
-using std::string;
using lyx::frontend::Dialog;
-// Note that static boost signals break some compilers, so this wrapper
-// initialises the signal dynamically when it is first invoked.
-template
-class BugfixSignal {
-public:
- Signal & operator()() { return thesignal(); }
- Signal const & operator()() const { return thesignal(); }
-
-private:
- Signal & thesignal() const
- {
- if (!signal_.get())
- signal_.reset(new Signal);
- return *signal_;
- }
-
- mutable boost::scoped_ptr signal_;
-};
-
-
-namespace {
-
-BugfixSignal > hideSignal;
-
-}
-
-
-void Dialogs::hide(string const & name, Inset* inset)
-{
- // Don't send the signal if we are quitting, because on MSVC it is
- // destructed before the cut stack in CutAndPaste.cpp, and this method
- // is called from some inset destructor if the cut stack is not empty
- // on exit.
- if (!quitting)
- hideSignal()(name, inset);
-}
-
-
Dialogs::Dialogs(LyXView & lyxview)
: lyxview_(lyxview), in_show_(false)
{
- // Connect signals
- connection_ = hideSignal().connect(boost::bind(::hideSlot,
this, _1, _2));
}
-Dialogs::~Dialogs()
-{
- connection_.disconnect();
-}
Dialog * Dialogs::find_or_build(string const & name)
{
@@ -149,8 +104,15 @@
}
-void Dialogs::hideSlot(string const & name, Inset * inset)
+void Dialogs::hide(string const & name, Inset* inset)
{
+ // Don't send the signal if we are quitting, because on MSVC it is
+ // destructed before the cut stack in CutAndPaste.cpp, and this method
+ // is called from some inset destructor if the cut stack is not empty
+ // on exit.
+ if (quitting)
+ return;
+
std::map::const_iterator it =
dialogs_.find(name);
if (it == dialogs_.end())
Index: frontends/Dialogs.h
===
--- frontends/Dialogs.h (revision 19080)
+++ frontends/Dialogs.h (working copy)
@@ -31,8 +31,6 @@
public:
///
Dialogs(LyXView &);
- ///
- ~Dialogs();
/** Check the status of all visible dialogs and disable or reenable
* them as appropriate.
@@ -89,15 +87,13 @@
/** All Dialogs of the given \param name will be closed if they are
connected to the given \param inset.
*/
- static void hide(std::string const & name, Inset * inset);
+ void hide(std::string const & name, Inset * inset);
///
void disconnect(std::string const & name);
///
Inset * getOpenInset(std::string const & name) const;
private:
///
- void hideSlot(std::string
Re: [PATCH] Re: Current svn: Crash with pdfsync
On Tuesday 17 July 2007 09:43:12 Abdelrazak Younes wrote: > There's nothing much to think about IMO. The two patches are fixing > _real_ crashes: Close to the final release any patch that is not a one line makes me nervous, no matter if they fix crashes or not. :-) > * delete_hideSignal.patch: > 1) create a doc > 2) insert an ert inset > 3) right-click the inset > 4) new window > 5) delete the ert inset: BOOM! There us some kind of poetic justice here. :-) > * crash_exit_multiview.patch: > With or without multiview, the crash happens randomly if the statusbar > timer times out after the view is closed. Two reason for that: > 1) LyXFunc::lyx_view_ is not set to 0 > 2) quiting is not set to true. OK to both. > Abdel. -- José Abílio
Re: [PATCH] Re: Current svn: Crash with pdfsync
José Matos wrote: On Tuesday 17 July 2007 09:43:12 Abdelrazak Younes wrote: There's nothing much to think about IMO. The two patches are fixing _real_ crashes: Close to the final release any patch that is not a one line makes me nervous, no matter if they fix crashes or not. :-) I understand but those two are really simple and, this time, I actually made sure there was no "brown paper bag possible. The first one remove some code which is always a good sign :-) * delete_hideSignal.patch: 1) create a doc 2) insert an ert inset 3) right-click the inset 4) new window 5) delete the ert inset: BOOM! There us some kind of poetic justice here. :-) I am a poet ;-) * crash_exit_multiview.patch: With or without multiview, the crash happens randomly if the statusbar timer times out after the view is closed. Two reason for that: 1) LyXFunc::lyx_view_ is not set to 0 2) quiting is not set to true. OK to both. OK, will commit in a minute, thanks! Abdel.
Re: [patch] Reversing numbers in arabic_arabi
On Monday 16 July 2007 20:17:44 Dov Feldstern wrote: > This is technically a format change, though I would again argue that we > should *not* create a lyx2lyx for it. However, if this is not > acceptable, a lyx2lyx patch should be relatively simple; and that only > underlines the need for applying this before 1.5.0. Who are our users of arabi? That is the main question to ask. :-) If the answer is developers then I do not have any problem letting this go without a file format change. > Dov -- José Abílio
Re: [patch] Reversing numbers in arabic_arabi
José Matos wrote: On Monday 16 July 2007 20:17:44 Dov Feldstern wrote: This is technically a format change, though I would again argue that we should *not* create a lyx2lyx for it. However, if this is not acceptable, a lyx2lyx patch should be relatively simple; and that only underlines the need for applying this before 1.5.0. Who are our users of arabi? That is the main question to ask. :-) If the answer is developers then I do not have any problem letting this go without a file format change. "arabi" was not supported up until recently (1.5 only) so there was no users of it, only Mostafa recently for Farsi. Abdel.
Re: [patch] Reversing numbers in arabic_arabi
On Tuesday 17 July 2007 10:52:13 Abdelrazak Younes wrote: > "arabi" was not supported up until recently (1.5 only) so there was no > users of it, only Mostafa recently for Farsi. I know that. But we have already released pre-releases with the support on it and we want our users to take the pre-releases seriously. > Abdel. -- José Abílio
Re: [patch] Reversing numbers in arabic_arabi
José Matos wrote: On Tuesday 17 July 2007 10:52:13 Abdelrazak Younes wrote: "arabi" was not supported up until recently (1.5 only) so there was no users of it, only Mostafa recently for Farsi. I know that. But we have already released pre-releases with the support on it and we want our users to take the pre-releases seriously. Then ask on the users list and ask to Mostafa too. Quite frankly, I don't think there's anybody but Mostafa. Even though there is other users the only difference with the patch is, AFAIU, that the number in the output will be in the correct order. This was clearly a bug in LyX latex export and not a format change IMHO. Abdel.
Re: [patch] Reversing numbers in arabic_arabi
On Tuesday 17 July 2007 11:28:26 Abdelrazak Younes wrote: > Quite frankly, I don't think there's anybody but Mostafa. Even though > there is other users the only difference with the patch is, AFAIU, that > the number in the output will be in the correct order. This was clearly > a bug in LyX latex export and not a format change IMHO. I don't disagree with I just want to be sure that this is the case. > Abdel. -- José Abílio
Re: [updated PATCH] bugs 3958, 3313 and 3976 lyx2lyx and unicode characters
On Friday 13 July 2007 13:16:46 Anders Ekberg wrote:
> I have tried to address Georg's and Juergen's comments.
> To avoid data-loss, the function is only run if the encoding is auto
> or default and there are no language changes (overly conservative,
> but possible to work around, as commented in the code). Now, I
> *assume* this should prevent any cases that can cause data-loss (i.e.
> assuming unicode encoding when it is not), but I don't know the
> format good enough to be sure, so please correct the code if I'm wrong.
We can extend the test to see if the included languages have the same
encoding...
> To avoid the need for two unicodesymbols files, I have removed that
> requirement by assuming any command that includes { and } and not any
> of the exception tokens, to be an accented character. I also check
> for combining characters and don't translate these (which allowed the
> removal of an if-test in the end of the code). It is not pretty, but
> works...
>
> Details and an idea for a (hopefully) better solution are in bugzilla
> http://bugzilla.lyx.org/show_bug.cgi?id=3958
As I said there the format change needs to be in lyx_1_5.py and not in
LyX.py.
> Anders
--
José Abílio
Re: Search LyX Text Functionality.
Abdelrazak Younes ha scritto: I'll try to look at the Controller code tommorrow. Obviously, the controller was missing. Added a new patch. T.
[patch] fix drawing issue
This oneliner fixes some ugly drawing artefacts with insets in the appendix
(probably introduced with revision 19039).
Attached also a testcase where you can see the artefacts.
OK to apply?
Jürgen
Index: src/rowpainter.cpp
===
--- src/rowpainter.cpp (Revision 19092)
+++ src/rowpainter.cpp (Arbeitskopie)
@@ -471,7 +471,7 @@
void RowPainter::paintAppendix()
{
- if (!par_.params().appendix())
+ if (!par_.params().appendix() || !text_.isMainText(*bv_.buffer()))
return;
int y = yo_ - row_.ascent();
redraw.lyx
Description: application/lyx
Re: [patch] fix drawing issue
On Tuesday 17 July 2007 14:25:23 Jürgen Spitzmüller wrote: > This oneliner fixes some ugly drawing artefacts with insets in the appendix > (probably introduced with revision 19039). > > Attached also a testcase where you can see the artefacts. > > OK to apply? OK. > Jürgen -- José Abílio
Re: lyx2lyx help
On Sunday 15 July 2007 18:02:46 Dov Feldstern wrote: > Files from pre-249 are wrong, but post-249 don't have the problem. So my > new stage (277) should only run on files which originated at pre-249... > Currently, since I'm running on everything, I'm trying to "fix" things > which aren't broken... Assuming I understand what you mean it seems that this fix should be made for the 248->249 step, this would solve that particular problem. > Thanks! > Dov -- José Abílio
Re: [patch] Reversing numbers in arabic_arabi
The patch sent by Dov is OK. I am really sorry for being late in replying to the emails. These days I have too many things TODO. Mostafa - Need a vacation? Get great deals to amazing places on Yahoo! Travel.
Re: Search LyX Text Functionality.
Tommaso Cucinotta wrote: > Added a new patch. Hi Tommaso, this is just to let you know that we are actually noticing what you are doing :-) You might be aware that we are busy with getting 1.5.0 out (and in feature freeze), so you will have to be a bit patient. I have applied your patch and had a quick look (I had to add the Controllers to controllers/Makefile.am to make it compile). It looks very promising! Some things are not working yet (e.g. searching for special symbols like ligature breaks, replacing), but you might be aware of that. I also think you new input widget (i.e. the small work area) might be of general use for other dialogs, such as the url and index dialogs (which would fix the problems with non-escaped characters). Impressing stuff. Jürgen P.S. Some formal issues I've noticed with the patch: - our source files are encoded in latin 1 (your patch mangles names with special characters, such as "Bjønnes") - please adapt the formatting (always tab for indendation, max line lenght ~75 chars) to the rest of the code. Have a look at development/code_rules for some hints. Jürgen
Re: [patch] fix drawing issue
On 7/17/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote: This oneliner fixes some ugly drawing artefacts with insets in the appendix (probably introduced with revision 19039). There is also a redraw problem when you delete in ERT or listings inset, do you also have an oneliner? :-) Bo
Convert source code to utf8? (was Re: Search LyX Text Functionality.
Jürgen Spitzmüller wrote: - our source files are encoded in latin 1 (your patch mangles names with special characters, such as "Bjønnes") Shouldn't we convert that to utf8 before 1.5.0? I remind you that we need to do that for layouts too. Abdel.
Re: [patch] fix drawing issue
Bo Peng wrote: > There is also a redraw problem when you delete in ERT or listings > inset, do you also have an oneliner? :-) No, unfortunately not. Jürgen
Re: [patch] Reversing numbers in arabic_arabi
On Tuesday 17 July 2007 15:02:42 Mostafa Vahedi wrote: > The patch sent by Dov is OK. I am really sorry for being late in replying > to the emails. These days I have too many things TODO. OK then. > Mostafa -- José Abílio
Bug parsing latex command
This bug was reported in the users list.
The problem was with the translation of the following piece:
\begin_inset LatexCommand
\url{http://www.worldscinet.com/ijmpc/mkt/guidelines.s
html}
\end_inset
lyx2lyx was expecting the whole command to be in the same line so it left that
html} alone in a single line.
\begin_inset LatexCommand url
target "http://www.worldscinet.com/ijmpc/mkt/guidelines.s;
html}
\end_inset
This was enough to crash lyx.
Adding the following piece of code takes care about those cases and it works
so I will commit it.
Index: lyx_1_5.py
===
--- lyx_1_5.py (revision 19100)
+++ lyx_1_5.py (working copy)
@@ -444,6 +444,13 @@
i = i + 1
continue
+j = find_token(document.body, "\\end_inset", i+1)
+if j == -1:
+document.warning("Malformed document")
+else:
+command += "".join(document.body[i+1:j])
+document.body[i+1:j] = []
+
# The following parser is taken from the original
InsetCommandParams::scanCommand
name = ""
option1 = ""
--
José Abílio
crash while dissolving tabular
- New Document - Insert 1x1 tabular (one cell) - type "foo" inside cell - hit DEL => crash Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47819059702400 (LWP 29034)] 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x00a11d53 in lyx::InsetTabularMailer::params2string ([EMAIL PROTECTED]) at InsetTabular.cpp:4848 #2 0x00a11fc7 in lyx::InsetTabularMailer::inset2string (this=) at InsetTabular.cpp:4813 #3 0x0091b751 in lyx::MailInset::updateDialog (this=0x7179c9a0, bv=0x1717dc0) at MailInset.cpp:38 #4 0x00a25bd4 in lyx::InsetTabular::doDispatch (this=0x19a0820, [EMAIL PROTECTED], [EMAIL PROTECTED]) at InsetTabular.cpp:3499 #5 0x0091dee6 in lyx::Inset::dispatch (this=0x19a0820, [EMAIL PROTECTED], [EMAIL PROTECTED]) at Inset.cpp:145 #6 0x0057960b in lyx::Cursor::dispatch (this=0x1718158, [EMAIL PROTECTED]) at Cursor.cpp:317 #7 0x006dc3ff in lyx::LyXFunc::dispatch (this=0x14b7040, [EMAIL PROTECTED]) at LyXFunc.cpp:1808 #8 0x006dde35 in lyx::LyXFunc::processKeySym (this=0x14b7040, [EMAIL PROTECTED], state=lyx::key_modifier::none) at LyXFunc.cpp:383 #9 0x00a9a3c8 in lyx::frontend::WorkArea::processKeySym (this=0x1612dd8, [EMAIL PROTECTED], state=lyx::key_modifier::none) at WorkArea.cpp:180 #10 0x00b08133 in lyx::frontend::GuiWorkArea::keyPressEvent (this=0x1612db0, e=0x7179f480) at GuiWorkArea.cpp:474 #11 0x2b7db96d4878 in QWidget::event (this=0x1612db0, event=0x7179f480) at kernel/qwidget.cpp:5753 ---Type to continue, or q to quit--- #12 0x2b7db9925409 in QFrame::event (this=0x19a0820, e=0x3) at widgets/qframe.cpp:633 #13 0x2b7db998e6eb in QAbstractScrollArea::event (this=0x1612db0, e=0x7179f480) at widgets/qabstractscrollarea.cpp:810 #14 0x2b7db968fbbc in QApplicationPrivate::notify_helper (this=0x0, receiver=0x1612db0, e=0x7179f480) at kernel/qapplication.cpp:3439 #15 0x2b7db96926db in QApplication::notify (this=, receiver=0x1612db0, e=0x7179f480) at kernel/qapplication.cpp:3067 #16 0x00aee4c4 in lyx::frontend::GuiApplication::notify (this=0x19a0820, receiver=0x3, event=0x7179c3a0) at GuiApplication.cpp:237 #17 0x2b7db96d94fd in qt_sendSpontaneousEvent (receiver=0x6c757220, event=0x7179c3a0) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:186 #18 0x2b7db970194d in QKeyMapper::sendKeyEvent (keyWidget=0x1612db0, grab=, type=QEvent::KeyPress, code=16777223, [EMAIL PROTECTED], [EMAIL PROTECTED], autorepeat=, count=1, nativeScanCode=107, nativeVirtualKey=65535, nativeModifiers=16) at kernel/qkeymapper_x11.cpp:1580 #19 0x2b7db9703889 in QKeyMapperPrivate::translateKeyEvent (this=0x14f6f40, keyWidget=0x1612db0, event=0x7179fcf0, grab=3) at kernel/qkeymapper_x11.cpp:1560 #20 0x2b7db96e31e7 in QApplication::x11ProcessEvent (this=0x14bca00, event=0x7179fcf0) at kernel/qapplication_x11.cpp:2782 #21 0x2b7db9704ca5 in x11EventSourceDispatch (s=0x14c4b60, callback=0, user_data=0x0) at kernel/qguieventdispatcher_glib.cpp:122 #22 0x2b7dbbb56f94 in g_main_context_dispatch () from /opt/gnome/lib64/libglib-2.0.so.0 ---Type to continue, or q to quit--- #23 0x2b7dbbb59dc5 in g_main_context_prepare () from /opt/gnome/lib64/libglib-2.0.so.0 #24 0x2b7dbbb5a2ee in g_main_context_iteration () from /opt/gnome/lib64/libglib-2.0.so.0 #25 0x2b7dbb6a0430 in QEventDispatcherGlib::processEvents (this=0x14c1080, flags=) at kernel/qeventdispatcher_glib.cpp:366 #26 0x2b7db9704abf in QGuiEventDispatcherGlib::processEvents (this=0x19a0820, flags=) at kernel/qguieventdispatcher_glib.cpp:178 #27 0x2b7dbb67eda8 in QEventLoop::processEvents (this=, flags=) at kernel/qeventloop.cpp:126 #28 0x2b7dbb67eeb9 in QEventLoop::exec (this=0x717a0070, [EMAIL PROTECTED]) at kernel/qeventloop.cpp:172 #29 0x2b7dbb681080 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:730 #30 0x00aed749 in lyx::frontend::GuiApplication::exec (this=) at GuiApplication.cpp:158 #31 0x006b4ca2 in lyx::LyX::exec (this=0x717a1290, argc=, argv=) at LyX.cpp:475 #32 0x0042b7af in main (argc=1, argv=0x717a13a8) at main.cpp:48 Jürgen
Re: crash while dissolving tabular
Jürgen Spitzmüller wrote: - New Document - Insert 1x1 tabular (one cell) - type "foo" inside cell - hit DEL => crash I cannot reproduce the crash under windows but this looks familiar to an old crash you had with the Toc if you remember. I just committed a fix in the std declaration, does that help? Abdel.
Re: crash while dissolving tabular
Abdelrazak Younes wrote: > I just committed a fix in the std declaration, does that help? No. Jürgen
[PATCH] 3404: lyx2lyx adds too many \end_layout tokens
Jose:
The test case of bug 3404 has multiple consecutive
\begin_deeper
\begin_deeper
\end_deeper
\end_deeper
and an \end_layout is inserted before each \begin_deeper. This leads
to excessive \end_layout.
I am *not* familiar with lyx 1.3.x format and I do not know if there
are valid cases where multiple \begin_deeper should yield multiple
\end_layout. If you know the answer, the attached patch fixes bug
3404.
Cheers,
Bo
Index: lib/lyx2lyx/lyx_1_4.py
===
--- lib/lyx2lyx/lyx_1_4.py (revision 19100)
+++ lib/lyx2lyx/lyx_1_4.py (working copy)
@@ -466,6 +466,9 @@
document.body.insert(i,"")
document.body.insert(i,"\\end_layout")
i = i + 3
+# consecutive begin_deeper only insert one end_layout
+while document.body[i].startswith('\\begin_deeper'):
+i += 1
struct_stack.append(token)
continue
Index: lib/lyx2lyx/lyx_1_4.py
===
--- lib/lyx2lyx/lyx_1_4.py (revision 19100)
+++ lib/lyx2lyx/lyx_1_4.py (working copy)
@@ -466,6 +466,9 @@
document.body.insert(i,"")
document.body.insert(i,"\\end_layout")
i = i + 3
+# consecutive begin_deeper only insert one end_layout
+while document.body[i].startswith('\\begin_deeper'):
+i += 1
struct_stack.append(token)
continue
Re: crash while dissolving tabular
On 7/17/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote: - New Document - Insert 1x1 tabular (one cell) - type "foo" inside cell - hit DEL => crash I can confirm this. A really easy way to crash lyx. Bo
Re: [patch] fix drawing issue
Bo Peng wrote:
> There is also a redraw problem when you delete in ERT or listings
> inset, do you also have an oneliner? :-)
Try this (OK, a bit more than one line).
Jürgen
Index: src/rowpainter.cpp
===
--- src/rowpainter.cpp (Revision 19101)
+++ src/rowpainter.cpp (Arbeitskopie)
@@ -918,13 +918,21 @@
{
// check whether the current inset is nested in a non-wide inset
Cursor & cur = pi.base.bv->cursor();
- for (int i = cur.depth() - 1; --i >= 0; ) {
+ Inset const * cur_in = ();
+ // check all higher nested insets
+ for (size_type i = 1; i < cur.depth(); ++i) {
Inset * const in = [i].inset();
- if (in) {
+ if (in == cur_in)
+ // we reached the level of the current inset, so stop
+ return false;
+ else if (in) {
+ if (in->hasFixedWidth())
+return true;
InsetText * t =
const_cast(in->asTextInset());
- if (t)
-return !t->wide();
+ if (t && !t->wide())
+// OK, we are in a non-wide() inset
+return true;
}
}
return false;
@@ -1000,7 +1008,7 @@
// Clear background of this row
// (if paragraph background was not cleared)
if (!repaintAll &&
- (!(in_inset_alone_on_row && leftEdgeFixed)
+ (!(in_inset_alone_on_row && leftEdgeFixed && !inNarrowIns)
|| row_has_changed)) {
pi.pain.fillRectangle(x, y - rit->ascent(),
rp.maxWidth(), rit->height(),
Re: crash while dissolving tabular
Abdelrazak Younes wrote: > I cannot reproduce the crash under windows but this looks familiar to an > old crash you had with the Toc if you remember. I rather think it's a remainder of bug 3258. Note that in the backtrace, line 3497 in InsetTabular::doDispatch is reached, if (!is_deleted_) InsetTabularMailer(*this).updateDialog(()); // <-- this one which means that is_deleted_ is false. AFAIU your fix in revision 17568, is_deleted_ should be true in this case. Jürgen
Re: [patch] fix drawing issue
On 7/17/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote: Bo Peng wrote: > There is also a redraw problem when you delete in ERT or listings > inset, do you also have an oneliner? :-) Try this (OK, a bit more than one line). The problem seems to be solved, but I can not figure out when an ERT inset will occupy the rest of the line during edition. E.g. Normal Listings: Usually [listings ] Edit [listings ] Inline listings and ERT: Always "a[ERT]" or "[ERT]a" if there is something before/after it, otherwise span to the end of line during edition. I think it makes sense to either 1. does not expand to the end of the line at all, or 2. only expand when there is nothing after it. I.e. remove the case of a[ERT]. Bo
Re: [patch] Reversing numbers in arabic_arabi
José Matos wrote: On Tuesday 17 July 2007 15:02:42 Mostafa Vahedi wrote: The patch sent by Dov is OK. I am really sorry for being late in replying to the emails. These days I have too many things TODO. OK then. Mostafa Committed as 19105. Dov
Re: [patch] fix drawing issue
Bo Peng wrote: > The problem seems to be solved, but I can not figure out when an ERT > inset will occupy the rest of the line during edition. E.g. This is the unsavoury "wide() thing" (TM). The rule is: an inset spans the whole line, if - it is the only thing in the row and - the cursor is inside. > Normal Listings: > Usually [listings ] > Edit [listings ] Yes. > Inline listings and ERT: > > Always "a[ERT]" or "[ERT]a" if there is something before/after it, > otherwise span to the end of line during edition. Exactly. > I think it makes sense to either > 1. does not expand to the end of the line at all, or > 2. only expand when there is nothing after it. I.e. remove the case of > a[ERT]. I won't spend a single minute on improving it. IMO, the only reasonable goal is to remove the wide() thing altogether, once the speed problems are resolved (remember the wide() thing is just a hack to work around the speed issues). So if you think that bug 3582 is solved, I'd propose to put that into 1.5.0. Jürgen
Re: [patch] fix drawing issue
So if you think that bug 3582 is solved, I'd propose to put that into 1.5.0. It should, but you need another OK. Bo
Re: [patch] fix drawing issue
Bo Peng wrote: So if you think that bug 3582 is solved, I'd propose to put that into 1.5.0. It should, but you need another OK. OK from me. Abdel.
[patch] fix doc_toc.py documentation bug 3798
The attached documentation patch fixes http://bugzilla.lyx.org/show_bug.cgi?id=3798 It also converts depend.py to UTF-8 format that we use for all Python scripts in LyX 1.5. Can this go in José? regards Uwe Index: depend.py === --- depend.py (revision 19106) +++ depend.py (working copy) @@ -1,7 +1,7 @@ #! /usr/bin/env python -# -*- coding: iso-8859-1 -*- +# -*- coding: utf-8 -*- # This file is part of the LyX Documentation -# Copyright (C) 2004 José Matos <[EMAIL PROTECTED]> +# Copyright (C) 2004 José Matos <[EMAIL PROTECTED]> # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License @@ -21,6 +21,9 @@ # It does so by going through the files and printing out all of the # chapter, section, and sub(sub)section headings out. (It numbers the # sections sequentially; hopefully noone's using Section* in the docs.) +# It calls the script doc_toc.py using this syntax: +# depend.py doc_toc.py SetOfDocuments +# where SetOfDocuments is a set of documents import sys import os Index: doc_toc.py === --- doc_toc.py (revision 19106) +++ doc_toc.py (working copy) @@ -17,10 +17,14 @@ # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. -# This script creates a "master table of contents" for a set of LyX docs. +# This script is called by the script depend.py to create a "master table of contents" +# for a set of LyX docs. # It does so by going through the files and printing out all of the # chapter, section, and sub(sub)section headings out. (It numbers the # sections sequentially; hopefully noone's using Section* in the docs.) +# It is calledusing this syntax: +# depend.py doc_toc.py SetOfDocuments +# where SetOfDocuments is a set of documents import sys import os
[patch] remove linuxdoc from all doc files
Jürgen requested that I fix bug 2787:
http://bugzilla.lyx.org/show_bug.cgi?id=2787
for LyX 1.5.0.
I did this in the attached patch. (I can do the same for the translated manuals
when I get the OK.)
But when applying this, the "generate hyperlink" option in the URL dialog is then senseless (perhaps
this is already the case) and should be removed from this dialog. (Someone else should do this please.)
Opinions?
regards Uwe
Index: Customization.lyx
===
--- Customization.lyx (revision 19106)
+++ Customization.lyx (working copy)
@@ -1,5 +1,5 @@
#LyX 1.5.0svn created this file. For more info see http://www.lyx.org/
-\lyxformat 274
+\lyxformat 276
\begin_document
\begin_header
\textclass book
@@ -39,9 +39,10 @@
\paperpagestyle headings
\tracking_changes false
\output_changes false
-\author "Richard Heck"
-\author "Jean-Marc Lasgouttes"
-\author "usti"
+\author ""
+\author ""
+\author ""
+\author ""
\end_header
\begin_body
@@ -5967,7 +5968,7 @@
\begin_layout Standard
This indicates that your text class uses the foo.sty package.
- Finally, it is also possible to declare classes for SGML and DocBook code.
+ Finally, it is also possible to declare classes for DocBook code.
Typical declarations will look like
\end_layout
@@ -5982,20 +5983,6 @@
\size small
#
\backslash
-DeclareSGMLClass{SGML (LinuxDoc)}
-\end_layout
-
-\begin_layout Standard
-or
-\end_layout
-
-\begin_layout LyX-Code
-#% Do not delete the line below; configure depends on this
-\end_layout
-
-\begin_layout LyX-Code
-#
-\backslash
DeclareDocBookClass[article]{SGML (DocBook article)}
\end_layout
@@ -9473,10 +9460,6 @@
\end_layout
\begin_layout LyX-Code
-Format LinuxDoc
-\end_layout
-
-\begin_layout LyX-Code
Product "[XFig: $$FName]"
\end_layout
@@ -9666,7 +9649,7 @@
\family typewriter
\series medium
Format\InsetSpace ~
-LaTeX|PDFLaTeX|PlainText|DocBook|LinuxDoc
+LaTeX|PDFLaTeX|PlainText|DocBook
\family default
\series default
The primary document file format that this format definition is for.
@@ -9676,8 +9659,7 @@
Format
\family default
section for all formats.
- Use a dummy text when no representation is available (see the LinuxDoc
- format in the example above).
+ Use a dummy text when no representation is available.
Then you can at least see a reference to the external material in the exported
document.
\end_layout
Index: EmbeddedObjects.lyx
===
--- EmbeddedObjects.lyx (revision 19106)
+++ EmbeddedObjects.lyx (working copy)
@@ -201,7 +201,8 @@
\bullet 3 2 7 -1
\tracking_changes false
\output_changes false
-\author "Uwe Stöhr"
+\author ""
+\author ""
\end_header
\begin_body
@@ -26880,28 +26881,6 @@
\end_layout
\begin_layout Standard
-The option
-\family sans
-Generate\InsetSpace ~
-hyperlink
-\family default
- in the URL dialog has only an affect when you export your document to the
- format
-\begin_inset Quotes eld
-\end_inset
-
-
-\family sans
-LinuxDoc
-\family default
-
-\begin_inset Quotes erd
-\end_inset
-
-.
-\end_layout
-
-\begin_layout Standard
You cannot change the style of the link text.
The text of the
\family sans
Index: Extended.lyx
===
--- Extended.lyx (revision 19106)
+++ Extended.lyx (working copy)
@@ -1,5 +1,5 @@
#LyX 1.5.0svn created this file. For more info see http://www.lyx.org/
-\lyxformat 274
+\lyxformat 276
\begin_document
\begin_header
\textclass book
@@ -37,7 +37,8 @@
\paperpagestyle headings
\tracking_changes false
\output_changes false
-\author "usti"
+\author ""
+\author ""
\end_header
\begin_body
@@ -15404,675 +15405,6 @@
\end_layout
\begin_layout Section
-Using LyX with SGML-Tools (aka LinuxDoc)
-\end_layout
-
-\begin_layout Standard
-by
-\noun on
-Paul Evans
-\end_layout
-
-\begin_layout Subsection
-Overview
-\end_layout
-
-\begin_layout Standard
-LinuxDoc is a document class available in LyX if you have the
-\family typewriter
-sgml-tools
-\family default
- package installed.
- You can use it to produce documents in the so-called Standardized General
- Mark-up Language (SGML) in the particular format used by the Linux Documentatio
-n Project.
- That is obviously helpful if you are contributing to that project.
- You can use the SGML format with the
-\family typewriter
-sgml-tools
-\family default
- package of scripts and programs (to produce other formats, including LaTeX,
- HTML, plain text, man pages and\SpecialChar \ldots{}
-).
- You may therefore prefer to use this document class if you want to write
- something that can be easily translated into other formats.
-\end_layout
-
-\begin_layout Standard
-You will find that LinuxDoc has fewer layout options than the other text
- classes in LyX.
- This is mainly so that the translations into other formats have a chance
- of making some sense.
- In this section we
lyx2lyx for patch 1820
Hi! Attached find a lyx2lyx for patch 1820. It's not perfect, though --- it actually corrupts some files which shouldn't be changed at all; if anyone wants to try and fix that, be my guest, I've just spent the past six hours on this and I'm not sure that it's doable. Also, this has only convinced me even more that it's wrong to apply a lyx2lyx fix for this patch: this is a bug fix, there were previously .lyx files which were ok, but which lyx was generating incorrect latex for, and patch 1820 fixes that. If there are lyx documents out there which patch 1820 affects, it can only do them good. All this lyx2lyx patch does is to explicitly set the language to the wrong values in all kinds of situations. I would urge for what Martin suggested a few days ago: have an empty format change to go along with patch 1820, just to mark the fix, but not to apply any lyx2lyx for now. We have this patch in store, if anyone decides that it really *is* necessary, we'll always be able to apply it retroactively, since the format change was marked. Dov Index: lyx-devel/lib/lyx2lyx/lyx_1_5.py === --- lyx-devel.orig/lib/lyx2lyx/lyx_1_5.py 2007-07-17 22:38:36.0 +0300 +++ lyx-devel/lib/lyx2lyx/lyx_1_5.py2007-07-18 03:04:40.0 +0300 @@ -42,9 +42,122 @@ "Find beginning of layout, where lines[i] is included." return find_beginning_of(lines, i, "\\begin_layout", "\\end_layout") +def isRTL(language): +from lyx2lyx_lang import lang +return lang[language][2] == "true" + # End of helper functions +def recreate_bug1820(document): + """This function tries to undo the fix for bug 1820, so that documents +are displayed wrongly, as they were before the fix for that bug. + +Specifically, intra-paragraph language switches are closed before openning +an inset; and upon entering an inset, if in the new lyx the language is now +different than it would have been in the old lyx, then we now explicitly set +it to what it would have been in old lyx.""" + + lang_re = re.compile(r"^\\lang\s(\S+)") + inset_re = re.compile(r"^\\begin_inset\s(\S+)") + inset_end_re = re.compile(r"^\\end_inset") + status_re = re.compile(r"^status") + layout_re = re.compile(r"^\\begin_layout") + layout_end_re = re.compile(r"^\\end_layout") + + new_cur_lang = [document.language] + old_cur_lang = [document.language] + new_outer_lang = [document.language] + old_outer_lang = [document.language] + just_entered_inset = False + entered_inset_layout = False + + # we'll only insert the necessary lines at the end, in order not to + # interfere with the looping over the lines... + line_insertions = [] # (insert before line number, line to insert) + + for i in range(len(document.body)): + # determine the current language + result = lang_re.match(document.body[i]) + if result: + new_cur_lang[-1] = result.group(1) + old_cur_lang[-1] = result.group(1) + continue + result = layout_re.match(document.body[i]) + if result: + new_cur_lang[-1] = new_outer_lang[-1] + old_cur_lang[-1] = old_outer_lang[-1] + if not just_entered_inset: + continue + + # if we're openning an inset, and the current language is different + # than the paragraph language: + # old: close the current language + # new: close the current langauge, unless the RTL-ness of the two + # languages are different + if inset_re.match(document.body[i]): + par_language = get_paragraph_language(document, i) + + if old_cur_lang[-1] != par_language: + # write the closure to the file + line_insertions.insert(0, (i, "\\lang %s"%par_language)) + + # the second clause says that if we just closed the current + # language, then as far as the new lyx is concerned, we're + # back to the paragraph language + if isRTL(par_language) != isRTL(new_cur_lang[-1]) and \ + not old_cur_lang[-1] != par_language: + new_outer_lang.append(new_cur_lang[-1]) + new_cur_lang.append(new_cur_lang[-1]) + else: + new_outer_lang.append(par_language) + new_cur_lang.append(par_language) + +
Patches for 1820 and 3613
Hi! I've spent an enormous amount of time on getting these two bugs fixed for 1.5.0, since we realized that they involve format changes. I think I deserve to have them applied and tested, even if it means postponing the release for a week or two. I already suggested how we can do this without having to halt continued development (by branching now, but not yet releasing). Given that there have been a lot of little changes since the last RC, I also think it wouldn't be a bad idea to apply these patches, branch, and then release an RC, which would really be a release candidate this time: unless there are critical fixes / format changes, no more changes would be made to the 1.5.0 branch until the final release. So far, though, these two patches have mostly been ignored --- a few people have responded, but not many. It's not like anyone has shown that these patches are problematic, break things, etc. --- they've just been ignored. If these don't make it into the release for no good reason, and then have to wait until 1.6, I think that would be quite unfair. Dov
Re: Patches for 1820 and 3613
Dov Feldstern wrote: I've spent an enormous amount of time on getting these two bugs fixed for 1.5.0, since we realized that they involve format changes. I think I deserve to have them applied and tested, even if it means postponing the release for a week or two. I already suggested how we can do this without having to halt continued development (by branching now, but not yet releasing). Given that there have been a lot of little changes since the last RC, I also think it wouldn't be a bad idea to apply these patches, branch, and then release an RC, which would really be a release candidate this time: unless there are critical fixes / format changes, no more changes would be made to the 1.5.0 branch until the final release. So far, though, these two patches have mostly been ignored --- a few people have responded, but not many. It's not like anyone has shown that these patches are problematic, break things, etc. --- they've just been ignored. If these don't make it into the release for no good reason, and then have to wait until 1.6, I think that would be quite unfair. I agree with you: I'd like to see this fix go in for 1.5, as it seems important to some people, and this is ready. That said, however, I don't use the facilities that give rise to these bugs, and I'm not sure how many people do, at least in ways that will cause the very subtle problems to which you're responding. I think that's why there's been such silence---that, and the fact that so many people seem to have vanished, waiting for 1.5.0 to arrive so we can "get back to work". So yes, there too, I agree that 1.5 should branch now, or near to now. I've got work myself that is waiting. 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] remove linuxdoc from all doc files
Uwe Stöhr wrote:
Jürgen requested that I fix bug 2787:
http://bugzilla.lyx.org/show_bug.cgi?id=2787
for LyX 1.5.0.
I did this in the attached patch. (I can do the same for the
translated manuals when I get the OK.)
But when applying this, the "generate hyperlink" option in the URL
dialog is then senseless (perhaps this is already the case) and should
be removed from this dialog. (Someone else should do this please.)
I've done this: patch attached. That said, just removing the option from
the dialog won't do anything one way or another about old files in which
it exists. Those files will still be loaded with that option, and it
won't be handled properly.
Maybe that's OK for now, but I'd have thought we should eliminate it
altogether, if we're removing it from the dialog. If so, this is a
format change, and appropriate lyx2lyx will presumably be needed (maybe
just to convert htmlurl insets into url insets). I haven't gone into
lyx2lyx, so someone else would need to do that. To eliminate this, we'd
need changes everywhere htmlurl is mentioned:
factory.cpp:430: || cmdName == "htmlurl") {
insets/Inset.cpp:64:InsetName("htmlurl", Inset::HTMLURL_CODE),
insets/InsetCommandParams.cpp:166: if (name == "htmlurl" || name ==
"url") {
Text3.cpp:1166: InsetCommandParams p("htmlurl");
But those changes are pretty obvious. It's the lyx2lyx stuff that I
don't understand.
Richard
Opinions?
regards Uwe
Index: Customization.lyx
===
--- Customization.lyx (revision 19106)
+++ Customization.lyx (working copy)
@@ -1,5 +1,5 @@
#LyX 1.5.0svn created this file. For more info see http://www.lyx.org/
-\lyxformat 274
+\lyxformat 276
\begin_document
\begin_header
\textclass book
@@ -39,9 +39,10 @@
\paperpagestyle headings
\tracking_changes false
\output_changes false
-\author "Richard Heck"
-\author "Jean-Marc Lasgouttes"
-\author "usti"
+\author ""
+\author ""
+\author ""
+\author ""
\end_header
\begin_body
@@ -5967,7 +5968,7 @@
\begin_layout Standard
This indicates that your text class uses the foo.sty package.
- Finally, it is also possible to declare classes for SGML and DocBook code.
+ Finally, it is also possible to declare classes for DocBook code.
Typical declarations will look like
\end_layout
@@ -5982,20 +5983,6 @@
\size small
#
\backslash
-DeclareSGMLClass{SGML (LinuxDoc)}
-\end_layout
-
-\begin_layout Standard
-or
-\end_layout
-
-\begin_layout LyX-Code
-#% Do not delete the line below; configure depends on this
-\end_layout
-
-\begin_layout LyX-Code
-#
-\backslash
DeclareDocBookClass[article]{SGML (DocBook article)}
\end_layout
@@ -9473,10 +9460,6 @@
\end_layout
\begin_layout LyX-Code
-Format LinuxDoc
-\end_layout
-
-\begin_layout LyX-Code
Product "[XFig: $$FName]"
\end_layout
@@ -9666,7 +9649,7 @@
\family typewriter
\series medium
Format\InsetSpace ~
-LaTeX|PDFLaTeX|PlainText|DocBook|LinuxDoc
+LaTeX|PDFLaTeX|PlainText|DocBook
\family default
\series default
The primary document file format that this format definition is for.
@@ -9676,8 +9659,7 @@
Format
\family default
section for all formats.
- Use a dummy text when no representation is available (see the LinuxDoc
- format in the example above).
+ Use a dummy text when no representation is available.
Then you can at least see a reference to the external material in the exported
document.
\end_layout
Index: EmbeddedObjects.lyx
===
--- EmbeddedObjects.lyx (revision 19106)
+++ EmbeddedObjects.lyx (working copy)
@@ -201,7 +201,8 @@
\bullet 3 2 7 -1
\tracking_changes false
\output_changes false
-\author "Uwe Stöhr"
+\author ""
+\author ""
\end_header
\begin_body
@@ -26880,28 +26881,6 @@
\end_layout
\begin_layout Standard
-The option
-\family sans
-Generate\InsetSpace ~
-hyperlink
-\family default
- in the URL dialog has only an affect when you export your document to the
- format
-\begin_inset Quotes eld
-\end_inset
-
-
-\family sans
-LinuxDoc
-\family default
-
-\begin_inset Quotes erd
-\end_inset
-
-.
-\end_layout
-
-\begin_layout Standard
You cannot change the style of the link text.
The text of the
\family sans
Index: Extended.lyx
===
--- Extended.lyx(revision 19106)
+++ Extended.lyx(working copy)
@@ -1,5 +1,5 @@
#LyX 1.5.0svn created this file. For more info see http://www.lyx.org/
-\lyxformat 274
+\lyxformat 276
\begin_document
\begin_header
\textclass book
@@ -37,7 +37,8 @@
\paperpagestyle headings
\tracking_changes false
\output_changes false
-\author "usti"
+\author ""
+\author ""
\end_header
\begin_body
@@ -15404,675 +15405,6 @@
\end_layout
\begin_layout Section
-Using LyX with SGML-Tools (aka
Re: lyx2lyx for patch 1820
On Wed, Jul 18, 2007 at 03:21:52AM +0300, Dov Feldstern wrote: > Hi! > > Attached find a lyx2lyx for patch 1820. It's not perfect, though --- it > actually corrupts some files which shouldn't be changed at all; if > anyone wants to try and fix that, be my guest, I've just spent the past > six hours on this and I'm not sure that it's doable. > > Also, this has only convinced me even more that it's wrong to apply a > lyx2lyx fix for this patch: this is a bug fix, there were previously > .lyx files which were ok, but which lyx was generating incorrect latex > for, and patch 1820 fixes that. If there are lyx documents out there > which patch 1820 affects, it can only do them good. All this lyx2lyx > patch does is to explicitly set the language to the wrong values in all > kinds of situations. FWIW, I agree with you. LyX was generating wrong LaTeX code in those cases and this should be considered as bug fix. IMO, it is laughable requiring a lyx2lyx patch in order to perpetuate the bug. -- Enrico
Re: lyx2lyx for patch 1820
Enrico Forestieri wrote: On Wed, Jul 18, 2007 at 03:21:52AM +0300, Dov Feldstern wrote: Hi! Attached find a lyx2lyx for patch 1820. It's not perfect, though --- it actually corrupts some files which shouldn't be changed at all; if anyone wants to try and fix that, be my guest, I've just spent the past six hours on this and I'm not sure that it's doable. Also, this has only convinced me even more that it's wrong to apply a lyx2lyx fix for this patch: this is a bug fix, there were previously .lyx files which were ok, but which lyx was generating incorrect latex for, and patch 1820 fixes that. If there are lyx documents out there which patch 1820 affects, it can only do them good. All this lyx2lyx patch does is to explicitly set the language to the wrong values in all kinds of situations. FWIW, I agree with you. LyX was generating wrong LaTeX code in those cases and this should be considered as bug fix. IMO, it is laughable requiring a lyx2lyx patch in order to perpetuate the bug. + ALOT. rh -- == 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: Patches for 1820 and 3613
Dov Feldstern wrote: > So far, though, these two patches have mostly been ignored --- a few > people have responded, but not many. You're not ignored. I agree that these patches should be considered, but I don't understand the stuff enough to comment (and I'm too busy for testing). I think you should be patient and wait until José, who is the one who decides and also probably the one who understands the changes, finds time to look at it. Please accept that he is also quite busy with the lyx2lyx bugs currently. Jürgen
Re: [patch] fix drawing issue
Abdelrazak Younes wrote: > > It should, but you need another OK. > > OK from me. José? Jürgen
Text Settings Dialog [Beyond 1.5]
There are several large issues with this dialog collected in bug 3893.
It really doesn't work very well. Here is a radical suggestion: Get rid
of it in favor of character styles. So we'd have character styles like
Italic, SmallCaps, and the like, accessed via the Edit>Text Styles menu,
rather than through a dialog. These could all be defined in a
StdCharStyles.inc file to be included in other layouts.
There are some issues with this. At present, nesting character styles
can lead to some ugly display, because the lines under the text nest and
create quite a mess. I'd suggest making these optional, via a Layout
setting. The attached patch gives some idea how this might work. It can
be tried with these character styles:
CharStyle Italic
LatexType Command
LatexName textit
ShowBox false
Font
Shape Italic
EndFont
End
CharStyle SmallCaps
LatexType Command
LatexName textsc
ShowBox false
Font
Shape SmallCaps
EndFont
End
But there are still some issues here with the behavior of the cursor, as
it seems to expect a border between the inset and the surrounding text,
which has been removed.
Another issue is that the Edit>Text Style menu could become very
crowded. It'd be nice to be able to define character styles and put them
into submenus, perhaps via a setting that was something like:
Submenu Shape
Which would create and populate submenus.
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
Index: src/insets/InsetCharStyle.cpp
===
--- src/insets/InsetCharStyle.cpp (revision 19107)
+++ src/insets/InsetCharStyle.cpp (working copy)
@@ -102,6 +102,7 @@
params_.font = Font(Font::ALL_INHERIT);
params_.labelfont = Font(Font::ALL_INHERIT);
params_.labelfont.setColor(Color::error);
+ params_.showbox = true;
params_.show_label = true;
}
@@ -113,7 +114,8 @@
params_.latexparam = cs->latexparam;
params_.font = cs->font;
params_.labelfont = cs->labelfont;
- params_.show_label = true;
+ params_.showbox = cs->showbox;
+ params_.show_label = cs->showbox; //can't show label if no box
}
@@ -144,31 +146,34 @@
getDrawFont(mi.base.font);
mi.base.font.reduce(Font(Font::ALL_SANE));
mi.base.font.realize(tmpfont);
- mi.base.textwidth -= 2 * TEXT_TO_INSET_OFFSET;
+ if (params_.showbox)
+ mi.base.textwidth -= 2 * TEXT_TO_INSET_OFFSET;
InsetText::metrics(mi, dim);
mi.base.font = tmpfont;
- if (params_.show_label) {
- // consider width of the inset label
- Font font(params_.labelfont);
- font.realize(Font(Font::ALL_SANE));
- font.decSize();
- font.decSize();
- int w = 0;
- int a = 0;
- int d = 0;
- // FIXME UNICODE
- docstring s(from_utf8(params_.type));
- if (undefined())
- s = _("Undef: ") + s;
- theFontMetrics(font).rectText(s, w, a, d);
- dim.wid = max(dim.wid, w);
+ if (params_.showbox) {
+ if (params_.show_label) {
+ // consider width of the inset label
+ Font font(params_.labelfont);
+ font.realize(Font(Font::ALL_SANE));
+ font.decSize();
+ font.decSize();
+ int w = 0;
+ int a = 0;
+ int d = 0;
+ // FIXME UNICODE
+ docstring s(from_utf8(params_.type));
+ if (undefined())
+s = _("Undef: ") + s;
+ theFontMetrics(font).rectText(s, w, a, d);
+ dim.wid = max(dim.wid, w);
+ }
+ dim.asc += TEXT_TO_INSET_OFFSET;
+ dim.des += TEXT_TO_INSET_OFFSET;
+ dim.wid += 2 * TEXT_TO_INSET_OFFSET;
+ mi.base.textwidth += 2 * TEXT_TO_INSET_OFFSET;
+ if (params_.show_label)
+ dim.des += ascent();
}
- dim.asc += TEXT_TO_INSET_OFFSET;
- dim.des += TEXT_TO_INSET_OFFSET;
- dim.wid += 2 * TEXT_TO_INSET_OFFSET;
- mi.base.textwidth += 2 * TEXT_TO_INSET_OFFSET;
- if (params_.show_label)
- dim.des += ascent();
bool const changed = dim_ != dim;
dim_ = dim;
return changed;
@@ -183,40 +188,42 @@
getDrawFont(pi.base.font);
// I don't understand why the above .reduce and .realize aren't
//needed, or even wanted, here. It just works. -- MV 10.04.2005
- InsetText::draw(pi, x + TEXT_TO_INSET_OFFSET, y);
+ InsetText::draw(pi, x + (params_.showbox ? TEXT_TO_INSET_OFFSET : 0), y);
pi.base.font = tmpfont;
int desc = InsetText::descent();
- if (params_.show_label)
- desc -= ascent();
- pi.pain.line(x, y + desc - 4, x, y + desc, params_.labelfont.color());
- pi.pain.line(x, y + desc, x + dim_.wid - 3, y + desc,
- params_.labelfont.color());
- pi.pain.line(x + dim_.wid - 3, y + desc, x + dim_.wid - 3, y + desc - 4,
- params_.labelfont.color());
+ if (params_.showbox) {
+ if (params_.show_label)
+ desc -= ascent();
+ pi.pain.line(x, y + desc - 4, x, y + desc,
