Re: update(), second try

[Lars Gullik Bjønnes]

Andre Poenitz <[EMAIL PROTECTED]> writes:

| Index: rowpainter.C

Ok, I will try this out later tonight. (Sorry that I cannot test it
earlier.)

-- 
Lgb

Re: update(), second try

[Andre Poenitz]

On Tue, Jun 03, 2003 at 05:25:48PM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
> 
> | Index: rowpainter.C
> 
> Ok, I will try this out later tonight. (Sorry that I cannot test it
> earlier.)

Fine with me.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: Pasting the "wrong" inset.

[Lars Gullik Bjønnes]

John Levon <[EMAIL PROTECTED]> writes:

| On Tue, Jun 03, 2003 at 04:21:14PM +, Angus Leeming wrote:
| 
| > // A 'paste' operation creates a new inset with the correct filepath,
| > // but then the 'old' inset stored in the 'copy' operation is actually
| > // added to the buffer.
| 
| I don't see how this can happen. We clone the inset used in cut_clone.

Note that some of the implementation changed as part of the
CutAndPaste work some weeks ago.

-- 
Lgb

boost::trackable confusion

[Angus Leeming]

 #warning I have zero idea about the trackable()
 InsetGraphics::InsetGraphics(InsetGraphics const & ig)
: Inset(ig),
- boost::signals::trackable(ig),
+ boost::signals::trackable(),
  graphic_label(uniqueID()),
  cache_(new Cache(*this))
{
setParams(ig.params());
}


Fortunately, I do ;-)

trackable is tracking the existence of this instance of the class, or will 
do once a signal is connected to return to it.

There has been no attempt yet to connect a signal from the GraphicsLoader to 
this->statusChanged() so there is no need for trackable to track anything 
yet.

Make sense now?

(I'll fix it.)

-- 
Angus

Re: boost::trackable confusion

[John Levon]

On Tue, Jun 03, 2003 at 04:34:24PM +, Angus Leeming wrote:

> There has been no attempt yet to connect a signal from the GraphicsLoader to 
> this->statusChanged() so there is no need for trackable to track anything 
> yet.
> 
> Make sense now?
> 
> (I'll fix it.)

OK, thanks a lot Angus

regards
john

Re: [1.3.2] Don't assume sys/select.h exists

[John Levon]

On Tue, Jun 03, 2003 at 01:31:51AM -0500, Albert Chin wrote:

>  Doesn't exist on HP-UX 11.x. Patch below against 1.3.2.

Applied to CVS thanks. JMarc ?

john

Re: Pasting the "wrong" inset.

[Angus Leeming]

Lars Gullik Bjønnes wrote:

> Angus Leeming <[EMAIL PROTECTED]> writes:
> 
> | Sometime ago I put the following message into InsetGraphic::draw
> | 
> | // MakeAbsPath returns filename_ unchanged if it is absolute
> | // already.
> | string const file_with_path =
> | MakeAbsPath(params_.filename, bv->buffer()->filePath());
> | 
> | // A 'paste' operation creates a new inset with the correct
> | filepath, // but then the 'old' inset stored in the 'copy'
> | operation is actually // added to the buffer.
> | // Thus, we should ensure that the filepath is correct.
> | if (file_with_path != loader_.filename()) {
> | params_.filename = file_with_path;
> | update(params_);
> | }
> | 
> | I suspect that John's changes to store the absolute path name internally
> | will have cured the symptoms of this problem, but it would be nice if
> | paste used the correct inset...
> 
> I do not quite get what you are at? Can you elaborate a bit?

Sure. Sometime _last year_ I put this message into the method.

Until John's clone patch, we stored the file internally sometimes with a 
relative path to the buffer and sometimes with an absolute path.

If it were stored with a relative path in subdir/file.eps and I _cut_ it and 
pasted it into a new buffer with a different buffer->filePath(), we failed 
to find the graphics file.

It turned out --- lots of digging --- that we were doing what I describe 
above.

I don't know if this is still the case and suspect that the problem will be 
hidden if it is (because the absolute file path is now stored internally). 
Nonetheless it would appear to be a bug waiting to bite again.

-- 
Angus

Re: Pasting the "wrong" inset.

[Angus Leeming]

Angus Leeming wrote:

> If it were stored with a relative path in subdir/file.eps and I cut it and
> pasted it into a new buffer with a different buffer->filePath(), we failed
> to find the graphics file.

Actually, this description is exactly wrong ;-)

If the file is stored with a relative path and I either cut it or copy it 
and then paste it into a buffer with a different buffer->filePath(), then 
LyX _finds_ and displays it. Of course, no file exists at this absolute 
(new buffer) + (relative path to graphic file) location, so we should fail 
to find it and display nothing.

And yes, the bug still exists. Ie, paste is shoving in the "wrong" inset.

-- 
Angus

Re: Pasting the "wrong" inset.

[John Levon]

On Tue, Jun 03, 2003 at 05:00:35PM +, Angus Leeming wrote:

> If the file is stored with a relative path and I either cut it or copy it 
> and then paste it into a buffer with a different buffer->filePath(), then 
> LyX _finds_ and displays it. Of course, no file exists at this absolute 
> (new buffer) + (relative path to graphic file) location, so we should fail 
> to find it and display nothing.

If I'm understanding you correctly then I strongly disagree. The
computer shouldn't act like a moron. If it knows where the file is (and
it does), then when I paste it into another document, it should get
added there. We should handle all the relative path stuff automatically
... and we do now.

Previously (storing relative path in the params) it would break even if
the user did Save As. That's obviously not too clever.

Example: I have two docs /foo/a.lyx and /bar/b.lyx, and a graphics file
/foo/a.eps

a.lyx when loaded contains a graphics inset with a graphics path
"/foo/a.eps". I cut and paste that into b.lyx. Now that contains
"/foo/a.eps". All works as is. The former is *saved* as "a.eps" and the
latter as "/foo/a.eps", and that's what we show the user, but that's
all.

The only corner case I'm aware of is if the user does mv /foo /baz
Then in the current code we'll not be able to find the image unless the
user reloads the document as /baz/a.lyx. But I don't see a "smart" way
around that.

> And yes, the bug still exists. Ie, paste is shoving in the "wrong" inset.

I totally don't get this sorry :/

john

Re: Pasting the "wrong" inset.

[Angus Leeming]

John Levon wrote:

> On Tue, Jun 03, 2003 at 05:00:35PM +, Angus Leeming wrote:
> 
>> If the file is stored with a relative path and I either cut it or copy it
>> and then paste it into a buffer with a different buffer->filePath(), then
>> LyX _finds_ and displays it. Of course, no file exists at this absolute
>> (new buffer) + (relative path to graphic file) location, so we should
>> fail to find it and display nothing.
> 
> If I'm understanding you correctly then I strongly disagree. The
> computer shouldn't act like a moron. If it knows where the file is (and
> it does), then when I paste it into another document, it should get
> added there. We should handle all the relative path stuff automatically
> ... and we do now.

Then it should also display the correct path (presumably now absolute) when 
I open the dialog. And here, where I have removed the fudge I describe, it 
does not.

> I totally don't get this sorry :/

Because the fudge I pointed out in draw still exists in your tree.

-- 
Angus

Re: [patch] update, re-done

[John Levon]

On Tue, Jun 03, 2003 at 05:19:16PM +0200, Andre Poenitz wrote:

> Index: rowpainter.C

My experience mirrors yours: everything works fine, except tabular,
which is significantly broken.

I suspect that if we somehow force a "redo" in tabularFeature()
somewhere, things will behave better. But the form of this redo ...

regards
john

Re: Pasting the "wrong" inset.

[John Levon]

On Tue, Jun 03, 2003 at 05:21:56PM +, Angus Leeming wrote:

> Then it should also display the correct path (presumably now absolute) when 
> I open the dialog. And here, where I have removed the fudge I describe, it 
> does not.

Why ? The document is saved with relative paths. The absolute path thing
is basically an implementation detail.

> Because the fudge I pointed out in draw still exists in your tree.

InsetGraphics::draw ? Where ? I thought I'd removed it

regards
john

[patch]: clean-up InsetGraphics::Cache and make it accessible to all

[Angus Leeming]

This cleans up InsetGraphics::Cache and renames it as GraphicsInset so that 
the external inset can use it too.

