Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE
So, this may have to be modified too. > (gdb) p *start > $38 = (const wchar_t &) @0x8b1e9c0: 49 > (gdb) x/5s 0x8b1e9c0 > 0x8b1e9c0: "1" > 0x8b1e9c2: "" > 0x8b1e9c3: "" > 0x8b1e9c4: "$" > 0x8b1e9c6: "" > 0x8b1e9c7: "" > 0x8b1e9c8: "s" > 0x8b1e9ca: "" > 0x8b1e9cb: "" > 0x8b1e9cc: "\r0" > 0x8b1e9cf: "" > 0x8b1e9d0: "\2220" > 0x8b1e9d3: "" > 0x8b1e9d4: "\\O" > 0x8b1e9d7: "" > 0x8b1e9d8: "\020b" > 0x8b1e9db: "" > 0x8b1e9dc: "W0" > 0x8b1e9df: "" > 0x8b1e9e0: "f0" > 0x8b1e9e3: "" > 0x8b1e9e4: "D0" > 0x8b1e9e7: "" > 0x8b1e9e8: "~0" > 0x8b1e9eb: "" where string size is > (gdb) p fstring_size > $54 = 25 Koji
Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE
Also, template< class Ch, class Tr, class Alloc> basic_format:: basic_format(const string_type& s) : style_(0), cur_arg_(0), num_args_(0), dumped_(false), exceptions_(io::all_error_bits) { parse(s); } it contains: > (gdb) p &s > $47 = ( > const std::basic_string,std::allocator > *) 0xbfbfe588 > > (gdb) x/s 0xbfbfe588 > 0xbfbfe588: "[EMAIL PROTECTED],%\bD" and in bool parse_ok = io::detail::parse_printf_directive( it, buf.end(), &items_[cur_item], fac, i1, exceptions()); we have the following argument data: > (gdb) p &items_[cur_item] > $48 = ( const boost::io::detail::format_item,std::allocator > *) 0x8af4a80 > > (gdb) x/s 0x8af4a80 > 0x8af4a80: "\b\b" Koji
Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE
> I'm not quite sure about the data structure used here, but arguments fmt > and arg1 in bformat() seem to contain no data fields: Oh, I should assume &fmt and &arg1 contain pointers. Sorry. > (gdb) p &fmt > $44 = (const docstring *) 0xbfbfe588 > (gdb) p &arg1 > $46 = (docstring *) 0xbfbfe580 > (gdb) x/s 0xbfbfe588 > 0xbfbfe588: "[EMAIL PROTECTED],%\bD" > (gdb) x/s 0xbfbfe580 > 0xbfbfe580: "[EMAIL PROTECTED],%\bD" Koji
Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE
Georg Baum wrote: If you want to debug this fdurther it might be a good idea to write a small standalone program that simply calls boost::format with the problematic input. boost::basic_format() itself seems working if it is called with "ordinary" strings: > #include > #include > > using namespace std; > > main() > { > cout << boost::basic_format("test %1$s \n") % "OK"; > } which prints out test OK And what is the value of *start? And how does the whole format string look like? They are as follows: > (gdb) p *start > $38 = (const wchar_t &) @0x8b1e9c0: 49 > > (gdb) p start > $39 = ( > __gnu_cxx::__normal_iterator wchar_t*,std::basic_string, > std::allocator > > &) @0xbfbfe2cc: { > _M_current = 0x8b1e9c0} > > (gdb) x/25s 0xbfbfe2cc > 0xbfbfe2cc: "\300\351\261\b\030\033\177)\r" > 0xbfbfe2d6: "" > 0xbfbfe2d7: "" > 0xbfbfe2d8: "\214\351\261\bp\352\261\b" > 0xbfbfe2e1: "" > 0xbfbfe2e2: "" > 0xbfbfe2e3: "" > 0xbfbfe2e4: "" > 0xbfbfe2e5: "" > 0xbfbfe2e6: "" > 0xbfbfe2e7: "" > 0xbfbfe2e8: "" > 0xbfbfe2e9: "" > 0xbfbfe2ea: "" > 0xbfbfe2eb: "" > 0xbfbfe2ec: "\234\v\177)\314;\177)8\344\277\277(\343\277\277f|v)\354;\177)\001" > 0xbfbfe306: "" > 0xbfbfe307: "" > 0xbfbfe308: "([EMAIL PROTECTED] \037\177)%" > 0xbfbfe32a: "" > 0xbfbfe32b: "" > 0xbfbfe32c: "\016\312\023\001\377\377\377\377" > 0xbfbfe335: "" > 0xbfbfe336: "" > 0xbfbfe337: "" I am now pretty sure that the problem is not in any locale stuff, but in boost::format itself, because normally this part of the code should only be reached with valid format characters (and signed -65 == unsigned 191 == 0277 == 0xbf is not a valid format character). I'm not quite sure about the data structure used here, but arguments fmt and arg1 in bformat() seem to contain no data fields: src/support/lstrings.cpp line 875 > template<> docstring bformat(docstring const & fmt, docstring arg1) { return (boost::basic_format(fmt) % arg1).str(); } Data: fmt = $26 = (const docstring &) @0xbfbfe588: {static npos = 4294967295, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x8b1e98c}} arg1 = $27 = (docstring &) @0xbfbfe580: {static npos = 4294967295, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x8b1e70c}} And, subsequently call in boost/format/format_implementation.hpp line 60 template< class Ch, class Tr, class Alloc> basic_format:: basic_format(const string_type& s) : style_(0), cur_arg_(0), num_args_(0), dumped_(false), exceptions_(io::all_error_bits) { parse(s); } Data: s = $28 = ( const std::basic_string,std::allocator > &) @0xbfbfe588: {static npos = 4294967295, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x8b1e98c}} I also attach the data of arguments passed to parse_printf_directive() in boost/format/parsing.hpp which is called later: boost/format/parsing.hpp line 437 > bool parse_ok = io::detail::parse_printf_directive( it, buf.end(), &items_[cur_item], fac, i1, exceptions()); (gdb) p it $29 = {_M_current = 0x8b1e9c0} (gdb) p buf.end() $30 = {_M_current = 0x8b1ea70} (gdb) p &items_[cur_item] $31 = ( const class boost::io::detail::format_item,std::allocator > *) 0x8af4a80 (gdb) p items_[cur_item] $35 = ( const boost::io::detail::format_item,std::allocator > &) @0x8af4a80: {argN_ = -1, res_ = { static npos = 4294967295, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x8a5a7a8}}, appendix_ = {static npos = 4294967295, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x8a5a7a8}}, fmtstate_ = {width_ = 0, precision_ = 6, fill_ = 32, flags_ = 4098, rdstate_ = std::_S_goodbit, exceptions_ = std::_S_goodbit, loc_ = {> = { = {}, m_initialized = false, m_storage = {dummy_ = {data = "\000\000\000", aligner_ = }}}, }}, truncate_ = 2147483647, pad_scheme_ = 0} (gdb) p fac $32 = (const struct std::ctype &) @0x297f1f20: (gdb) p i1 $33 = 13 (gdb) p exceptions() $34 = 255 '\377' Are these passed data OK? Thank you, Koji
Re: lyx farsi support??
behzad maha wrote: hi I want to do some coding help. My language is persian(farsi) and I want to help Lyx support farsi.But I don't have experience coding for multi-lingual documents.Can anyone help me where to start? regards behzad Hi, Behzad! Mostafa Vahedi has recently done a lot of work in order to get Farsi working in LyX. I think most of what he has done is already in the main trunk, so the latest development version (and RC2, which is supposed to be released soon) should work pretty well for Farsi. Have you tried this? Are there any other issues that you see which are not yet working for Farsi in LyX? In any case, Mostafa probably knows best what the current situation is, and what still needs to be done... Dov
Re: Spaces on RTL boundaries
Sorry --- wrong patch attached! Here's the correct one (rather shorter ;) ) Dov Feldstern wrote: Georg Baum wrote: Stefan Schimanski wrote: Then the question is only from which file format revision we start with a lyx2lyx filter: from the change of the exporting behavior or from the fix from today and the last days... That depends on the format when the change happened. If it was during the 1.5 development cycle I would introduce a new file format now and declare all 1.5svn versions between the original change and this new format buggy. We did this for example with format 261. If it was earlier you can't simply declare stable versions buggy (and people will have corrected the wrong spaces by hand if they noticed), so it is better to put the conversion between the old formats. Then it will at least help people who now convert old documents. Georg Hi! Georg, there never was a format change of this issue, but their *should* have been, because although the format of the lyx file was not changed, its interpretation *was* (not by us now, but back when the original change in the latex generation occurred, see below; as Stefan pointed out, all we did now was to bring the GUI up to date with the change which already occurred then in the latex generation). The change I'm talking about occurred somewhere between 17143 and 17158 (I think it's 17144, but there are other changes in the above range which may be somewhat related, and format change 259 is somewhere in the middle there, too...). This is the issue: until 17143 (including), "abc[FED ] ghi" was output to latex as "abc \R{DEF} ghi"; but starting with 17144, the output for the same text (no change in the .lyx file at all!) became "abc\R{ DEF} ghi". So a format change is needed which explicitly changes the .lyx file: any occurrence of "abc[FED ] ghi" should be changed to "abc [FED] ghi", in order that the same latex output be generated. (Note that there is no need for doing anything when downgrading: both forms will be interpreted identically in the old LyX versions, so we can just as easily use the new format, in this respect. It's just that there are some things which couldn't be typeset before 17144, so the explicit differentiation wasn't needed.) I think that in order to deal with this cleanly, what we have to do is this: we create a new file format *now* (at first I was thinking we should use version 259 to tag these differences, because it was so close to when the changes were actually made; but then I realized the following: if someone has already converted from pre-259 to post-259, then if we now make this lyx2lyx change as part of 259, then that file will never get fixed; so we need to do it now, so that already-converted files will also get fixed. I'm not so worried about post-259 files where the above construct now exists on purpose, because it's very very rare for someone to really want it; in fact, I assume that even now it's just an oversight on the part of the user). This new file format doesn't have any real format changes associated with it, except that the version number gets incremented. Besides that, what the conversion does is to find occurrences of "space" which appear between LTR and RTL sections, and makes sure that they are in the language which has the same direction as the language of the paragraph. So: 1) Does this sound right? 2) How do I do it in lyx2lyx? I looked at normalize_font_whitespace() --- *** I now see what the problem is! What we need is *exactly* the change of format 259; but in lyx2lyx, the \\lang property wasn't included for some reason! The attached patch fixes this, and the output is now OK (i.e., with this patch, a file created from before the change (also attached), and in which the problem occurs, is output correctly and displays correctly in the GUI even now!). But anyway, for the reasons outlined above, I still think it's more correct to do this is a separate, new file format, effective as of now. I guess that means duplicating normalize_font_whitespace(), but having it now act *only* on the lang property (Georg, you may want to make sure there aren't any other forgotten properties, once we're at it...), and applying the new function as the converter to a new file format... So Georg, does all this make sense? And if so, could you please take care of it? I guess we also need Jose's OK for this... Thanks! Dov Index: lib/lyx2lyx/lyx_1_5.py === --- lib/lyx2lyx/lyx_1_5.py (revision 17158) +++ lib/lyx2lyx/lyx_1_5.py (working copy) @@ -1101,6 +1101,7 @@ "\\color": "none", "\\shape": "default", "\\bar": "default", + "\\lang": "default", "\\family": "default"} changes = {}
Re: [patch] sometimes only paragraph of cursor is visible, #3231
Stefan Schimanski wrote: Here is a fix for the grey-bar bug, i.e. randomly only the current paragraph is drawn and everything else is greyed out. It'd be great if this fixed this bug. It's very annoying. Richard I think it is related to synthetic mouse event. Somehow a redraw is triggered, but the ViewMetric.update_strategy is set to NoScreenUpdate. The two condition, that I change in the patch, evaluate to true and the grey bars are drawn. Here is a backtrace of the issue: #0 lyx::paintText ([EMAIL PROTECTED], [EMAIL PROTECTED]) at /Users/sts/Quellen/mac/lyx-devel/src/rowpainter.cpp:1065 #1 0x0023570a in lyx::frontend::GuiWorkArea::updateScreen (this=0x261a0e30) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/qt4/GuiWorkArea.cpp:592 #2 0x0023574f in lyx::frontend::GuiWorkArea::expose (this=0x261a0e30, x=0, y=31, w=671, h=105) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/qt4/GuiWorkArea.cpp:575 #3 0x0022295a in lyx::frontend::WorkArea::redraw (this=0x261a0e44) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/WorkArea.cpp:159 #4 0x00223212 in lyx::frontend::WorkArea::dispatch (this=0x261a0e44, [EMAIL PROTECTED], k=none) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/WorkArea.cpp:218 #5 0x00237432 in lyx::frontend::GuiWorkArea::mouseMoveEvent (this=0x261a0e30, e=0xbfffefe0) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/qt4/GuiWorkArea.cpp:414 It happened with two footnote in the view, just moving the mouse around. So could it be related to the mouse hover maybe? I think though that the change in the patch is reasonable nevertheless. The comparison to SingleParUpdate is wrong. The drawText function must work with every update_strategy. Stefan Index: lyx-devel/src/rowpainter.cpp === --- lyx-devel.orig/src/rowpainter.cpp2007-06-08 07:09:41.0 +0200 +++ lyx-devel/src/rowpainter.cpp2007-06-09 14:17:25.0 +0200 @@ -1061,12 +1061,12 @@ // and grey out above (should not happen later) //lyxerr << "par ascent: " << text.getPar(vi.p1).ascent() << endl; -if (vi.y1 > 0 && vi.update_strategy != SingleParUpdate) +if (vi.y1 > 0 && vi.update_strategy == FullScreenUpdate) pain.fillRectangle(0, 0, bv.workWidth(), vi.y1, Color::bottomarea); // and possibly grey out below //lyxerr << "par descent: " << text.getPar(vi.p1).ascent() << endl; -if (vi.y2 < bv.workHeight() && vi.update_strategy != SingleParUpdate) +if (vi.y2 < bv.workHeight() && vi.update_strategy == FullScreenUpdate) pain.fillRectangle(0, vi.y2, bv.workWidth(), bv.workHeight() - vi.y2, Color::bottomarea); } -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Spaces on RTL boundaries
Georg Baum wrote: Stefan Schimanski wrote: Then the question is only from which file format revision we start with a lyx2lyx filter: from the change of the exporting behavior or from the fix from today and the last days... That depends on the format when the change happened. If it was during the 1.5 development cycle I would introduce a new file format now and declare all 1.5svn versions between the original change and this new format buggy. We did this for example with format 261. If it was earlier you can't simply declare stable versions buggy (and people will have corrected the wrong spaces by hand if they noticed), so it is better to put the conversion between the old formats. Then it will at least help people who now convert old documents. Georg Hi! Georg, there never was a format change of this issue, but their *should* have been, because although the format of the lyx file was not changed, its interpretation *was* (not by us now, but back when the original change in the latex generation occurred, see below; as Stefan pointed out, all we did now was to bring the GUI up to date with the change which already occurred then in the latex generation). The change I'm talking about occurred somewhere between 17143 and 17158 (I think it's 17144, but there are other changes in the above range which may be somewhat related, and format change 259 is somewhere in the middle there, too...). This is the issue: until 17143 (including), "abc[FED ] ghi" was output to latex as "abc \R{DEF} ghi"; but starting with 17144, the output for the same text (no change in the .lyx file at all!) became "abc\R{ DEF} ghi". So a format change is needed which explicitly changes the .lyx file: any occurrence of "abc[FED ] ghi" should be changed to "abc [FED] ghi", in order that the same latex output be generated. (Note that there is no need for doing anything when downgrading: both forms will be interpreted identically in the old LyX versions, so we can just as easily use the new format, in this respect. It's just that there are some things which couldn't be typeset before 17144, so the explicit differentiation wasn't needed.) I think that in order to deal with this cleanly, what we have to do is this: we create a new file format *now* (at first I was thinking we should use version 259 to tag these differences, because it was so close to when the changes were actually made; but then I realized the following: if someone has already converted from pre-259 to post-259, then if we now make this lyx2lyx change as part of 259, then that file will never get fixed; so we need to do it now, so that already-converted files will also get fixed. I'm not so worried about post-259 files where the above construct now exists on purpose, because it's very very rare for someone to really want it; in fact, I assume that even now it's just an oversight on the part of the user). This new file format doesn't have any real format changes associated with it, except that the version number gets incremented. Besides that, what the conversion does is to find occurrences of "space" which appear between LTR and RTL sections, and makes sure that they are in the language which has the same direction as the language of the paragraph. So: 1) Does this sound right? 2) How do I do it in lyx2lyx? I looked at normalize_font_whitespace() --- *** I now see what the problem is! What we need is *exactly* the change of format 259; but in lyx2lyx, the \\lang property wasn't included for some reason! The attached patch fixes this, and the output is now OK (i.e., with this patch, a file created from before the change (also attached), and in which the problem occurs, is output correctly and displays correctly in the GUI even now!). But anyway, for the reasons outlined above, I still think it's more correct to do this is a separate, new file format, effective as of now. I guess that means duplicating normalize_font_whitespace(), but having it now act *only* on the lang property (Georg, you may want to make sure there aren't any other forgotten properties, once we're at it...), and applying the new function as the converter to a new file format... So Georg, does all this make sense? And if so, could you please take care of it? I guess we also need Jose's OK for this... Thanks! Dov more_heb_problems.lyx Description: application/lyx Index: lyx-devel/src/Bidi.cpp === --- lyx-devel.orig/src/Bidi.cpp 2007-06-08 08:42:47.0 +0200 +++ lyx-devel/src/Bidi.cpp 2007-06-08 08:43:30.0 +0200 @@ -95,7 +95,11 @@ pos_type const body_pos = par.beginOfBody(); for (pos_type lpos = start_; lpos <= end_; ++lpos) { - bool is_space = par.isLineSeparator(lpos); + bool is_space = false; + // We do not handle spaces around an RTL segment in a special way anymore. + // Neither do
Re: serious bug
> > confirmed. i filed the bug http://bugzilla.lyx.org/show_bug.cgi?id=3844 . > > Strange, I cannot reproduce. svn up did the trick. current trunk is ok. pavel
Re: serious bug
Alfredo Braunstein wrote: > Pavel Sanda wrote: > >>> I just reproduced it on this file. >>> Move cursor to the end of paragraph, then to start of work "tasks" do CR >>> Move cursor to start of words "seller biased", then CR >>> Move cursor to the start of "that for" then CR at that point lyx >>> crashes. >>> - >>> W. Bentley MacLeod >> >> confirmed. i filed the bug http://bugzilla.lyx.org/show_bug.cgi?id=3844 . > > Strange, I cannot reproduce. linux, btw. A/
Re: serious bug
W. Bentley MacLeod wrote: When editing, and doing a carriage return, then backspace on the old paragraph, carriage return, results in lyx 1.5.0rc1 crashing - 1.5 is so much better than 1.4.4 in many respects I am trying to use it, but this bug keeps occurring. I am using the windows version on XP service pack 2. I can't reproduce the crash with current svn. I presume you know already that the math panel does not toggle in this version (it did in beta 3). This neither. Abdel.
Re: serious bug
Pavel Sanda wrote: >> I just reproduced it on this file. >> Move cursor to the end of paragraph, then to start of work "tasks" do CR >> Move cursor to start of words "seller biased", then CR >> Move cursor to the start of "that for" then CR at that point lyx crashes. >> - >> W. Bentley MacLeod > > confirmed. i filed the bug http://bugzilla.lyx.org/show_bug.cgi?id=3844 . Strange, I cannot reproduce. A/
Re: Crash with the new TOC widget
[EMAIL PROTECTED] wrote: Hello, I've compiled LyX 5.0 svn. 1) Open User Guide 2) Tools -> outline 3) Document -> Next cross-reference 4) Click in the Toc Widget on the second section 5) Boum with this (rather unhelpful message) /usr/include/c++/4.1.3/debug/safe_iterator.h:130:error: attempt to copy- construct an iterator from a singular iterator. The problem has been introduced at revision 18693 URL: http://www.lyx.org/trac/changeset/18693 Log: Update Toc when navigation menu is trigged. This is fixed now. Abdel. Author: younes Date: Sun Jun 10 00:21:21 2007 New Revision: 18730 URL: http://www.lyx.org/trac/changeset/18730 Log: Fix missing signal emission following revision 18693. Modified: lyx-devel/trunk/src/MenuBackend.cpp Modified: lyx-devel/trunk/src/MenuBackend.cpp URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/MenuBackend.cpp?rev=18730 == --- lyx-devel/trunk/src/MenuBackend.cpp (original) +++ lyx-devel/trunk/src/MenuBackend.cpp Sun Jun 10 00:21:21 2007 @@ -705,7 +705,9 @@ return; } - const_cast(buf)->tocBackend().update(); + Buffer* cbuf = const_cast(buf); + cbuf->tocBackend().update(); + cbuf->structureChanged(); // Add an entry for the master doc if this is a child doc Buffer const * const master = buf->getMasterBuffer();
Re: serious bug
> I just reproduced it on this file. > Move cursor to the end of paragraph, then to start of work "tasks" do CR > Move cursor to start of words "seller biased", then CR > Move cursor to the start of "that for" then CR at that point lyx crashes. > - > W. Bentley MacLeod confirmed. i filed the bug http://bugzilla.lyx.org/show_bug.cgi?id=3844 . thank you for reporting. pavel
Re: serious bug
> When editing, and doing a carriage return, then backspace on the old > paragraph, carriage return, results in lyx 1.5.0rc1 crashing - 1.5 is i'm not able to reproduce it. can you provide exact steps how to achive this crash ? pavel
serious bug
When editing, and doing a carriage return, then backspace on the old paragraph, carriage return, results in lyx 1.5.0rc1 crashing - 1.5 is so much better than 1.4.4 in many respects I am trying to use it, but this bug keeps occurring. I am using the windows version on XP service pack 2. I presume you know already that the math panel does not toggle in this version (it did in beta 3). best bm. -- - W. Bentley MacLeod Professor and Co-Director, Program for Economic Research Columbia University 420 West 118th, Mail Code 3308 New York, NY 10027-7296 Email: [EMAIL PROTECTED]
Re: [patch] fixing segfault because of empty coord cache
Am 09.06.2007 um 08:37 schrieb Martin Vermeer: On Fri, Jun 08, 2007 at 08:22:42PM +0200, Jean-Marc Lasgouttes wrote: "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes: Stefan> Critical bugs don't get less critical by ignorance. If anybody Stefan> wants to know more: [snip] Great analysis! I would say that the fix is correct, but I'd wait for Andre's input. JMarc Hear, hear. This kind of analysis should be in the code, as comment. Do I understand correctly that this presupposes that 1) every mathinset must have an isActive method and 2) it should return true only if the inset has really accessible cells? 1) You get it for free if you derive from InsetMathNest. It returns true if you have at least one cell. Any inset just derived from InsetMath, but not from InsetMathNest do not need it. 2) Yes, if you use a InsetMathNest with cells you better do not return true if you do not draw the cells. Stefan PGP.sig Description: Signierter Teil der Nachricht
[PATCH] Add bypass validation checkboxes to dialogs that enter listings parameters
Dear all, I reverted my previous patch that add @para to allow para to bypass validation. The major problem is the handling @ in lyx2lyx. In this patch, I add a check box 'bypass validation' that will allow any listings parameters to be passed to lyx/latex if this checkboz is checked. No file format is changed so no lyx2lyx is needed. There has been a lot of underlying changes. exception invalidParam is removed and validation is no longer triggered automatically. Transmission of parameters will not be checked. An error message is returned explicitly when InsetListingsParams::validate() is called from GUI dialogs. Please test. Cheers, Bo Index: src/insets/InsetListingsParams.h === --- src/insets/InsetListingsParams.h (revision 18729) +++ src/insets/InsetListingsParams.h (working copy) @@ -74,6 +74,9 @@ /// void clear() { params_.clear(); } + + /// validate parameter, return an error message + docstring validate() const; private: /// inline or normal listings @@ -87,22 +90,6 @@ }; -class invalidParam : public std::exception { -public: - invalidParam(docstring const & details) - : details_(to_utf8(details)) - {} - - virtual const char * what() const throw() { - return details_.c_str(); - } - - virtual ~invalidParam() throw() {} -private: - std::string const details_; -}; - - } // namespace lyx #endif Index: src/insets/InsetListingsParams.cpp === --- src/insets/InsetListingsParams.cpp (revision 18729) +++ src/insets/InsetListingsParams.cpp (working copy) @@ -271,15 +271,13 @@ public: ParValidator(); - /// \return the associated \c ListingsParam. - /// \warning an \c invalidParamexception will be thrown - /// if the key is not found. - ListingsParam const & param(string const & key) const; + /// validate a parameter for a given name. + /// return an error message if \c par is an invalid parameter. + docstring validate(string const & name, string const & par) const; - /// validate a parameter for a given key. - /// \warning an \c invalidParam exception will be thrown if - /// \c par is an invalid parameter. - ListingsParam const & validate(string const & key, string const & par) const; + /// return the onoff status of a parameter \c key, if \c key is not found + /// return false + bool onoff(string const & key) const; private: /// key is the name of the parameter @@ -584,21 +582,11 @@ } -ListingsParam const & ParValidator::validate(string const & key, +docstring ParValidator::validate(string const & name, string const & par) const { - ListingsParam const & lparam = param(key); - docstring s = lparam.validate(par); - if (!s.empty()) - throw invalidParam(bformat(_("Parameter %1$s: "), from_utf8(key)) + s); - return lparam; -} - - -ListingsParam const & ParValidator::param(string const & name) const -{ if (name.empty()) - throw invalidParam(_("Invalid (empty) listing parameter name.")); + return _("Invalid (empty) listing parameter name."); if (name[0] == '?') { string suffix = trim(string(name, 1)); @@ -613,39 +601,59 @@ } } if (suffix.empty()) - throw invalidParam(bformat( - _("Available listing parameters are %1$s"), from_ascii(param_names))); + return bformat( + _("Available listing parameters are %1$s"), from_ascii(param_names)); else - throw invalidParam(bformat( + return bformat( _("Available listings parameters containing string \"%1$s\" are %2$s"), - from_utf8(suffix), from_utf8(param_names))); + from_utf8(suffix), from_utf8(param_names)); } // locate name in parameter table ListingsParams::const_iterator it = all_params_.find(name); - if (it != all_params_.end()) - return it->second; - - // otherwise, produce a meaningful error message. - string matching_names; - ListingsParams::const_iterator end = all_params_.end(); - for (it = all_params_.begin(); it != end; ++it) { - if (prefixIs(it->first, name)) { - if (!matching_names.empty()) -matching_names += ", "; - matching_names += it->first; + if (it != all_params_.end()) { + docstring msg = it->second.validate(par); + if (msg.empty()) + return msg; + else + return bformat(_("Parameter %1$s: "), from_utf8(name)) + msg; + } else { + // otherwise, produce a meaningful error message. + string matching_names; + ListingsParams::const_iterator end = all_params_.end(); + for (it = all_params_.begin(); it != end; ++it) { + if (prefixIs(it->first, name)) { +if (!matching_names.empty()) + matching_names += ", "; +matching_names += it->first; + } } + if (matching_names.empty()) + return bformat(_("Unknown listing parameter name: %1$s"), +from_utf8(name)); + else + return bformat(_("Parameters starting with '%1$s': %2$s"), +from_utf8(name), from_utf8(matching_names)); } - if (matching_names.empty()) - throw invalidParam(bformat(_("Unknown listing parame
Re: [PATCH] 2697: SplitLayout environment.
On 6/9/07, Martin Vermeer <[EMAIL PROTECTED]> wrote: On Sat, Jun 09, 2007 at 10:49:13AM -0500, Bo Peng wrote: ... > +def revert_splitlayout(document): > +r''' Revert SplitLayout to a lyx node > +From That would be 'note' Will be corrected when applied. Thanks. Bo
Re: [PATCH] 2697: SplitLayout environment.
On Sat, Jun 09, 2007 at 10:49:13AM -0500, Bo Peng wrote: ... > +def revert_splitlayout(document): > +r''' Revert SplitLayout to a lyx node > +From That would be 'note' ... - Martin
Re: r18728 - in /lyx-devel/trunk/src/insets: InsetListings.cp...
There's no other possibility IMO. That is *too much* work! I will propose, instead, 1. revert my @ idea 2. add a checkbox like 'bypass validation', 'use what I have inputted'. 3. if this checkbox is clicked, the parameter is allowed. In this way, there will be no lyx2lyx problem. Agreed? Bo
Re: Bug #3812: Comments on patch
Jürgen Spitzmüller schrieb: Michael Gerz wrote: for (; cur; cur.forwardChar()) - if (cur.inTexted() && match(cur.paragraph(), cur.pos())) + if (cur.inTexted() && + (find_del || !cur.paragraph().isDeleted(cur.pos())) && + match(cur.paragraph(), cur.pos())) return true; return false; } AFAICS, you only check the deletion status of the first character. However, ALL matching characters shouldn't be marked as deleted. I don't understand. I just assure that a character is skipped on find if it is marked deleted. Since the loop moves ahead, this test applies to all characters of a word. And nothing will be "marked" anyway. Or do I miss something? Maybe I was talking nonsense. I just looked at the patch (without the surrounding code). It looked like you check for the first character and then match(...) tries to match the complete string. If this isn't true, please ingore my comment and ask for another OK. (I have to leave in a few seconds.) Michael
[patch] Up/down cursor in math-macro jumps out of the macro, #3830
Bug: http://bugzilla.lyx.org/show_bug.cgi?id=3830 The patch should be obvious. Stefan Index: lyx-devel/src/mathed/MathMacro.cpp === --- lyx-devel.orig/src/mathed/MathMacro.cpp 2007-06-02 11:24:05.0 +0200 +++ lyx-devel/src/mathed/MathMacro.cpp 2007-06-09 18:24:35.0 +0200 @@ -254,6 +254,22 @@ } +bool MathMacro::idxUpDown(Cursor & cur, bool up) const +{ + if (up) { + if (cur.idx() == 0) + return false; + --cur.idx(); + } else { + if (cur.idx() >= nargs() - 1) + return false; + ++cur.idx(); + } + cur.pos() = cell(cur.idx()).x2pos(cur.x_target()); + return true; +} + + bool MathMacro::notifyCursorLeaves(Cursor & cur) { cur.updateFlags(Update::Force); Index: lyx-devel/src/mathed/MathMacro.h === --- lyx-devel.orig/src/mathed/MathMacro.h 2007-05-19 19:12:30.0 +0200 +++ lyx-devel/src/mathed/MathMacro.h2007-06-09 18:14:31.0 +0200 @@ -48,6 +48,8 @@ /// target pos when we enter the inset from the right by pressing "Left" bool idxLast(Cursor &) const; /// + bool MathMacro::idxUpDown(Cursor & cur, bool up) const; + /// virtual bool notifyCursorLeaves(Cursor &); /// docstring name() const; PGP.sig Description: Signierter Teil der Nachricht
Re: Bug #3812: Comments on patch
Michael Gerz wrote: > > for (; cur; cur.forwardChar()) > > - if (cur.inTexted() && match(cur.paragraph(), cur.pos())) > > + if (cur.inTexted() && > > + (find_del || !cur.paragraph().isDeleted(cur.pos())) && > > + match(cur.paragraph(), cur.pos())) > > return true; > > return false; > > } > > AFAICS, you only check the deletion status of the first character. However, > ALL matching characters shouldn't be marked as deleted. I don't understand. I just assure that a character is skipped on find if it is marked deleted. Since the loop moves ahead, this test applies to all characters of a word. And nothing will be "marked" anyway. Or do I miss something? Jürgen
Bug #3812: Comments on patch
Jürgen, your patch looks nice in general. I can imagine that it even fixes #3160. Below please find some additional comments. Michael Index: src/lyxfind.cpp === --- src/lyxfind.cpp (Revision 18711) +++ src/lyxfind.cpp (Arbeitskopie) @@ -101,20 +101,26 @@ }; -bool findForward(DocIterator & cur, MatchString const & match) +bool findForward(DocIterator & cur, MatchString const & match, +bool find_del = true) { for (; cur; cur.forwardChar()) - if (cur.inTexted() && match(cur.paragraph(), cur.pos())) + if (cur.inTexted() && + (find_del || !cur.paragraph().isDeleted(cur.pos())) && + match(cur.paragraph(), cur.pos())) return true; return false; } AFAICS, you only check the deletion status of the first character. However, ALL matching characters shouldn't be marked as deleted. -bool findBackwards(DocIterator & cur, MatchString const & match) +bool findBackwards(DocIterator & cur, MatchString const & match, +bool find_del = true) { while (cur) { cur.backwardChar(); - if (cur.inTexted() && match(cur.paragraph(), cur.pos())) + if (cur.inTexted() && + (find_del || !cur.paragraph().isDeleted(cur.pos())) && + match(cur.paragraph(), cur.pos())) return true; } return false; The same here. Maybe we should propagate find_del to match(...). + case LFUN_WORD_REPLACE: + flag.enabled(!cur.paragraph().isDeleted(cur.pos())); + break; + ... and here (but I am willing to accept this minor bug) ... *** The End ***
Re: Change tracking and replace: unexpected behavior
Michael Gerz wrote: > IMHO, "find & replace" should always ignore deleted text, in CT mode as > well as in non-CT mode. That's what my patch does. I'm just waiting for your testing. Jürgen
Re: r18728 - in /lyx-devel/trunk/src/insets: InsetListings.cp...
Bo Peng wrote: > > But we have to maintain backwards compatibility also within the 1.5 > > cycle. And is the backwards compatibility to 1.4 assured? I.e., will > > @extraparams be reverted to ERT correctly? > > I see a point here. When reverting to ERT, @ needs to be removed. I > will commit a patch soon. No, that's wrong. > > IMHO , the only way to assure all this is to bump the file format > > _immediately_ and add a lyx2lyx reversion step that converts all listings > > insets that contain @extraparams to ERT. > > We already have lyx2lyx entries to convert InsetListings to ERT so I > will just modify them. You have to create another one. And you'll have to change the file format for every new parameter you will add in the future (to add the '@'). > Adding a separate entry will only benefit RC1 so I do not really want > to do that. Sure, if you use RC1 to open a file with @para, @para will > not pass validation. However, @para is supposed to be used when para > can not pass validation, so removing @ through lyx2lyx will not help. I didn't say removing. When @para is used, you'll have to transfer the whole listing to ERT for rc1 and friends, and include para (without the @). There's no other possibility IMO. > Cheers, > Bo Jürgen
Re: Change tracking and replace: unexpected behavior
Helge Hafting schrieb: If you turn off change tracking and edit, then surely all new stuff should be without the change tracking markings. (i.e. not deleted or marked as inserted by someone.) You may be able to add inside a deleted region, but that should split the deleted region in two. That's exactly what we do. IOW: There is no problem. Michael
Re: r18728 - in /lyx-devel/trunk/src/insets: InsetListings.cp...
But we have to maintain backwards compatibility also within the 1.5 cycle. And is the backwards compatibility to 1.4 assured? I.e., will @extraparams be reverted to ERT correctly? I see a point here. When reverting to ERT, @ needs to be removed. I will commit a patch soon. IMHO , the only way to assure all this is to bump the file format _immediately_ and add a lyx2lyx reversion step that converts all listings insets that contain @extraparams to ERT. We already have lyx2lyx entries to convert InsetListings to ERT so I will just modify them. Adding a separate entry will only benefit RC1 so I do not really want to do that. Sure, if you use RC1 to open a file with @para, @para will not pass validation. However, @para is supposed to be used when para can not pass validation, so removing @ through lyx2lyx will not help. Cheers, Bo
Re: Change tracking and replace: unexpected behavior
Bennett Helm schrieb: I agree with the last sentence, but notice that the patch doesn't do this! When change tracking is turned off, it is entirely possible to delete -- remove from the file -- text that is marked as deleted. Right. Even if we prohibited it, the user may always accept deleted text (such that it is gone) or reject a deletion and change the text afterwards. After all, the user is always able to edit his text. Nonetheless, I think even manual replace ought to skip deleted text. It's not expected behavior even on manual replace to replace deleted text with undeleted text (as the patch currently allows). And I don't think we should replace deleted text with deleted text either: that obscures the document history which is part of the point of change tracking. IMHO, "find & replace" should always ignore deleted text, in CT mode as well as in non-CT mode. Michael
Re: r18728 - in /lyx-devel/trunk/src/insets: InsetListings.cp...
Bo Peng wrote: > I would not consider rc1 because it is a temporary release. After > 1.5.0, @para will always be accepted and will compile if a user's > listings package supports para. But we have to maintain backwards compatibility also within the 1.5 cycle. And is the backwards compatibility to 1.4 assured? I.e., will @extraparams be reverted to ERT correctly? IMHO , the only way to assure all this is to bump the file format _immediately_ and add a lyx2lyx reversion step that converts all listings insets that contain @extraparams to ERT. If not, the LyX backwards chain is corrupted. > Of course, to minimize the use of this feature, I will have to look > through the parameters again, using the latest listings version. This does not matter. Jürgen
Re: [PATCH] 2697: SplitLayout environment.
Bo Peng wrote: Herbert> The current behaviour is easy! But not so easy for lyx newbies. The question is: what to insert that do not show up in the screen output (better latex output), yet split the environment? I remember that it took me 10 minutes to figure that out a few years ago. And, as I've said, this comes up on the user list from time to time, too, and I even filed an enhancement request related to this. Bo's solution may not be perfect, but it works. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: EndEnvironment layout entry.
Jean-Marc Lasgouttes wrote: Another solution is to remove this special handling for environments and force to use depth when several paragraphs are in a same env. Richard> But the many-paragraphs case isn't that exceptional and, in Richard> some cases, is even the most common. So it seems wrong to Richard> force extra work in that case. Surely we'd get a lot more Richard> complaints if the case at issue here were the more common Richard> one. That is possible indeed. Inserting boxes for anything one wants to do is not a very exiting prospect either :) You don't want to make the easy case hard. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH] 2697: SplitLayout environment.
I prefer normalsize roman font and red (like beamer pause/endFrame) or blue (like pagebreak). That will be the attached, which has the following style entry: Style SplitLayout KeepEmpty 1 MarginDynamic LatexType Paragraph LatexName dummy ParIndent MM Align Block AlignPossible Block LabelType Static LabelString "--- Split Layout ---" LabelFont Family Roman Series Medium SizeNormal Color Blue EndFont End Jose, OK to commit? Bo Index: src/Buffer.cpp === --- src/Buffer.cpp (revision 18726) +++ src/Buffer.cpp (working copy) @@ -142,7 +142,7 @@ namespace { -int const LYX_FORMAT = 271; +int const LYX_FORMAT = 272; } // namespace anon Index: lib/lyx2lyx/LyX.py === --- lib/lyx2lyx/LyX.py (revision 18726) +++ lib/lyx2lyx/LyX.py (working copy) @@ -77,7 +77,7 @@ ("1_2", [220], generate_minor_versions("1.2" , 4)), ("1_3", [221], generate_minor_versions("1.3" , 7)), ("1_4", range(222,246), generate_minor_versions("1.4" , 4)), - ("1_5", range(246,272), generate_minor_versions("1.5" , 0))] + ("1_5", range(246,273), generate_minor_versions("1.5" , 0))] def formats_list(): Index: lib/lyx2lyx/lyx_1_5.py === --- lib/lyx2lyx/lyx_1_5.py (revision 18726) +++ lib/lyx2lyx/lyx_1_5.py (working copy) @@ -1656,7 +1656,53 @@ else: del document.header[i] +def revert_splitlayout(document): +r''' Revert SplitLayout to a lyx node +From +\begin_layout SplitLayout +something +\end_layout + +to + +\begin_layout Standard +\begin_inset Note Note +status open + +\begin_layout Standard +end evironmnet +\end_layout + +\end_inset +something + +\end_layout + +''' + +i = 0 +while True: +i = find_token(document.body, r'\begin_layout SplitLayout', i) +if i == -1: +break +j = find_end_of_layout(document.body, i + 1) +if j == -1: +# this should not happen +break +document.body[i : j + 1] = [r'\begin_layout Standard', +r'\begin_inset Note Note', +'status open', +'', +r'\begin_layout Standard', +'Split Layout', +r'\end_layout', +'', +r'\end_inset'] + \ +document.body[ i + 1 : j] + \ +['', +r'\end_layout' +] ## # Conversion hub # @@ -1687,10 +1733,12 @@ [268, []], [269, []], [270, []], - [271, [convert_ext_font_sizes]] + [271, [convert_ext_font_sizes]], + [272, []], ] revert = [ + [271, [revert_splitlayout]], [270, [revert_ext_font_sizes]], [269, [revert_beamer_alert, revert_beamer_structure]], [268, [revert_preamble_listings_params, revert_listings_inset, revert_include_listings]], Index: lib/layouts/stdlayouts.inc === --- lib/layouts/stdlayouts.inc (revision 18726) +++ lib/layouts/stdlayouts.inc (working copy) @@ -61,5 +61,20 @@ End - - +Style SplitLayout + KeepEmpty 1 + MarginDynamic + LatexType Paragraph + LatexName dummy + ParIndent MM + Align Block + AlignPossible Block + LabelType Static + LabelString "--- Split Layout ---" + LabelFont + Family Roman + Series Medium + SizeNormal + Color Blue + EndFont +End Index: lib/doc/UserGuide.lyx === --- lib/doc/UserGuide.lyx (revision 18726) +++ lib/doc/UserGuide.lyx (working copy) @@ -1,5 +1,5 @@ #LyX 1.5.0svn created this file. For more info see http://www.lyx.org/ -\lyxformat 263 +\lyxformat 272 \begin_document \begin_header \textclass scrbook @@ -91,8 +91,9 @@ \paperpagestyle default \tracking_changes false \output_changes false -\author "usti" -\author "Uwe Stöhr" +\author "Bo Peng" +\author "usti" +\author "Uwe Stöhr" \end_header \begin_body @@ -9278,6 +9279,28 @@ \end_layout +\begin_layout Standard +In case that you want to
Re: r18728 - in /lyx-devel/trunk/src/insets: InsetListings.cp...
But what happens if a file with such a parameter is opened by an older version (rc1, for instance)? I guess LyX will crash, no? I would not consider rc1 because it is a temporary release. After 1.5.0, @para will always be accepted and will compile if a user's listings package supports para. Of course, to minimize the use of this feature, I will have to look through the parameters again, using the latest listings version. Bo
Re: Close tab button
> Yes, in the long term this is a solution. But currently we rely on Qt 4.1, > so I hope it could go in for 1.5. i hope so :) pavel
Re: Close tab button
Pavel Sanda wrote: I agree with Pavel. >>> I not, because I don't like such buttons. >> I like the patch like it is. Single tab buttons take screen space and >> clutter the appearance. > > i suppose it wont be problem to make switch between these two appearances in > preferences when the second is available. > > pavel > Yes, in the long term this is a solution. But currently we rely on Qt 4.1, so I hope it could go in for 1.5. Peter
Re: r18728 - in /lyx-devel/trunk/src/insets: InsetListings.cp...
Bo Peng wrote: > No. Previously, only valid parameter strings such as 'firstline=5' are > allowed. Now, trashes like '@IamTrash,firstline=5' can also be > entered, although in this particular case latex will not compile > (wrong parameter IamTrash). But what happens if a file with such a parameter is opened by an older version (rc1, for instance)? I guess LyX will crash, no? Jürgen
Re: Crash with the new TOC widget
[EMAIL PROTECTED] wrote: Hello, I've compiled LyX 5.0 svn. 1) Open User Guide 2) Tools -> outline 3) Document -> Next cross-reference Here (Win/MSVC) it crashes at point 3 with this backtrace: lyx-qt4.exe!lyx::frontend::TocModel::modelIndex(const std::_Vector_const_iterator > & it={par_it_={...} depth_=3 str_={...} }) Line 57 + 0x13 bytes C++ lyx-qt4.exe!lyx::frontend::QToc::getCurrentIndex(int type=2) Line 90 + 0x44 bytes C++ lyx-qt4.exe!lyx::frontend::TocWidget::update() Line 235 + 0x25 bytes C++ lyx-qt4.exe!lyx::frontend::DockView::update() Line 62 C++ lyx-qt4.exe!lyx::frontend::Dialog::checkStatus() Line 192 + 0x1a bytes C++ lyx-qt4.exe!lyx::Dialogs::checkStatus() Line 256 C++ lyx-qt4.exe!lyx::LyXView::updateToolbars() Line 347C++ lyx-qt4.exe!lyx::LyXFunc::dispatch(const lyx::FuncRequest & cmd={...}) Line 1817 C++ lyx-qt4.exe!lyx::dispatch(const lyx::FuncRequest & action={...}) Line 1464 C++ lyx-qt4.exe!lyx::LyXView::dispatch(const lyx::FuncRequest & cmd={...}) Line 446 + 0x9 bytes C++ lyx-qt4.exe!lyx::frontend::Action::action() Line 91C++
Re: r18728 - in /lyx-devel/trunk/src/insets: InsetListings.cp...
On 6/9/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] wrote: > Allow prefixing a listings parameter with @ to bypass validation, useful > when new parameters are added in a new listings version Isn't this a file format change? No. Previously, only valid parameter strings such as 'firstline=5' are allowed. Now, trashes like '@IamTrash,firstline=5' can also be entered, although in this particular case latex will not compile (wrong parameter IamTrash). Cheers, Bo
Re: r18728 - in /lyx-devel/trunk/src/insets: InsetListings.cp...
[EMAIL PROTECTED] wrote: > Allow prefixing a listings parameter with @ to bypass validation, useful > when new parameters are added in a new listings version Isn't this a file format change? Jürgen
Re: [PATCH] Allow parameters to bypass InsetListingsParams validation.
I think the proper way to solve any option would have been to outsource the option definitions in a text file which is easily upgradable. But then 1.5.0 will not be usable for listings 2009... Adding a backdoor is always safer. :-) Bo
Re: [PATCH] Allow parameters to bypass InsetListingsParams validation.
Bo Peng wrote: I see no comment on this patch. Because this is within my field, I will commit tomorrow if there is no objection. No objection, so it is in. I think the proper way to solve any option would have been to outsource the option definitions in a text file which is easily upgradable. Abdel.
Re: [PATCH] Part of Bug 3719 -- TOC out of sync
Bo Peng wrote: > We have not done anything, and if the operators are cheap as you > described, it is perfectly fine to me to make TocUpdate automatic. Good, thanks. But then it is your job to get it done. :-) I am slowly coming back, don't ask me too much ;-) Seriously, as we have discussed, the problem lies in 'when to update Toc'. It is unwise to update Toc when we enter each character when editing a caption, but there is no proper way to know 'editing is done here'... The proper way is to check the Buffer structure when you are editing the caption with a call to checkBufferStructure(), maybe this is already done. Then you also need to correct InsetCaption::addToToc(), the same way as you did with InsetListings. Finally, you'll have to make sure that TocBackend::updateItem() properly find the correct TocItem. Not a lot of work but a lot of testing is required. Abdel.
Re: [PATCH] Allow parameters to bypass InsetListingsParams validation.
I see no comment on this patch. Because this is within my field, I will commit tomorrow if there is no objection. No objection, so it is in. Cheers, Bo
Re: Road to rc2 - fixIfBroken
Am 09.06.2007 um 15:05 schrieb Abdelrazak Younes: Stefan Schimanski wrote: Am 09.06.2007 um 14:46 schrieb Abdelrazak Younes: Stefan Schimanski wrote: Ok, committed. So let's see if everything is alright now. We still have some days to the RC2 for testing. If the testing reveals that we don't need the Inset::destroyed() signal, this should be deleted before RC2 too. Right. But then we can also do it now and add it again if we need it? Nice, now it's even usable again with stdlib-debug enabled. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: lyx farsi support??
behzad maha wrote: hi I want to do some coding help. My language is persian(farsi) and I want to help Lyx support farsi.But I don't have experience coding for multi-lingual documents.Can anyone help me where to start? Hello Behzad, We have already a Farsi developper around (Mostafa Vahedi). In principle Farsi should be already supported in current svn (and since RC1 AFAIR). You are of course welcome to help us polishing it and more generally polishing Right-To-Left language support (which has seen a lot of activity recently) First thing to do is to test LyX-svn ;-) Abdel.
Re: [PATCH] Part of Bug 3719 -- TOC out of sync
> We have not done anything, and if the operators are cheap as you > described, it is perfectly fine to me to make TocUpdate automatic. Good, thanks. But then it is your job to get it done. :-) Seriously, as we have discussed, the problem lies in 'when to update Toc'. It is unwise to update Toc when we enter each character when editing a caption, but there is no proper way to know 'editing is done here'... Bo
Re: [PATCH] Part of Bug 3719 -- TOC out of sync
Bo Peng wrote: Please don't touch at that. When you change a section depth, the full renumbering is done (in updateLabels()). It is only natural to update also the TocBackend at the same time. Actually this update is much quicker than the section renumbering. We have not done anything, and if the operators are cheap as you described, it is perfectly fine to me to make TocUpdate automatic. Good, thanks. Abdel.
Re: compile error
InsetMathMBox is compiled only with CMake. That's because I wanted to make sure that it stays compilable until it's time to use it. I was thinking that scons (or worse, gcc) is broken. :-) Bo
Re: Road to rc2 - fixIfBroken
Stefan Schimanski wrote: Am 09.06.2007 um 14:46 schrieb Abdelrazak Younes: Stefan Schimanski wrote: Ok, committed. So let's see if everything is alright now. We still have some days to the RC2 for testing. If the testing reveals that we don't need the Inset::destroyed() signal, this should be deleted before RC2 too. Right. But then we can also do it now and add it again if we need it? I'll do it. Abdel
Re: [PATCH] Part of Bug 3719 -- TOC out of sync
Please don't touch at that. When you change a section depth, the full renumbering is done (in updateLabels()). It is only natural to update also the TocBackend at the same time. Actually this update is much quicker than the section renumbering. We have not done anything, and if the operators are cheap as you described, it is perfectly fine to me to make TocUpdate automatic. Bo
Re: Road to rc2 - fixIfBroken
Stefan Schimanski wrote: Am 09.06.2007 um 14:46 schrieb Abdelrazak Younes: Stefan Schimanski wrote: Ok, committed. So let's see if everything is alright now. We still have some days to the RC2 for testing. If the testing reveals that we don't need the Inset::destroyed() signal, this should be deleted before RC2 too. Right. But then we can also do it now and add it again if we need it? Yep, as you feel. Abdel.
Re: Road to rc2 - fixIfBroken
Am 09.06.2007 um 14:46 schrieb Abdelrazak Younes: Stefan Schimanski wrote: Ok, committed. So let's see if everything is alright now. We still have some days to the RC2 for testing. If the testing reveals that we don't need the Inset::destroyed() signal, this should be deleted before RC2 too. Right. But then we can also do it now and add it again if we need it? Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: Road to rc2 - fixIfBroken
Stefan Schimanski wrote: Ok, committed. So let's see if everything is alright now. We still have some days to the RC2 for testing. If the testing reveals that we don't need the Inset::destroyed() signal, this should be deleted before RC2 too. Abdel.
Re: Crash with the new TOC widget
[EMAIL PROTECTED] wrote: > Done Thanks. I confirmed it and targetted it to 1.5.0. Jürgen
Re: [PATCH] Part of Bug 3719 -- TOC out of sync
Bo Peng wrote: The way to solve this might be to put some appropriate code into InsetCaption::notifyCursorLeaves(). I do not think it is a good idea to update Toc during editing, because simple add/remove of sections, change of environment will break Toc, so it is close to impossible to consider all cases and update Toc. Because TocBackend::update() is expansive, I even think we should remove all such calls triggered by, e.g., changing the environment of a paragraph to section. Please don't touch at that. When you change a section depth, the full renumbering is done (in updateLabels()). It is only natural to update also the TocBackend at the same time. Actually this update is much quicker than the section renumbering. Abdel.
Re: Road to rc2 - fixIfBroken
Ok, committed. So let's see if everything is alright now. We still have some days to the RC2 for testing. Stefan Am 09.06.2007 um 14:32 schrieb Alfredo Braunstein: Abdelrazak Younes wrote: Stefan Schimanski wrote: It works fine (as far as I can judge after 2 minutes testing). I added some comments and pulled apart the loop to make the control flow easier. Alfredo, can you check please? I would be happy if we could get rid of the signals finally like this. I am not Alfredo but it looks fine. I'd say shove it in. ;-) A/ PGP.sig Description: Signierter Teil der Nachricht
Re: BufferView <-> tab
Abdelrazak Younes wrote: > Alfredo Braunstein wrote: >> Why do we have a BufferView for every window instead of one for every >> tab? The latter would be a much simpler scheme... > > The plan is to have one BufferView per Buffer for a given window. The > plan is also to have one WorkArea per tab, thus one BufferView per tab. > At this point we will switch to a QTabWidget instead of the hand made > widget with a QTabBar. > > 1.6 matter... Cool... I've been wanting this for ages, and now there's finally agreement! A/
Re: compile error
Stefan Schimanski wrote: drawMarkers moved to InsetMathNest?! See r18701. Please revert or fix that. /Users/sts/Quellen/mac/lyx-devel/src/mathed/InsetMathMBox.cpp: In member function 'virtual void lyx::InsetMathMBox::draw(lyx::PainterInfo&, int, int) const': /Users/sts/Quellen/mac/lyx-devel/src/mathed/InsetMathMBox.cpp:73: error: 'drawMarkers' was not declared in this scope InsetMathMBox is compiled only with CMake. That's because I wanted to make sure that it stays compilable until it's time to use it. Abdel.
Re: Crash with the new TOC widget
Done #3843
Re: [PATCH] Part of Bug 3719 -- TOC out of sync
Richard Heck wrote: Bo Peng wrote: The way to solve this might be to put some appropriate code into InsetCaption::notifyCursorLeaves(). I do not think it is a good idea to update Toc during editing, because simple add/remove of sections, change of environment will break Toc, so it is close to impossible to consider all cases and update Toc. Yes, you are absolutely right. It's too bad, really. I think Abdel was right to want it to update automatically, but there are too many cases. Wait, when you modify a section text, only the corresponding TocItem is updated, not the full TocBackend (Have a look at TocBackend::updateItem()). The item updating is done only for sections, not for captions because of the limitation of the Inset::addToToc() method. I see that you changed that now so we can synchronize the view and the TocBackend for captions and listings too in a very cheap way now. I don't have the time to read all the messages since last week but if you decided to deleted these update calls please give me a summary of the discussion. Abdel.
[patch] sometimes only paragraph of cursor is visible, #3231
Here is a fix for the grey-bar bug, i.e. randomly only the current paragraph is drawn and everything else is greyed out. I think it is related to synthetic mouse event. Somehow a redraw is triggered, but the ViewMetric.update_strategy is set to NoScreenUpdate. The two condition, that I change in the patch, evaluate to true and the grey bars are drawn. Here is a backtrace of the issue: #0 lyx::paintText ([EMAIL PROTECTED], [EMAIL PROTECTED]) at /Users/sts/ Quellen/mac/lyx-devel/src/rowpainter.cpp:1065 #1 0x0023570a in lyx::frontend::GuiWorkArea::updateScreen (this=0x261a0e30) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/ qt4/GuiWorkArea.cpp:592 #2 0x0023574f in lyx::frontend::GuiWorkArea::expose (this=0x261a0e30, x=0, y=31, w=671, h=105) at /Users/sts/Quellen/mac/ lyx-devel/src/frontends/qt4/GuiWorkArea.cpp:575 #3 0x0022295a in lyx::frontend::WorkArea::redraw (this=0x261a0e44) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/WorkArea.cpp:159 #4 0x00223212 in lyx::frontend::WorkArea::dispatch (this=0x261a0e44, [EMAIL PROTECTED], k=none) at /Users/sts/Quellen/mac/lyx-devel/src/ frontends/WorkArea.cpp:218 #5 0x00237432 in lyx::frontend::GuiWorkArea::mouseMoveEvent (this=0x261a0e30, e=0xbfffefe0) at /Users/sts/Quellen/mac/lyx-devel/ src/frontends/qt4/GuiWorkArea.cpp:414 It happened with two footnote in the view, just moving the mouse around. So could it be related to the mouse hover maybe? I think though that the change in the patch is reasonable nevertheless. The comparison to SingleParUpdate is wrong. The drawText function must work with every update_strategy. Stefan Index: lyx-devel/src/rowpainter.cpp === --- lyx-devel.orig/src/rowpainter.cpp 2007-06-08 07:09:41.0 +0200 +++ lyx-devel/src/rowpainter.cpp2007-06-09 14:17:25.0 +0200 @@ -1061,12 +1061,12 @@ // and grey out above (should not happen later) // lyxerr << "par ascent: " << text.getPar(vi.p1).ascent() << endl; - if (vi.y1 > 0 && vi.update_strategy != SingleParUpdate) + if (vi.y1 > 0 && vi.update_strategy == FullScreenUpdate) pain.fillRectangle(0, 0, bv.workWidth(), vi.y1, Color::bottomarea); // and possibly grey out below // lyxerr << "par descent: " << text.getPar(vi.p1).ascent() << endl; - if (vi.y2 < bv.workHeight() && vi.update_strategy != SingleParUpdate) + if (vi.y2 < bv.workHeight() && vi.update_strategy == FullScreenUpdate) pain.fillRectangle(0, vi.y2, bv.workWidth(), bv.workHeight() - vi.y2, Color::bottomarea); } PGP.sig Description: Signierter Teil der Nachricht
Re: Road to rc2 - fixIfBroken
Abdelrazak Younes wrote: > Stefan Schimanski wrote: >> It works fine (as far as I can judge after 2 minutes testing). I added >> some comments and pulled apart the loop to make the control flow easier. >> Alfredo, can you check please? I would be happy if we could get rid of >> the signals finally like this. > > I am not Alfredo but it looks fine. I'd say shove it in. ;-) A/
Re: [PATCH] Bug 3711, add insets without valid ParConstIterator to TOC.
Bo Peng wrote: Bo> Fixed in the attached patch. Jose, OK to apply? I am not very pleased with the use of an exception there, but on the other hand I do not have (yet) a better idea. I though of returning TocItem and let update() add the labels. However, ParConstIterator does not have a default constructor like ParConstIterator(0) so I can not test special cases in update(). Per the use of exception, I think exception should be used more often in lyx. For example, counters are not updated immediately after, say, an caption is added to InsetInclude. It would be good to have something like try work on inset going on except updateCounter (+1, or -1) except updateScreen (partial or all) except kill me please Just some random thought. IMHO exceptions should only be used in _exceptional_ situation because they bypass the normal function to function communication. I think the way you want to use them is going to slow down the code significantly. This is reason why I don't like for example the way exceptions are misused in the listings code. Abdel.
Re: BufferView <-> tab
Alfredo Braunstein wrote: Why do we have a BufferView for every window instead of one for every tab? The latter would be a much simpler scheme... The plan is to have one BufferView per Buffer for a given window. The plan is also to have one WorkArea per tab, thus one BufferView per tab. At this point we will switch to a QTabWidget instead of the hand made widget with a QTabBar. 1.6 matter... A/ Ab/
Re: Road to rc2 - fixIfBroken
Stefan Schimanski wrote: It works fine (as far as I can judge after 2 minutes testing). I added some comments and pulled apart the loop to make the control flow easier. Alfredo, can you check please? I would be happy if we could get rid of the signals finally like this. I am not Alfredo but it looks fine. Abdel.
Re: Road to rc2 - fixIfBroken
Am 09.06.2007 um 13:09 schrieb Alfredo Braunstein: Stefan Schimanski wrote: It works fine (as far as I can judge after 2 minutes testing). I added some comments and pulled apart the loop to make the control flow easier. Alfredo, can you check please? I would be happy if we could get rid of the signals finally like this. Sure, but I cannot right now. Give me a couple of hours. Ok. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: Converter problem with Mac OS packages
Le 8 juin 07 à 10:28, Mael Hilléreau a écrit : What is the status of this patch? What do you mean by "status" exactly? I don't know if it was tested by others than me. But to be integrated, it is clear that the code needs more testing, and then some #ifdefs in order to be applied only to Mac OS. Well, of course, we need to find a consensus on how updates should be done... At the end, will we use a timestamp alone or in conjunction with CRC? IMHO, the timestamp is sufficient and I didn't encounter inconsistencies while using the existing patch (in which the CRC isn't used for directories). In contrast, you (Andre and Jean-Marc) think a Timestap+CRC would be better. Andre said that some problems could arise when saving a file more than one time within a second. For my part, I think that this situation won't arise when dealing with external graphics. Perhaps you had a more general point of view and thought about other conversions such as in math previews, or anything else... But as I'm new to LyX sources, I don't know much about how the preview mechanism is led. I think we really need to clarify how an update should be triggered. We could start by describing the problem as follows: * Approach: Timestamp (i), Timestamp+CRC (ii) * Contents changed? Yes (1), no (2) * Timestamp changed? Yes (a), no (b) All possible situations are: * 1a: this case leads to an update in (i) and (ii). If we use (i) the test is cheaper; * 1b: this situation is inconsistent: the editor updated the contents but not the timestamp of the directory, or it updated the timestamp but didn't change it (less than 1 sec interval). If we use (i) this situation cannot be detected whereas it can if we use (ii); * 2a: this situation is inconsistent: the user updated the file without changing its contents. It cannot be reached if situation 1b can (excluding the 1 sec problem), and conversely. If we use (ii) the test is cheaper assuming that the conversion process is more expensive than the CRC; * 2b: no modification is made in both (i) and (ii). If we use (i), the test is cheaper. Recall: IMO 1a and 2b are the most frequently, 2a is rare and 1b never occurs when dealing with external graphics. That's why I would pitch on approach (i). The questions are mainly: should we consider that situation 1b can arise or not? And is it worthwhile to save time in 2a if we loose time in 1a and 2b? Could anyone give us more information/suggestions/ point of views about this? Finally, what kind of #ifdef should be used: Should we select Mac OS only, or should we create some variable for OSes providing graphics as directories (e.g. #ifdef HAVE_GRAPHICS_DIR)? Mael.
Re: Road to rc2 - fixIfBroken
Stefan Schimanski wrote: > It works fine (as far as I can judge after 2 minutes testing). I > added some comments and pulled apart the loop to make the control > flow easier. Alfredo, can you check please? I would be happy if we > could get rid of the signals finally like this. Sure, but I cannot right now. Give me a couple of hours. A/
Re: Close tab button
> >>I agree with Pavel. > > > >I not, because I don't like such buttons. > > I like the patch like it is. Single tab buttons take screen space and > clutter the appearance. i suppose it wont be problem to make switch between these two appearances in preferences when the second is available. pavel
Re: Outline panel hidden at inappropriate times
Le 9 juin 07 à 12:30, Jürgen Spitzmüller a écrit : Mael Hilléreau wrote: May I file an enhancement request at bugzilla? Yes, please do so (this is something for post-1.5.0). Done: http://bugzilla.lyx.org/show_bug.cgi?id=3842 Mael.
Re: Road to rc2 - fixIfBroken
It works fine (as far as I can judge after 2 minutes testing). I added some comments and pulled apart the loop to make the control flow easier. Alfredo, can you check please? I would be happy if we could get rid of the signals finally like this. Stefan Index: lyx-devel/src/CursorSlice.cpp === --- lyx-devel.orig/src/CursorSlice.cpp 2007-06-02 11:24:26.0 +0200 +++ lyx-devel/src/CursorSlice.cpp 2007-06-09 12:11:13.0 +0200 @@ -42,10 +42,6 @@ : inset_(&p), idx_(0), pit_(0), pos_(0) { BOOST_ASSERT(inset_); - boost::signal * destroyed_signal = inset_->destroyedSignal(); - if (destroyed_signal) - inset_connection_ = destroyed_signal->connect( - boost::bind(&CursorSlice::invalidate, this)); } @@ -55,22 +51,12 @@ } -CursorSlice::~CursorSlice() -{ - inset_connection_.disconnect(); -} - - CursorSlice & CursorSlice::operator=(CursorSlice const & cs) { inset_ = cs.inset_; idx_ = cs.idx_; pit_ = cs.pit_; pos_ = cs.pos_; - if (inset_ && inset_->destroyedSignal()) { - inset_connection_ = inset_->destroyedSignal()->connect( - boost::bind(&CursorSlice::invalidate, this)); - } return *this; } @@ -112,6 +98,14 @@ } +pit_type CursorSlice::lastpit() const +{ + if (inset().inMathed()) + return 0; + return text()->paragraphs().size() - 1; +} + + CursorSlice::row_type CursorSlice::row() const { BOOST_ASSERT(asInsetMath()); Index: lyx-devel/src/CursorSlice.h === --- lyx-devel.orig/src/CursorSlice.h2007-06-02 11:24:26.0 +0200 +++ lyx-devel/src/CursorSlice.h 2007-06-09 12:12:17.0 +0200 @@ -41,7 +41,7 @@ // that of MathData and Text should vanish. They are conceptually the // same (now...) -class CursorSlice : public boost::signals::trackable { +class CursorSlice { public: /// Those needs inset_ access. ///@{ @@ -63,8 +63,6 @@ /// explicit CursorSlice(Inset &); /// - virtual ~CursorSlice(); - /// CursorSlice & operator=(CursorSlice const &); /// bool isValid() const; @@ -81,6 +79,8 @@ pit_type pit() const { return pit_; } /// set the offset of the paragraph this cursor is in pit_type & pit() { return pit_; } + /// return the last paragraph offset this cursor is in + pit_type lastpit() const; /// increments the paragraph this cursor is in void incrementPar(); /// decrements the paragraph this cursor is in @@ -158,8 +158,6 @@ bool pit_valid_; /// position in this cell pos_type pos_; - /// connection to referred \c inset_ destruction signal. - boost::signals::connection inset_connection_; }; /// test for equality Index: lyx-devel/src/DocIterator.cpp === --- lyx-devel.orig/src/DocIterator.cpp 2007-06-08 22:20:09.0 +0200 +++ lyx-devel/src/DocIterator.cpp 2007-06-09 12:44:07.0 +0200 @@ -4,6 +4,7 @@ * Licence details can be found in the file COPYING. * * \author André Pönitz + * \author Alfredo Braunstein * * Full author contact details are available in file CREDITS. */ @@ -560,53 +561,55 @@ bool DocIterator::fixIfBroken() { - bool fixed = false; - - for (size_t i = slices_.size() - 1; i != 0; --i) - if (!slices_[i].isValid()) { - pop_back(); - fixed = true; + // Go through the slice stack from the bottom. + // Check that all coordinates (idx, pit, pos) are correct and + // that the inset is the one which is claimed to be there + Inset * inset = &slices_[0].inset(); + size_t i = 0; + size_t n = slices_.size(); + for (; i != n; ++i) { + CursorSlice & cs = slices_[i]; + if (&cs.inset() != inset) { + // the whole slice is wrong, chop off this as well + --i; + LYXERR(Debug::DEBUG) << "fixIfBroken(): inset changed" << endl; + break; + } else if (cs.idx() > cs.lastidx()) { + cs.idx() = cs.lastidx(); + cs.pit() = cs.lastpit(); + cs.pos() = cs.lastpos(); + LYXERR(Debug::DEBUG) << "fixIfBroken(): idx fixed" << endl; + break; + } else if (cs.pit() > cs.lastpit()) { + cs.pit() = cs.lastpit(); + cs.pos() = cs.lastpos(); + LYXERR(Debug::DEBUG) << "fixIfBroken(): pit fixed" << endl; + break; + } else if (cs.pos() > cs.lastpos()) { + cs.p
RE: SV: [PATCH] Change default mathbg and add mathhoverbg.
Jean-Marc Lasgouttes wrote: > It is completely different: dEPM disallows things that have _no_ > meaning to LaTeX (like double space). And empty math inset is > acceptable, even if it is most of the times not wanted. sure, perhaps latex permits this but when would you want to create an empty math inset? > I see two solutions: > > 1/ an _empty_ math inset (not $\ $!) is removed when leaving it with > the cursor. This is already what happens with the script inset. > > 2/ an _empty_ math inset (not $\ $!) does not get a preview. > > None of these solve the problem for an inset containing a hard space, > but those who ask for trouble deserve it. maybe we should disallow a space after a backslash in math? or are there situations where this makes sense?
Re: Road to rc2 - fixIfBroken
Stefan Schimanski wrote: >>> Some small questions: >>> Why don't you like comments? >> >> ? Be more specific. OTOH, I would have like some comment of yours >> when I >> asked for them a week ago... ;-) > > Sorry, meant something like two lines describing what the big loop is > doing. Not the comments here :) Something like this? //At the end of this loop the DocIterator should be valid, we //ensure this by working out this condition from the bottom() //to the top() slices. > I guess yes. Compiling right now. If it does, that would be great. Thanks Stefan. > Signals in those CursorSlices, always feel in a strange way when > thinking about it :) Yes, I don't like it either. I'm trying to code something to having edition-persistent iterators(*). I have a partial solution, that includes a MarkersList administrated by the InsetList inside every paragraph. (where markers are like insets, but they just don't take out editing space). The problem right now is what to do when the paragraph is removed completely; then we lose track completely and something else has to be considered. (*) this could have many uses: cursor in other window, bookmarks, error lists etc. A/
Re: Outline panel hidden at inappropriate times
Mael Hilléreau wrote: > May I file an enhancement request at bugzilla? Yes, please do so (this is something for post-1.5.0). Jürgen
Re: Road to rc2 - fixIfBroken
Stefan Schimanski wrote: > I guess yes. Compiling right now. If it does, that would be great. > Signals in those CursorSlices, always feel in a strange way when > thinking about it :) Since you are at it, could you please just commit if you think it is correct? Jürgen
Re: Outline panel hidden at inappropriate times
Le 8 juin 07 à 12:15, Mael Hilléreau a écrit : Le 6 juin 07 à 16:58, Richard Heck a écrit : Mael Hilléreau wrote: Le 6 juin 07 à 15:54, Richard Heck a écrit : Mael Hilléreau wrote: I'm on Mac OS 10.4.9, with 1.5.0rc1. In the two following situations, the outline panel is hidden whereas it should remain visible: 1. Open several documents (e.g. User's guide and Introduction), show the outline, and close one of the documents; This has been fixed in current svn, or should have been: http:// www.lyx.org/trac/changeset/18651. This was bug 3701. I tested, its ok for me. Sorry, I didn't see the bug. No problem. There are a lot of them Another remark regarding the outline panel: wouldn't it be also appropriate to save its status (visible/hidden) into the session file? Anybody has feedback about this suggestion? May I file an enhancement request at bugzilla? Mael.
Re: Road to rc2 - fixIfBroken
Some small questions: Why don't you like comments? ? Be more specific. OTOH, I would have like some comment of yours when I asked for them a week ago... ;-) Sorry, meant something like two lines describing what the big loop is doing. Not the comments here :) Why do you need this complicated logic to set the inset to 0 in many cases. Won't that end the loop anyway in the next round? Yes, but cutting off the DocIterator. And, if the inset = 0 it's a broken cursor in any way, no? So take a wrong idx, hence inset=0. In the next loop with inset()==inset will not cut if off. I think it's wrong. Oh yes I forgot (too much time passed). This patch is intended to work *without* the signaling mechanism. So we should have no slice with inset == 0. So if the patch is to be applied without removing/deactivating the signaling mechanism, this slightly different version should do it, agreed? I guess yes. Compiling right now. If it does, that would be great. Signals in those CursorSlices, always feel in a strange way when thinking about it :) Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: Road to rc2 - fixIfBroken
Stefan Schimanski wrote: > Some small questions: > Why don't you like comments? ? Be more specific. OTOH, I would have like some comment of yours when I asked for them a week ago... ;-) > Why do you need this complicated logic to set the inset to 0 in many > cases. Won't that end the loop anyway in the next round? Yes, but cutting off the DocIterator. > And, if the inset = 0 it's a broken cursor in any way, no? So take a > wrong idx, hence inset=0. In the next loop with inset()==inset will > not cut if off. I think it's wrong. Oh yes I forgot (too much time passed). This patch is intended to work *without* the signaling mechanism. So we should have no slice with inset == 0. So if the patch is to be applied without removing/deactivating the signaling mechanism, this slightly different version should do it, agreed? A/ Index: DocIterator.cpp === --- DocIterator.cpp (revision 18720) +++ DocIterator.cpp (working copy) @@ -562,50 +562,48 @@ { bool fixed = false; - for (size_t i = slices_.size() - 1; i != 0; --i) - if (!slices_[i].isValid()) { - pop_back(); + Inset * inset = &slices_[0].inset(); + for (size_t i = 0, n = slices_.size(); i != n; ++i) { + CursorSlice & cs = slices_[i]; + if (&cs.inset() != inset || inset == 0) { + LYXERR(Debug::DEBUG) +<< "fixIfBroken(): cursor chopped at " +<< i << " because " << &cs.inset() +<< " != " << inset << endl; + resize(i); + return true; + } else if (cs.idx() > cs.lastidx()) { + cs.idx() = cs.lastidx(); + cs.pit() = cs.lastpit(); + cs.pos() = cs.lastpos(); + inset = 0; fixed = true; + LYXERR(Debug::DEBUG) +<< "fixIfBroken(): idx fixed" << endl; + } else if (cs.pit() > cs.lastpit()) { + cs.pit() = cs.lastpit(); + cs.pos() = cs.lastpos(); + inset = 0; + fixed = true; + LYXERR(Debug::DEBUG) +<< "fixIfBroken(): pit fixed" << endl; + } else if (cs.pos() > cs.lastpos()) { + cs.pos() = cs.lastpos(); + inset = 0; + fixed = true; + LYXERR(Debug::DEBUG) +<< "fixIfBroken(): pos fixed" << endl; + } else if (i != n - 1 && cs.pos() != cs.lastpos()) { + if (cs.inset().inMathed()) { +inset = (cs.cell().begin() + + cs.pos())->nucleus(); + } else { +inset = cs.paragraph().isInset(cs.pos()) ? + cs.paragraph().getInset(cs.pos()) : 0; + } } - - // The top level CursorSlice should always be valid. - BOOST_ASSERT(slices_[0].isValid()); - - if (idx() > lastidx()) { - lyxerr << "wrong idx " << idx() - << ", max is " << lastidx() - << " at level " << depth() - << ". Trying to correct this." << endl; - lyxerr << "old: " << *this << endl; - for (size_t i = idx(); i != lastidx(); --i) - pop_back(); - idx() = lastidx(); - pit() = lastpit(); - pos() = lastpos(); - fixed = true; } - else if (pit() > lastpit()) { - lyxerr << "wrong pit " << pit() - << ", max is " << lastpit() - << " at level " << depth() - << ". Trying to correct this." << endl; - lyxerr << "old: " << *this << endl; - pit() = lastpit(); - pos() = 0; - fixed = true; - } - else if (pos() > lastpos()) { - lyxerr << "wrong pos " << pos() - << ", max is " << lastpos() - << " at level " << depth() - << ". Trying to correct this." << endl; - lyxerr << "old: " << *this << endl; - pos() = lastpos(); - fixed = true; - } - if (fixed) { - lyxerr << "new: " << *this << endl; - } + return fixed; } Index: CursorSlice.h === --- CursorSlice.h (revision 18720) +++ CursorSlice.h (working copy) @@ -81,6 +81,8 @@ pit_type pit() const { return pit_; } /// set the offset of the paragraph this cursor is in pit_type & pit() { return pit_; } + /// return the last paragraph offset this cursor is in + pit_type lastpit() const; /// increments the paragraph this cursor is in void incrementPar(); /// decrements the paragraph this cursor is in Index: CursorSlice.cpp === --- CursorSlice.cpp (revision 18720) +++ CursorSlice.cpp (working copy) @@ -112,6 +112,14 @@ } +pit_type CursorSlice::lastpit() const +{ + if (inset().inMathed()) + return 0; + return text()->paragraphs().size() - 1; +} + + CursorSlice::row_type CursorSlice::row() const { BOOST_ASSERT(asInsetMath());
Re: [patch] LyX crashes with multiple views, #3785
And, if the inset = 0 it's a broken cursor in any way, no? So take a wrong idx, hence inset=0. In the next loop with inset()==inset will not cut if off. I think it's wrong. I was right. You can crash it like this: "abcde", insert ERT inset, type inside "fgh". Place the cursor behind the h. Create a new window, select the everything and delete (even less is enough) => crash because nargs is called on a 0 inset. Stefan PGP.sig Description: Signierter Teil der Nachricht
Window-independent dialogs
Hi! Is there a reason that the non-modal dialogs (like to edit tables, change text styles etc.) depend on the LyX window? You can open another one for every window which is open. It's somehow strange and confusing to have a text style dialog, but it "doesn't work" because it belongs to another window. Create a bug report for it: http://bugzilla.lyx.org/show_bug.cgi?id=3836 Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [patch] LyX crashes with multiple views, #3785
Am 09.06.2007 um 11:07 schrieb Jürgen Spitzmüller: Alfredo Braunstein wrote: I tested it a few days without problems. I don't have svn rights ATM, you should get them back as soon as possible IMHO. Then you're indebted to contribute again ;-) could someone else do it for me? Last version is in the 'road to rc2' thread. I'll do it. Please read my comment in the rc2 thread. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: Road to rc2 - fixIfBroken
Am 09.06.2007 um 00:28 schrieb Alfredo Braunstein: Jean-Marc Lasgouttes wrote: Yes, the patch looks good, except that the messages are not very informative (but as a usr I would be scared to see all these messages in normal operation). And there is a very long line. Fixed. Note that the scary messages are already there in svn. Please apply. A/ PS: should I prepare another patch with the removal of the destroyed signals etc? Some small questions: Why don't you like comments? Why do you need this complicated logic to set the inset to 0 in many cases. Won't that end the loop anyway in the next round? And, if the inset = 0 it's a broken cursor in any way, no? So take a wrong idx, hence inset=0. In the next loop with inset()==inset will not cut if off. I think it's wrong. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [patch] LyX crashes with multiple views, #3785
Am Samstag, 9. Juni 2007 schrieb Jürgen Spitzmüller: > > could someone else do it for me? Last version is in the 'road to rc2' > > thread. > > I'll do it. But please write a log message. Jürgen
Re: [patch] LyX crashes with multiple views, #3785
Alfredo Braunstein wrote: > I tested it a few days without problems. I don't have svn rights ATM, you should get them back as soon as possible IMHO. Then you're indebted to contribute again ;-) > could someone else do it for me? Last version is in the 'road to rc2' > thread. I'll do it. Jürgen
Re: [patch] lyx crashes/mutilates document using math-delimiter ( ) in hebrew text
Stefan Schimanski wrote: > Which kind of flashing?! What is flashing? The whole bufferview? The > math? Don't see any like that here. rather the math. it looks like the cursor is very rapidly put inside the inset and back outside. If I have the math panel toolbar opened (in auto mode), it flashes up shortly and disappears again. Also, the math inset itself "flashes" and something (which I cannot identify) pops up shortly. This is when I move the cursor with the arrow keys. Note, however, that I'm totally RTL ignorant, so I have no idea about how the cursor movement should be "naturally". > And btw, I checked again: the crash is there without the patch. I tried yesterday (without your patch) and I couldn't reproduce, so I thought it was cured by your Bidi work. Jürgen
Re: [patch] LyX crashes with multiple views, #3785
Jürgen Spitzmüller wrote: > Alfredo Braunstein wrote: >> I was hoping for the patch to be applied sooner, as >> it was discussed enough, fixed a crash, and had some good side effects >> (removal of the destroyed signals etc)... > > But you wrote it's "completely untested". If this is no more true, I'd say > go ahead and apply it. I tested it a few days without problems. I don't have svn rights ATM, could someone else do it for me? Last version is in the 'road to rc2' thread. A/
Re: Close tab button
Am 09.06.2007 um 09:52 schrieb Peter Kümmel: Jürgen Spitzmüller wrote: Pavel Sanda wrote: Firefox also had only one button in the 1.5 series. And I don't like the 2.x UI with the button per tab. please dont close the bug for close button on tab. the main advantage of one button per tab is the possibility to close different tabs just by one click without choosing the tab to be active. it maybe not so neat, but is much more effective for work. Anyway, a button per tab is much more complicated than this solution. i would wait when trolltech include this feature to the qtabbar class. I agree with Pavel. I not, because I don't like such buttons. I like the patch like it is. Single tab buttons take screen space and clutter the appearance. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [patch] lyx crashes/mutilates document using math-delimiter ( ) in hebrew text
Am 09.06.2007 um 09:22 schrieb Jürgen Spitzmüller: Stefan Schimanski wrote: The bug: http://bugzilla.lyx.org/show_bug.cgi?id=2446 The patch: It seems to improve the situation (besides the crash, which is gone also without your patch), but I still get some flashing effects when trying the testcase of bug 2446 (screen flickering whenever I move the cursor in the math inset with the keyboard). Which kind of flashing?! What is flashing? The whole bufferview? The math? Don't see any like that here. And btw, I checked again: the crash is there without the patch. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: Crash with the new TOC widget
[EMAIL PROTECTED] wrote: > 1) Open User Guide > 2) Tools -> outline > 3) Document -> Next cross-reference > 4) Click in the Toc Widget on the second section > 5) Boum Confirmed (backtrace below). Please file a bug report. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47150429772400 (LWP 14733)] 0x005b9359 in lyx::ParConstIterator::operator-> (this=0x18b0a48) at CursorSlice.h:81 81 pit_type pit() const { return pit_; } (gdb) bt #0 0x005b9359 in lyx::ParConstIterator::operator-> (this=0x18b0a48) at CursorSlice.h:81 #1 0x0060a4ff in lyx::TocItem::id (this=0x18b0a48) at TocBackend.cpp:80 #2 0x0092f1a2 in lyx::frontend::ControlToc::goTo (this=0x1b09bd0, [EMAIL PROTECTED]) at ControlToc.cpp:83 #3 0x008d270c in lyx::frontend::QToc::goTo (this=0x1b09bc0, type=, [EMAIL PROTECTED]) at QToc.cpp:110 #4 0x008cdf00 in lyx::frontend::TocWidget::selectionChanged (this=0x1b101b0, [EMAIL PROTECTED]) at TocWidget.cpp:88 #5 0x008ce9fc in lyx::frontend::TocWidget::qt_metacall (this=0x1b101b0, _c=QMetaObject::InvokeMetaMethod, _id=104, _a=0x7fff9eecf560) at TocWidget_moc.cpp:87 #6 0x2ae20df5ebcb in QMetaObject::activate (sender=0x1460e30, from_signal_index=5, to_signal_index=5, argv=0x1) at kernel/qobject.cpp:2940 #7 0x2ae20c2eb1fa in QItemSelectionModel::currentChanged (this=0x18b0a48, _t1=, _t2=) at .moc/release-shared/moc_qitemselectionmodel.cpp:150 #8 0x2ae20c2eb534 in QItemSelectionModel::setCurrentIndex (this=0x1460e30, index=, [EMAIL PROTECTED]) at itemviews/qitemselectionmodel.cpp:1057 #9 0x2ae20c2b57d1 in QAbstractItemView::mousePressEvent (this=0x1b100f0, event=0x7fff9eed0040) at itemviews/qabstractitemview.cpp:1306 #10 0x2ae20c2dfc2e in QTreeView::mousePressEvent (this=0x1b100f0, event=0x7fff9eed0040) at itemviews/qtreeview.cpp:1347 #11 0x2ae20bfa356a in QWidget::event (this=0x1b100f0, event=0x7fff9eed0040) at kernel/qwidget.cpp:5714 #12 0x2ae20c1f4409 in QFrame::event (this=0x18b0a48, e=0x18b0a48) at widgets/qframe.cpp:633 #13 0x2ae20c25bc8a in QAbstractScrollArea::viewportEvent (this=0x18b0a48, e=0x18b0a48) at widgets/qabstractscrollarea.cpp:854 ---Type to continue, or q to quit--- #14 0x2ae20c2b0d41 in QAbstractItemView::viewportEvent (this=0x1b100f0, event=0x7fff9eed0040) at itemviews/qabstractitemview.cpp:1270 #15 0x2ae20c25df98 in QAbstractScrollAreaFilter::eventFilter (this=, o=, e=0x1b200e0) at widgets/qabstractscrollarea_p.h:78 #16 0x2ae20bf5eb73 in QApplicationPrivate::notify_helper (this=, receiver=0x1b12140, e=0x7fff9eed0040) at kernel/qapplication.cpp:3431 #17 0x2ae20bf614a1 in QApplication::notify (this=0xe4e4d0, receiver=0x1b12140, e=0x7fff9eed0040) at kernel/qapplication.cpp:3138 #18 0x007d8668 in lyx::frontend::GuiApplication::notify (this=0x18b0a48, receiver=0x18b0a48, event=0x1b200e0) at GuiApplication.cpp:237 #19 0x2ae20bfb3406 in QETWidget::translateMouseEvent (this=0x1b12140, event=) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:186 #20 0x2ae20bfb22da in QApplication::x11ProcessEvent (this=0x136, event=0x7fff9eed0510) at kernel/qapplication_x11.cpp:2853 #21 0x2ae20bfd3ca5 in x11EventSourceDispatch (s=0xe564a0, callback=0, user_data=0x0) at kernel/qguieventdispatcher_glib.cpp:122 #22 0x2ae20e425f94 in g_main_context_dispatch () from /opt/gnome/lib64/libglib-2.0.so.0 #23 0x2ae20e428dc5 in g_main_context_prepare () from /opt/gnome/lib64/libglib-2.0.so.0 #24 0x2ae20e4292ee in g_main_context_iteration () from /opt/gnome/lib64/libglib-2.0.so.0 #25 0x2ae20df6f430 in QEventDispatcherGlib::processEvents (this=0xe529b0, flags=) at kernel/qeventdispatcher_glib.cpp:366 #26 0x2ae20bfd3abf in QGuiEventDispatcherGlib::processEvents (this=0x18b0a48, flags=) at kernel/qguieventdispatcher_glib.cpp:178 ---Type to continue, or q to quit--- #27 0x2ae20df4dda8 in QEventLoop::processEvents (this=, flags=) at kernel/qeventloop.cpp:126 #28 0x2ae20df4deb9 in QEventLoop::exec (this=0x7fff9eed0890, [EMAIL PROTECTED]) at kernel/qeventloop.cpp:172 #29 0x2ae20df50080 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:730 #30 0x007d85d9 in lyx::frontend::GuiApplication::exec (this=) at GuiApplication.cpp:158 #31 0x00550740 in lyx::LyX::exec (this=0x7fff9eed09c0, argc=, argv=) at LyX.cpp:463 #32 0x004288ff in main (argc=1, argv=0x7fff9eed0ad8) at main.cpp:48 Jürgen
Re: Close tab button
Jürgen Spitzmüller wrote: > Pavel Sanda wrote: >>> Firefox also had only one button in the 1.5 series. And I don't like >>> the 2.x UI with the button per tab. >> please dont close the bug for close button on tab. >> the main advantage of one button per tab is the possibility to close >> different tabs just by one click without choosing the tab to be >> active. it maybe not so neat, but is much more effective for work. >> >>> Anyway, a button per tab is much more complicated than this solution. >> i would wait when trolltech include this feature to the qtabbar class. > > I agree with Pavel. I not, because I don't like such buttons. > > Jürgen > Peter
Crash with the new TOC widget
Hello, I've compiled LyX 5.0 svn. 1) Open User Guide 2) Tools -> outline 3) Document -> Next cross-reference 4) Click in the Toc Widget on the second section 5) Boum with this (rather unhelpful message) /usr/include/c++/4.1.3/debug/safe_iterator.h:130:error: attempt to copy- construct an iterator from a singular iterator. Objects involved in the operation: iterator "this" @ 0x0xaf918fe0 { type = N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPKN3lyx7TocItemEN10__gnu_norm6vectorIS4_SaIS4_EN15__gnu_debug_def6vectorIS4_S9_ (constant iterator); state = singular; } iterator "other" @ 0x0x92abed0 { type = N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPKN3lyx7TocItemEN10__gnu_norm6vectorIS4_SaIS4_EN15__gnu_debug_def6vectorIS4_S9_ (constant iterator); state = singular; } Cheers, Charles
Re: [patch] fixing segfault because of empty coord cache
Martin Vermeer wrote: On Fri, Jun 08, 2007 at 08:22:42PM +0200, Jean-Marc Lasgouttes wrote: "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes: Stefan> Critical bugs don't get less critical by ignorance. If anybody Stefan> wants to know more: [snip] Great analysis! I would say that the fix is correct, but I'd wait for Andre's input. JMarc Hear, hear. This kind of analysis should be in the code, as comment. Do I understand correctly that this presupposes that 1) every mathinset must have an isActive method and 2) it should return true only if the inset has really accessible cells? Not really. IIRC, the problem with mathed (as opposed to the other insets) is that the metrics are saved in the CoordCache at draw() time as opposed to updateMetrics() time. The real fix is to align this treatment for all insets. Abdel.
Re: Close tab button
Pavel Sanda wrote: > > Firefox also had only one button in the 1.5 series. And I don't like > > the 2.x UI with the button per tab. > > please dont close the bug for close button on tab. > the main advantage of one button per tab is the possibility to close > different tabs just by one click without choosing the tab to be > active. it maybe not so neat, but is much more effective for work. > > > Anyway, a button per tab is much more complicated than this solution. > > i would wait when trolltech include this feature to the qtabbar class. I agree with Pavel. Jürgen
Re: [patch] lyx crashes/mutilates document using math-delimiter ( ) in hebrew text
Stefan Schimanski wrote: > The bug: http://bugzilla.lyx.org/show_bug.cgi?id=2446 > The patch: It seems to improve the situation (besides the crash, which is gone also without your patch), but I still get some flashing effects when trying the testcase of bug 2446 (screen flickering whenever I move the cursor in the math inset with the keyboard). Jürgen