Re: [PATCH[ New LFUN: layout-reload

2007-09-11 Thread Jean-Marc Lasgouttes
Richard Heck [EMAIL PROTECTED] writes:

 Oh, it's not as bad as that, really. If the layout file can't be read,
 LyX will switch to something else, like Article (SGML), which is kind
 of a hassle. But it's not a critical error, and anyone who's editing
 their layouts shouldn't simultaneously be doing any serious work. So
 there isn't any real risk, I think, of data loss, and an appropriate
 warning could be issued. That said, since we do have a Save All...
 LFUN (we do now, right?) that could simply be called right before
 layout-reload does its actual work.

I am not sure I understand how it works: each paragraph has a Layout
pointer, right? How is this kept working after reloading the class?

JMarc


Re: [PATCH[ New LFUN: layout-reload

2007-09-11 Thread Richard Heck

Jean-Marc Lasgouttes wrote:

Richard Heck [EMAIL PROTECTED] writes:

  

Oh, it's not as bad as that, really. If the layout file can't be read,
LyX will switch to something else, like Article (SGML), which is kind
of a hassle. But it's not a critical error, and anyone who's editing
their layouts shouldn't simultaneously be doing any serious work. So
there isn't any real risk, I think, of data loss, and an appropriate
warning could be issued. That said, since we do have a Save All...
LFUN (we do now, right?) that could simply be called right before
layout-reload does its actual work.


I am not sure I understand how it works: each paragraph has a Layout
pointer, right? How is this kept working after reloading the class?
  
Whenever we reload the class, we do the update layout routine from 
CutAndPaste, which is what is used for any change of classes. So 
basically we're treating layout reload like change of class. The same 
thing gets done on loading of modules. So, basically, if the layout file 
can't be read, then you get switched to some other document class.


Richard

--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto



Re: [PATCH[ New LFUN: layout-reload

2007-09-11 Thread Jean-Marc Lasgouttes
Richard Heck [EMAIL PROTECTED] writes:

 Whenever we reload the class, we do the update layout routine from
 CutAndPaste, which is what is used for any change of classes. So
 basically we're treating layout reload like change of class. The same
 thing gets done on loading of modules. So, basically, if the layout
 file can't be read, then you get switched to some other document
 class.

I see. Thanks.

JMarc


Re: [PATCH[ New LFUN: layout-reload

2007-09-11 Thread Jean-Marc Lasgouttes
Richard Heck <[EMAIL PROTECTED]> writes:

> Oh, it's not as bad as that, really. If the layout file can't be read,
> LyX will switch to something else, like Article (SGML), which is kind
> of a hassle. But it's not a critical error, and anyone who's editing
> their layouts shouldn't simultaneously be doing any serious work. So
> there isn't any real risk, I think, of data loss, and an appropriate
> warning could be issued. That said, since we do have a "Save All..."
> LFUN (we do now, right?) that could simply be called right before
> layout-reload does its actual work.

I am not sure I understand how it works: each paragraph has a Layout
pointer, right? How is this kept working after reloading the class?

JMarc


Re: [PATCH[ New LFUN: layout-reload

2007-09-11 Thread Richard Heck

Jean-Marc Lasgouttes wrote:

Richard Heck <[EMAIL PROTECTED]> writes:

  

Oh, it's not as bad as that, really. If the layout file can't be read,
LyX will switch to something else, like Article (SGML), which is kind
of a hassle. But it's not a critical error, and anyone who's editing
their layouts shouldn't simultaneously be doing any serious work. So
there isn't any real risk, I think, of data loss, and an appropriate
warning could be issued. That said, since we do have a "Save All..."
LFUN (we do now, right?) that could simply be called right before
layout-reload does its actual work.


I am not sure I understand how it works: each paragraph has a Layout
pointer, right? How is this kept working after reloading the class?
  
Whenever we reload the class, we do the "update layout" routine from 
CutAndPaste, which is what is used for any change of classes. So 
basically we're treating layout reload like change of class. The same 
thing gets done on loading of modules. So, basically, if the layout file 
can't be read, then you get switched to some other document class.


Richard

--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto



Re: [PATCH[ New LFUN: layout-reload

2007-09-11 Thread Jean-Marc Lasgouttes
Richard Heck <[EMAIL PROTECTED]> writes:

> Whenever we reload the class, we do the "update layout" routine from
> CutAndPaste, which is what is used for any change of classes. So
> basically we're treating layout reload like change of class. The same
> thing gets done on loading of modules. So, basically, if the layout
> file can't be read, then you get switched to some other document
> class.

I see. Thanks.

JMarc


Re: [PATCH[ New LFUN: layout-reload

2007-09-10 Thread Jean-Marc Lasgouttes
Richard Heck [EMAIL PROTECTED] writes:

 This is a very simple patch made possible by the recent changes to how
 TextClasses are handled. It introduces a layout-reload LFUN that
 forces the current layout to be reloaded and re-read from disk. I
 don't propose to put this into the GUI. It's something that will be
 needed only by people who are modifying layouts, and it probably ought
 to come with warnings: If the layout file can't be read (say you make
 a syntax error), LyX's behavior is not terribly pretty. 

Yes, this is indeed the problem with such approaches. Is there a way
to mitigate the problem by re-reading all files afterwards?

JMarc


Re: [PATCH[ New LFUN: layout-reload

2007-09-10 Thread Richard Heck

Jean-Marc Lasgouttes wrote:

Richard Heck [EMAIL PROTECTED] writes:

  

This is a very simple patch made possible by the recent changes to how
TextClasses are handled. It introduces a layout-reload LFUN that
forces the current layout to be reloaded and re-read from disk. I
don't propose to put this into the GUI. It's something that will be
needed only by people who are modifying layouts, and it probably ought
to come with warnings: If the layout file can't be read (say you make
a syntax error), LyX's behavior is not terribly pretty. 


Yes, this is indeed the problem with such approaches. Is there a way
to mitigate the problem by re-reading all files afterwards?
  

I'm not sure what you mean here. After what?

rh


--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto



Re: [PATCH[ New LFUN: layout-reload

2007-09-10 Thread Jean-Marc Lasgouttes
Richard Heck [EMAIL PROTECTED] writes:

 I'm not sure what you mean here. After what?

Save all changed lyx file (after asking?) re-read layout files,
re-load lyx files.

JMarc


Re: [PATCH[ New LFUN: layout-reload

2007-09-10 Thread Richard Heck

Jean-Marc Lasgouttes wrote:

Richard Heck [EMAIL PROTECTED] writes:
  

I'm not sure what you mean here. After what?


Save all changed lyx file (after asking?) re-read layout files, re-load lyx 
files.
  
Oh, it's not as bad as that, really. If the layout file can't be read, 
LyX will switch to something else, like Article (SGML), which is kind of 
a hassle. But it's not a critical error, and anyone who's editing their 
layouts shouldn't simultaneously be doing any serious work. So there 
isn't any real risk, I think, of data loss, and an appropriate warning 
could be issued. That said, since we do have a Save All... LFUN (we do 
now, right?) that could simply be called right before layout-reload does 
its actual work.


Richard

--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto



Re: [PATCH[ New LFUN: layout-reload

2007-09-10 Thread Jean-Marc Lasgouttes
Richard Heck <[EMAIL PROTECTED]> writes:

> This is a very simple patch made possible by the recent changes to how
> TextClasses are handled. It introduces a layout-reload LFUN that
> forces the current layout to be reloaded and re-read from disk. I
> don't propose to put this into the GUI. It's something that will be
> needed only by people who are modifying layouts, and it probably ought
> to come with warnings: If the layout file can't be read (say you make
> a syntax error), LyX's behavior is not terribly pretty. 

Yes, this is indeed the problem with such approaches. Is there a way
to mitigate the problem by re-reading all files afterwards?

JMarc


Re: [PATCH[ New LFUN: layout-reload

2007-09-10 Thread Richard Heck

Jean-Marc Lasgouttes wrote:

Richard Heck <[EMAIL PROTECTED]> writes:

  

This is a very simple patch made possible by the recent changes to how
TextClasses are handled. It introduces a layout-reload LFUN that
forces the current layout to be reloaded and re-read from disk. I
don't propose to put this into the GUI. It's something that will be
needed only by people who are modifying layouts, and it probably ought
to come with warnings: If the layout file can't be read (say you make
a syntax error), LyX's behavior is not terribly pretty. 


Yes, this is indeed the problem with such approaches. Is there a way
to mitigate the problem by re-reading all files afterwards?
  

I'm not sure what you mean here. After what?

rh


--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto



Re: [PATCH[ New LFUN: layout-reload

2007-09-10 Thread Jean-Marc Lasgouttes
Richard Heck <[EMAIL PROTECTED]> writes:

> I'm not sure what you mean here. After what?

Save all changed lyx file (after asking?) re-read layout files,
re-load lyx files.

JMarc


Re: [PATCH[ New LFUN: layout-reload

2007-09-10 Thread Richard Heck

Jean-Marc Lasgouttes wrote:

Richard Heck <[EMAIL PROTECTED]> writes:
  

I'm not sure what you mean here. After what?


Save all changed lyx file (after asking?) re-read layout files, re-load lyx 
files.
  
Oh, it's not as bad as that, really. If the layout file can't be read, 
LyX will switch to something else, like Article (SGML), which is kind of 
a hassle. But it's not a critical error, and anyone who's editing their 
layouts shouldn't simultaneously be doing any serious work. So there 
isn't any real risk, I think, of data loss, and an appropriate warning 
could be issued. That said, since we do have a "Save All..." LFUN (we do 
now, right?) that could simply be called right before layout-reload does 
its actual work.


Richard

--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto



[PATCH[ New LFUN: layout-reload

2007-09-08 Thread Richard Heck


This is a very simple patch made possible by the recent changes to how 
TextClasses are handled. It introduces a layout-reload LFUN that forces 
the current layout to be reloaded and re-read from disk. I don't propose 
to put this into the GUI. It's something that will be needed only by 
people who are modifying layouts, and it probably ought to come with 
warnings: If the layout file can't be read (say you make a syntax 
error), LyX's behavior is not terribly pretty. (You can't do very much 
at all, since all the layouts are now invalid.) But it is still very, 
very useful if you are trying to create a new layout file not to have to 
restart LyX every time you make a change.


This is often mentioned on the user list.

Comments welcome.

By the way, there's a bug I introduced regarding layout files that can't 
be read. I'm working on that.


Richard

--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto

Index: src/lfuns.h
===
--- src/lfuns.h	(revision 20140)
+++ src/lfuns.h	(working copy)
@@ -402,6 +402,7 @@
 	LFUN_PARAGRAPH_PARAMS,   // rgh, 200708XX
 	LFUN_LAYOUT_MODULES_CLEAR,   // rgh, 20070825
 	LFUN_LAYOUT_MODULE_ADD,  // rgh, 20070825
+	LFUN_LAYOUT_RELOAD,  // rgh, 20070903
 
 	LFUN_LASTACTION  // end of the table
 };
Index: src/LyXAction.cpp
===
--- src/LyXAction.cpp	(revision 20140)
+++ src/LyXAction.cpp	(working copy)
@@ -374,6 +374,7 @@
 		{ LFUN_LISTING_INSERT, listing-insert, Noop },
 		{ LFUN_LAYOUT_MODULES_CLEAR, layout-modules-clear, Noop },
 		{ LFUN_LAYOUT_MODULE_ADD, layout-module-add, Noop },
+		{ LFUN_LAYOUT_RELOAD, layout-reload, Noop },
 
 		{ LFUN_NOACTION, , Noop }
 	};
Index: src/LyXFunc.cpp
===
--- src/LyXFunc.cpp	(revision 20140)
+++ src/LyXFunc.cpp	(working copy)
@@ -731,6 +731,7 @@
 	case LFUN_BUFFER_PARAMS_APPLY:
 	case LFUN_LAYOUT_MODULES_CLEAR:
 	case LFUN_LAYOUT_MODULE_ADD:
+	case LFUN_LAYOUT_RELOAD:
 	case LFUN_LYXRC_APPLY:
 	case LFUN_BUFFER_NEXT:
 	case LFUN_BUFFER_PREVIOUS:
@@ -1835,6 +1836,18 @@
 			updateFlags = Update::Force | Update::FitCursor;
 			break;
 		}
+		
+		case LFUN_LAYOUT_RELOAD: {
+			BOOST_ASSERT(lyx_view_);
+			Buffer * buffer = lyx_view_-buffer();
+			TextClass_ptr oldClass = buffer-params().getTextClass_ptr();
+			textclass_type const tc = buffer-params().getBaseClass();
+			textclasslist.reset(tc);
+			buffer-params().setBaseClass(tc);
+			updateLayout(oldClass, buffer);
+			updateFlags = Update::Force | Update::FitCursor;
+			break;
+		}
 
 		case LFUN_TEXTCLASS_LOAD:
 			loadTextclass(argument);
Index: src/TextClassList.h
===
--- src/TextClassList.h	(revision 20140)
+++ src/TextClassList.h	(working copy)
@@ -50,6 +50,9 @@
 
 	/// Read textclass list.  Returns false if this fails.
 	bool read();
+	
+	/// Clears the textclass so as to force it to be reloaded
+	void reset(textclass_type const textclass);
 
 	/// add a textclass from user local directory.
 	/// Return ture/false, and textclass number
Index: src/TextClassList.cpp
===
--- src/TextClassList.cpp	(revision 20140)
+++ src/TextClassList.cpp	(working copy)
@@ -66,11 +66,12 @@
 TextClass const 
 TextClassList::operator[](textclass_type textclass) const
 {
+	if (textclass = classlist_.size())
+		return classlist_[0];
+	
+	//FIXME I don't believe the following line is actually necessary (rgh)
 	classlist_[textclass].load();
-	if (textclass  classlist_.size())
-		return classlist_[textclass];
-	else
-		return classlist_[0];
+	return classlist_[textclass];
 }
 
 
@@ -175,6 +176,16 @@
 }
 
 
+void TextClassList::reset(textclass_type const textclass) {
+	if (textclass = classlist_.size())
+		return;
+	TextClass const  tc = classlist_[textclass];
+	TextClass tmpl(tc.name(), tc.latexname(), tc.description(), 
+	   tc.isTeXClassAvailable());
+	classlist_[textclass] = tmpl;
+}
+
+
 std::pairbool, textclass_type const
 TextClassList::addTextClass(std::string const  textclass, std::string const  path)
 {


[PATCH[ New LFUN: layout-reload

2007-09-08 Thread Richard Heck


This is a very simple patch made possible by the recent changes to how 
TextClasses are handled. It introduces a layout-reload LFUN that forces 
the current layout to be reloaded and re-read from disk. I don't propose 
to put this into the GUI. It's something that will be needed only by 
people who are modifying layouts, and it probably ought to come with 
warnings: If the layout file can't be read (say you make a syntax 
error), LyX's behavior is not terribly pretty. (You can't do very much 
at all, since all the layouts are now invalid.) But it is still very, 
very useful if you are trying to create a new layout file not to have to 
restart LyX every time you make a change.


This is often mentioned on the user list.

Comments welcome.

By the way, there's a bug I introduced regarding layout files that can't 
be read. I'm working on that.


Richard

--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto

Index: src/lfuns.h
===
--- src/lfuns.h	(revision 20140)
+++ src/lfuns.h	(working copy)
@@ -402,6 +402,7 @@
 	LFUN_PARAGRAPH_PARAMS,   // rgh, 200708XX
 	LFUN_LAYOUT_MODULES_CLEAR,   // rgh, 20070825
 	LFUN_LAYOUT_MODULE_ADD,  // rgh, 20070825
+	LFUN_LAYOUT_RELOAD,  // rgh, 20070903
 
 	LFUN_LASTACTION  // end of the table
 };
Index: src/LyXAction.cpp
===
--- src/LyXAction.cpp	(revision 20140)
+++ src/LyXAction.cpp	(working copy)
@@ -374,6 +374,7 @@
 		{ LFUN_LISTING_INSERT, "listing-insert", Noop },
 		{ LFUN_LAYOUT_MODULES_CLEAR, "layout-modules-clear", Noop },
 		{ LFUN_LAYOUT_MODULE_ADD, "layout-module-add", Noop },
+		{ LFUN_LAYOUT_RELOAD, "layout-reload", Noop },
 
 		{ LFUN_NOACTION, "", Noop }
 	};
Index: src/LyXFunc.cpp
===
--- src/LyXFunc.cpp	(revision 20140)
+++ src/LyXFunc.cpp	(working copy)
@@ -731,6 +731,7 @@
 	case LFUN_BUFFER_PARAMS_APPLY:
 	case LFUN_LAYOUT_MODULES_CLEAR:
 	case LFUN_LAYOUT_MODULE_ADD:
+	case LFUN_LAYOUT_RELOAD:
 	case LFUN_LYXRC_APPLY:
 	case LFUN_BUFFER_NEXT:
 	case LFUN_BUFFER_PREVIOUS:
@@ -1835,6 +1836,18 @@
 			updateFlags = Update::Force | Update::FitCursor;
 			break;
 		}
+		
+		case LFUN_LAYOUT_RELOAD: {
+			BOOST_ASSERT(lyx_view_);
+			Buffer * buffer = lyx_view_->buffer();
+			TextClass_ptr oldClass = buffer->params().getTextClass_ptr();
+			textclass_type const tc = buffer->params().getBaseClass();
+			textclasslist.reset(tc);
+			buffer->params().setBaseClass(tc);
+			updateLayout(oldClass, buffer);
+			updateFlags = Update::Force | Update::FitCursor;
+			break;
+		}
 
 		case LFUN_TEXTCLASS_LOAD:
 			loadTextclass(argument);
Index: src/TextClassList.h
===
--- src/TextClassList.h	(revision 20140)
+++ src/TextClassList.h	(working copy)
@@ -50,6 +50,9 @@
 
 	/// Read textclass list.  Returns false if this fails.
 	bool read();
+	
+	/// Clears the textclass so as to force it to be reloaded
+	void reset(textclass_type const textclass);
 
 	/// add a textclass from user local directory.
 	/// Return ture/false, and textclass number
Index: src/TextClassList.cpp
===
--- src/TextClassList.cpp	(revision 20140)
+++ src/TextClassList.cpp	(working copy)
@@ -66,11 +66,12 @@
 TextClass const &
 TextClassList::operator[](textclass_type textclass) const
 {
+	if (textclass >= classlist_.size())
+		return classlist_[0];
+	
+	//FIXME I don't believe the following line is actually necessary (rgh)
 	classlist_[textclass].load();
-	if (textclass < classlist_.size())
-		return classlist_[textclass];
-	else
-		return classlist_[0];
+	return classlist_[textclass];
 }
 
 
@@ -175,6 +176,16 @@
 }
 
 
+void TextClassList::reset(textclass_type const textclass) {
+	if (textclass >= classlist_.size())
+		return;
+	TextClass const & tc = classlist_[textclass];
+	TextClass tmpl(tc.name(), tc.latexname(), tc.description(), 
+	   tc.isTeXClassAvailable());
+	classlist_[textclass] = tmpl;
+}
+
+
 std::pair const
 TextClassList::addTextClass(std::string const & textclass, std::string const & path)
 {