-- 
AngusIndex: src/insets/graphicinset.h
===
RCS file: src/insets/graphicinset.h
diff -N src/insets/graphicinset.h
--- /dev/null	1 Jan 1970 00:00:00 -
+++ src/insets/graphicinset.h	3 Jun 2003 17:13:29 -
@@ -0,0 +1,90 @@
+// -*- C++ -*-
+/**
+ * \file graphicinset.h
+ * This file is part of LyX, the document processor.
+ * Licence details can be found in the file COPYING.
+ *
+ * \author Angus Leeming
+ *
+ * Full author contact details are available in file CREDITS
+ */
+
+#ifndef GRAPHICINSET_H
+#define GRAPHICINSET_H
+
+#include "dimension.h"
+
+#include "graphics/GraphicsLoader.h"
+#include "graphics/GraphicsParams.h"
+#include "graphics/GraphicsTypes.h"
+
+#include 
+#include 
+
+
+class MetricsInfo;
+class PainterInfo;
+
+
+class GraphicInset
+{
+public:
+	GraphicInset();
+	GraphicInset(GraphicInset const &);
+
+	/** Set the message that the inset will show when the
+	 *  display of the graphic is deactivated.
+	 *  The default is nothing, meaning that the inset will
+	 *  show a message descibing the state of the image
+	 *  loading process.
+	 */
+	void setNoDisplayMessage(string const & msg);
+	
+	/// Refresh the info about which file to display and how to display it.
+	void update(grfx::Params const & params);
+	/// File name, image size, rotation angle etc.
+	grfx::Params const & params() const;
+
+	/// compute the size of the object returned in dim
+	void metrics(MetricsInfo & mi, Dimension & dim) const;
+	/// draw inset and update (xo, yo)-cache
+	void draw(PainterInfo & pi, int x, int y) const;
+
+	/// Is the stored checksum different to that of the graphics loader?
+	bool hasFileChanged() const;
+	/// An accessor function to the cached store.
+	BufferView * view() const;
+
+	/** Connect and you'll be informed when the loading status of the image
+	 *  changes.
+	 */
+	typedef boost::signal0::slot_type slot_type;
+	boost::signals::connection connect(slot_type const &) const;
+
+private:
+	enum DisplayType {
+		IMAGE,
+		STATUS_MESSAGE,
+		NODISPLAY_MESSAGE
+	};
+
+	/// Is the image ready to draw, or should we display a message instead?
+	DisplayType displayType() const;
+	
+	/// The message to display instead of the graphic itself.
+	string const statusMessage() const;
+
+	/// The stored data.
+	grfx::Loader loader_;
+	grfx::Params params_;
+	string nodisplay_message_;
+
+	/// These are all cached variables.
+	mutable int old_ascent_;
+	mutable unsigned long checksum_;
+	mutable boost::weak_ptr view_;
+	mutable Dimension dim_;
+};
+
+
+#endif // NOT GRAPHICINSET_H
Index: src/insets/graphicinset.C
===
RCS file: src/insets/graphicinset.C
diff -N src/insets/graphicinset.C
--- /dev/null	1 Jan 1970 00:00:00 -
+++ src/insets/graphicinset.C	3 Jun 2003 17:13:30 -
@@ -0,0 +1,287 @@
+/**
+ * \file graphicinset.C
+ * This file is part of LyX, the document processor.
+ * Licence details can be found in the file COPYING.
+ *
+ * \author Angus Leeming
+ *
+ * Full author contact details are available in file CREDITS
+ */
+
+#include 
+
+#include "insets/graphicinset.h"
+
+#include "buffer.h"
+#include "BufferView.h"
+#include "gettext.h"
+#include "metricsinfo.h"
+
+#include "frontends/font_metrics.h"
+#include "frontends/LyXView.h"
+#include "frontends/Painter.h"
+
+#include "graphics/GraphicsImage.h"
+
+#include "support/filetools.h"
+
+
+GraphicInset::GraphicInset()
+	: old_ascent_(0), checksum_(0)
+{}
+
+
+GraphicInset::GraphicInset(GraphicInset const & other)
+	: loader_(other.loader_),
+	  params_(other.params_),
+	  nodisplay_message_(other.nodisplay_message_),
+	  old_ascent_(0),
+	  checksum_(0)
+{}
+
+
+void GraphicInset::update(grfx::Params const & params)
+{
+	if (!params.filename.empty()) {
+		lyx::Assert(AbsolutePath(params.filename));
+		loader_.reset(params_.filename, params_);
+	}
+	params_ = params;
+}
+
+
+grfx::Params const & GraphicInset::params() const
+{
+	return params_;
+}
+
+
+bool GraphicInset::hasFileChanged() const
+{
+	unsigned long const new_checksum = loader_.checksum();
+	bool const file_has_changed = checksum_ != new_checksum;
+	if (file_has_changed)
+		checksum_ = new_checksum;
+	return file_has_changed;
+}
+
+
+BufferView * GraphicInset::view() const
+{
+	return view_.lock().get();
+}
+
+
+boost::signals::connection GraphicInset::connect(slot_type const & slot) const
+{
+	return loader_.connect(slot);
+}
+
+
+void GraphicInset::setNoDisplayMessage(string const & str)
+{
+	nodisplay_message_ = str;
+}
+
+
+string const GraphicInset::statusMessage() const
+{
+	switch (loader_.status()) {
+		case grfx::WaitingToLoad:
+			return _("Not shown.");
+		case grfx::Loading:
+			return _("Loading...");
+		case grfx::Converting:
+			return _("Converting to loadable format...");
+		case grfx::Loaded:
+			return _("Loaded into 

Using Qt designer

[Angus Leeming]

I'm trying to get to grips with Qt's designer (I am using Qt2's designer. I 
think that's correct isn't it?)

Attached is a screenshot of what I've got so far for the External dialog. 
I'm trying to add some widgets to control the appearence of the inset 
within LyX. Basically, I'm just copying the equivalent stuff in the 
Graphics dialog.

You can see how I've grouped the various widgets together. Look Ok?

My question: how do I tell them they're sitting in the "LyX Display" frame. 
Thereafter, how do I layout this frame within the whole dialog. Seems I've 
got stuck.

-- 
Angus<>

Re: Using Qt designer

[Angus Leeming]

Angus Leeming wrote:

> I'm trying to get to grips with Qt's designer (I am using Qt2's designer.
> I think that's correct isn't it?)
> 
> Attached is a screenshot of what I've got so far for the External dialog.
> I'm trying to add some widgets to control the appearence of the inset
> within LyX. Basically, I'm just copying the equivalent stuff in the
> Graphics dialog.
> 
> You can see how I've grouped the various widgets together. Look Ok?
> 
> My question: how do I tell them they're sitting in the "LyX Display"
> frame. Thereafter, how do I layout this frame within the whole dialog.
> Seems I've got stuck.

Ahhh! Click that lil' ol' grid icon on the toolbar. Once for the frame and 
once for the whole dialog. Too easy for an old codger!

-- 
Angus

Re: Using Qt designer

[John Levon]

On Tue, Jun 03, 2003 at 07:11:43PM +, Angus Leeming wrote:

> I'm trying to get to grips with Qt's designer (I am using Qt2's designer. I 
> think that's correct isn't it?)

Yes.

> You can see how I've grouped the various widgets together. Look Ok?

I would place the template combo at the top, as it is dominant over the
other stuff. And possibly make it a grooup box so it's obvious what is
in the text area. Even better, would be to change the visual look of the
text area so it's not sunken...

> My question: how do I tell them they're sitting in the "LyX Display" frame. 

They're probably there. If you drag the frame, do they follow ?

Right click in the frame and choose the option to lay out the children
as a grid, horiz or vert.

> Thereafter, how do I layout this frame within the whole dialog. Seems I've 
> got stuck.

Same thing. Generally if you lay it roughly out, then "Layout as grid"
works.

But don't worry too much, I can do details stuff if you like

regards
john

Re: Using Qt designer

[Angus Leeming]

John Levon wrote:

>> You can see how I've grouped the various widgets together. Look Ok?
> 
> I would place the template combo at the top, as it is dominant over the
> other stuff. And possibly make it a grooup box so it's obvious what is
> in the text area. Even better, would be to change the visual look of the
> text area so it's not sunken...

Well I've put the template at the top.

> But don't worry too much, I can do details stuff if you like

I'll continue to play willing.

I've connected the signals and slots and have added code to 
QExternal::update_contents and QExternal::apply.

Question. xforms has input filters. In this case I have 
fl_set_input_filter(dialog_->input_lyxscale, fl_unsigned_int_filter);

Is there any equivalent in the Qt code?

-- 
Angus

Re: Using Qt designer

[John Levon]

On Tue, Jun 03, 2003 at 08:02:23PM +, Angus Leeming wrote:

> Question. xforms has input filters. In this case I have 
> fl_set_input_filter(dialog_->input_lyxscale, fl_unsigned_int_filter);
> 
> Is there any equivalent in the Qt code?

http://doc.trolltech.com/2.3/qlineedit.html#766d94

john

Re: Using Qt designer

[Angus Leeming]

John Levon wrote:

> On Tue, Jun 03, 2003 at 08:02:23PM +, Angus Leeming wrote:
> 
>> Question. xforms has input filters. In this case I have
>> fl_set_input_filter(dialog_->input_lyxscale,
>> fl_unsigned_int_filter);
>> 
>> Is there any equivalent in the Qt code?
> 
> http://doc.trolltech.com/2.3/qlineedit.html#766d94
> 
> john

Hmmm. I guess you don't use it much:

$ grep setValidator * */* */*/*
QParagraphDialog.C: linespacingValue->setValidator(new 
QDoubleValidator(linespacingValue));

Any reason why not?

-- 
Angus

Re: Using Qt designer

[John Levon]

On Tue, Jun 03, 2003 at 08:28:46PM +, Angus Leeming wrote:

> Hmmm. I guess you don't use it much:
> Any reason why not?

Most of them are units dialogs. But no, no real reason for the others.

(bug: qtabular doesn't take units for the col width)

john

Re: [1.3.2] Don't assume sys/select.h exists

[Jean-Marc Lasgouttes]

> "John" == John Levon <[EMAIL PROTECTED]> writes:

John> On Tue, Jun 03, 2003 at 01:31:51AM -0500, Albert Chin wrote:
>>  Doesn't exist on HP-UX 11.x. Patch below against
>> 1.3.2.

John> Applied to CVS thanks. JMarc ?

If you don't apply it to 1.3.X, I will have to do it myself...

JMarc

Re: [1.3.2] Don't assume sys/select.h exists

[John Levon]

On Tue, Jun 03, 2003 at 10:44:15PM +0200, Jean-Marc Lasgouttes wrote:

> If you don't apply it to 1.3.X, I will have to do it myself...

Why, such subtlety :)

done

regards
john

[patch]: the external inset reworking.

[Angus Leeming]

I attach my changes to the external inset and dialogs. I think that it is 
pretty close to finished. Please feel free to try it out. Note that there 
is a file format change so don't save any important docs with it.

Note that the default is NoDisplay meaning that you'll get a button
[ Xfig: file.fig ]
Click on the inset to pop up the dialog to change that.

The next step will be to remove the parameters variable from the 
InsetExternal::Params struct. I'll take the opportunity then to rewrite the 
InsetExternal::Read and Write methods to be less clunky. (Ie, Read will use 
lyxlex properly.) At the moment the external inset is written as

\begin_inset External RasterImage,"taulogo.png",""

where the last field is the (effectively redundant) params variable.

The patch changes this to

\begin_inset External RasterImage,"taulogo.png","",,

which is still clunky. After this patch is applied I'll change it to 
something more like the Graphics Inset:

\begin_inset External
template RasterImage
filename taulogo.png
lyxscale 80
display color

These last two will be output only if different from the default 100 and 
NoDisplay respectively.


Attached are two files.
external.diff.gz contains the changes to the LyX source.
external.tar.gz will expand to a directory External containing a small lyx 
document to test out the external inset with.

If nobody says otherwise, I'll probably apply what I have sometime 
tomorrow...

-- 
Angus

external.diff.gz
Description: GNU Zip compressed data


external.tar.gz
Description: GNU Zip compressed data

[lrathle@kde-france.org: lyx-1.3.2-1mdk91-qt.i586.rpm]

[Kayvan A. Sylvan]

Can anyone answer this for Laurent?

- Forwarded message from Laurent Rathle <[EMAIL PROTECTED]> -

From: Laurent Rathle <[EMAIL PROTECTED]>
Organization: Kde france
To: [EMAIL PROTECTED]
Subject: lyx-1.3.2-1mdk91-qt.i586.rpm
Date: Tue, 3 Jun 2003 23:46:51 +0200
User-Agent: KMail/1.5


Hello,

There is a little problem with the lix package for Mandrake 9.1. It does'nt 
want to install since it ask for Qt 2 and Mandrake 9.1 is Qt 3.1.1.

Thank you for your work,

Have a nice evening,

-- 
[EMAIL PROTECTED]
http://www.kde-france.org

- End forwarded message -

-- 
Kayvan A. Sylvan  | Proud husband of   | Father to my kids:
Sylvan Associates, Inc.   | Laura Isabella Sylvan  | Katherine Yelena (8/8/89)
http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)

Re: [patch] update, re-done

[Lars Gullik Bjønnes]

John Levon <[EMAIL PROTECTED]> writes:

| On Tue, Jun 03, 2003 at 05:19:16PM +0200, Andre Poenitz wrote:
| 
| > Index: rowpainter.C
| 
| My experience mirrors yours: everything works fine, except tabular,
| which is significantly broken.

Any idea why it is broken? Can it easily be fixed?
I am not so sure that we want to introduce known regressions at this
stage.

-- 
Lgb

Re: [patch] update, re-done

[John Levon]

On Wed, Jun 04, 2003 at 12:31:17AM +0200, Lars Gullik Bj?nnes wrote:

> Any idea why it is broken?

Not in any concrete sense.

> Can it easily be fixed?

I strongly doubt it. The difficult part is not construction but
discovery. But  that is just a guess.

> I am not so sure that we want to introduce known regressions at this
> stage.

I agree. Let's fix undo first.

regards
john

Re: [patch]: clean-up InsetGraphics::Cache and make it accessible to all

[Andre Poenitz]

On Tue, Jun 03, 2003 at 06:17:10PM +, Angus Leeming wrote:
> This cleans up InsetGraphics::Cache and renames it as GraphicsInset so that 
> the external inset can use it too.

What do you need old_ascent_ for?

+   old_ascent_ = (type == IMAGE) ? loader_.image()->getHeight() : 50;
+
+   dim.asc = old_ascent_;
+   dim.des = 0;
+   [...]
+   dim_ = dim;

You could use  dim_.asc  instead...

Andre'

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: [patch] update, re-done

[Andre Poenitz]

On Wed, Jun 04, 2003 at 12:31:17AM +0200, Lars Gullik Bjønnes wrote:
> John Levon <[EMAIL PROTECTED]> writes:
> 
> | On Tue, Jun 03, 2003 at 05:19:16PM +0200, Andre Poenitz wrote:
> | 
> | > Index: rowpainter.C
> | 
> | My experience mirrors yours: everything works fine, except tabular,
> | which is significantly broken.
> 
> Any idea why it is broken?

Probably because I copied just a single line out of 47 from
InsetTabular::update over to InsetTabular::metrics and some other line
in there does something sensible, too.

> Can it easily be fixed?

There is no technical reason why it cannot work.

> I am not so sure that we want to introduce known regressions at this
> stage.

I'll have a look again later...

Andre'

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

[patch] undo (partial...)

[Andre Poenitz]

This makes undo partially work. It crashes always when used in the last
par and after "complicated" operations, but it works if used in the middle
of the text for simple insertions/deletions, sometimes even multi-par
stuff. 

In any case, this is somewhat beter than what we have now.

Note that I had to implement Paragraph::operator=() (Lars, you are a
naughty boy...). Replace it with something closer to your taste if you
want. The swap idiom is a bit more work here because the inset owners
need to be set..

Next change i the return type of limited_stack::top(). It's (a) used this
way and (b) consistent with std::stack<> now.

The rest is undo specific stuff, some simplification of the logic and some
code to 'make it work'.

Ok?

[Note that the logic might even get simpler if we would not use paragraph
ids, but ParagraphList ids and use distances from plist->begin() instead of
'first_id' and from plist->end() fo 'last_id'.

In that case, undo would not need Paragraph::id anymore and possibly no
Inset::id, too.]

Andre'


-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Index: buffer.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.h,v
retrieving revision 1.143
diff -u -p -r1.143 buffer.h
--- buffer.h2 Jun 2003 14:02:58 -   1.143
+++ buffer.h4 Jun 2003 06:09:49 -
@@ -23,7 +23,6 @@
 #include "author.h"
 #include "iterators.h"
 
-#include 
 #include 
 
 class BufferView;
@@ -273,10 +272,10 @@ public:
bool isMultiLingual();
 
/// Does this mean that this is buffer local?
-   limited_stack undostack;
+   limited_stack undostack;
 
/// Does this mean that this is buffer local?
-   limited_stack redostack;
+   limited_stack redostack;
 
///
BufferParams params;
Index: lyxfunc.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxfunc.C,v
retrieving revision 1.448
diff -u -p -r1.448 lyxfunc.C
--- lyxfunc.C   2 Jun 2003 14:19:29 -   1.448
+++ lyxfunc.C   4 Jun 2003 06:09:49 -
@@ -501,7 +501,7 @@ FuncStatus LyXFunc::getStatus(FuncReques
// jump back to owner if an InsetText, so
// we get back to the InsetTabular or whatever
if (inset->lyxCode() == Inset::TEXT_CODE)
-   inset = static_cast(inset->owner());
+   inset = inset->owner();
 
Inset::Code code = inset->lyxCode();
switch (code) {
Index: paragraph.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/paragraph.C,v
retrieving revision 1.280
diff -u -p -r1.280 paragraph.C
--- paragraph.C 3 Jun 2003 15:10:07 -   1.280
+++ paragraph.C 4 Jun 2003 06:09:49 -
@@ -97,6 +97,31 @@ Paragraph::Paragraph(Paragraph const & l
 }
 
 
+void Paragraph::operator=(Paragraph const & lp)
+{
+   if ( != this)
+   return;
+   lyxerr << "Paragraph::operator=()\n";
+   delete pimpl_;
+   pimpl_ = new Pimpl(*lp.pimpl_, this);
+
+   enumdepth = lp.enumdepth;
+   itemdepth = lp.itemdepth;
+   // this is because of the dummy layout of the paragraphs that
+   // follow footnotes
+   layout_ = lp.layout();
+
+   // copy everything behind the break-position to the new paragraph
+   insetlist = lp.insetlist;
+   InsetList::iterator it = insetlist.begin();
+   InsetList::iterator end = insetlist.end();
+   for (; it != end; ++it) {
+   it->inset = it->inset->clone();
+   // tell the new inset who is the boss now
+   it->inset->parOwner(this);
+   }
+}
+
 // the destructor removes the new paragraph from the list
 Paragraph::~Paragraph()
 {
@@ -1205,14 +1230,14 @@ string const Paragraph::asString(Buffer 
 }
 
 
-void Paragraph::setInsetOwner(Inset * i)
+void Paragraph::setInsetOwner(UpdatableInset * inset)
 {
-   pimpl_->inset_owner = i;
+   pimpl_->inset_owner = inset;
InsetList::iterator it = insetlist.begin();
InsetList::iterator end = insetlist.end();
for (; it != end; ++it)
if (it->inset)
-   it->inset->setOwner(i);
+   it->inset->setOwner(inset);
 }
 
 
@@ -1350,7 +1375,7 @@ void Paragraph::layout(LyXLayout_ptr con
 }
 
 
-Inset * Paragraph::inInset() const
+UpdatableInset * Paragraph::inInset() const
 {
return pimpl_->inset_owner;
 }
Index: paragraph.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/paragraph.h,v
retrieving revision 1.86
diff -u -p -r1.86 paragraph.h
--- paragraph.h 3 Jun 2003 15:10:07 -   1.86
+++ paragraph.h 4 Jun 

preamble

[Andre Poenitz]

The preamble dialog is not nice to use (not just the size, but the
editing is very limited at least under xforms).

So what about using a InsetPreamble (some collapsable inset, perhaps on top
of InsertERT) instead of the separate preamble dialog?

Technically there is no problem: It simply adds its contents to the written
preamble in validate(), it gets added a the begin of a doc when read from
the .lyx.

For editing we could use all the 'main LyX editing features' and are not
limited to what xforms provides. 

I was thinking about doing something similar for the math macro definitions
anyway, so everything would be more consistent this way, too...

Opinions?

Andre' 

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: [patch] undo (partial...)

[Lars Gullik Bjønnes]

Andre Poenitz <[EMAIL PROTECTED]> writes:

| This makes undo partially work. It crashes always when used in the last
| par and after "complicated" operations, but it works if used in the middle
| of the text for simple insertions/deletions, sometimes even multi-par
| stuff. 
| 
| In any case, this is somewhat beter than what we have now.

Good... and long as it gets better we should push on.
 
| Note that I had to implement Paragraph::operator=() (Lars, you are a
| naughty boy...).

I had it implemented (with swap), but that was before the clone
fixes... so it did not really compile :-/

| Replace it with something closer to your taste if you
| want. The swap idiom is a bit more work here because the inset owners
| need to be set..

Not if a proper operator= is implemented for InsetList.
(a setOwner will still be needed though).
 
| Next change i the return type of limited_stack::top(). It's (a) used this
| way and (b) consistent with std::stack<> now.

ok.
 
| The rest is undo specific stuff, some simplification of the logic and some
| code to 'make it work'.
| 
| Ok?

Yes.

-- 
Lgb

Re: preamble

[Lars Gullik Bjønnes]

Andre Poenitz <[EMAIL PROTECTED]> writes:

| The preamble dialog is not nice to use (not just the size, but the
| editing is very limited at least under xforms).
| 
| So what about using a InsetPreamble (some collapsable inset, perhaps on top
| of InsertERT) instead of the separate preamble dialog?

Have I said this about hundred times now?: We need an InsetEditor
 
| Technically there is no problem: It simply adds its contents to the written
| preamble in validate(), it gets added a the begin of a doc when read from
| the .lyx.
| 
| For editing we could use all the 'main LyX editing features' and are not
| limited to what xforms provides. 
| 
| I was thinking about doing something similar for the math macro definitions
| anyway, so everything would be more consistent this way, too...
| 
| Opinions?

I am not alian to this idea.

But I do not think that this inset should be allowed anywhere... IMHO
only at the _very_ beginning of the document. And only one of them.

-- 
Lgb

Re: preamble

[Andre Poenitz]

On Wed, Jun 04, 2003 at 08:56:30AM +0200, Lars Gullik Bjønnes wrote:
> But I do not think that this inset should be allowed anywhere... IMHO
> only at the _very_ beginning of the document. And only one of them.

This would be naturally enforced when reading a .lyx file.

It would be just a few lines to prevent the insertion of a second 'preamble
inset' in the doc, it would be a bit more difficult to fix the position of
the inset at the beginning of the doc

Andre'

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: [patch]: the external inset reworking.

[Alfredo Braunstein]

Angus Leeming wrote:

> These last two will be output only if different from the default 100 and
> NoDisplay respectively.

Maybe it may make sense to keep the default value for NoDisplay somewhere...
like on the template (then it should be output in any case, though)?

> If nobody says otherwise, I'll probably apply what I have sometime
> tomorrow...
 
I say something: cool.  


Regards, Alfredo

Re: preamble

[Lars Gullik Bjønnes]

Andre Poenitz <[EMAIL PROTECTED]> writes:

| On Wed, Jun 04, 2003 at 08:56:30AM +0200, Lars Gullik Bjønnes wrote:
| > But I do not think that this inset should be allowed anywhere... IMHO
| > only at the _very_ beginning of the document. And only one of them.
| 
| This would be naturally enforced when reading a .lyx file.

Not all documents are read... some are created from scratch...
 
| It would be just a few lines to prevent the insertion of a second 'preamble
| inset' in the doc, it would be a bit more difficult to fix the position of
| the inset at the beginning of the doc

Would it? 

LFUN_INSERT_PREAMBLE would only insert at paragraphs.begin()[0] and
only allow one.

-- 
Lgb

Re: [patch]: clean-up InsetGraphics::Cache and make it accessible to all

[Angus Leeming]

Andre Poenitz wrote:

> On Tue, Jun 03, 2003 at 06:17:10PM +, Angus Leeming wrote:
>> This cleans up InsetGraphics::Cache and renames it as GraphicsInset so
>> that the external inset can use it too.
> 
> What do you need old_ascent_ for?
> 
> +   old_ascent_ = (type == IMAGE) ? loader_.image()->getHeight() : 50;
> +
> +   dim.asc = old_ascent_;
> +   dim.des = 0;
> +   [...]
> +   dim_ = dim;
> 
> You could use  dim_.asc  instead...

This is what I call "Juergen magic". I didn't really understand it then. I 
still don't. If you tell me that it is "premature optimization" then I will 
remove it.

-- 
Angus

Re: preamble

[Andre Poenitz]

On Wed, Jun 04, 2003 at 09:44:09AM +0200, Lars Gullik Bjønnes wrote:
> | It would be just a few lines to prevent the insertion of a second 'preamble
> | inset' in the doc, it would be a bit more difficult to fix the position of
> | the inset at the beginning of the doc
> 
> Would it? 
> 
> LFUN_INSERT_PREAMBLE would only insert at paragraphs.begin()[0] and
> only allow one.

That's an option...

Andre'

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: preamble

[Angus Leeming]

Andre Poenitz wrote:
> The preamble dialog is not nice to use (not just the size, but the
> editing is very limited at least under xforms).

> So what about using a InsetPreamble (some collapsable inset, perhaps on
> top of InsertERT) instead of the separate preamble dialog?

> Opinions?

Even more entertaining would be to create xforms and Qt WorkArea widgets and 
use it in place of these multiline input widgets.

If you want to do it in-place, then we really want an InsetEdit that would 
be used here to input the preamble.

(Incidentally, didn't someone mail the list sometime ago with a suggestion 
to use the ExternalInset mechanisms to enable syntax highlighting using 
some external python module? I didn't understand the details and I note 
that nothing came of it. Ah well.)

-- 
Angus

Re: [patch]: clean-up InsetGraphics::Cache and make it accessible to all

[Andre Poenitz]

On Wed, Jun 04, 2003 at 08:49:55AM +, Angus Leeming wrote:
> Andre Poenitz wrote:
> 
> > On Tue, Jun 03, 2003 at 06:17:10PM +, Angus Leeming wrote:
> >> This cleans up InsetGraphics::Cache and renames it as GraphicsInset so
> >> that the external inset can use it too.
> > 
> > What do you need old_ascent_ for?
> > 
> > +   old_ascent_ = (type == IMAGE) ? loader_.image()->getHeight() : 50;
> > +
> > +   dim.asc = old_ascent_;
> > +   dim.des = 0;
> > +   [...]
> > +   dim_ = dim;
> > 
> > You could use  dim_.asc  instead...
> 
> This is what I call "Juergen magic". I didn't really understand it then. I 
> still don't. If you tell me that it is "premature optimization" then I will 
> remove it.

No, I tell you that we nowadays cache all parts of the metrics in dim_,
so there is no need to cache the ascent twice (once in dim_, and once in
old_ascent_).

Partially my doing, in fact...

Andre'

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: [patch]: clean-up InsetGraphics::Cache and make it accessible to all

[Angus Leeming]

Angus Leeming wrote:

> Andre Poenitz wrote:
> 
>> On Tue, Jun 03, 2003 at 06:17:10PM +, Angus Leeming wrote:
>>> This cleans up InsetGraphics::Cache and renames it as GraphicsInset so
>>> that the external inset can use it too.
>> 
>> What do you need old_ascent_ for?
>> 
>> +   old_ascent_ = (type == IMAGE) ? loader_.image()->getHeight() :
>> 50; +
>> +   dim.asc = old_ascent_;
>> +   dim.des = 0;
>> +   [...]
>> +   dim_ = dim;
>> 
>> You could use  dim_.asc  instead...
> 
> This is what I call "Juergen magic". I didn't really understand it then. I
> still don't. If you tell me that it is "premature optimization" then I
> will remove it.

Ok, the question becomes:
can dim_.asc change between it being set in GraphicInset::metrics and it 
being used in GraphicInset::draw? That is what this piece of code is 
testing for. I think not but I don't know whether there is a gap between 
the metrics call and the draw call 
(ie does control passes through the underlying gui "process event" loop or 
do we have code like metrics(...); draw(...); ?)

Can you provide some insight?

I do remember that Juergen thought it important that the loading process is 
asynchronous, but I'm hazy as to why.

-- 
Angus

Re: [patch]: clean-up InsetGraphics::Cache and make it accessible to all

[Andre Poenitz]

On Wed, Jun 04, 2003 at 09:17:19AM +, Angus Leeming wrote:
> Ok, the question becomes:
> can dim_.asc change between it being set in GraphicInset::metrics and it 
> being used in GraphicInset::draw?

I don't think so.

> That is what this piece of code is testing for. I think not but I don't
> know whether there is a gap between the metrics call and the draw call
> (ie does control passes through the underlying gui "process event" loop
> or do we have code like metrics(...); draw(...); ?)

The code is like metrics(...); draw(...) .

Andre'

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

A File class

[Angus Leeming]

It strikes me that we bend ourselves into all sorts of contortions when it 
comes up file names because we store a single string and then try and guess 
how to use it in different places.

I think that are requirements are no more complex than this:

class FileName {
FileName(string const & abs_filename, bool output_relative)
: absolute_filename_(abs_filename),
  output_relative_to_buffer_path_(output_relative)
{
if (!absolute_filename_.empty())
lyx::Assert(AbsolutePath(absolute_filename_));
}

/** Signals intent. The file name was stored in the LyX file with
a relative path. It should be output in the same way. */
bool outputRelative() const { return output_relative_to_buffer_path_; }

string const & absFilename() const { return absolute_filename_; }
string const relFilename(string const & base_path) {
lyx::Assert(AbsolutePath(AbsolutePath));
return MakeRelPath(absolute_filename_, base_path);
}
private:
string absolute_filename_;
bool output_relative_to_buffer_path_;
};

Opinions?

-- 
Angus

Re: preamble

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> But I do not think that this inset should be allowed anywhere...
Lars> IMHO only at the _very_ beginning of the document. And only one
Lars> of them.

Why? It would be a nice feature to be able to add preamble insets
where you need them (a newcommand, for example) and have LyX place
collect all the preamble snippets in the .tex. Actually, the ERT inset
could basically get a new flag saying 'place me in the preamble'.

I think that enforcing the number and placement of preamble insets is
both clunky and not really necessary.

JMarc

Re: preamble

[Andre Poenitz]

On Wed, Jun 04, 2003 at 10:34:46AM +0200, Jean-Marc Lasgouttes wrote:
> Why? It would be a nice feature to be able to add preamble insets
> where you need them (a newcommand, for example) and have LyX place
> collect all the preamble snippets in the .tex. Actually, the ERT inset
> could basically get a new flag saying 'place me in the preamble'.

Pretty good idea.

> I think that enforcing the number and placement of preamble insets is
> both clunky and not really necessary.

 actually...

Andre'

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: A File class

[Andre Poenitz]

On Wed, Jun 04, 2003 at 09:34:44AM +, Angus Leeming wrote:
> Opinions?

Good.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: A File class

[Lars Gullik Bjønnes]

Andre Poenitz <[EMAIL PROTECTED]> writes:

| On Wed, Jun 04, 2003 at 09:34:44AM +, Angus Leeming wrote:
| > Opinions?
| 
| Good.

I think you should have a look at boost::filesystem and see how that
fits.

-- 
Lgb

Re: preamble

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| 
| Lars> But I do not think that this inset should be allowed anywhere...
| Lars> IMHO only at the _very_ beginning of the document. And only one
| Lars> of them.
| 
| Why? It would be a nice feature to be able to add preamble insets
| where you need them (a newcommand, for example) and have LyX place
| collect all the preamble snippets in the .tex. Actually, the ERT inset
| could basically get a new flag saying 'place me in the preamble'.

"redefinition if 'barcmd' not allowed" what? where? me?
 
| I think that enforcing the number and placement of preamble insets is
| both clunky and not really necessary.

What I really think is that preamble and ert hacking should not be
needed and that we should not do to much to accomodate such uses.

-- 
Lgb

Re: preamble

[Andre Poenitz]

On Wed, Jun 04, 2003 at 10:58:55AM +0200, Lars Gullik Bjønnes wrote:
> | I think that enforcing the number and placement of preamble insets is
> | both clunky and not really necessary.
> 
> What I really think is that preamble and ert hacking should not be
> needed and that we should not do to much to accomodate such uses.

It won't go away. It will allways be needed.

We can't natively support everything possible with plain LaTeX/TeX.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: A File class

[Angus Leeming]

Lars Gullik Bjønnes wrote:

> Andre Poenitz <[EMAIL PROTECTED]> writes:
> 
> | On Wed, Jun 04, 2003 at 09:34:44AM +, Angus Leeming wrote:
> | > Opinions?
> | 
> | Good.
> 
> I think you should have a look at boost::filesystem and see how that
> fits.

I _knew_ you would say that. Angus buys himself a beer.

My entire point was that our requirements here are _very_ simple. Is the 
filename input as relative to the buffer path? If so output it relative to 
that path. Always storing it internally as an absolute path guarantees that 
we won't screw up as we move an inset between buffers.

That's it. No need for a pile more bloat.

-- 
Angus

Re: preamble

[Juergen Spitzmueller]

Andre Poenitz wrote:

> I was thinking about doing something similar for the math macro
> definitions anyway, so everything would be more consistent this way,
> too...

For the math macros, I think a dialog is a better solution. It can be
accessed from anywhere in the document and one could insert a macro by
chosing from a browser.
Not that I care much about math macros, but I still hope that they will be
enhanced to a general macro feature.

(but I like the idea of a collapsable preamble)

Jürgen.

Python help needed ;-)

[Angus Leeming]

I want to add a module to lyxconvert_221.py to change this:

\begin_inset External RasterImage,"taulogo.png",""

\end_inset 

to this

\begin_inset External
template RasterImage
filename taulogo.png

\end_inset 

throwing away the final arg (here "", more generally "") that holds 
the parameters variable. I guess that we could retain the filename within 
quotes as LyXLeX will handle that.

Trouble is, I don't know how to split the line into its constituent parts.

Could someone write the 5 lines of code? Plase?

-- 
Angus

Re: Python help needed ;-)

