Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Am Samstag, 18. März 2006 18:13 schrieb Enrico Forestieri: Georg Baum [EMAIL PROTECTED] writes: I had to compile every library I needed for building LyX, and it turned out that I only needed Qt, aspell, and libiconv. Nothing more. Ah, that information was missing until now. So, given that those libraries don't use -mms-bitfields, I think it is safe avoiding it. Moreover, if those libraries don't use -mms-bitfields and you enforce it, problems arise (see Abdel case). I agree. If these libraries don't use -mms-bitfield then LyX must not use it either. I had a look at the qt3 port for windows, and it does not use it either in the default configuration for mingw and cygwin. So even if we wanted to use other libraries that would require the switch we cannot do so because qt3 does not use it. Those who compile qt3 with nonstandard settings know what they are doing anyway and can still add the flag by hand. I am therefore committing the attached patch. Georg Log: Remove -mms-bitfields compiler option on windows, since all qt releases that we support with the gcc toolchain on windows are compiled without it. Index: config/cygwin.m4 === --- config/cygwin.m4 (Revision 13418) +++ config/cygwin.m4 (Arbeitskopie) @@ -5,35 +5,6 @@ AC_DEFUN([CHECK_WITH_CYGWIN], [ case $host_os in cygwin* | mingw* | pw32* ) -if test $GCC = yes; then - # Ensure MSVC-compatible struct packing convention. - # Depends on GCC version. gcc2 uses -fnative-struct while - # gcc3 uses -mms-bitfields. - # - msnative_struct='' - AC_MSG_CHECKING([how to get MSVC-compatible struct packing]) - case `$CC --version | sed -e 's,\..*,.,' -e q` in - 2.) -if $CC -v --help 2/dev/null | grep fnative-struct /dev/null; then -msnative_struct='-fnative-struct' -fi -;; - *) -if $CC -v --help 2/dev/null | grep ms-bitfields /dev/null; then -msnative_struct='-mms-bitfields' -fi -;; - esac - - if test x$msnative_struct = x; then -AC_MSG_RESULT([no way]) -AC_MSG_WARN([produced libraries might be incompatible with MSVC libs]) - else -CXXFLAGS=$CXXFLAGS $msnative_struct -AC_MSG_RESULT([${msnative_struct}]) - fi -fi - # Export all symbols to Win32 DLL using MinGW 2.0 ld. WIN32_LD_EXPORT_ALL_SYMBOLS='' AC_MSG_CHECKING([whether ld accepts --export-all-symbols])
Re: r13417 - /lyx-devel/trunk/configure.ac
[EMAIL PROTECTED] wrote: Author: baum Date: Sat Mar 18 17:14:31 2006 New Revision: 13417 Log: fix lib/configure.py invocation for builddir != srcdir (create the lib directorty if it does not exist before running the script) Modified: lyx-devel/trunk/configure.ac Another 1.4.X candidate??? Michael
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Enrico Forestieri wrote: Then why not compiling libiconv with mingw, too? It is quite strightforward to do. As regards gettext, if you configure with --with-included-gettext, it will be compiled alongside LyX. Then why not keeping the option? Why all the trouble? Michael
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Abdelrazak Younes wrote: I forgot about that. Are we linking with libiconv or just using iconv.exe? Same question for gettext. https://sourceforge.net/project/shownotes.php?release_id=389183 Says that the lib is compiled with mingw so this should not be a problem. This is not the libiconv version that Angus and I are using! Please be careful with what you are doing! I really need this option to be removed for the qt4 frontend when compiled with mingw. Why? Michael
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Michael Gerz wrote: This is not the libiconv version that Angus and I are using! Please be careful with what you are doing! Ok, I see that the flag has been removed already. I will check my installation guide before I continue complaining... Michael
Re: r13417 - /lyx-devel/trunk/configure.ac
Am Sonntag, 19. März 2006 09:52 schrieb Michael Gerz: Another 1.4.X candidate??? No. configure.py is only used in 1.5. Georg
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Am Sonntag, 19. März 2006 10:00 schrieb Michael Gerz: This is not the libiconv version that Angus and I are using! Please be careful with what you are doing! We are. LyX must be compiled without -mms-bitfields, since the qt4 Open Source edition available from trolltech is compiled without it, and the default configuration of the Q..3/Windows Free Edition does not use this switch either. Therefore you and Angus have no choice and must use a libiconv that is compatible to this setting, too. The only possibility to use a libiconv that requires -mms-bitfields is to set this switch by hand when compiling qt yourself. In this case you can (and have to) set it by hand for LyX, too. If you know a way to detect the -mms-bitfields setting of qt automatically then I'll be happy to put code to do that in cygwin.m4. I really need this option to be removed for the qt4 frontend when compiled with mingw. Why? Because of crashes. Please read the whole thread. This has been discussed extensively. Georg
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Georg Baum wrote: Because of crashes. Please read the whole thread. This has been discussed extensively. Funny. It means that I should have experienced crashes all the time. I wonder why I haven't... Very strange... I will look for a bullet-proof compilation instruction. Michael
Re: qt4: remove (2nd) add dialog in add bib tex ref dialog
Abdelrazak Younes wrote: IMHO, the bibtex dialog should be accessible from the citation dialog. For the matter, I think everything related to citation should be accessible through the citation dialog. And if we have several different bibtext insets (bibtopic)? Jürgen
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Jean-Marc Lasgouttes wrote: There are no speedups yet. I thought we would have really bad bugs to catter for, but I was wrong. Therefore I think we should add some speedup bugs. What else? I am tempted to keep the change tracking patches for the next round. There are many other small patches targetted at 1.4.1, and most of them could go in now. Hi Jean-Marc, given the fact that some bigger changes have to go into 1.4.X sooner or later (speedups CT), I think we should keep 1.5.X and 1.4.X in sync as long as possible. I tried to keep track of all potentially relevant changes that haven't been applied to 1.4.X, yet. r13328 - Fix bug 2195: Slowness in rendering inside insets, especially on the Mac r13339 - Fix bug 880, or the multi-paragraph change tracking patch r13356 - fix painting of change bar with only paragraph break changed r13385 - Change tracking -related bug fixes (reported by Juergen) r13408 - fix stripLeadingSpaces mechanism with change tracking enabled r13415 - Changes to the within-inset row rendering caching code r13418 - expand redrawing of current row to endpos() AGAIN r13420 - constify; remove unneeded casts r13422 - Fix changebar non-update (Juergen) IMHO we should apply at least a few of them. Otherwise, it will become more and more complicated to extract patches from the trunk. Michael
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: | | Abdelrazak I would say that it's a good first step. No need to add | Abdelrazak more speedup fixes. The major one would have to wait | Abdelrazak (RandomAccessList and UpdateCounter). | | Ha! I forgot about RandomAccessList! Did someone try it out on 1.4? I | did and it seems to work in its latest incarnation. I am doing a final look over now beforee committing to trunk. -- Lgb
[patch] bug 2322: New bibtex insets don't have style set to plain, it's empty.
http://bugzilla.lyx.org/show_bug.cgi?id=2322 As advertised, the last patch I have in my tree for 1.4.1. Jürgen Index: src/frontends/gtk/GBibtex.C === --- src/frontends/gtk/GBibtex.C (Revision 13342) +++ src/frontends/gtk/GBibtex.C (Arbeitskopie) @@ -28,8 +28,6 @@ #include libglademm.h using lyx::support::ChangeExtension; -using lyx::support::contains; -using lyx::support::prefixIs; using lyx::support::split; using lyx::support::trim; @@ -109,20 +107,10 @@ void GBibtex::update() } } - string bibtotoc = bibtotoc; - string bibstyle(controller().params().getOptions()); - - // bibtotoc exists? - if (prefixIs(bibstyle, bibtotoc)){ - // bibstyle exists? - if (contains(bibstyle,',')) - bibstyle = split(bibstyle, bibtotoc, ','); - else - bibstyle.erase(); - } + string bibstyle(controller().getStylefile()); bool const bibtopic = controller().usingBibtopic(); - if (prefixIs(bibstyle, bibtotoc) !bibtopic) + if (controller().bibtotoc() !bibtopic) toccheck_-set_active(true); else toccheck_-set_active(false); Index: src/frontends/qt2/QBibtex.C === --- src/frontends/qt2/QBibtex.C (Revision 13342) +++ src/frontends/qt2/QBibtex.C (Arbeitskopie) @@ -33,8 +33,6 @@ using lyx::support::ChangeExtension; -using lyx::support::contains; -using lyx::support::prefixIs; using lyx::support::split; using lyx::support::trim; @@ -98,23 +96,7 @@ void QBibtex::update_contents() dialog_-add_-bibLB-insertItem(toqstr(bibItem)); } - string bibtotoc = bibtotoc; - string bibstyle(controller().params().getOptions()); - - // bibtotoc exists? - if (prefixIs(bibstyle, bibtotoc)){ - // bibstyle exists? - if (contains(bibstyle,',')) - bibstyle = split(bibstyle, bibtotoc, ','); - else - bibstyle.erase(); - } - - if (prefixIs(bibstyle, bibtotoc) !bibtopic) - dialog_-bibtocCB-setChecked(true); - else - dialog_-bibtocCB-setChecked(false); - + dialog_-bibtocCB-setChecked(controller().bibtotoc() !bibtopic); dialog_-bibtocCB-setEnabled(!bibtopic); string btprint(controller().params().getSecOptions()); @@ -130,6 +112,7 @@ void QBibtex::update_contents() dialog_-styleCB-clear(); int item_nr(-1); + string bibstyle(controller().getStylefile()); vectorstring str; controller().getBibStyles(str); Index: src/frontends/qt4/QBibtex.C === --- src/frontends/qt4/QBibtex.C (Revision 13342) +++ src/frontends/qt4/QBibtex.C (Arbeitskopie) @@ -32,8 +32,6 @@ using lyx::support::ChangeExtension; -using lyx::support::contains; -using lyx::support::prefixIs; using lyx::support::split; using lyx::support::trim; @@ -97,23 +95,9 @@ void QBibtex::update_contents() dialog_-add_-bibLB-insertItem(toqstr(bibItem)); } - string bibtotoc = bibtotoc; - string bibstyle(controller().params().getOptions()); - - // bibtotoc exists? - if (prefixIs(bibstyle, bibtotoc)){ - // bibstyle exists? - if (contains(bibstyle,',')) - bibstyle = split(bibstyle, bibtotoc, ','); - else - bibstyle.erase(); - } - - if (prefixIs(bibstyle, bibtotoc) !bibtopic) - dialog_-bibtocCB-setChecked(true); - else - dialog_-bibtocCB-setChecked(false); + string bibstyle(controller().getStylefile()); + dialog_-bibtocCB-setChecked(controller().bibtotoc() !bibtopic); dialog_-bibtocCB-setEnabled(!bibtopic); string btprint(controller().params().getSecOptions()); Index: src/frontends/xforms/FormBibtex.C === --- src/frontends/xforms/FormBibtex.C (Revision 13342) +++ src/frontends/xforms/FormBibtex.C (Arbeitskopie) @@ -34,12 +34,10 @@ namespace lyx { using support::ChangeExtension; using support::compare; -using support::contains; using support::FileFilterList; using support::getStringFromVector; using support::getVectorFromString; using support::OnlyFilename; -using support::prefixIs; using support::split; namespace frontend { @@ -179,20 +177,13 @@ void FormBibtex::update() fl_set_input(dialog_-input_database, controller().params().getContents().c_str()); - string bibtotoc = bibtotoc; - string bibstyle = controller().params().getOptions(); + string bibstyle = controller().getStylefile(); bool const bibtopic = controller().usingBibtopic(); - bool const bibtotoc_exists = prefixIs(bibstyle, bibtotoc); - fl_set_button(dialog_-check_bibtotoc, bibtotoc_exists !bibtopic); + fl_set_button(dialog_-check_bibtotoc, + controller().bibtotoc() !bibtopic); setEnabled(dialog_-check_bibtotoc, !bibtopic); - if (bibtotoc_exists) { - if (contains(bibstyle, ',')) { // bibstyle exists? - bibstyle = split(bibstyle, bibtotoc, ','); - } else { - bibstyle.erase(); - } - } + fl_set_input(dialog_-input_style, bibstyle.c_str()); string btprint = controller().params().getSecOptions(); Index: src/frontends/controllers/ControlBibtex.C
Re: [patch] rowpainter.C
Martin Vermeer wrote: Yes, and I committed a patch to trunk Perfect! From my POV, multi par change tracking seems to be finished and working now, no more complaints :-) Do you have a cumulative patch for 1.4 that combines all the changes and subsequent fixes you (and others) have done? I'd like to give it a test in branch to see if we didn't forget anything. Thanks, Jürgen
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
On Sun, Mar 19, 2006 at 11:22:31AM +0100, Michael Gerz wrote: Jean-Marc Lasgouttes wrote: ... given the fact that some bigger changes have to go into 1.4.X sooner or later (speedups CT), I think we should keep 1.5.X and 1.4.X in sync as long as possible. I tried to keep track of all potentially relevant changes that haven't been applied to 1.4.X, yet. These together constitute the multi-par CT work: r13339 - Fix bug 880, or the multi-paragraph change tracking patch r13356 - fix painting of change bar with only paragraph break changed r13385 - Change tracking -related bug fixes (reported by Juergen) r13408 - fix stripLeadingSpaces mechanism with change tracking enabled r13418 - expand redrawing of current row to endpos() AGAIN r13422 - Fix changebar non-update (Juergen) And these together the speedup (row paint caching inside insets) work. r13328 - Fix bug 2195: Slowness in rendering inside insets, especially on the Mac r13415 - Changes to the within-inset row rendering caching code r13420 - constify; remove unneeded casts Thanks for this compilation! IMHO we should apply at least a few of them. Otherwise, it will become more and more complicated to extract patches from the trunk. Yes, I think so. But as blocks as above, because they belong together. As for the speedup patch, I would like to know what makes your document slow. At least *that* speedup patch (if we have it :-) should be considered next for 1.4.x. - Martin pgpVNtetOM0tz.pgp Description: PGP signature
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Michael Gerz a écrit : Georg Baum wrote: Because of crashes. Please read the whole thread. This has been discussed extensively. Funny. It means that I should have experienced crashes all the time. I wonder why I haven't... Very strange... I will look for a bullet-proof compilation instruction. It was with the qt4 frontend Michael not qt2. The painting does not work at all when QWorkArea is compiled with -mms-bitfields. Something related to different memory models apparently. Abdel.
Re: [patch] rowpainter.C
On Sun, Mar 19, 2006 at 12:49:53PM +0100, Juergen Spitzmueller wrote: Martin Vermeer wrote: Yes, and I committed a patch to trunk Perfect! From my POV, multi par change tracking seems to be finished and working now, no more complaints :-) Do you have a cumulative patch for 1.4 that combines all the changes and subsequent fixes you (and others) have done? I'd like to give it a test in branch to see if we didn't forget anything. Thanks, Jürgen Here is the cumulative patch, with thanks to Michael Gerz. I haven't compiled this myself yet so you may run into surprises ;-) - Martin Index: paragraph.h === --- paragraph.h (revision 13338) +++ paragraph.h (revision 13422) @@ -224,6 +224,9 @@ public: /// set change at pos void setChange(lyx::pos_type pos, Change::Type type); + + /// set full change at pos + void setChangeFull(lyx::pos_type pos, Change change); /// accept change void acceptChange(lyx::pos_type start, lyx::pos_type end); Index: paragraph_pimpl.C === --- paragraph_pimpl.C (revision 13338) +++ paragraph_pimpl.C (revision 13422) @@ -99,7 +99,7 @@ void Paragraph::Pimpl::trackChanges(Chan lyxerr[Debug::CHANGES] track changes for par id_ type type endl; changes_.reset(new Changes(type)); - changes_-set(type, 0, size()); + changes_-set(type, 0, size() + 1); } @@ -116,7 +116,7 @@ void Paragraph::Pimpl::cleanChanges() return; changes_.reset(new Changes(Change::INSERTED)); - changes_-set(Change::INSERTED, 0, size()); + changes_-set(Change::INSERTED, 0, size() + 1); } @@ -147,6 +147,14 @@ void Paragraph::Pimpl::setChange(pos_typ } +void Paragraph::Pimpl::setChangeFull(pos_type pos, Change change) +{ + if (!tracking()) + return; + + changes_-set(change, pos); +} + Change::Type Paragraph::Pimpl::lookupChange(pos_type pos) const { if (!tracking()) @@ -204,10 +212,14 @@ void Paragraph::Pimpl::acceptChange(pos_ break; case Change::DELETED: - eraseIntern(i); - changes_-erase(i); - --end; - --i; + // Suppress access to nonexistent + // end-of-paragraph char: + if (i size()) { + eraseIntern(i); + changes_-erase(i); + --end; + --i; + } break; } } @@ -235,15 +247,18 @@ void Paragraph::Pimpl::rejectChange(pos_ break; case Change::INSERTED: - eraseIntern(i); - changes_-erase(i); - --end; - --i; + if (i size()) { + eraseIntern(i); + changes_-erase(i); + --end; + --i; + } break; case Change::DELETED: changes_-set(Change::UNCHANGED, i); - if (owner_-isInset(i)) + // No real char at position size(): + if (i size() owner_-isInset(i)) owner_-getInset(i)-markErased(false); break; } @@ -351,7 +366,7 @@ void Paragraph::Pimpl::eraseIntern(pos_t bool Paragraph::Pimpl::erase(pos_type pos) { - BOOST_ASSERT(pos size()); + BOOST_ASSERT(pos = size()); if (tracking()) { Change::Type changetype(changes_-lookup(pos)); @@ -359,14 +374,19 @@ bool Paragraph::Pimpl::erase(pos_type po // only allow the actual removal if it was /new/ text if (changetype != Change::INSERTED) { - if (owner_-isInset(pos)) + if (pos size() owner_-isInset(pos)) owner_-getInset(pos)-markErased(true); return false; } } - eraseIntern(pos); - return true; + // Don't physically access nonexistent end-of-paragraph char + if (pos size()) { + eraseIntern(pos); + return true; + } + + return false; } Index:
Re: qt4: remove (2nd) add dialog in add bib tex ref dialog
Juergen Spitzmueller a écrit : Abdelrazak Younes wrote: IMHO, the bibtex dialog should be accessible from the citation dialog. For the matter, I think everything related to citation should be accessible through the citation dialog. And if we have several different bibtext insets (bibtopic)? Good question, I don't know. As I said I am not really a Bibtex user but I feel like some kind of generalisation of the bibliography interface should be done. Abdel.
Re: [patch] rowpainter.C
Martin Vermeer wrote: Here is the cumulative patch, with thanks to Michael Gerz. I haven't compiled this myself yet so you may run into surprises ;-) Some tweaking was necessary to get it to work. Attached is the resulting patch, which seems to work well. I'll post it to bugzilla, so that people can test it in 1.4svn. Jürgen Index: src/paragraph.h === --- src/paragraph.h (Revision 13423) +++ src/paragraph.h (Arbeitskopie) @@ -224,6 +224,9 @@ public: /// set change at pos void setChange(lyx::pos_type pos, Change::Type type); + + /// set full change at pos + void setChangeFull(lyx::pos_type pos, Change change); /// accept change void acceptChange(lyx::pos_type start, lyx::pos_type end); Index: src/paragraph_pimpl.C === --- src/paragraph_pimpl.C (Revision 13423) +++ src/paragraph_pimpl.C (Arbeitskopie) @@ -99,7 +99,7 @@ void Paragraph::Pimpl::trackChanges(Chan lyxerr[Debug::CHANGES] track changes for par id_ type type endl; changes_.reset(new Changes(type)); - changes_-set(type, 0, size()); + changes_-set(type, 0, size() + 1); } @@ -116,7 +116,7 @@ void Paragraph::Pimpl::cleanChanges() return; changes_.reset(new Changes(Change::INSERTED)); - changes_-set(Change::INSERTED, 0, size()); + changes_-set(Change::INSERTED, 0, size() + 1); } @@ -147,6 +147,14 @@ void Paragraph::Pimpl::setChange(pos_typ } +void Paragraph::Pimpl::setChangeFull(pos_type pos, Change change) +{ + if (!tracking()) + return; + + changes_-set(change, pos); +} + Change::Type Paragraph::Pimpl::lookupChange(pos_type pos) const { if (!tracking()) @@ -204,10 +212,14 @@ void Paragraph::Pimpl::acceptChange(pos_ break; case Change::DELETED: -eraseIntern(i); -changes_-erase(i); ---end; ---i; +// Suppress access to nonexistent +// end-of-paragraph char: +if (i size()) { + eraseIntern(i); + changes_-erase(i); + --end; + --i; +} break; } } @@ -235,15 +247,18 @@ void Paragraph::Pimpl::rejectChange(pos_ break; case Change::INSERTED: -eraseIntern(i); -changes_-erase(i); ---end; ---i; +if (i size()) { + eraseIntern(i); + changes_-erase(i); + --end; + --i; +} break; case Change::DELETED: changes_-set(Change::UNCHANGED, i); -if (owner_-isInset(i)) +// No real char at position size(): +if (i size() owner_-isInset(i)) owner_-getInset(i)-markErased(false); break; } @@ -351,7 +366,7 @@ void Paragraph::Pimpl::eraseIntern(pos_t bool Paragraph::Pimpl::erase(pos_type pos) { - BOOST_ASSERT(pos size()); + BOOST_ASSERT(pos = size()); if (tracking()) { Change::Type changetype(changes_-lookup(pos)); @@ -359,14 +374,19 @@ bool Paragraph::Pimpl::erase(pos_type po // only allow the actual removal if it was /new/ text if (changetype != Change::INSERTED) { - if (owner_-isInset(pos)) + if (pos size() owner_-isInset(pos)) owner_-getInset(pos)-markErased(true); return false; } } - eraseIntern(pos); - return true; + // Don't physically access nonexistent end-of-paragraph char + if (pos size()) { + eraseIntern(pos); + return true; + } + + return false; } Index: src/CutAndPaste.C === --- src/CutAndPaste.C (Revision 13423) +++ src/CutAndPaste.C (Arbeitskopie) @@ -234,7 +234,8 @@ pasteSelectionHelper(Buffer const buff pit = last_paste; pos = pars[last_paste].size(); - // Maybe some pasting. + // Join (conditionally) last pasted paragraph with next one, i.e., + // the tail of the spliced document paragraph if (!empty last_paste + 1 != pit_type(pars.size())) { if (pars[last_paste + 1].hasSameLayout(pars[last_paste])) { mergeParagraph(buffer.params(), pars, last_paste); @@ -271,64 +272,35 @@ PitPosPair eraseSelectionHelper(BufferPa return PitPosPair(endpit, endpos); } - bool all_erased = true; - -// Clear fragments of the first par in selection - pars[startpit].erase(startpos, pars[startpit].size()); - if (pars[startpit].size() != startpos) - all_erased = false; - -// Clear fragments of the last par in selection - endpos -= pars[endpit].erase(0, endpos); - if (endpos != 0) - all_erased = false; - -// Erase all the middle paragraphs. - if (params.tracking_changes) { - // Look through the deleted pars if any, erasing as needed - for (pit_type pit = startpit + 1; pit != endpit;) { - // erase the contents of the par - pars[pit].erase(0, pars[pit].size()); - if (pars[pit].empty()) { -// remove the par if it's now empty -pars.erase(pars.begin() + pit); ---endpit; - } else { -++pit; -all_erased = false; - } - } - } else { - pars.erase(pars.begin() + startpit + 1, pars.begin() + endpit); - endpit = startpit + 1; - } - -#if 0 // FIXME: why for cut
[Patch] raise/lower selected super/sub -scripts in math
This is a regression from 1.3. It should be possible, both with ^ _ keys and with the math panel (and directly with the commands math-superscript and math-subscript), to raise the selection to a superscript or lower it to a subscript. Works in 1.3.7. At the same time we get rid of The Abominable LCursor::paste() Method. Will go into trunk later if nobody spots a problem. - Martin Index: cursor.C === --- cursor.C(revision 13408) +++ cursor.C(working copy) @@ -379,15 +379,6 @@ void LCursor::getPos(int x, int y) c } -// Don't use this routine. It is erroneous: LFUN_PASTE should be called with -// buffer number, not data to be inserted -- MV 26.02.2006 -void LCursor::paste(string const data) -{ - if (!data.empty()) - dispatch(FuncRequest(LFUN_PASTE, data)); -} - - void LCursor::resetAnchor() { anchor_ = *this; Index: mathed/math_nestinset.C === --- mathed/math_nestinset.C (revision 13408) +++ mathed/math_nestinset.C (working copy) @@ -685,9 +685,13 @@ void MathNestInset::doDispatch(LCursor cur.posLeft(); cur.pushLeft(*cur.nextInset()); } - } else if (!interpret(cur, cmd.argument[0])) { - cmd = FuncRequest(LFUN_FINISHED_RIGHT); - cur.undispatched(); + } else { + // single character, e.g. ^ or _ + safe_ = grabAndEraseSelection(cur); + if (!interpret(cur, cmd.argument[0])) { + cmd = FuncRequest(LFUN_FINISHED_RIGHT); + cur.undispatched(); + } } break; @@ -868,13 +872,16 @@ void MathNestInset::doDispatch(LCursor case LFUN_SUBSCRIPT: // interpret this as if a _ was typed + // E.g., called from minibuffer (math-subscript) recordUndo(cur, Undo::ATOMIC); + safe_ = grabAndEraseSelection(cur); interpret(cur, '_'); break; case LFUN_SUPERSCRIPT: // interpret this as if a ^ was typed recordUndo(cur, Undo::ATOMIC); + safe_ = grabAndEraseSelection(cur); interpret(cur, '^'); break; @@ -882,13 +889,12 @@ void MathNestInset::doDispatch(LCursor // handling such that self-insert works on arbitrary stuff too, and // math-insert only handles special math things like matrix. case LFUN_INSERT_MATH: { + safe_ = grabAndEraseSelection(cur); recordUndo(cur, Undo::ATOMIC); - MathArray ar; - asArray(cmd.argument, ar); - int cell(0); - if (cmd.argument == \\root) - cell = 1; - cur.niceInsert(cmd.argument); + if (cmd.argument.size() == 1) + interpret(cur, cmd.argument[0]); + else + cur.niceInsert(cmd.argument); break; } @@ -1246,7 +1252,6 @@ bool MathNestInset::script(LCursor cur } cur.macroModeClose(); - string safe = grabAndEraseSelection(cur); if (asScriptInset() cur.idx() == 0) { // we are in a nucleus of a script inset, move to _our_ script MathScriptInset * inset = asScriptInset(); @@ -1277,9 +1282,9 @@ bool MathNestInset::script(LCursor cur cur.idx() = 1; cur.pos() = 0; } - //lyxerr pasting 1: safe:\n safe endl; - cur.paste(safe); + //lyxerr pasting 1: safe:\n safe_ endl; + cur.niceInsert(safe_); cur.resetAnchor(); - //lyxerr pasting 2: safe:\n safe endl; + //lyxerr pasting 2: safe:\n safe_ endl; return true; } pgpM0IeScFCFh.pgp Description: PGP signature
Please Add Document Classes for AMS + NoWeb
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hell, LyX Team! First, thanks so much for a great tool! I'm finding some rough edges in 1.4.0 on Mac OS X and have filed bug reports on BugZilla, but now I have a feature request. It would be very nice if LyX provided document classes that combined AMS support and NoWeb support. I'm using LyX to work through Benjamin Pierce's Types and Programming Languages, and the AMS support is great for typesetting all of the type theory material, but I'd also like to use the NoWeb support to actually put my code for the exercises in the document as well. Of course, in the short term, some idea as to how to do that with LyX 1.4.0 as-is would be handy as well. Many thanks and best regards, Paul Snively -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iEYEARECAAYFAkQduaYACgkQS6yIxITC5OrHmgCfXK+AbHFh2n++JH9+4nsd/WcY CYUAnA+eZOMp3wNCITasRUQpnmg7Bt2V =Byah -END PGP SIGNATURE-
Re: [Patch] raise/lower selected super/sub -scripts in math
On Sun, Mar 19, 2006 at 09:42:09PM +0200, Martin Vermeer wrote: This is a regression from 1.3. It should be possible, both with ^ _ keys and with the math panel (and directly with the commands math-superscript and math-subscript), to raise the selection to a superscript or lower it to a subscript. Works in 1.3.7. At the same time we get rid of The Abominable LCursor::paste() Method. Will go into trunk later if nobody spots a problem. - Martin Sorry, file mising. New patch attached. - Martin Index: cursor.C === --- cursor.C(revision 13408) +++ cursor.C(working copy) @@ -379,15 +379,6 @@ void LCursor::getPos(int x, int y) c } -// Don't use this routine. It is erroneous: LFUN_PASTE should be called with -// buffer number, not data to be inserted -- MV 26.02.2006 -void LCursor::paste(string const data) -{ - if (!data.empty()) - dispatch(FuncRequest(LFUN_PASTE, data)); -} - - void LCursor::resetAnchor() { anchor_ = *this; Index: mathed/math_nestinset.C === --- mathed/math_nestinset.C (revision 13408) +++ mathed/math_nestinset.C (working copy) @@ -685,9 +685,13 @@ void MathNestInset::doDispatch(LCursor cur.posLeft(); cur.pushLeft(*cur.nextInset()); } - } else if (!interpret(cur, cmd.argument[0])) { - cmd = FuncRequest(LFUN_FINISHED_RIGHT); - cur.undispatched(); + } else { + // single character, e.g. ^ or _ + safe_ = grabAndEraseSelection(cur); + if (!interpret(cur, cmd.argument[0])) { + cmd = FuncRequest(LFUN_FINISHED_RIGHT); + cur.undispatched(); + } } break; @@ -868,13 +872,16 @@ void MathNestInset::doDispatch(LCursor case LFUN_SUBSCRIPT: // interpret this as if a _ was typed + // E.g., called from minibuffer (math-subscript) recordUndo(cur, Undo::ATOMIC); + safe_ = grabAndEraseSelection(cur); interpret(cur, '_'); break; case LFUN_SUPERSCRIPT: // interpret this as if a ^ was typed recordUndo(cur, Undo::ATOMIC); + safe_ = grabAndEraseSelection(cur); interpret(cur, '^'); break; @@ -882,13 +889,12 @@ void MathNestInset::doDispatch(LCursor // handling such that self-insert works on arbitrary stuff too, and // math-insert only handles special math things like matrix. case LFUN_INSERT_MATH: { + safe_ = grabAndEraseSelection(cur); recordUndo(cur, Undo::ATOMIC); - MathArray ar; - asArray(cmd.argument, ar); - int cell(0); - if (cmd.argument == \\root) - cell = 1; - cur.niceInsert(cmd.argument); + if (cmd.argument.size() == 1) + interpret(cur, cmd.argument[0]); + else + cur.niceInsert(cmd.argument); break; } @@ -1246,7 +1252,6 @@ bool MathNestInset::script(LCursor cur } cur.macroModeClose(); - string safe = grabAndEraseSelection(cur); if (asScriptInset() cur.idx() == 0) { // we are in a nucleus of a script inset, move to _our_ script MathScriptInset * inset = asScriptInset(); @@ -1277,9 +1282,9 @@ bool MathNestInset::script(LCursor cur cur.idx() = 1; cur.pos() = 0; } - //lyxerr pasting 1: safe:\n safe endl; - cur.paste(safe); + //lyxerr pasting 1: safe:\n safe_ endl; + cur.niceInsert(safe_); cur.resetAnchor(); - //lyxerr pasting 2: safe:\n safe endl; + //lyxerr pasting 2: safe:\n safe_ endl; return true; } Index: mathed/math_nestinset.h === --- mathed/math_nestinset.h (revision 13408) +++ mathed/math_nestinset.h (working copy) @@ -128,6 +128,8 @@ protected: cells_type cells_; /// if the inset is locked, it can't be entered with the cursor bool lock_; + /// + std::string safe_; }; #endif pgphyXawIBA95.pgp Description: PGP signature
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Abdelrazak Younes a écrit : Enrico Forestieri a écrit : Abdelrazak Younes [EMAIL PROTECTED] writes: This is interesting. I'll try to compile for a mingw target without the -mms-bitfield switch and see what happens... I bet nothing I have tried that in the past but did not succeed (compiling from cygwin a mingw target). The resulting executable never worked. This was related to some ld problems IIRC. I hope you'll have more success. Strange, I do that all the time without any problem. Perhaps this is due to the fact that I also compile Qt using -mno-cygwin but following the exact procedure as if I was directly using the mingw compiler. This requires patching the Qt sources, but that should be done only for once. I am developing for Qt4 and for me patching it is out of the question. I will try again when I have some time. Success! I managed to compile everything (qt4) without MSYS. There two small problem though: 1) I have to use -sysdir option because the generated executable look for an inexistant directory: $ ./lyx-qt4 Unable to determine the system directory having searched d:/msys/home/yns/lyx/trunk/share/lyx-svn/ Try the '-sysdir' command line parameter or set the environment variable LYX_DIR_14x to the LyX system directory containing the file `chkconfig.ltx'. 2) I had to hack the source code in order to replace '/tmp' with 'c:/temp' because lyx tells me it cannot write the '/tmp' directory. Except for that I am happy to report that I cannot see any difference with the lyx I generated within MSYS. Except that the executable is smaller (12Mo instead of 19Mo) and that the compilation is faster. Enrico, if you have any hint for the problems above... Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Michael Gerz [EMAIL PROTECTED] writes: Enrico Forestieri wrote: Then why not compiling libiconv with mingw, too? It is quite strightforward to do. As regards gettext, if you configure with --with-included-gettext, it will be compiled alongside LyX. Then why not keeping the option? Why all the trouble? I am neither against nor pro it. I have tried compiling LyX with and without it, and it seems to make no difference for me. However, Abdel found that it hurts him. Given that it is simpler adding it to CPPFLAGS if it is needed than getting rid of it if it hurts, I think that the most logical thing to do is not enforcing it. I am fine with whatever resolution. -- Enrico
LyX 1.4.1 pre1
With the help of the attached patch, I have built and uploaded a snapshot of the 1.4.x branch to: http://wiki.lyx.org/uploads/Windows/LyX141pre/lyx-1.4.1-pre_win32_setup_v1.exe Jean-Marc, could you apply the patch please? (I have been unable to create a writable subversion repository on Windows; something to do with my firewall, I think.) I built against Aspell 0.6 and the latest and greatest snapshot of Qt/Win Free. I configured --with-version-suffix='1.4.x' prefix, but after local installation in the installprefix directory, I manually changed the names of the executables in the bin directory to lyx.exe and tex2lyx.exe. I did this so that the lyx.bat generated by the installer would work as expected. Here, I have the thing installed at J:\Program Files\LyX14x. User-level support files are to be found in C:\Documents and Settings\Angus\Application Data\LyX1.4.x. I continue to be able to use LyX 1.3.7. Everything seems to work... Would interested parties please try this out? If it proves to work as advertised I'll put together a page on the wiki and we can advertise more widely. Regards, Angus Index: boost/libs/filesystem/src/operations_posix_windows.cpp === --- boost/libs/filesystem/src/operations_posix_windows.cpp (revision 13423) +++ boost/libs/filesystem/src/operations_posix_windows.cpp (working copy) @@ -73,7 +73,7 @@ // if WINVER 0x04A. # include w32api.h # if __W32API_MAJOR_VERSION 3 || \ - __W32API_MAJOR_VERSION == 3 __W32API_MINOR_VERSION = 3 + __W32API_MAJOR_VERSION == 3 __W32API_MINOR_VERSION = 6 # define BOOST_FILESYSTEM_WINVER WINVER # undef WINVER # define WINVER 0x040A Index: development/Win32/packaging/build_lyxwin.sh === --- development/Win32/packaging/build_lyxwin.sh (revision 13423) +++ development/Win32/packaging/build_lyxwin.sh (working copy) @@ -170,7 +170,7 @@ Error Unable to create build dir, ${BUILDDIR}. } - CONFIGURE=../configure --without-x --with-included-gettext --with-extra-prefix='${LYX_ASPELL_DIR}' --with-frontend=qt QTDIR='$QT_DIR' --disable-maintainer-mode --disable-debug --enable-optimization --disable-pch --disable-concept-checks --disable-stdlib-debug + CONFIGURE=../configure --with-version-suffix='1.4.x' --without-x --with-included-gettext --with-extra-prefix='${LYX_ASPELL_DIR}' --with-frontend=qt QTDIR='$QT_DIR' --disable-maintainer-mode --disable-debug --enable-optimization --disable-pch --disable-concept-checks --disable-stdlib-debug echo ${CONFIGURE} cd ${BUILDDIR} Index: development/Win32/packaging/installer/lyx_installer.nsi === --- development/Win32/packaging/installer/lyx_installer.nsi (revision 13423) +++ development/Win32/packaging/installer/lyx_installer.nsi (working copy) @@ -20,7 +20,7 @@ CRCCheck force ; Make the installer as small as possible. -SetCompressor lzma +SetCompressor /SOLID lzma ; ; You should need to change only these macros...
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Enrico Forestieri wrote: Michael Gerz [EMAIL PROTECTED] writes: Enrico Forestieri wrote: Then why not compiling libiconv with mingw, too? It is quite strightforward to do. As regards gettext, if you configure with --with-included-gettext, it will be compiled alongside LyX. Then why not keeping the option? Why all the trouble? I am neither against nor pro it. I have tried compiling LyX with and without it, and it seems to make no difference for me. However, Abdel found that it hurts him. Given that it is simpler adding it to CPPFLAGS if it is needed than getting rid of it if it hurts, I think that the most logical thing to do is not enforcing it. I am fine with whatever resolution. Enrico, Using MSYS, I have built the libiconv package suggested by Michael and then gone on to build LyX using --with-included-gettext. configure finds libiconv and the build proceeds happily, but I find that the resulting .exe is unable to change the installed .po (.gmo) dynamically to the local locale. If I understood your message of some time ago correctly, you reported that your essentially-identical cygwin build was able to display a Polish LyX with native Windows LANG. When I read the libiconv/gettext build docs, it seems that the build process is essentially circular. First build gettext, then libiconv, then gettext again. (Or start with libiconv, then gettext, then libiconv again.) So, I suspect that my build doesn't work as advertised because my build is incomplete. Before I invest time and effort into trying out my theory, can you explain in more detail just what you did to get this stuff working? Regards, Angus
LyX/Win 1.4.1 pre1
Changing subject for advertising reasons... Angus
Re: LyX/Win 1.4.1 pre1
Angus Leeming [EMAIL PROTECTED] writes: | Changing subject for advertising reasons... Ok, where is the tar.gz? If this is only a Win test build of 1.4.xSVN then say so. -- Lgb
Re: LyX/Win 1.4.1 pre1
Lars Gullik Bjønnes wrote: Angus Leeming writes: | Changing subject for advertising reasons... Ok, where is the tar.gz? If this is only a Win test build of 1.4.xSVN then say so. ??? I think you need to get some rest ;-P The start of the original post: With the help of the attached patch, I have built and uploaded a snapshot of the 1.4.x branch to: http://wiki.lyx.org/uploads/Windows/LyX141pre/lyx-1.4.1-pre_win32_setup_v1.exe Good night. Angus
Re: LyX/Win 1.4.1 pre1
Angus Leeming [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: | Angus Leeming writes: | | Changing subject for advertising reasons... | | Ok, where is the tar.gz? | If this is only a Win test build of 1.4.xSVN then say so. | | ??? I think you need to get some rest ;-P | | The start of the original post: And now go read the subject. And you lost all the messges from the original post when you changed the subject in the followup. -- Lgb
Re: Problem compiling Lyx 1.4. svn
Charles de Miramon [EMAIL PROTECTED] writes: | Hello, | | I'm trying to compile from svn to check if bug #2379 is corrected. | | 1) I've checked the code with : | svn co svn://svn.lyx.org/lyx/lyx-devel/trunk lyx-devel | | I guess, I have downloaded the future 1.4.1 1.5 actually. If you want the base for 1.4.x you have to get svn://svn.lyx.org/lyx/lyx-devel/branches/BRANCH_1_4_X/ | 2) I've configured with : | ./configure --with-version-suffix=-svn --with-frontend=qt | --with-qt-dir=/usr/share/qt3 | | 3) After a while, Make stops during the compilation of 'libsupport.a' | I attach the last lines of the compilation log There is a problem with some distributions releases of gcc. I think you have one of those. Is it a gcc 4.0.3 pre-release? -- Lgb
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Abdelrazak Younes [EMAIL PROTECTED] writes: Success! I managed to compile everything (qt4) without MSYS. There two small problem though: 1) I have to use -sysdir option because the generated executable look for an inexistant directory: $ ./lyx-qt4 Unable to determine the system directory having searched d:/msys/home/yns/lyx/trunk/share/lyx-svn/ Try the '-sysdir' command line parameter or set the environment variable LYX_DIR_14x to the LyX system directory containing the file `chkconfig.ltx'. That also happened to me once, when I tried running LyX in place. However, after installation I had no problems. If I remember correctly, it was immediately after the switch from ...\Resources\lyx to ...\Resources so, perhaps this is the case with you, too. If not, see below. I don't see this problem anymore, so may be it was due to not updated configuration files. 2) I had to hack the source code in order to replace '/tmp' with 'c:/temp' because lyx tells me it cannot write the '/tmp' directory. Except for that I am happy to report that I cannot see any difference with the lyx I generated within MSYS. Except that the executable is smaller (12Mo instead of 19Mo) and that the compilation is faster. This may simply be due to the fact that mingw executables are to be stripped. I don't see any significant difference in size between a mingw and a cygwin LyX. Enrico, if you have any hint for the problems above... Well, if '/tmp' is present in the source code, this is a bug with a native LyX and you have no choice but replacing it with a proper path, probably protecting the change using an #ifdef. But it may be a configuration problem. All cygwin tools use posix syntax by default, so care must be taken when generating Makefiles if they are meant for building a native version of LyX. For example, when invoking 'configure', you should use --prefix=C:/Programs/LyX instead of --prefix=/c/Programs/LyX, but it is safe using --with-extra-prefix=/c/MinGW. Another problem can arise when a path is autogenerated by configure. There is some code in the configure script that turns 'C:/Programs/LyX' into '/c/Programs/LyX' (or '/cygdrive/c/Programs/LyX', depending on your settings), so I had to add the following to the sed command I use for modifying configure: # Set locale and data dir in mixed rather than posix format /^ *LYX_ABS_INSTALLED/s/\(^ *\)/\1ac_val=`cygpath -m \\$ac_val\`\n\1/ otherwise I get '/c/Programs/LyX/Resources/locale' hardcoded into the executable instead of 'C:/Programs/LyX/Resources/locale', and the net effect would be that setting LANG to some locale doesn't work. Thinking about it, perhaps this is the reason (hardcoded path) why Angus reports that setting LANG seems not working in mingw builds. However, this is the only problem that I spotted. To be honest there was another one, but it was about the recognition of a multi-threaded Qt. For some reason the default test program used in configure: int main () { QApplication a(0,0); a.unlock(); ; return 0; } fails compilation and a multi-threaded Qt would be not recognized as such. I had to modify that program in the following way: int main () { int argc; char **argv = NULL; QApplication a(argc,argv); a.unlock(); ; return 0; } for the test to be successful in the case Qt is multi-threaded. I think that's all. The native LyX I compile using cygwin is fully functional and until now I have seen no side effects. -- Enrico
Re: LyX/Win 1.4.1 pre1
Just tried the new installer. The configure script didn't find my PDF and PS viewers, even after adding the paths to \path_prefix in lyxrc.defaults. C:\Program Files\Adobe\Acrobat 7.0\Reader\AcroRd32.exe c:\Program Files\GSview\gsview\gsview32.exe I can set the viewers manually but shouldn't the script find them? Thanks, Paul
[Ãpatch] RandomAccessList take 4
Ok, this is what I am going to commit. I am not really happy with the fact that RandomListIterator really is a std::list::iterator. I'd like it to be a real random_access_iterator. We should probably create our own. (And no; I don't agree that we should only work with offsets and indices, iterators are nice and we should use them.) This works for me. [[ * output_latex.h: * buffer.h: * CutAndPaste.h: * pariterator.h: * paragraph_funcs.h: * output_linuxdoc.h: * output_docbook.h: * insets/insettext.h: get forward declaration of ParagraphList * output_plaintext.C: * bufferlist.C: * undo.C: * lyxtext.h: * undo.h: * buffer_funcs.C: * insets/insetbibitem.C: get proper ParagraphList decls * output_linuxdoc.C (linuxdocParagraphs): * output_latex.C (TeXOnePar): * insets/insettext.C (appendParagraphs): * insets/insetcharstyle.C (docbook): use std::distance * CutAndPaste.C (pasteSelectionHelper, copySelectionHelper): * paragraph_funcs.C (breakParagraph, breakParagraphConservative, mergeParagraph): * text.C (acceptChange, rejectChange): * text2.C (deleteEmptyParagraphMechanism): use boost::next * output_docbook.C (several places): use boost::next and std::distance * ParagraphList_fwd.h: modify to provid a forward declaratoin of the new ParagraphList. * RandomAccessList.h: New container for Paragraphs from Abdelrazak Younes * ParagraphList.h: new file, setup user of RandomAccessList * paragraph.C: remove ParagraphList constructor from this file ]] Index: src/insets/insettext.h === --- src/insets/insettext.h (revision 13423) +++ src/insets/insettext.h (working copy) @@ -16,6 +16,7 @@ #include RowList_fwd.h #include lyxfont.h #include lyxtext.h +#include ParagraphList_fwd.h #include support/types.h @@ -27,7 +28,6 @@ class CursorSlice; class Dimension; class LColor_color; -class ParagraphList; /** Index: src/insets/insetbibitem.C === --- src/insets/insetbibitem.C (revision 13423) +++ src/insets/insetbibitem.C (working copy) @@ -19,7 +19,7 @@ #include lyxfont.h #include lyxlex.h #include paragraph.h -#include ParagraphList_fwd.h +#include ParagraphList.h #include frontends/font_metrics.h Index: src/insets/insetcharstyle.C === --- src/insets/insetcharstyle.C (revision 13423) +++ src/insets/insetcharstyle.C (working copy) @@ -289,6 +289,7 @@ int InsetCharStyle::docbook(Buffer const buf, ostream os, OutputParams const runparams) const { + ParagraphList::const_iterator beg = paragraphs().begin(); ParagraphList::const_iterator par = paragraphs().begin(); ParagraphList::const_iterator end = paragraphs().end(); @@ -298,7 +299,7 @@ for (; par != end; ++par) { par-simpleDocBookOnePar(buf, os, runparams, - outerFont(par - paragraphs().begin(), + outerFont(std::distance(beg, par), paragraphs())); } Index: src/insets/insettext.C === --- src/insets/insettext.C (revision 13423) +++ src/insets/insettext.C (working copy) @@ -422,7 +422,8 @@ ParagraphList::iterator pit = plist.begin(); ParagraphList::iterator ins = pl.insert(pl.end(), *pit); ++pit; - mergeParagraph(buffer-params(), pl, ins - pl.begin() - 1); + mergeParagraph(buffer-params(), pl, + std::distance(pl.begin(), ins) - 1); for_each(pit, plist.end(), bind(ParagraphList::push_back, ref(pl), _1)); Index: src/output_plaintext.C === --- src/output_plaintext.C (revision 13423) +++ src/output_plaintext.C (working copy) @@ -19,7 +19,7 @@ #include output.h #include outputparams.h #include paragraph.h -#include ParagraphList_fwd.h +#include ParagraphList.h #include ParagraphParameters.h #include support/lstrings.h Index: src/output_latex.h === --- src/output_latex.h (revision 13423) +++ src/output_latex.h (working copy) @@ -12,11 +12,12 @@ #ifndef OUTPUT_LATEX_H #define OUTPUT_LATEX_H +#include ParagraphList_fwd.h + #include string class Buffer; class OutputParams; -class ParagraphList; class TexRow; /// Just a wrapper for the method below, first creating the ofstream. Index: src/bufferlist.C === --- src/bufferlist.C (revision 13423) +++ src/bufferlist.C (working copy) @@ -22,7 +22,7 @@ #include lyx_main.h #include output_latex.h #include paragraph.h -#include ParagraphList_fwd.h +#include ParagraphList.h #include frontends/Alert.h
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Angus Leeming [EMAIL PROTECTED] writes: Enrico, Using MSYS, I have built the libiconv package suggested by Michael and then gone on to build LyX using --with-included-gettext. configure finds libiconv and the build proceeds happily, but I find that the resulting .exe is unable to change the installed .po (.gmo) dynamically to the local locale. If I understood your message of some time ago correctly, you reported that your essentially-identical cygwin build was able to display a Polish LyX with native Windows LANG. When I read the libiconv/gettext build docs, it seems that the build process is essentially circular. First build gettext, then libiconv, then gettext again. (Or start with libiconv, then gettext, then libiconv again.) So, I suspect that my build doesn't work as advertised because my build is incomplete. Before I invest time and effort into trying out my theory, can you explain in more detail just what you did to get this stuff working? Angus, I suspect that this is an hardcoded path problem. The configure script sets LYX_ABS_INSTALLED_LOCALEDIR to the directory $prefix/Resources/locale and then this directory is hardcoded into the executable. So, if LyX is installed in a different place than the $prefix dir, it will be unable to find the files. I don't know how this can be cleanly solved. I can think of two solutions. The first one is rather dirty: hack the configure script such that LYX_ABS_INSTALLED_LOCALEDIR is set to a PATH_MAX long string and then at installation time overwrite the string in the LyX executable with the proper path (other than dirty, this may also be fragile). The second one is the following. You already have an hardcoded path C:/Aspell, so you could change that to C:/LyXsupport and put there both aspell and locale files. A third possibility is investigating wheter libiconv/gettext support dynamic relocation. A fourth possibility is switching to cygwin and forget all those problems, but I suspect that this is not an option ;-) But, wait a moment... what about hacking configure such that LYX_ABS_INSTALLED_LOCALEDIR is a relative path? Uhm... perhaps that is not possible to do, I mean that perhaps it has to be an absolute path. -- Enrico
Re: LyX/Win 1.4.1 pre1
Paul [EMAIL PROTECTED] writes: Just tried the new installer. The configure script didn't find my PDF and PS viewers, even after adding the paths to \path_prefix in lyxrc.defaults. Never mind, I got it to work. I modified the wrong file (needed to change configure).
LyX/Win 1.4.1 pre1
Works good! I have only one entry for LyX under Add/Remove programs. Perhaps it would be better to have separate uninstalls for LyX137, LyX14x? I was able to change my viewers by modifying the File format-Viewer field. Path prefix was generated properly though I use paths without spaces. The Users will be pleased! Stephen
Minor problem with sciword.bind
When I use sciword.bind, LyX: BN_BIND: Unknown LyX function `find-replace' [around line 165 of file /usr/local/share/lyx/bind/sciword.bind] Cheers, Bo
Re: [Patch] raise/lower selected super/sub -scripts in math
Martin Vermeer wrote: This is a regression from 1.3. It should be possible, both with ^ _ keys and with the math panel (and directly with the commands math-superscript and math-subscript), to raise the selection to a superscript or lower it to a subscript. Works in 1.3.7. Does this fix bug 2345? Jürgen
Re: [Patch] raise/lower selected super/sub -scripts in math
On Sun, 2006-03-19 at 22:12 +0200, Martin Vermeer wrote: On Sun, Mar 19, 2006 at 09:42:09PM +0200, Martin Vermeer wrote: This is a regression from 1.3. It should be possible, both with ^ _ keys and with the math panel (and directly with the commands math-superscript and math-subscript), to raise the selection to a superscript or lower it to a subscript. Works in 1.3.7. At the same time we get rid of The Abominable LCursor::paste() Method. Will go into trunk later if nobody spots a problem. - Martin Sorry, file mising. New patch attached. Bit more polished version attached. This one goes in. Log message: Get raising/lowering into super/subscripts of selection working (1.3 regression) * cursor.C: get rid of paste() * mathed/math_nestinset.C (MathNestInset::doDispatch): (MathNestInset::lfunMouseRelease): define safe_ (selection) in several places (MathNestInset::script): use data member safe_ to insert selection * mathed/math_nestinset.h: data member safe_ - Martin signature.asc Description: This is a digitally signed message part
Re: [Patch] raise/lower selected super/sub -scripts in math
On Mon, 2006-03-20 at 07:49 +0100, Juergen Spitzmueller wrote: Martin Vermeer wrote: This is a regression from 1.3. It should be possible, both with ^ _ keys and with the math panel (and directly with the commands math-superscript and math-subscript), to raise the selection to a superscript or lower it to a subscript. Works in 1.3.7. Does this fix bug 2345? No...should it? Looks completely unrelated to me. - Martin signature.asc Description: This is a digitally signed message part
Re: [Patch] raise/lower selected super/sub -scripts in math
On Mon, 2006-03-20 at 09:41 +0200, Martin Vermeer wrote: On Mon, 2006-03-20 at 07:49 +0100, Juergen Spitzmueller wrote: Martin Vermeer wrote: This is a regression from 1.3. It should be possible, both with ^ _ keys and with the math panel (and directly with the commands math-superscript and math-subscript), to raise the selection to a superscript or lower it to a subscript. Works in 1.3.7. Does this fix bug 2345? No...should it? Looks completely unrelated to me. ... but the same trick works here too, see patch. Great intuition, thanks! - Martin Index: math_nestinset.C === --- math_nestinset.C (revision 13424) +++ math_nestinset.C (working copy) @@ -798,11 +798,13 @@ void MathNestInset::doDispatch(LCursor if (currentMode() == InsetBase::MATH_MODE cmd.argument == on) break; cur.macroModeClose(); + safe_ = grabAndEraseSelection(cur); selClearOrDel(cur); //cur.plainInsert(MathAtom(new MathMBoxInset(cur.bv(; cur.plainInsert(MathAtom(new MathBoxInset(mbox))); cur.posLeft(); cur.pushLeft(*cur.nextInset()); + cur.niceInsert(safe_); #else if (currentMode() == InsetBase::TEXT_MODE) { cur.niceInsert(MathAtom(new MathHullInset(simple))); signature.asc Description: This is a digitally signed message part
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Am Samstag, 18. März 2006 18:13 schrieb Enrico Forestieri: > Georg Baum <[EMAIL PROTECTED]> writes: > I had to compile every library I needed for building LyX, and it > turned out that I only needed Qt, aspell, and libiconv. Nothing more. Ah, that information was missing until now. > So, given that those libraries don't use -mms-bitfields, I think it is > safe avoiding it. Moreover, if those libraries don't use -mms-bitfields > and you enforce it, problems arise (see Abdel case). I agree. If these libraries don't use -mms-bitfield then LyX must not use it either. I had a look at the qt3 port for windows, and it does not use it either in the default configuration for mingw and cygwin. So even if we wanted to use other libraries that would require the switch we cannot do so because qt3 does not use it. Those who compile qt3 with nonstandard settings know what they are doing anyway and can still add the flag by hand. I am therefore committing the attached patch. Georg Log: Remove -mms-bitfields compiler option on windows, since all qt releases that we support with the gcc toolchain on windows are compiled without it. Index: config/cygwin.m4 === --- config/cygwin.m4 (Revision 13418) +++ config/cygwin.m4 (Arbeitskopie) @@ -5,35 +5,6 @@ AC_DEFUN([CHECK_WITH_CYGWIN], [ case $host_os in cygwin* | mingw* | pw32* ) -if test "$GCC" = yes; then - # Ensure MSVC-compatible struct packing convention. - # Depends on GCC version. gcc2 uses -fnative-struct while - # gcc3 uses -mms-bitfields. - # - msnative_struct='' - AC_MSG_CHECKING([how to get MSVC-compatible struct packing]) - case `$CC --version | sed -e 's,\..*,.,' -e q` in - 2.) -if $CC -v --help 2>/dev/null | grep fnative-struct > /dev/null; then -msnative_struct='-fnative-struct' -fi -;; - *) -if $CC -v --help 2>/dev/null | grep ms-bitfields > /dev/null; then -msnative_struct='-mms-bitfields' -fi -;; - esac - - if test x"$msnative_struct" = x; then -AC_MSG_RESULT([no way]) -AC_MSG_WARN([produced libraries might be incompatible with MSVC libs]) - else -CXXFLAGS="$CXXFLAGS $msnative_struct" -AC_MSG_RESULT([${msnative_struct}]) - fi -fi - # Export all symbols to Win32 DLL using MinGW 2.0 ld. WIN32_LD_EXPORT_ALL_SYMBOLS='' AC_MSG_CHECKING([whether ld accepts --export-all-symbols])
Re: r13417 - /lyx-devel/trunk/configure.ac
[EMAIL PROTECTED] wrote: Author: baum Date: Sat Mar 18 17:14:31 2006 New Revision: 13417 Log: fix lib/configure.py invocation for builddir != srcdir (create the lib directorty if it does not exist before running the script) Modified: lyx-devel/trunk/configure.ac Another 1.4.X candidate??? Michael
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Enrico Forestieri wrote: Then why not compiling libiconv with mingw, too? It is quite strightforward to do. As regards gettext, if you configure with --with-included-gettext, it will be compiled alongside LyX. Then why not keeping the option? Why all the trouble? Michael
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Abdelrazak Younes wrote: I forgot about that. Are we linking with libiconv or just using iconv.exe? Same question for gettext. https://sourceforge.net/project/shownotes.php?release_id=389183 Says that the lib is compiled with mingw so this should not be a problem. This is not the libiconv version that Angus and I are using! Please be careful with what you are doing! I really need this option to be removed for the qt4 frontend when compiled with mingw. Why? Michael
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Michael Gerz wrote: This is not the libiconv version that Angus and I are using! Please be careful with what you are doing! Ok, I see that the flag has been removed already. I will check my installation guide before I continue complaining... Michael
Re: r13417 - /lyx-devel/trunk/configure.ac
Am Sonntag, 19. März 2006 09:52 schrieb Michael Gerz: > Another 1.4.X candidate??? No. configure.py is only used in 1.5. Georg
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Am Sonntag, 19. März 2006 10:00 schrieb Michael Gerz: > This is not the libiconv version that Angus and I are using! Please be > careful with what you are doing! We are. LyX must be compiled without -mms-bitfields, since the qt4 Open Source edition available from trolltech is compiled without it, and the default configuration of the Q..3/Windows Free Edition does not use this switch either. Therefore you and Angus have no choice and must use a libiconv that is compatible to this setting, too. The only possibility to use a libiconv that requires -mms-bitfields is to set this switch by hand when compiling qt yourself. In this case you can (and have to) set it by hand for LyX, too. If you know a way to detect the -mms-bitfields setting of qt automatically then I'll be happy to put code to do that in cygwin.m4. > > I really need this option to be removed for the qt4 frontend when > > compiled with mingw. > > Why? Because of crashes. Please read the whole thread. This has been discussed extensively. Georg
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Georg Baum wrote: Because of crashes. Please read the whole thread. This has been discussed extensively. Funny. It means that I should have experienced crashes all the time. I wonder why I haven't... Very strange... I will look for a bullet-proof compilation instruction. Michael
Re: qt4: remove (2nd) add dialog in add bib tex ref dialog
Abdelrazak Younes wrote: > IMHO, the bibtex dialog should be accessible from the citation dialog. > For the matter, I think everything related to citation should be > accessible through the citation dialog. And if we have several different bibtext insets (bibtopic)? Jürgen
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Jean-Marc Lasgouttes wrote: There are no speedups yet. I thought we would have really bad bugs to catter for, but I was wrong. Therefore I think we should add some speedup bugs. What else? I am tempted to keep the change tracking patches for the next round. There are many other small patches targetted at 1.4.1, and most of them could go in now. Hi Jean-Marc, given the fact that some bigger changes have to go into 1.4.X sooner or later (speedups & CT), I think we should keep 1.5.X and 1.4.X in sync as long as possible. I tried to keep track of all potentially relevant changes that haven't been applied to 1.4.X, yet. r13328 - Fix bug 2195: Slowness in rendering inside insets, especially on the Mac r13339 - Fix bug 880, or the multi-paragraph change tracking patch r13356 - fix painting of change bar with only paragraph break changed r13385 - Change tracking -related bug fixes (reported by Juergen) r13408 - fix stripLeadingSpaces mechanism with change tracking enabled r13415 - Changes to the within-inset row rendering caching code r13418 - expand redrawing of current row to endpos() AGAIN r13420 - constify; remove unneeded casts r13422 - Fix changebar non-update (Juergen) IMHO we should apply at least a few of them. Otherwise, it will become more and more complicated to extract patches from the trunk. Michael
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: | | Abdelrazak> I would say that it's a good first step. No need to add | Abdelrazak> more speedup fixes. The major one would have to wait | Abdelrazak> (RandomAccessList and UpdateCounter). | | Ha! I forgot about RandomAccessList! Did someone try it out on 1.4? I | did and it seems to work in its latest incarnation. I am doing a final look over now beforee committing to trunk. -- Lgb
[patch] bug 2322: New bibtex insets don't have style set to "plain", it's empty.
http://bugzilla.lyx.org/show_bug.cgi?id=2322 As advertised, the last patch I have in my tree for 1.4.1. Jürgen Index: src/frontends/gtk/GBibtex.C === --- src/frontends/gtk/GBibtex.C (Revision 13342) +++ src/frontends/gtk/GBibtex.C (Arbeitskopie) @@ -28,8 +28,6 @@ #include using lyx::support::ChangeExtension; -using lyx::support::contains; -using lyx::support::prefixIs; using lyx::support::split; using lyx::support::trim; @@ -109,20 +107,10 @@ void GBibtex::update() } } - string bibtotoc = "bibtotoc"; - string bibstyle(controller().params().getOptions()); - - // bibtotoc exists? - if (prefixIs(bibstyle, bibtotoc)){ - // bibstyle exists? - if (contains(bibstyle,',')) - bibstyle = split(bibstyle, bibtotoc, ','); - else - bibstyle.erase(); - } + string bibstyle(controller().getStylefile()); bool const bibtopic = controller().usingBibtopic(); - if (prefixIs(bibstyle, bibtotoc) && !bibtopic) + if (controller().bibtotoc() && !bibtopic) toccheck_->set_active(true); else toccheck_->set_active(false); Index: src/frontends/qt2/QBibtex.C === --- src/frontends/qt2/QBibtex.C (Revision 13342) +++ src/frontends/qt2/QBibtex.C (Arbeitskopie) @@ -33,8 +33,6 @@ using lyx::support::ChangeExtension; -using lyx::support::contains; -using lyx::support::prefixIs; using lyx::support::split; using lyx::support::trim; @@ -98,23 +96,7 @@ void QBibtex::update_contents() dialog_->add_->bibLB->insertItem(toqstr(bibItem)); } - string bibtotoc = "bibtotoc"; - string bibstyle(controller().params().getOptions()); - - // bibtotoc exists? - if (prefixIs(bibstyle, bibtotoc)){ - // bibstyle exists? - if (contains(bibstyle,',')) - bibstyle = split(bibstyle, bibtotoc, ','); - else - bibstyle.erase(); - } - - if (prefixIs(bibstyle, bibtotoc) && !bibtopic) - dialog_->bibtocCB->setChecked(true); - else - dialog_->bibtocCB->setChecked(false); - + dialog_->bibtocCB->setChecked(controller().bibtotoc() && !bibtopic); dialog_->bibtocCB->setEnabled(!bibtopic); string btprint(controller().params().getSecOptions()); @@ -130,6 +112,7 @@ void QBibtex::update_contents() dialog_->styleCB->clear(); int item_nr(-1); + string bibstyle(controller().getStylefile()); vector str; controller().getBibStyles(str); Index: src/frontends/qt4/QBibtex.C === --- src/frontends/qt4/QBibtex.C (Revision 13342) +++ src/frontends/qt4/QBibtex.C (Arbeitskopie) @@ -32,8 +32,6 @@ using lyx::support::ChangeExtension; -using lyx::support::contains; -using lyx::support::prefixIs; using lyx::support::split; using lyx::support::trim; @@ -97,23 +95,9 @@ void QBibtex::update_contents() dialog_->add_->bibLB->insertItem(toqstr(bibItem)); } - string bibtotoc = "bibtotoc"; - string bibstyle(controller().params().getOptions()); - - // bibtotoc exists? - if (prefixIs(bibstyle, bibtotoc)){ - // bibstyle exists? - if (contains(bibstyle,',')) - bibstyle = split(bibstyle, bibtotoc, ','); - else - bibstyle.erase(); - } - - if (prefixIs(bibstyle, bibtotoc) && !bibtopic) - dialog_->bibtocCB->setChecked(true); - else - dialog_->bibtocCB->setChecked(false); + string bibstyle(controller().getStylefile()); + dialog_->bibtocCB->setChecked(controller().bibtotoc() && !bibtopic); dialog_->bibtocCB->setEnabled(!bibtopic); string btprint(controller().params().getSecOptions()); Index: src/frontends/xforms/FormBibtex.C === --- src/frontends/xforms/FormBibtex.C (Revision 13342) +++ src/frontends/xforms/FormBibtex.C (Arbeitskopie) @@ -34,12 +34,10 @@ namespace lyx { using support::ChangeExtension; using support::compare; -using support::contains; using support::FileFilterList; using support::getStringFromVector; using support::getVectorFromString; using support::OnlyFilename; -using support::prefixIs; using support::split; namespace frontend { @@ -179,20 +177,13 @@ void FormBibtex::update() fl_set_input(dialog_->input_database, controller().params().getContents().c_str()); - string bibtotoc = "bibtotoc"; - string bibstyle = controller().params().getOptions(); + string bibstyle = controller().getStylefile(); bool const bibtopic = controller().usingBibtopic(); - bool const bibtotoc_exists = prefixIs(bibstyle, bibtotoc); - fl_set_button(dialog_->check_bibtotoc, bibtotoc_exists && !bibtopic); + fl_set_button(dialog_->check_bibtotoc, + controller().bibtotoc() && !bibtopic); setEnabled(dialog_->check_bibtotoc, !bibtopic); - if (bibtotoc_exists) { - if (contains(bibstyle, ',')) { // bibstyle exists? - bibstyle = split(bibstyle, bibtotoc, ','); - } else { - bibstyle.erase(); - } - } + fl_set_input(dialog_->input_style, bibstyle.c_str()); string btprint = controller().params().getSecOptions(); Index:
Re: [patch] rowpainter.C
Martin Vermeer wrote: > Yes, and I committed a patch to trunk Perfect! From my POV, multi par change tracking seems to be finished and working now, no more complaints :-) Do you have a cumulative patch for 1.4 that combines all the changes and subsequent fixes you (and others) have done? I'd like to give it a test in branch to see if we didn't forget anything. Thanks, Jürgen
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
On Sun, Mar 19, 2006 at 11:22:31AM +0100, Michael Gerz wrote: > Jean-Marc Lasgouttes wrote: ... > given the fact that some bigger changes have to go into 1.4.X sooner or > later (speedups & CT), I think we should keep 1.5.X and 1.4.X in sync as > long as possible. I tried to keep track of all potentially relevant changes > that haven't been applied to 1.4.X, yet. These together constitute the multi-par CT work: > r13339 - Fix bug 880, or the multi-paragraph change tracking patch > r13356 - fix painting of change bar with only paragraph break changed > r13385 - Change tracking -related bug fixes (reported by Juergen) > r13408 - fix stripLeadingSpaces mechanism with change tracking enabled > r13418 - expand redrawing of current row to endpos() AGAIN > r13422 - Fix changebar non-update (Juergen) And these together the speedup (row paint caching inside insets) work. > r13328 - Fix bug 2195: Slowness in rendering inside insets, especially > on the Mac > r13415 - Changes to the within-inset row rendering caching code > r13420 - constify; remove unneeded casts Thanks for this compilation! > IMHO we should apply at least a few of them. Otherwise, it will become > more and more complicated to extract patches from the trunk. Yes, I think so. But as blocks as above, because they belong together. As for the speedup patch, I would like to know what makes your document slow. At least *that* speedup patch (if we have it :-) should be considered next for 1.4.x. - Martin pgpVNtetOM0tz.pgp Description: PGP signature
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Michael Gerz a écrit : Georg Baum wrote: Because of crashes. Please read the whole thread. This has been discussed extensively. Funny. It means that I should have experienced crashes all the time. I wonder why I haven't... Very strange... I will look for a bullet-proof compilation instruction. It was with the qt4 frontend Michael not qt2. The painting does not work at all when QWorkArea is compiled with -mms-bitfields. Something related to different memory models apparently. Abdel.
Re: [patch] rowpainter.C
On Sun, Mar 19, 2006 at 12:49:53PM +0100, Juergen Spitzmueller wrote: > Martin Vermeer wrote: > > Yes, and I committed a patch to trunk > > Perfect! From my POV, multi par change tracking seems to be finished and > working now, no more complaints :-) > > Do you have a cumulative patch for 1.4 that combines all the changes and > subsequent fixes you (and others) have done? I'd like to give it a test in > branch to see if we didn't forget anything. > > Thanks, > Jürgen Here is the cumulative patch, with thanks to Michael Gerz. I haven't compiled this myself yet so you may run into surprises ;-) - Martin Index: paragraph.h === --- paragraph.h (revision 13338) +++ paragraph.h (revision 13422) @@ -224,6 +224,9 @@ public: /// set change at pos void setChange(lyx::pos_type pos, Change::Type type); + + /// set full change at pos + void setChangeFull(lyx::pos_type pos, Change change); /// accept change void acceptChange(lyx::pos_type start, lyx::pos_type end); Index: paragraph_pimpl.C === --- paragraph_pimpl.C (revision 13338) +++ paragraph_pimpl.C (revision 13422) @@ -99,7 +99,7 @@ void Paragraph::Pimpl::trackChanges(Chan lyxerr[Debug::CHANGES] << "track changes for par " << id_ << " type " << type << endl; changes_.reset(new Changes(type)); - changes_->set(type, 0, size()); + changes_->set(type, 0, size() + 1); } @@ -116,7 +116,7 @@ void Paragraph::Pimpl::cleanChanges() return; changes_.reset(new Changes(Change::INSERTED)); - changes_->set(Change::INSERTED, 0, size()); + changes_->set(Change::INSERTED, 0, size() + 1); } @@ -147,6 +147,14 @@ void Paragraph::Pimpl::setChange(pos_typ } +void Paragraph::Pimpl::setChangeFull(pos_type pos, Change change) +{ + if (!tracking()) + return; + + changes_->set(change, pos); +} + Change::Type Paragraph::Pimpl::lookupChange(pos_type pos) const { if (!tracking()) @@ -204,10 +212,14 @@ void Paragraph::Pimpl::acceptChange(pos_ break; case Change::DELETED: - eraseIntern(i); - changes_->erase(i); - --end; - --i; + // Suppress access to nonexistent + // "end-of-paragraph char": + if (i < size()) { + eraseIntern(i); + changes_->erase(i); + --end; + --i; + } break; } } @@ -235,15 +247,18 @@ void Paragraph::Pimpl::rejectChange(pos_ break; case Change::INSERTED: - eraseIntern(i); - changes_->erase(i); - --end; - --i; + if (i < size()) { + eraseIntern(i); + changes_->erase(i); + --end; + --i; + } break; case Change::DELETED: changes_->set(Change::UNCHANGED, i); - if (owner_->isInset(i)) + // No real char at position size(): + if (i < size() && owner_->isInset(i)) owner_->getInset(i)->markErased(false); break; } @@ -351,7 +366,7 @@ void Paragraph::Pimpl::eraseIntern(pos_t bool Paragraph::Pimpl::erase(pos_type pos) { - BOOST_ASSERT(pos < size()); + BOOST_ASSERT(pos <= size()); if (tracking()) { Change::Type changetype(changes_->lookup(pos)); @@ -359,14 +374,19 @@ bool Paragraph::Pimpl::erase(pos_type po // only allow the actual removal if it was /new/ text if (changetype != Change::INSERTED) { - if (owner_->isInset(pos)) + if (pos < size() && owner_->isInset(pos)) owner_->getInset(pos)->markErased(true); return false; } } - eraseIntern(pos); - return true; + // Don't physically access nonexistent end-of-paragraph char + if (pos < size()) { + eraseIntern(pos); + return true; +
Re: qt4: remove (2nd) add dialog in add bib tex ref dialog
Juergen Spitzmueller a écrit : Abdelrazak Younes wrote: IMHO, the bibtex dialog should be accessible from the citation dialog. For the matter, I think everything related to citation should be accessible through the citation dialog. And if we have several different bibtext insets (bibtopic)? Good question, I don't know. As I said I am not really a Bibtex user but I feel like some kind of generalisation of the bibliography interface should be done. Abdel.
Re: [patch] rowpainter.C
Martin Vermeer wrote: > Here is the cumulative patch, with thanks to Michael Gerz. I haven't > compiled this myself yet so you may run into surprises ;-) Some tweaking was necessary to get it to work. Attached is the resulting patch, which seems to work well. I'll post it to bugzilla, so that people can test it in 1.4svn. Jürgen Index: src/paragraph.h === --- src/paragraph.h (Revision 13423) +++ src/paragraph.h (Arbeitskopie) @@ -224,6 +224,9 @@ public: /// set change at pos void setChange(lyx::pos_type pos, Change::Type type); + + /// set full change at pos + void setChangeFull(lyx::pos_type pos, Change change); /// accept change void acceptChange(lyx::pos_type start, lyx::pos_type end); Index: src/paragraph_pimpl.C === --- src/paragraph_pimpl.C (Revision 13423) +++ src/paragraph_pimpl.C (Arbeitskopie) @@ -99,7 +99,7 @@ void Paragraph::Pimpl::trackChanges(Chan lyxerr[Debug::CHANGES] << "track changes for par " << id_ << " type " << type << endl; changes_.reset(new Changes(type)); - changes_->set(type, 0, size()); + changes_->set(type, 0, size() + 1); } @@ -116,7 +116,7 @@ void Paragraph::Pimpl::cleanChanges() return; changes_.reset(new Changes(Change::INSERTED)); - changes_->set(Change::INSERTED, 0, size()); + changes_->set(Change::INSERTED, 0, size() + 1); } @@ -147,6 +147,14 @@ void Paragraph::Pimpl::setChange(pos_typ } +void Paragraph::Pimpl::setChangeFull(pos_type pos, Change change) +{ + if (!tracking()) + return; + + changes_->set(change, pos); +} + Change::Type Paragraph::Pimpl::lookupChange(pos_type pos) const { if (!tracking()) @@ -204,10 +212,14 @@ void Paragraph::Pimpl::acceptChange(pos_ break; case Change::DELETED: -eraseIntern(i); -changes_->erase(i); ---end; ---i; +// Suppress access to nonexistent +// "end-of-paragraph char": +if (i < size()) { + eraseIntern(i); + changes_->erase(i); + --end; + --i; +} break; } } @@ -235,15 +247,18 @@ void Paragraph::Pimpl::rejectChange(pos_ break; case Change::INSERTED: -eraseIntern(i); -changes_->erase(i); ---end; ---i; +if (i < size()) { + eraseIntern(i); + changes_->erase(i); + --end; + --i; +} break; case Change::DELETED: changes_->set(Change::UNCHANGED, i); -if (owner_->isInset(i)) +// No real char at position size(): +if (i < size() && owner_->isInset(i)) owner_->getInset(i)->markErased(false); break; } @@ -351,7 +366,7 @@ void Paragraph::Pimpl::eraseIntern(pos_t bool Paragraph::Pimpl::erase(pos_type pos) { - BOOST_ASSERT(pos < size()); + BOOST_ASSERT(pos <= size()); if (tracking()) { Change::Type changetype(changes_->lookup(pos)); @@ -359,14 +374,19 @@ bool Paragraph::Pimpl::erase(pos_type po // only allow the actual removal if it was /new/ text if (changetype != Change::INSERTED) { - if (owner_->isInset(pos)) + if (pos < size() && owner_->isInset(pos)) owner_->getInset(pos)->markErased(true); return false; } } - eraseIntern(pos); - return true; + // Don't physically access nonexistent end-of-paragraph char + if (pos < size()) { + eraseIntern(pos); + return true; + } + + return false; } Index: src/CutAndPaste.C === --- src/CutAndPaste.C (Revision 13423) +++ src/CutAndPaste.C (Arbeitskopie) @@ -234,7 +234,8 @@ pasteSelectionHelper(Buffer const & buff pit = last_paste; pos = pars[last_paste].size(); - // Maybe some pasting. + // Join (conditionally) last pasted paragraph with next one, i.e., + // the tail of the spliced document paragraph if (!empty && last_paste + 1 != pit_type(pars.size())) { if (pars[last_paste + 1].hasSameLayout(pars[last_paste])) { mergeParagraph(buffer.params(), pars, last_paste); @@ -271,64 +272,35 @@ PitPosPair eraseSelectionHelper(BufferPa return PitPosPair(endpit, endpos); } - bool all_erased = true; - -// Clear fragments of the first par in selection - pars[startpit].erase(startpos, pars[startpit].size()); - if (pars[startpit].size() != startpos) - all_erased = false; - -// Clear fragments of the last par in selection - endpos -= pars[endpit].erase(0, endpos); - if (endpos != 0) - all_erased = false; - -// Erase all the "middle" paragraphs. - if (params.tracking_changes) { - // Look through the deleted pars if any, erasing as needed - for (pit_type pit = startpit + 1; pit != endpit;) { - // "erase" the contents of the par - pars[pit].erase(0, pars[pit].size()); - if (pars[pit].empty()) { -// remove the par if it's now empty -pars.erase(pars.begin() + pit); ---endpit; - } else { -++pit; -all_erased = false; - } - } - } else { - pars.erase(pars.begin() + startpit + 1, pars.begin() + endpit); - endpit
[Patch] raise/lower selected super/sub -scripts in math
This is a regression from 1.3. It should be possible, both with ^ _ keys and with the math panel (and directly with the commands math-superscript and math-subscript), to raise the selection to a superscript or lower it to a subscript. Works in 1.3.7. At the same time we get rid of The Abominable LCursor::paste() Method. Will go into trunk later if nobody spots a problem. - Martin Index: cursor.C === --- cursor.C(revision 13408) +++ cursor.C(working copy) @@ -379,15 +379,6 @@ void LCursor::getPos(int & x, int & y) c } -// Don't use this routine. It is erroneous: LFUN_PASTE should be called with -// buffer number, not data to be inserted -- MV 26.02.2006 -void LCursor::paste(string const & data) -{ - if (!data.empty()) - dispatch(FuncRequest(LFUN_PASTE, data)); -} - - void LCursor::resetAnchor() { anchor_ = *this; Index: mathed/math_nestinset.C === --- mathed/math_nestinset.C (revision 13408) +++ mathed/math_nestinset.C (working copy) @@ -685,9 +685,13 @@ void MathNestInset::doDispatch(LCursor & cur.posLeft(); cur.pushLeft(*cur.nextInset()); } - } else if (!interpret(cur, cmd.argument[0])) { - cmd = FuncRequest(LFUN_FINISHED_RIGHT); - cur.undispatched(); + } else { + // single character, e.g. ^ or _ + safe_ = grabAndEraseSelection(cur); + if (!interpret(cur, cmd.argument[0])) { + cmd = FuncRequest(LFUN_FINISHED_RIGHT); + cur.undispatched(); + } } break; @@ -868,13 +872,16 @@ void MathNestInset::doDispatch(LCursor & case LFUN_SUBSCRIPT: // interpret this as if a _ was typed + // E.g., called from minibuffer (math-subscript) recordUndo(cur, Undo::ATOMIC); + safe_ = grabAndEraseSelection(cur); interpret(cur, '_'); break; case LFUN_SUPERSCRIPT: // interpret this as if a ^ was typed recordUndo(cur, Undo::ATOMIC); + safe_ = grabAndEraseSelection(cur); interpret(cur, '^'); break; @@ -882,13 +889,12 @@ void MathNestInset::doDispatch(LCursor & // handling such that "self-insert" works on "arbitrary stuff" too, and // math-insert only handles special math things like "matrix". case LFUN_INSERT_MATH: { + safe_ = grabAndEraseSelection(cur); recordUndo(cur, Undo::ATOMIC); - MathArray ar; - asArray(cmd.argument, ar); - int cell(0); - if (cmd.argument == "\\root") - cell = 1; - cur.niceInsert(cmd.argument); + if (cmd.argument.size() == 1) + interpret(cur, cmd.argument[0]); + else + cur.niceInsert(cmd.argument); break; } @@ -1246,7 +1252,6 @@ bool MathNestInset::script(LCursor & cur } cur.macroModeClose(); - string safe = grabAndEraseSelection(cur); if (asScriptInset() && cur.idx() == 0) { // we are in a nucleus of a script inset, move to _our_ script MathScriptInset * inset = asScriptInset(); @@ -1277,9 +1282,9 @@ bool MathNestInset::script(LCursor & cur cur.idx() = 1; cur.pos() = 0; } - //lyxerr << "pasting 1: safe:\n" << safe << endl; - cur.paste(safe); + //lyxerr << "pasting 1: safe:\n" << safe_ << endl; + cur.niceInsert(safe_); cur.resetAnchor(); - //lyxerr << "pasting 2: safe:\n" << safe << endl; + //lyxerr << "pasting 2: safe:\n" << safe_ << endl; return true; } pgpM0IeScFCFh.pgp Description: PGP signature
Please Add Document Classes for AMS + NoWeb
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hell, LyX Team! First, thanks so much for a great tool! I'm finding some rough edges in 1.4.0 on Mac OS X and have filed bug reports on BugZilla, but now I have a feature request. It would be very nice if LyX provided document classes that combined AMS support and NoWeb support. I'm using LyX to work through Benjamin Pierce's "Types and Programming Languages," and the AMS support is great for typesetting all of the type theory material, but I'd also like to use the NoWeb support to actually put my code for the exercises in the document as well. Of course, in the short term, some idea as to how to do that with LyX 1.4.0 as-is would be handy as well. Many thanks and best regards, Paul Snively -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iEYEARECAAYFAkQduaYACgkQS6yIxITC5OrHmgCfXK+AbHFh2n++JH9+4nsd/WcY CYUAnA+eZOMp3wNCITasRUQpnmg7Bt2V =Byah -END PGP SIGNATURE-
Re: [Patch] raise/lower selected super/sub -scripts in math
On Sun, Mar 19, 2006 at 09:42:09PM +0200, Martin Vermeer wrote: > > This is a regression from 1.3. It should be possible, both with ^ _ keys > and with the math panel (and directly with the commands math-superscript > and math-subscript), to raise the selection to a superscript or lower it > to a subscript. Works in 1.3.7. > > At the same time we get rid of The Abominable LCursor::paste() Method. > > Will go into trunk later if nobody spots a problem. > > - Martin Sorry, file mising. New patch attached. - Martin Index: cursor.C === --- cursor.C(revision 13408) +++ cursor.C(working copy) @@ -379,15 +379,6 @@ void LCursor::getPos(int & x, int & y) c } -// Don't use this routine. It is erroneous: LFUN_PASTE should be called with -// buffer number, not data to be inserted -- MV 26.02.2006 -void LCursor::paste(string const & data) -{ - if (!data.empty()) - dispatch(FuncRequest(LFUN_PASTE, data)); -} - - void LCursor::resetAnchor() { anchor_ = *this; Index: mathed/math_nestinset.C === --- mathed/math_nestinset.C (revision 13408) +++ mathed/math_nestinset.C (working copy) @@ -685,9 +685,13 @@ void MathNestInset::doDispatch(LCursor & cur.posLeft(); cur.pushLeft(*cur.nextInset()); } - } else if (!interpret(cur, cmd.argument[0])) { - cmd = FuncRequest(LFUN_FINISHED_RIGHT); - cur.undispatched(); + } else { + // single character, e.g. ^ or _ + safe_ = grabAndEraseSelection(cur); + if (!interpret(cur, cmd.argument[0])) { + cmd = FuncRequest(LFUN_FINISHED_RIGHT); + cur.undispatched(); + } } break; @@ -868,13 +872,16 @@ void MathNestInset::doDispatch(LCursor & case LFUN_SUBSCRIPT: // interpret this as if a _ was typed + // E.g., called from minibuffer (math-subscript) recordUndo(cur, Undo::ATOMIC); + safe_ = grabAndEraseSelection(cur); interpret(cur, '_'); break; case LFUN_SUPERSCRIPT: // interpret this as if a ^ was typed recordUndo(cur, Undo::ATOMIC); + safe_ = grabAndEraseSelection(cur); interpret(cur, '^'); break; @@ -882,13 +889,12 @@ void MathNestInset::doDispatch(LCursor & // handling such that "self-insert" works on "arbitrary stuff" too, and // math-insert only handles special math things like "matrix". case LFUN_INSERT_MATH: { + safe_ = grabAndEraseSelection(cur); recordUndo(cur, Undo::ATOMIC); - MathArray ar; - asArray(cmd.argument, ar); - int cell(0); - if (cmd.argument == "\\root") - cell = 1; - cur.niceInsert(cmd.argument); + if (cmd.argument.size() == 1) + interpret(cur, cmd.argument[0]); + else + cur.niceInsert(cmd.argument); break; } @@ -1246,7 +1252,6 @@ bool MathNestInset::script(LCursor & cur } cur.macroModeClose(); - string safe = grabAndEraseSelection(cur); if (asScriptInset() && cur.idx() == 0) { // we are in a nucleus of a script inset, move to _our_ script MathScriptInset * inset = asScriptInset(); @@ -1277,9 +1282,9 @@ bool MathNestInset::script(LCursor & cur cur.idx() = 1; cur.pos() = 0; } - //lyxerr << "pasting 1: safe:\n" << safe << endl; - cur.paste(safe); + //lyxerr << "pasting 1: safe:\n" << safe_ << endl; + cur.niceInsert(safe_); cur.resetAnchor(); - //lyxerr << "pasting 2: safe:\n" << safe << endl; + //lyxerr << "pasting 2: safe:\n" << safe_ << endl; return true; } Index: mathed/math_nestinset.h === --- mathed/math_nestinset.h (revision 13408) +++ mathed/math_nestinset.h (working copy) @@ -128,6 +128,8 @@ protected: cells_type cells_; /// if the inset is locked, it can't be entered with the cursor bool lock_; + /// + std::string safe_; }; #endif pgphyXawIBA95.pgp Description: PGP signature
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Abdelrazak Younes a écrit : Enrico Forestieri a écrit : Abdelrazak Younes <[EMAIL PROTECTED]> writes: This is interesting. I'll try to compile for a mingw target without the -mms-bitfield switch and see what happens... I bet nothing I have tried that in the past but did not succeed (compiling from cygwin a mingw target). The resulting executable never worked. This was related to some ld problems IIRC. I hope you'll have more success. Strange, I do that all the time without any problem. Perhaps this is due to the fact that I also compile Qt using -mno-cygwin but following the exact procedure as if I was directly using the mingw compiler. This requires patching the Qt sources, but that should be done only for once. I am developing for Qt4 and for me patching it is out of the question. I will try again when I have some time. Success! I managed to compile everything (qt4) without MSYS. There two small problem though: 1) I have to use -sysdir option because the generated executable look for an inexistant directory: $ ./lyx-qt4 Unable to determine the system directory having searched d:/msys/home/yns/lyx/trunk/share/lyx-svn/ Try the '-sysdir' command line parameter or set the environment variable LYX_DIR_14x to the LyX system directory containing the file `chkconfig.ltx'. 2) I had to hack the source code in order to replace '/tmp' with 'c:/temp' because lyx tells me it cannot write the '/tmp' directory. Except for that I am happy to report that I cannot see any difference with the lyx I generated within MSYS. Except that the executable is smaller (12Mo instead of 19Mo) and that the compilation is faster. Enrico, if you have any hint for the problems above... Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Michael Gerz <[EMAIL PROTECTED]> writes: > > Enrico Forestieri wrote: > > >Then why not compiling libiconv with mingw, too? It is quite strightforward > >to do. As regards gettext, if you configure with --with-included-gettext, > >it will be compiled alongside LyX. > > > > > Then why not keeping the option? Why all the trouble? I am neither against nor pro it. I have tried compiling LyX with and without it, and it seems to make no difference for me. However, Abdel found that it hurts him. Given that it is simpler adding it to CPPFLAGS if it is needed than getting rid of it if it hurts, I think that the most logical thing to do is not enforcing it. I am fine with whatever resolution. -- Enrico
LyX 1.4.1 pre1
With the help of the attached patch, I have built and uploaded a snapshot of the 1.4.x branch to: http://wiki.lyx.org/uploads/Windows/LyX141pre/lyx-1.4.1-pre_win32_setup_v1.exe Jean-Marc, could you apply the patch please? (I have been unable to create a writable subversion repository on Windows; something to do with my firewall, I think.) I built against Aspell 0.6 and the latest and greatest snapshot of Qt/Win Free. I configured --with-version-suffix='1.4.x' prefix, but after local installation in the installprefix directory, I manually changed the names of the executables in the bin directory to lyx.exe and tex2lyx.exe. I did this so that the lyx.bat generated by the installer would work as expected. Here, I have the thing installed at J:\Program Files\LyX14x. User-level support files are to be found in C:\Documents and Settings\Angus\Application Data\LyX1.4.x. I continue to be able to use LyX 1.3.7. Everything seems to work... Would interested parties please try this out? If it proves to work as advertised I'll put together a page on the wiki and we can advertise more widely. Regards, Angus Index: boost/libs/filesystem/src/operations_posix_windows.cpp === --- boost/libs/filesystem/src/operations_posix_windows.cpp (revision 13423) +++ boost/libs/filesystem/src/operations_posix_windows.cpp (working copy) @@ -73,7 +73,7 @@ // if WINVER < 0x04A. # include # if __W32API_MAJOR_VERSION < 3 || \ - __W32API_MAJOR_VERSION == 3 && __W32API_MINOR_VERSION <= 3 + __W32API_MAJOR_VERSION == 3 && __W32API_MINOR_VERSION <= 6 # define BOOST_FILESYSTEM_WINVER WINVER # undef WINVER # define WINVER 0x040A Index: development/Win32/packaging/build_lyxwin.sh === --- development/Win32/packaging/build_lyxwin.sh (revision 13423) +++ development/Win32/packaging/build_lyxwin.sh (working copy) @@ -170,7 +170,7 @@ Error "Unable to create build dir, ${BUILDDIR}." } - CONFIGURE="../configure --without-x --with-included-gettext --with-extra-prefix='${LYX_ASPELL_DIR}' --with-frontend=qt QTDIR='$QT_DIR' --disable-maintainer-mode --disable-debug --enable-optimization --disable-pch --disable-concept-checks --disable-stdlib-debug" + CONFIGURE="../configure --with-version-suffix='1.4.x' --without-x --with-included-gettext --with-extra-prefix='${LYX_ASPELL_DIR}' --with-frontend=qt QTDIR='$QT_DIR' --disable-maintainer-mode --disable-debug --enable-optimization --disable-pch --disable-concept-checks --disable-stdlib-debug" echo "${CONFIGURE}" cd "${BUILDDIR}" Index: development/Win32/packaging/installer/lyx_installer.nsi === --- development/Win32/packaging/installer/lyx_installer.nsi (revision 13423) +++ development/Win32/packaging/installer/lyx_installer.nsi (working copy) @@ -20,7 +20,7 @@ CRCCheck force ; Make the installer as small as possible. -SetCompressor lzma +SetCompressor /SOLID lzma ; ; You should need to change only these macros...
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Enrico Forestieri wrote: Michael Gerz <[EMAIL PROTECTED]> writes: Enrico Forestieri wrote: Then why not compiling libiconv with mingw, too? It is quite strightforward to do. As regards gettext, if you configure with --with-included-gettext, it will be compiled alongside LyX. Then why not keeping the option? Why all the trouble? I am neither against nor pro it. I have tried compiling LyX with and without it, and it seems to make no difference for me. However, Abdel found that it hurts him. Given that it is simpler adding it to CPPFLAGS if it is needed than getting rid of it if it hurts, I think that the most logical thing to do is not enforcing it. I am fine with whatever resolution. Enrico, Using MSYS, I have built the libiconv package suggested by Michael and then gone on to build LyX using --with-included-gettext. configure finds libiconv and the build proceeds happily, but I find that the resulting .exe is unable to change the installed .po (.gmo) dynamically to the local locale. If I understood your message of some time ago correctly, you reported that your essentially-identical cygwin build was able to display a Polish LyX with native Windows LANG. When I read the libiconv/gettext build docs, it seems that the build process is essentially circular. First build gettext, then libiconv, then gettext again. (Or start with libiconv, then gettext, then libiconv again.) So, I suspect that my build doesn't work as advertised because my build is incomplete. Before I invest time and effort into trying out my theory, can you explain in more detail just what you did to get this stuff working? Regards, Angus
LyX/Win 1.4.1 pre1
Changing subject for advertising reasons... Angus
Re: LyX/Win 1.4.1 pre1
Angus Leeming <[EMAIL PROTECTED]> writes: | Changing subject for advertising reasons... Ok, where is the tar.gz? If this is only a Win test build of 1.4.xSVN then say so. -- Lgb
Re: LyX/Win 1.4.1 pre1
Lars Gullik Bjønnes wrote: Angus Leeming writes: | Changing subject for advertising reasons... Ok, where is the tar.gz? If this is only a Win test build of 1.4.xSVN then say so. ??? I think you need to get some rest ;-P The start of the original post: With the help of the attached patch, I have built and uploaded a snapshot of the 1.4.x branch to: http://wiki.lyx.org/uploads/Windows/LyX141pre/lyx-1.4.1-pre_win32_setup_v1.exe Good night. Angus
Re: LyX/Win 1.4.1 pre1
Angus Leeming <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: | > Angus Leeming writes: | > | Changing subject for advertising reasons... | | > Ok, where is the tar.gz? | > If this is only a Win test build of 1.4.xSVN then say so. | | ??? I think you need to get some rest ;-P | | The start of the original post: And now go read the subject. And you lost all the messges from the original post when you changed the subject in the followup. -- Lgb
Re: Problem compiling Lyx 1.4. svn
Charles de Miramon <[EMAIL PROTECTED]> writes: | Hello, | | I'm trying to compile from svn to check if bug #2379 is corrected. | | 1) I've checked the code with : | svn co svn://svn.lyx.org/lyx/lyx-devel/trunk lyx-devel | | I guess, I have downloaded the future 1.4.1 1.5 actually. If you want the base for 1.4.x you have to get svn://svn.lyx.org/lyx/lyx-devel/branches/BRANCH_1_4_X/ | 2) I've configured with : | ./configure --with-version-suffix=-svn --with-frontend=qt | --with-qt-dir=/usr/share/qt3 | | 3) After a while, Make stops during the compilation of 'libsupport.a' | I attach the last lines of the compilation log There is a problem with some distributions releases of gcc. I think you have one of those. Is it a gcc 4.0.3 pre-release? -- Lgb
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Abdelrazak Younes <[EMAIL PROTECTED]> writes: > Success! I managed to compile everything (qt4) without MSYS. There two > small problem though: > 1) I have to use -sysdir option because the generated executable look > for an inexistant directory: > > $ ./lyx-qt4 > Unable to determine the system directory having searched > d:/msys/home/yns/lyx/trunk/share/lyx-svn/ > Try the '-sysdir' command line parameter or set the environment variable > LYX_DIR_14x to the LyX system directory containing the file `chkconfig.ltx'. That also happened to me once, when I tried running LyX in place. However, after installation I had no problems. If I remember correctly, it was immediately after the switch from ...\Resources\lyx to ...\Resources so, perhaps this is the case with you, too. If not, see below. I don't see this problem anymore, so may be it was due to not updated configuration files. > 2) I had to hack the source code in order to replace '/tmp' with > 'c:/temp' because lyx tells me it cannot write the '/tmp' directory. > > Except for that I am happy to report that I cannot see any difference > with the lyx I generated within MSYS. Except that the executable is > smaller (12Mo instead of 19Mo) and that the compilation is faster. This may simply be due to the fact that mingw executables are to be stripped. I don't see any significant difference in size between a mingw and a cygwin LyX. > Enrico, if you have any hint for the problems above... Well, if '/tmp' is present in the source code, this is a bug with a native LyX and you have no choice but replacing it with a proper path, probably protecting the change using an #ifdef. But it may be a configuration problem. All cygwin tools use posix syntax by default, so care must be taken when generating Makefiles if they are meant for building a native version of LyX. For example, when invoking 'configure', you should use --prefix=C:/Programs/LyX instead of --prefix=/c/Programs/LyX, but it is safe using --with-extra-prefix=/c/MinGW. Another problem can arise when a path is autogenerated by configure. There is some code in the configure script that turns 'C:/Programs/LyX' into '/c/Programs/LyX' (or '/cygdrive/c/Programs/LyX', depending on your settings), so I had to add the following to the sed command I use for modifying configure: # Set locale and data dir in mixed rather than posix format /^ *LYX_ABS_INSTALLED/s/\(^ *\)/\1ac_val=`cygpath -m \"\$ac_val\"`\n\1/ otherwise I get '/c/Programs/LyX/Resources/locale' hardcoded into the executable instead of 'C:/Programs/LyX/Resources/locale', and the net effect would be that setting LANG to some locale doesn't work. Thinking about it, perhaps this is the reason (hardcoded path) why Angus reports that setting LANG seems not working in mingw builds. However, this is the only problem that I spotted. To be honest there was another one, but it was about the recognition of a multi-threaded Qt. For some reason the default test program used in configure: int main () { QApplication a(0,0); a.unlock(); ; return 0; } fails compilation and a multi-threaded Qt would be not recognized as such. I had to modify that program in the following way: int main () { int argc; char **argv = NULL; QApplication a(argc,argv); a.unlock(); ; return 0; } for the test to be successful in the case Qt is multi-threaded. I think that's all. The native LyX I compile using cygwin is fully functional and until now I have seen no side effects. -- Enrico
Re: LyX/Win 1.4.1 pre1
Just tried the new installer. The configure script didn't find my PDF and PS viewers, even after adding the paths to \path_prefix in lyxrc.defaults. C:\Program Files\Adobe\Acrobat 7.0\Reader\AcroRd32.exe c:\Program Files\GSview\gsview\gsview32.exe I can set the viewers manually but shouldn't the script find them? Thanks, Paul
[Ãpatch] RandomAccessList take 4
Ok, this is what I am going to commit. I am not really happy with the fact that RandomListIterator really is a std::list<>::iterator. I'd like it to be a real random_access_iterator. We should probably create our own. (And no; I don't agree that we should only work with offsets and indices, iterators are nice and we should use them.) This works for me. [[ * output_latex.h: * buffer.h: * CutAndPaste.h: * pariterator.h: * paragraph_funcs.h: * output_linuxdoc.h: * output_docbook.h: * insets/insettext.h: get forward declaration of ParagraphList * output_plaintext.C: * bufferlist.C: * undo.C: * lyxtext.h: * undo.h: * buffer_funcs.C: * insets/insetbibitem.C: get proper ParagraphList decls * output_linuxdoc.C (linuxdocParagraphs): * output_latex.C (TeXOnePar): * insets/insettext.C (appendParagraphs): * insets/insetcharstyle.C (docbook): use std::distance * CutAndPaste.C (pasteSelectionHelper, copySelectionHelper): * paragraph_funcs.C (breakParagraph, breakParagraphConservative, mergeParagraph): * text.C (acceptChange, rejectChange): * text2.C (deleteEmptyParagraphMechanism): use boost::next * output_docbook.C (several places): use boost::next and std::distance * ParagraphList_fwd.h: modify to provid a forward declaratoin of the new ParagraphList. * RandomAccessList.h: New container for Paragraphs from Abdelrazak Younes * ParagraphList.h: new file, setup user of RandomAccessList * paragraph.C: remove ParagraphList constructor from this file ]] Index: src/insets/insettext.h === --- src/insets/insettext.h (revision 13423) +++ src/insets/insettext.h (working copy) @@ -16,6 +16,7 @@ #include "RowList_fwd.h" #include "lyxfont.h" #include "lyxtext.h" +#include "ParagraphList_fwd.h" #include "support/types.h" @@ -27,7 +28,6 @@ class CursorSlice; class Dimension; class LColor_color; -class ParagraphList; /** Index: src/insets/insetbibitem.C === --- src/insets/insetbibitem.C (revision 13423) +++ src/insets/insetbibitem.C (working copy) @@ -19,7 +19,7 @@ #include "lyxfont.h" #include "lyxlex.h" #include "paragraph.h" -#include "ParagraphList_fwd.h" +#include "ParagraphList.h" #include "frontends/font_metrics.h" Index: src/insets/insetcharstyle.C === --- src/insets/insetcharstyle.C (revision 13423) +++ src/insets/insetcharstyle.C (working copy) @@ -289,6 +289,7 @@ int InsetCharStyle::docbook(Buffer const & buf, ostream & os, OutputParams const & runparams) const { + ParagraphList::const_iterator beg = paragraphs().begin(); ParagraphList::const_iterator par = paragraphs().begin(); ParagraphList::const_iterator end = paragraphs().end(); @@ -298,7 +299,7 @@ for (; par != end; ++par) { par->simpleDocBookOnePar(buf, os, runparams, - outerFont(par - paragraphs().begin(), + outerFont(std::distance(beg, par), paragraphs())); } Index: src/insets/insettext.C === --- src/insets/insettext.C (revision 13423) +++ src/insets/insettext.C (working copy) @@ -422,7 +422,8 @@ ParagraphList::iterator pit = plist.begin(); ParagraphList::iterator ins = pl.insert(pl.end(), *pit); ++pit; - mergeParagraph(buffer->params(), pl, ins - pl.begin() - 1); + mergeParagraph(buffer->params(), pl, + std::distance(pl.begin(), ins) - 1); for_each(pit, plist.end(), bind(::push_back, ref(pl), _1)); Index: src/output_plaintext.C === --- src/output_plaintext.C (revision 13423) +++ src/output_plaintext.C (working copy) @@ -19,7 +19,7 @@ #include "output.h" #include "outputparams.h" #include "paragraph.h" -#include "ParagraphList_fwd.h" +#include "ParagraphList.h" #include "ParagraphParameters.h" #include "support/lstrings.h" Index: src/output_latex.h === --- src/output_latex.h (revision 13423) +++ src/output_latex.h (working copy) @@ -12,11 +12,12 @@ #ifndef OUTPUT_LATEX_H #define OUTPUT_LATEX_H +#include "ParagraphList_fwd.h" + #include class Buffer; class OutputParams; -class ParagraphList; class TexRow; /// Just a wrapper for the method below, first creating the ofstream. Index: src/bufferlist.C === --- src/bufferlist.C (revision 13423) +++ src/bufferlist.C (working copy) @@ -22,7 +22,7 @@ #include "lyx_main.h" #include "output_latex.h" #include "paragraph.h" -#include "ParagraphList_fwd.h" +#include
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Angus Leeming <[EMAIL PROTECTED]> writes: > Enrico, > > Using MSYS, I have built the libiconv package suggested by Michael and then > gone on to build LyX using --with-included-gettext. configure finds > libiconv and the build proceeds happily, but I find that the resulting .exe > is unable to change the installed .po (.gmo) dynamically to the local > locale. If I understood your message of some time ago correctly, you > reported that your essentially-identical cygwin build was able to display a > Polish LyX with native Windows LANG. > > When I read the libiconv/gettext build docs, it seems that the build > process is essentially circular. First build gettext, then libiconv, then > gettext again. (Or start with libiconv, then gettext, then libiconv again.) > > So, I suspect that my build doesn't work as advertised because my build is > incomplete. > > Before I invest time and effort into trying out my theory, can you explain > in more detail just what you did to get this stuff working? Angus, I suspect that this is an hardcoded path problem. The configure script sets LYX_ABS_INSTALLED_LOCALEDIR to the directory $prefix/Resources/locale and then this directory is hardcoded into the executable. So, if LyX is installed in a different place than the $prefix dir, it will be unable to find the files. I don't know how this can be cleanly solved. I can think of two solutions. The first one is rather dirty: hack the configure script such that LYX_ABS_INSTALLED_LOCALEDIR is set to a PATH_MAX long string and then at installation time overwrite the string in the LyX executable with the proper path (other than dirty, this may also be fragile). The second one is the following. You already have an hardcoded path "C:/Aspell", so you could change that to "C:/LyXsupport" and put there both aspell and locale files. A third possibility is investigating wheter libiconv/gettext support dynamic relocation. A fourth possibility is switching to cygwin and forget all those problems, but I suspect that this is not an option ;-) But, wait a moment... what about hacking configure such that LYX_ABS_INSTALLED_LOCALEDIR is a relative path? Uhm... perhaps that is not possible to do, I mean that perhaps it has to be an absolute path. -- Enrico
Re: LyX/Win 1.4.1 pre1
Paul <[EMAIL PROTECTED]> writes: > > Just tried the new installer. The configure script didn't find my PDF and PS > viewers, even after adding the paths to \path_prefix in lyxrc.defaults. Never mind, I got it to work. I modified the wrong file (needed to change configure).
LyX/Win 1.4.1 pre1
Works good! I have only one entry for LyX under Add/Remove programs. Perhaps it would be better to have separate uninstalls for LyX137, LyX14x? I was able to change my viewers by modifying the File format->Viewer field. Path prefix was generated properly though I use paths without spaces. The Users will be pleased! Stephen
Minor problem with sciword.bind
When I use sciword.bind, LyX: BN_BIND: Unknown LyX function `find-replace' [around line 165 of file /usr/local/share/lyx/bind/sciword.bind] Cheers, Bo
Re: [Patch] raise/lower selected super/sub -scripts in math
Martin Vermeer wrote: > This is a regression from 1.3. It should be possible, both with ^ _ keys > and with the math panel (and directly with the commands math-superscript > and math-subscript), to raise the selection to a superscript or lower it > to a subscript. Works in 1.3.7. Does this fix bug 2345? Jürgen
Re: [Patch] raise/lower selected super/sub -scripts in math
On Sun, 2006-03-19 at 22:12 +0200, Martin Vermeer wrote: > On Sun, Mar 19, 2006 at 09:42:09PM +0200, Martin Vermeer wrote: > > > > This is a regression from 1.3. It should be possible, both with ^ _ keys > > and with the math panel (and directly with the commands math-superscript > > and math-subscript), to raise the selection to a superscript or lower it > > to a subscript. Works in 1.3.7. > > > > At the same time we get rid of The Abominable LCursor::paste() Method. > > > > Will go into trunk later if nobody spots a problem. > > > > - Martin > > Sorry, file mising. New patch attached. Bit more polished version attached. This one goes in. Log message: Get raising/lowering into super/subscripts of selection working (1.3 regression) * cursor.C: get rid of paste() * mathed/math_nestinset.C (MathNestInset::doDispatch): (MathNestInset::lfunMouseRelease): define safe_ (selection) in several places (MathNestInset::script): use data member safe_ to insert selection * mathed/math_nestinset.h: data member safe_ - Martin signature.asc Description: This is a digitally signed message part
Re: [Patch] raise/lower selected super/sub -scripts in math
On Mon, 2006-03-20 at 07:49 +0100, Juergen Spitzmueller wrote: > Martin Vermeer wrote: > > This is a regression from 1.3. It should be possible, both with ^ _ keys > > and with the math panel (and directly with the commands math-superscript > > and math-subscript), to raise the selection to a superscript or lower it > > to a subscript. Works in 1.3.7. > > Does this fix bug 2345? No...should it? Looks completely unrelated to me. - Martin signature.asc Description: This is a digitally signed message part
Re: [Patch] raise/lower selected super/sub -scripts in math
On Mon, 2006-03-20 at 09:41 +0200, Martin Vermeer wrote: > On Mon, 2006-03-20 at 07:49 +0100, Juergen Spitzmueller wrote: > > Martin Vermeer wrote: > > > This is a regression from 1.3. It should be possible, both with ^ _ keys > > > and with the math panel (and directly with the commands math-superscript > > > and math-subscript), to raise the selection to a superscript or lower it > > > to a subscript. Works in 1.3.7. > > > > Does this fix bug 2345? > > No...should it? Looks completely unrelated to me. ... but the same trick works here too, see patch. Great intuition, thanks! - Martin Index: math_nestinset.C === --- math_nestinset.C (revision 13424) +++ math_nestinset.C (working copy) @@ -798,11 +798,13 @@ void MathNestInset::doDispatch(LCursor & if (currentMode() == InsetBase::MATH_MODE && cmd.argument == "on") break; cur.macroModeClose(); + safe_ = grabAndEraseSelection(cur); selClearOrDel(cur); //cur.plainInsert(MathAtom(new MathMBoxInset(cur.bv(; cur.plainInsert(MathAtom(new MathBoxInset("mbox"))); cur.posLeft(); cur.pushLeft(*cur.nextInset()); + cur.niceInsert(safe_); #else if (currentMode() == InsetBase::TEXT_MODE) { cur.niceInsert(MathAtom(new MathHullInset("simple"))); signature.asc Description: This is a digitally signed message part