Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options

2006-03-19 Thread Georg Baum
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

2006-03-19 Thread Michael Gerz

[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

2006-03-19 Thread Michael Gerz

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

2006-03-19 Thread Michael Gerz

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

2006-03-19 Thread Michael Gerz

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

2006-03-19 Thread Georg Baum
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

2006-03-19 Thread Georg Baum
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

2006-03-19 Thread Michael Gerz

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

2006-03-19 Thread Juergen Spitzmueller
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

2006-03-19 Thread Michael Gerz

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

2006-03-19 Thread Lars Gullik Bjønnes
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.

2006-03-19 Thread Juergen Spitzmueller
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

2006-03-19 Thread Juergen Spitzmueller
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

2006-03-19 Thread Martin Vermeer
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

2006-03-19 Thread Abdelrazak Younes

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

2006-03-19 Thread Martin Vermeer
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

2006-03-19 Thread Abdelrazak Younes

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

2006-03-19 Thread Juergen Spitzmueller
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

2006-03-19 Thread Martin Vermeer

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

2006-03-19 Thread Paul Snively

-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

2006-03-19 Thread Martin Vermeer
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

2006-03-19 Thread Abdelrazak Younes

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

2006-03-19 Thread Enrico Forestieri
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

2006-03-19 Thread Angus Leeming
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

2006-03-19 Thread Angus Leeming

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

2006-03-19 Thread Angus Leeming

Changing subject for advertising reasons...
Angus



Re: LyX/Win 1.4.1 pre1

2006-03-19 Thread Lars Gullik Bjønnes
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

2006-03-19 Thread Angus Leeming

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

2006-03-19 Thread Lars Gullik Bjønnes
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

2006-03-19 Thread Lars Gullik Bjønnes
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

2006-03-19 Thread Enrico Forestieri
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

2006-03-19 Thread Paul
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

2006-03-19 Thread Lars Gullik Bjønnes

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

2006-03-19 Thread Enrico Forestieri
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

2006-03-19 Thread Paul
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

2006-03-19 Thread Stephen Harris

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

2006-03-19 Thread Bo Peng
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

2006-03-19 Thread Juergen Spitzmueller
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

2006-03-19 Thread Martin Vermeer
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

2006-03-19 Thread Martin Vermeer
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

2006-03-19 Thread Martin Vermeer
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

2006-03-19 Thread Georg Baum
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

2006-03-19 Thread Michael Gerz

[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

2006-03-19 Thread Michael Gerz

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

2006-03-19 Thread Michael Gerz

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

2006-03-19 Thread Michael Gerz

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

2006-03-19 Thread Georg Baum
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

2006-03-19 Thread Georg Baum
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

2006-03-19 Thread Michael Gerz

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

2006-03-19 Thread Juergen Spitzmueller
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

2006-03-19 Thread Michael Gerz

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

2006-03-19 Thread Lars Gullik Bjønnes
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.

2006-03-19 Thread Juergen Spitzmueller
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

2006-03-19 Thread Juergen Spitzmueller
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

2006-03-19 Thread Martin Vermeer
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

2006-03-19 Thread Abdelrazak Younes

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

2006-03-19 Thread Martin Vermeer
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

2006-03-19 Thread Abdelrazak Younes

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

2006-03-19 Thread Juergen Spitzmueller
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

2006-03-19 Thread Martin Vermeer

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

2006-03-19 Thread Paul Snively

-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

2006-03-19 Thread Martin Vermeer
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

2006-03-19 Thread Abdelrazak Younes

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

2006-03-19 Thread Enrico Forestieri
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

2006-03-19 Thread Angus Leeming
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

2006-03-19 Thread Angus Leeming

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

2006-03-19 Thread Angus Leeming

Changing subject for advertising reasons...
Angus



Re: LyX/Win 1.4.1 pre1

2006-03-19 Thread Lars Gullik Bjønnes
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

2006-03-19 Thread Angus Leeming

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

2006-03-19 Thread Lars Gullik Bjønnes
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

2006-03-19 Thread Lars Gullik Bjønnes
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

2006-03-19 Thread Enrico Forestieri
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

2006-03-19 Thread Paul
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

2006-03-19 Thread Lars Gullik Bjønnes

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

2006-03-19 Thread Enrico Forestieri
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

2006-03-19 Thread Paul
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

2006-03-19 Thread Stephen Harris

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

2006-03-19 Thread Bo Peng
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

2006-03-19 Thread Juergen Spitzmueller
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

2006-03-19 Thread Martin Vermeer
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

2006-03-19 Thread Martin Vermeer
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

2006-03-19 Thread Martin Vermeer
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