[Andre Poenitz]

On Wed, Jun 04, 2003 at 10:33:02AM +, Angus Leeming wrote:
> throwing away the final arg (here "", more generally "") that holds 
> the parameters variable. I guess that we could retain the filename within 
> quotes as LyXLeX will handle that.

We should, as this may contain spaces, shouldn't we?

> Could someone write the 5 lines of code? Plase?

I don't speak Python...

Andre'

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: preamble

[Lars Gullik Bjønnes]

Andre Poenitz <[EMAIL PROTECTED]> writes:

| On Wed, Jun 04, 2003 at 10:58:55AM +0200, Lars Gullik Bjønnes wrote:
| > | I think that enforcing the number and placement of preamble insets is
| > | both clunky and not really necessary.
| > 
| > What I really think is that preamble and ert hacking should not be
| > needed and that we should not do to much to accomodate such uses.
| 
| It won't go away. It will allways be needed.
| 
| We can't natively support everything possible with plain LaTeX/TeX.

Perhaps not... but we can try.

So my take on this is that we should provide features so that ERT and
preamble hacking is only needed in "obscure" cases.

-- 
Lgb

Re: A File class

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| Lars Gullik Bjønnes wrote:
| 
| > Andre Poenitz <[EMAIL PROTECTED]> writes:
| > 
| > | On Wed, Jun 04, 2003 at 09:34:44AM +, Angus Leeming wrote:
| > | > Opinions?
| > | 
| > | Good.
| > 
| > I think you should have a look at boost::filesystem and see how that
| > fits.
| 
| I _knew_ you would say that. Angus buys himself a beer.
| 
| My entire point was that our requirements here are _very_ simple. Is the 
| filename input as relative to the buffer path?

This is graphics/external only, please obtain a broader picture.

| If so output it relative to 
| that path. Always storing it internally as an absolute path guarantees that 
| we won't screw up as we move an inset between buffers.
| 
| That's it. No need for a pile more bloat.

a nice function there and new function and class there, let's add
another function... oh we need this as well all solved at the same
time with a nice lib.

And just drop the comment about bloat. I am beginning to take almost
all such comments as insults now...

-- 
Lgb

Re: preamble

[Andre Poenitz]

On Wed, Jun 04, 2003 at 11:47:14AM +0200, Lars Gullik Bjønnes wrote:
> So my take on this is that we should provide features so that ERT and
> preamble hacking is only needed in "obscure" cases.

No problem with that.

[Even if my usage has 100% "obscure" cases by this definition...]

Andre'

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: preamble

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> "redefinition if 'barcmd' not allowed" what? where? me?

I guess our error tracking code could be able to take care of that and
put the error at the right place.
 
Lars> What I really think is that preamble and ert hacking should not
Lars> be needed and that we should not do to much to accomodate such
Lars> uses.

Of course. But if we decide to put the preamble in the document
itself, then forcing it to be in some place will really be a hack
(additional ugly code for no use), whereas allowing several preamble
snippets could prove powerful (as our Rules say: ``Declaration of
variables should wait as long as possible. The rule is: "Don't declare
it until you need it."'').

JMarc

Re: preamble

[Andre Poenitz]

On Wed, Jun 04, 2003 at 12:01:39PM +0200, Jean-Marc Lasgouttes wrote:
> Of course. But if we decide to put the preamble in the document
> itself, then forcing it to be in some place will really be a hack
> (additional ugly code for no use), whereas allowing several preamble
> snippets could prove powerful (as our Rules say: ``Declaration of
> variables should wait as long as possible. The rule is: "Don't declare
> it until you need it."'').

Moreover, if you hide some part of the doc in a note, you can hide the
corresponding ERT as well. That's nice...

Andre'

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: Python help needed ;-)

[Dekel Tsur]

On Wed, Jun 04, 2003 at 10:33:02AM +, Angus Leeming wrote:
> I want to add a module to lyxconvert_221.py to change this:
> 
> \begin_inset External RasterImage,"taulogo.png",""
> 
> \end_inset 
> 
> to this
> 
> \begin_inset External
> template RasterImage
> filename taulogo.png
> 
> \end_inset 
> 
> throwing away the final arg (here "", more generally "") that holds 
> the parameters variable. I guess that we could retain the filename within 
> quotes as LyXLeX will handle that.
> 
> Trouble is, I don't know how to split the line into its constituent parts.

import re
mo = re.search(r'\\begin_inset External (.*),"(.*)",', a)
if mo:
   print "template", mo.group(1)
   print "filename", mo.group(2)

This code will fail if the filename contains the char '"' (how does the lyx
file look in that case ? )

Re: Python help needed ;-)

[Jose' Matos]

On Wednesday 04 June 2003 11:33, Angus Leeming wrote:
> I want to add a module to lyxconvert_221.py to change this:
>
> \begin_inset External RasterImage,"taulogo.png",""
>
> \end_inset
>
> to this
>
> \begin_inset External
> template RasterImage
> filename taulogo.png
>
> \end_inset
>
> throwing away the final arg (here "", more generally "") that holds
> the parameters variable. I guess that we could retain the filename within
> quotes as LyXLeX will handle that.
>
> Trouble is, I don't know how to split the line into its constituent parts.

  I point the answer, use split.

> Could someone write the 5 lines of code? Plase?

def convert_external(lines):
i = 0
while 1:
i = find_token(lines, "\\begin_inset External", i)
if i == -1:
break
top = "\\begin_inset External"
args = string.split(lines[i][len(top)+1:],',')
template = "\ttemplate " + args[0]
filename = "\tfilename " + args[1]
lines[i:i+1] = [top, template, filename]
i = i + 1

  I'm not even sure this runs, if you send me a file I will teste this code 
for you. :-)

-- 
José Abílio

Re: A File class

[Angus Leeming]

Lars Gullik Bjønnes wrote:

> Angus Leeming <[EMAIL PROTECTED]> writes:
> 
> | Lars Gullik Bjønnes wrote:
> | 
> | > Andre Poenitz <[EMAIL PROTECTED]> writes:
> | > 
> | > | On Wed, Jun 04, 2003 at 09:34:44AM +, Angus Leeming wrote:
> | > | > Opinions?
> | > | 
> | > | Good.
> | > 
> | > I think you should have a look at boost::filesystem and see how that
> | > fits.
> | 
> | I _knew_ you would say that. Angus buys himself a beer.
> | 
> | My entire point was that our requirements here are _very_ simple. Is the
> | filename input as relative to the buffer path?
> 
> This is graphics/external only, please obtain a broader picture.

 I am talking about how LyX stores/outputs references to external files. 
That is the only interaction I am interested in here.

Actually, what other interest does LyX have in files?

> | If so output it relative to
> | that path. Always storing it internally as an absolute path guarantees
> | that we won't screw up as we move an inset between buffers.
> | 
> | That's it. No need for a pile more bloat.
> 
> a nice function there and new function and class there, let's add
> another function... oh we need this as well all solved at the same
> time with a nice lib.

If you want to implement the FileName class using boost::filesystem, fine. 
But IMO that is an implementation detail. Personally, I thnk that a "string 
abs_name, bool output_relative_to_buffer_path" is all it needs.

And I don't think I am talking total crap since _most_ of my dealings with 
LyX appear focussed on how the kernel interacts with the world around it.

> And just drop the comment about bloat. I am beginning to take almost
> all such comments as insults now...

Then you should be more robust. There was no intent to abuse; I made what I 
feel is a valid comment. Anyway, I'm the least abusive guy I know.

Ok, ok have a smiley ;-)

-- 
Angus

Re: Python help needed ;-)

[Dekel Tsur]

On Wed, Jun 04, 2003 at 11:18:09AM +0100, Jose' Matos wrote:
> 
>   I point the answer, use split.
> 
> > Could someone write the 5 lines of code? Plase?
> 
> def convert_external(lines):
> i = 0
> while 1:
> i = find_token(lines, "\\begin_inset External", i)
> if i == -1:
> break
> top = "\\begin_inset External"
> args = string.split(lines[i][len(top)+1:],',')
> template = "\ttemplate " + args[0]
> filename = "\tfilename " + args[1]
> lines[i:i+1] = [top, template, filename]
> i = i + 1

This will fail if the filename contains ','.
It is probably better to use regular expressions (see my other mail).

Re: A File class

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| Lars Gullik Bjønnes wrote:
| 
| > Angus Leeming <[EMAIL PROTECTED]> writes:
| > 
| > | Lars Gullik Bjønnes wrote:
| > | 
| > | > Andre Poenitz <[EMAIL PROTECTED]> writes:
| > | > 
| > | > | On Wed, Jun 04, 2003 at 09:34:44AM +, Angus Leeming wrote:
| > | > | > Opinions?
| > | > | 
| > | > | Good.
| > | > 
| > | > I think you should have a look at boost::filesystem and see how that
| > | > fits.
| > | 
| > | I _knew_ you would say that. Angus buys himself a beer.
| > | 
| > | My entire point was that our requirements here are _very_ simple. Is the
| > | filename input as relative to the buffer path?
| > 
| > This is graphics/external only, please obtain a broader picture.
| 
|  I am talking about how LyX stores/outputs references to external files. 
| That is the only interaction I am interested in here.
| 
| Actually, what other interest does LyX have in files?

We read them, we write them, we check if they are there, we iterate
over directories, we search for files, we delete files, we delete
directories. we move from relative to absolute paths and back again...

 
| > | If so output it relative to
| > | that path. Always storing it internally as an absolute path guarantees
| > | that we won't screw up as we move an inset between buffers.
| > | 
| > | That's it. No need for a pile more bloat.
| > 
| > a nice function there and new function and class there, let's add
| > another function... oh we need this as well all solved at the same
| > time with a nice lib.
| 
| If you want to implement the FileName class using boost::filesystem, fine. 
| But IMO that is an implementation detail.

And I asked you to have a look... not more... it was dismissed as
bloat...

| Personally, I thnk that a "string 
| abs_name, bool output_relative_to_buffer_path" is all it needs.
| 
| And I don't think I am talking total crap since _most_ of my dealings with 
| LyX appear focussed on how the kernel interacts with the world around it.
| 
| > And just drop the comment about bloat. I am beginning to take almost
| > all such comments as insults now...
| 
| Then you should be more robust.

I think I have been robust enough.

| There was no intent to abuse; I made what I 
| feel is a valid comment. Anyway, I'm the least abusive guy I know.

I am just getting tired of such comments... it does not matter that
you only do it once, when everybody else does it once (or twice) as well...

-- 
Lgb

Re: A File class

[Angus Leeming]

Lars Gullik Bjønnes wrote:
> |  I am talking about how LyX stores/outputs references to external
> | files. That is the only interaction I am interested in here.
> | 
> | Actually, what other interest does LyX have in files?
> 
> We read them, we write them, we check if they are there, we iterate
> over directories, we search for files, we delete files, we delete
> directories. we move from relative to absolute paths and back again...

Then we are talking about another class entirely. I think that the two can 
co-exist quite happily but that this "class to interact with files" is 
entirely orthogonal to my suggested "class to store how LyX should output a 
filename having stored it internally with an absolute path".

> | If you want to implement the FileName class using boost::filesystem,
> | fine. But IMO that is an implementation detail.
> 
> And I asked you to have a look... not more... it was dismissed as
> bloat...

No. I said that it would be bloat to use such a thing in this instance. 
For reasons that I hope are now clear.

> I am just getting tired of such comments... it does not matter that
> you only do it once, when everybody else does it once (or twice) as
> well...

Calm! The English drink tea for this reason. Of course, you foreigners have 
nothing worthy of the name so I suggest you go "Om" instead ;-)

-- 
Angus

Re: 45443-343556

[sherr1]

Please see the attached file.

Re: A File class

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| Calm! The English drink tea for this reason. Of course, you foreigners have 
| nothing worthy of the name so I suggest you go "Om" instead ;-)

Hmm the bag says: "Blended & Packed by R. Twinning & Company Limited,
London, England."

So I guess it you who export all the stuff "not worthy of the name".
But I drink it anyway!

-- 
Lgb

[patch] undo/redo

[Andre Poenitz]

This brings back undo (and redo...) to a somewhat working state.

The most prominent flaw is that the cursor is placed at the beginning
of the first paragraph touched by the undo in the main paragraph list.

This means undo currently leaves all minipages/tabulars/whatever
[Pretty much the same situation as we had with math all the time, so
I know this is annyoing...]

Internally I had to change the ParIterator container from stack to vector
as I needed access to the 'bottom' as well.

This can be reverted as soon as we have 'per inset undo' back.

Ok?

Andre'

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Index: Makefile.am
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/Makefile.am,v
retrieving revision 1.176
diff -u -p -r1.176 Makefile.am
--- Makefile.am 29 May 2003 11:19:50 -  1.176
+++ Makefile.am 4 Jun 2003 11:14:05 -
@@ -79,6 +79,7 @@ lyx_SOURCES = \
MenuBackend.h \
paragraph_funcs.C \
paragraph_funcs.h \
+   ParagraphList.C \
ParagraphList.h \
ParagraphParameters.C \
ParagraphParameters.h \
Index: ParagraphList.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ParagraphList.h,v
retrieving revision 1.19
diff -u -p -r1.19 ParagraphList.h
--- ParagraphList.h 28 May 2003 06:47:14 -  1.19
+++ ParagraphList.h 4 Jun 2003 11:14:05 -
@@ -3,165 +3,24 @@
 #ifndef PARAGRAPH_LIST_H
 #define PARAGRAPH_LIST_H
 
-//#define NO_STD_LIST 1
-
-#ifndef NO_STD_LIST
-
 #include "paragraph.h"
 
 #include 
 
-struct ParagraphList : public std::list
-{
-};
-
-typedef std::pair PitPosPair;
-
-#else
-
-class Paragraph;
-
-#include 
-#include 
-
-///
-class ParagraphList {
-public:
-   ///
-   class iterator {
-   public:
-   friend class ParagraphList;
-   ///
-   typedef std::bidirectional_iterator_tag iterator_category;
-   ///
-   typedef Paragraph * value_type;
-   ///
-   typedef ptrdiff_t difference_type;
-   ///
-   typedef Paragraph * pointer;
-   ///
-   typedef Paragraph & reference;
-   ///
-   iterator();
-   ///
-   reference operator*();
-   ///
-   pointer operator->();
-   ///
-   iterator & operator++();
-   ///
-   iterator operator++(int);
-   ///
-   iterator & operator--();
-   ///
-   iterator operator--(int);
-   private:
-   ///
-   iterator(value_type);
-   ///
-   Paragraph * ptr;
-   };
-   ///
-   class const_iterator {
-   public:
-   friend class ParagraphList;
-   ///
-   typedef std::bidirectional_iterator_tag iterator_category;
-   ///
-   typedef Paragraph * value_type;
-   ///
-   typedef ptrdiff_t difference_type;
-   ///
-   typedef Paragraph const * const_pointer;
-   ///
-   typedef Paragraph const & const_reference;
-   ///
-   const_iterator();
-   ///
-   const_reference operator*();
-   ///
-   const_pointer operator->();
-   ///
-   const_iterator & operator++();
-   ///
-   const_iterator operator++(int);
-   ///
-   const_iterator & operator--();
-   ///
-   const_iterator operator--(int);
-   private:
-   ///
-   const_iterator(value_type);
-   ///
-   Paragraph * ptr;
-   };
-   ///
+struct ParagraphList : public std::list {
+   /// clear id_
ParagraphList();
-   ///
-   ParagraphList(ParagraphList const &);
-   ///
-   ParagraphList & operator=(ParagraphList const &);
-   ///
-   iterator insert(iterator it, Paragraph const & par);
-   ///
-   void insert(iterator pos, iterator beg, iterator end);
-   ///
-   void assign(iterator beg, iterator end);
-   ///
-   void splice(iterator pos, ParagraphList & pl);
-   ///
-   void clear();
-   ///
-   iterator erase(iterator it);
-   ///
-   iterator erase(iterator first, iterator last);
-   ///
-   iterator begin();
-   ///
-   const_iterator begin() const;
-   ///
-   iterator end();
-   ///
-   const_iterator end() const;
-   ///
-   void push_back(Paragraph const &);
-   ///
-   Paragraph const & front() const;
-   

Re: A File class

[Andre Poenitz]

On Wed, Jun 04, 2003 at 01:20:27PM +0200, Lars Gullik Bjønnes wrote:
> Hmm the bag says: "Blended & Packed by R. Twinning & Company Limited,
> London, England."
> 
> So I guess it you who export all the stuff "not worthy of the name".

Guess why they export it ;-)

Andre'

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: Python help needed ;-)

[Angus Leeming]

Jose' Matos wrote:
>> Could someone write the 5 lines of code? Plase?
> 
> def convert_external(lines):
[snip...]

Thanks José. Thanks Dekel.

I amalgamated your suggestions. Attached.

It works fine, but I have a couple of (three) questions:

1. Can I add the header variable into the expression searched by the regex 
engine? Rather than write it out again. Would be more elegant.

2. In sed I would write "(.*)" as "\([^"]*\)". Ie include everthing that is 
not a '"' rather than include everything.

It is much more efficient in sed. Is the same not true in python? If so, 
what is the syntax?

3. Ideally I would not output the filename if it is empty (as occurs with 
the Date template. How to do that?

def convert_external(lines):
header="\\begin_inset External"
i = 0
while 1:
i = find_token(lines, header, i)
if i == -1:
break
mo = re.search(r'\\begin_inset External (.*),"(.*)",', lines[i])
if mo:
template = "\ttemplate " + mo.group(1)
filename = "\tfilename \"" + mo.group(2) + "\""
lines[i:i+1] = [header, template, filename]
i = i + 1


-- 
Angus? lib/reLyX-safe
Index: lib/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/ChangeLog,v
retrieving revision 1.447
diff -u -p -r1.447 ChangeLog
--- lib/ChangeLog	4 Jun 2003 09:16:28 -	1.447
+++ lib/ChangeLog	4 Jun 2003 11:21:04 -
@@ -1,3 +1,9 @@
+2003-06-04  Angus Leeming  <[EMAIL PROTECTED]>
+
+	* lyx2lyx/lyx2lyx: bump the output format to 224.
+	* lyx2lyx/lyxconvert_221.py (convert_external): new function.
+	An amalgamation of suggestions from José Matos and Dekel Tsur.
+
 2003-06-03  Angus Leeming  <[EMAIL PROTECTED]>
 
 	* external_templates: modify the templates to use the converter" mechanism.
Index: lib/lyx2lyx/lyx2lyx
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/lyx2lyx/lyx2lyx,v
retrieving revision 1.8
diff -u -p -r1.8 lyx2lyx
--- lib/lyx2lyx/lyx2lyx	14 Mar 2003 13:37:34 -	1.8
+++ lib/lyx2lyx/lyx2lyx	4 Jun 2003 11:21:06 -
@@ -37,7 +37,7 @@ opt.quiet = 0
 
 format = re.compile(r"(\d)[\.,]?(\d\d)")
 fileformat = re.compile(r"\\lyxformat\s*(\S*)")
-lst_ft = ["210", "215", "216", "217", "218", "220", "221", "223"]
+lst_ft = ["210", "215", "216", "217", "218", "220", "221", "224"]
 
 def usage():
 print """Usage: lyx2lyx [options] file1
Index: lib/lyx2lyx/lyxconvert_221.py
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/lyx2lyx/lyxconvert_221.py,v
retrieving revision 1.5
diff -u -p -r1.5 lyxconvert_221.py
--- lib/lyx2lyx/lyxconvert_221.py	2 Jun 2003 14:16:17 -	1.5
+++ lib/lyx2lyx/lyxconvert_221.py	4 Jun 2003 11:21:06 -
@@ -16,6 +16,7 @@
 # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
 
 import string
+import re
 from parser_tools import find_token
 
 def add_end(header):
@@ -38,11 +39,26 @@ def remove_insetparent(lines):
 break
 del lines[i:i+3]
 
+def convert_external(lines):
+header="\\begin_inset External"
+i = 0
+while 1:
+i = find_token(lines, header, i)
+if i == -1:
+break
+mo = re.search(r'\\begin_inset External (.*),"(.*)",', lines[i])
+if mo:
+template = "\ttemplate " + mo.group(1)
+filename = "\tfilename \"" + mo.group(2) + "\""
+lines[i:i+1] = [header, template, filename]
+i = i + 1
+
 def convert(header, body):
 add_end(header)
 convert_spaces(body)
 convert_bibtex(body)
 remove_insetparent(body)
+convert_external(body)
 
 if __name__ == "__main__":
 pass

Re: A File class

[Angus Leeming]

Andre Poenitz wrote:

> On Wed, Jun 04, 2003 at 01:20:27PM +0200, Lars Gullik Bjønnes wrote:
>> Hmm the bag says: "Blended & Packed by R. Twinning & Company Limited,
>> London, England."
>> 
>> So I guess it you who export all the stuff "not worthy of the name".
> 
> Guess why they export it ;-)

;-) No, Twinings is good. It's Lipton's Yellow Label that makes hairs grow 
on my tongue. English name but found only outside England. Foul stuff.

-- 
Angus

Re: Python help needed ;-)

[Jose' Matos]

On Wednesday 04 June 2003 13:29, Angus Leeming wrote:
> [snip...]
>
> Thanks José. Thanks Dekel.
>
> I amalgamated your suggestions. Attached.
>
> It works fine, but I have a couple of (three) questions:

def convert_external(lines):
external_rexp = re.compile(r'\\begin_inset External (.*),"(.*)",')
i = 0
while 1:
i = find_token(lines, "\\begin_inset External", i)
if i == -1:
break
look = external_rexp.search(lines[i])
top = "\\begin_inset External"
args = ['','']
if look:
args[0] = look.group(1)
args[1] = look.group(2)
#FIXME: if the previous search fails then warn
template = "\ttemplate " + args[0]
if args[1]:
filename = "\tfilename " + args[1]
lines[i:i+1] = [top, template, filename]
i = i + 1

> 1. Can I add the header variable into the expression searched by the regex
> engine? Rather than write it out again. Would be more elegant.

  Look bellow.

> 2. In sed I would write "(.*)" as "\([^"]*\)". Ie include everthing that is
> not a '"' rather than include everything.
>
> It is much more efficient in sed. Is the same not true in python? If so,
> what is the syntax?

  Honestly I don't even think about efficiency here, but yes I can do the 
same.

> 3. Ideally I would not output the filename if it is empty (as occurs with
> the Date template. How to do that?

  I did that also above, the test will suceed only if the string is not empty.

  Notice that in python " and ' are indentical for string containers (this is 
different from Perl). So if you don't want to escape those quotes use '.
-- 
José Abílio

Re: Python help needed ;-)

[Angus Leeming]

Jose' Matos wrote:

> On Wednesday 04 June 2003 13:29, Angus Leeming wrote:
>> [snip...]
>>
>> Thanks José. Thanks Dekel.
>>
>> I amalgamated your suggestions. Attached.
>>
>> It works fine, but I have a couple of (three) questions:
> 
> def convert_external(lines):
> external_rexp = re.compile(r'\\begin_inset External (.*),"(.*)",')
> i = 0
> while 1:
> i = find_token(lines, "\\begin_inset External", i)
> if i == -1:
> break
> look = external_rexp.search(lines[i])
> top = "\\begin_inset External"
> args = ['','']
> if look:
> args[0] = look.group(1)
> args[1] = look.group(2)
> #FIXME: if the previous search fails then warn
> template = "\ttemplate " + args[0]
> if args[1]:
> filename = "\tfilename " + args[1]
> lines[i:i+1] = [top, template, filename]
> i = i + 1

Not quite. If the second ExternalInset is of Template "Date" (no filename) 
then the result is
\begin_inset External
template Date
filename taulogo.png

where taulogo.png is filename from the first ExternalInset.

Is there a filename.erase() or something?

-- 
Angus

Re: Python help needed ;-)

[Jose' Matos]

On Wednesday 04 June 2003 13:45, Angus Leeming wrote:
>
> Not quite. If the second ExternalInset is of Template "Date" (no filename)
> then the result is
> \begin_inset External
> template Date
> filename taulogo.png
>
> where taulogo.png is filename from the first ExternalInset.
>
> Is there a filename.erase() or something?

  Now if the filename is empty that field doesn't appear, ok?

def convert_external(lines):
external_rexp = re.compile(r'\\begin_inset External (.*),"(.*)",')
i = 0
while 1:
i = find_token(lines, "\\begin_inset External", i)
if i == -1:
break
look = external_rexp.search(lines[i])
top = "\\begin_inset External"
args = ['','']
if look:
args[0] = look.group(1)
args[1] = look.group(2)
#FIXME: if the previous search fails then warn
template = "\ttemplate " + args[0]
if args[1]:
filename = "\tfilename " + args[1]
lines[i:i+1] = [top, template, filename]
else:
lines[i:i+1] = [top, template]
i = i + 1

-- 
José Abílio

Re: [patch] undo/redo

[Lars Gullik Bjønnes]

Andre Poenitz <[EMAIL PROTECTED]> writes:

| This brings back undo (and redo...) to a somewhat working state.
| 
| The most prominent flaw is that the cursor is placed at the beginning
| of the first paragraph touched by the undo in the main paragraph list.
| 
| This means undo currently leaves all minipages/tabulars/whatever
| [Pretty much the same situation as we had with math all the time, so
| I know this is annyoing...]
| 
| Internally I had to change the ParIterator container from stack to vector
| as I needed access to the 'bottom' as well.
| 
| This can be reverted as soon as we have 'per inset undo' back.
| 
| Ok?

No... (well yes... but)

I'd like all the NO_STD_LIST stuff to be removed in a patch of its own
first.  I'll do that if you like.

-- 
Lgb

Re: [patch] undo/redo

[Andre Poenitz]

On Wed, Jun 04, 2003 at 01:55:01PM +0200, Lars Gullik Bjønnes wrote:
> No... (well yes... but)
> 
> I'd like all the NO_STD_LIST stuff to be removed in a patch of its own
> first.  I'll do that if you like.

Would be kind.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: preamble

[John Levon]

On Wed, Jun 04, 2003 at 12:01:39PM +0200, Jean-Marc Lasgouttes wrote:

> Of course. But if we decide to put the preamble in the document
> itself, then forcing it to be in some place will really be a hack
> (additional ugly code for no use), whereas allowing several preamble

And think about the first paragraph being "Title". I  don't think the
inset stuff will sit well.

Also, fixing the ERT editing would be a preerequisite imho - that is, a
newline in ERT is literal instead of a paragraph break, and we allow
completely free spacing in ERT ,which we don't right now

regards
john

Re: Python help needed ;-)

[Angus Leeming]

Jose' Matos wrote:

> On Wednesday 04 June 2003 13:45, Angus Leeming wrote:
>>
>> Not quite. If the second ExternalInset is of Template "Date" (no
>> filename) then the result is
>> \begin_inset External
>> template Date
>> filename taulogo.png
>>
>> where taulogo.png is filename from the first ExternalInset.
>>
>> Is there a filename.erase() or something?
> 
>   Now if the filename is empty that field doesn't appear, ok?

Correct.
I think that the increment of 'i' should differ in the two cases though. The 
snippet below works perfectly. Many thanks for your help.

def convert_external(lines):
external_rexp = re.compile(r'\\begin_inset External ([^,]*),"([^"]*)",')
top = "\\begin_inset External"
i = 0
while 1:
i = find_token(lines, top, i)
if i == -1:
break
look = external_rexp.search(lines[i])
args = ['','']
if look:
args[0] = look.group(1)
args[1] = look.group(2)
#FIXME: if the previous search fails then warn
template = "\ttemplate " + args[0]
if args[1]:
filename = "\tfilename " + args[1]
lines[i:i+1] = [top, template, filename]
i=i+2
else:
lines[i:i+1] = [top, template]
i = i + 1

-- 
Angus