Andre Poenitz wrote:
On Mon, Apr 30, 2007 at 01:06:18AM +0200, Uwe Stöhr wrote:
On Windows I have of course only FAT and NTFS, in my case only NTFS.
This 'of course' is a limitation imposed by yourself.
You are going a bit far here :-)
There is no
problem to have e.g. ext2 partitions
On Mon, Apr 30, 2007 at 12:37:44AM +0200, Andre Poenitz wrote:
On Sun, Apr 29, 2007 at 11:50:08PM +0200, Abdelrazak Younes wrote:
Let's please drop this discussion that will get us nowhere. What's done
is done. Andre' is obviously a very competent programmer and he knows
what he is doing.
On Mon, Apr 30, 2007 at 09:47:20AM +0200, Abdelrazak Younes wrote:
Andre Poenitz wrote:
On Mon, Apr 30, 2007 at 01:06:18AM +0200, Uwe Stöhr wrote:
On Windows I have of course only FAT and NTFS, in my case only NTFS.
This 'of course' is a limitation imposed by yourself.
You are going a bit
On Mon, Apr 30, 2007 at 03:16:33AM +0200, Uwe Stöhr wrote:
SVN was _not_ broken.
First, you need not. svn help mv. URL-URL is the interesting part,
just rename one of the 'offending' files, run 'svn up' and be done.
TortoiseSVN suggested I should cleanup the tree but this doesn't help.
My
Andre Poenitz wrote:
On Mon, Apr 30, 2007 at 01:06:18AM +0200, Uwe Stöhr wrote:
On Windows I have of course only FAT and NTFS, in my case only NTFS.
This 'of course' is a limitation imposed by yourself.
You are going a bit far here :-)
There is no
problem to have e.g. ext2 partitions
On Mon, Apr 30, 2007 at 12:37:44AM +0200, Andre Poenitz wrote:
> On Sun, Apr 29, 2007 at 11:50:08PM +0200, Abdelrazak Younes wrote:
> > Let's please drop this discussion that will get us nowhere. What's done
> > is done. Andre' is obviously a very competent programmer and he knows
> > what he is
On Mon, Apr 30, 2007 at 09:47:20AM +0200, Abdelrazak Younes wrote:
> Andre Poenitz wrote:
> >On Mon, Apr 30, 2007 at 01:06:18AM +0200, Uwe Stöhr wrote:
> >>On Windows I have of course only FAT and NTFS, in my case only NTFS.
> >
> >This 'of course' is a limitation imposed by yourself.
>
> You are
On Mon, Apr 30, 2007 at 03:16:33AM +0200, Uwe Stöhr wrote:
> >>>SVN was _not_ broken.
>
> >First, you need not. svn help mv. URL->URL is the interesting part,
> >just rename one of the 'offending' files, run 'svn up' and be done.
>
> TortoiseSVN suggested I should cleanup the tree but this
Andre Poenitz wrote:
On Sat, Apr 28, 2007 at 10:45:18PM +0200, Abdelrazak Younes wrote:
setPosCache() is also implemented in InsetMathDim which is inherited by
most of the math insets; basically all except for InsetMathChar and
InsetMathSymbol. I've (in my local tree) transferred setPosCache()
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
What do you think?
Andre But I do not really want 'name_' in InstBase. _Every_ character
Andre in math will contain that...
Andre Of course we could implement name_ several times fuirther down
Andre in the hierarchy...
Do we really need to
On Sun, Apr 29, 2007 at 01:00:40PM +0200, Jean-Marc Lasgouttes wrote:
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
What do you think?
Andre But I do not really want 'name_' in InstBase. _Every_ character
Andre in math will contain that...
Andre Of course we could implement name_
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Do we really need to _set_ the inset name? Couldn'it be just a
virtual method returning the name?
Andre That would be something like the attached [plus renaming of
Andre InsetBase to Inset].
Good idea.
JMarc
I'm very displeased by the renamng actions you did the last week. This was absolutely unnecessary,
we just have released a second beta and our exercise is to fix the remaining bugs to be able to
release LyX 1.5.0.
Sorry, but why did you mean we have to change our complete infrastructure while
Uwe Stöhr wrote:
I'm very displeased by the renamng actions you did the last week. This
was absolutely unnecessary, we just have released a second beta and our
exercise is to fix the remaining bugs to be able to release LyX 1.5.0.
Please calm down Uwe, the renaming was discussed and approved
On Sun, Apr 29, 2007 at 07:21:34PM +0200, Uwe Stöhr wrote:
I'm very displeased by the renamng actions you did the last week. This was
absolutely unnecessary, we just have released a second beta and our
exercise is to fix the remaining bugs to be able to release LyX 1.5.0.
The idea was to
I'm sure that we have introduced new bugs and problems - the third beta
will tell.
We will see. Most of the changes were of the type 'safe if it compiles
afterwards'.
There is a difference between it compiles and it works without any bugs. I mean the dialog
source code merge is error
Uwe Stöhr schrieb:
We will see. Most of the changes were of the type 'safe if it compiles
afterwards'.
I forgot to mention the SVN problems. You blocked the SVN checkout by Color.h and color.h some
days ago and now again by Layout.h and layout.h. That an example of the problems I
Uwe Stöhr wrote:
Uwe Stöhr schrieb:
We will see. Most of the changes were of the type 'safe if it compiles
afterwards'.
I forgot to mention the SVN problems. You blocked the SVN checkout by
Color.h and color.h some days ago and now again by Layout.h and
layout.h. That an example of the
On Sunday 29 April 2007 18:21:34 Uwe Stöhr wrote:
I'm very displeased by the renamng actions you did the last week. This was
absolutely unnecessary, we just have released a second beta and our
exercise is to fix the remaining bugs to be able to release LyX 1.5.0.
Uwe, this was said before but
On Sun, Apr 29, 2007 at 11:38:58PM +0200, Uwe Stöhr wrote:
Does anybody know this method?
Anybody? Yes, obviously...
But besides this, now also many of the 1.5
patches in Bugzilla have the be rewritten. For me it was not easy to follow
e.g. where for example a patch to tabular.C is to be
On Sun, Apr 29, 2007 at 11:46:17PM +0200, Uwe Stöhr wrote:
Uwe Stöhr schrieb:
We will see. Most of the changes were of the type 'safe if it compiles
afterwards'.
I forgot to mention the SVN problems. You blocked the SVN checkout by
Color.h and color.h some days ago and now again by
On Sun, Apr 29, 2007 at 11:50:08PM +0200, Abdelrazak Younes wrote:
Let's please drop this discussion that will get us nowhere. What's done
is done. Andre' is obviously a very competent programmer and he knows
what he is doing.
I sometimes think I know what I am doing.
But the fact that we
SVN was _not_ broken.
Face it.
In fact, you could even manage files with 'case problems' under Windows,
and you could even _work_ with them if you really wanted. Not on NTFS or
FAT, of course.
Hä? I couldn't check out/in anything. My SVN makes lots of troubles and after a checkout try I
On Mon, Apr 30, 2007 at 01:06:18AM +0200, Uwe Stöhr wrote:
SVN was _not_ broken.
Face it.
In fact, you could even manage files with 'case problems' under Windows,
and you could even _work_ with them if you really wanted. Not on NTFS or
FAT, of course.
Hä? I couldn't check out/in
Andre Poenitz schrieb:
SVN was _not_ broken.
First, you need not. svn help mv. URL-URL is the interesting part,
just rename one of the 'offending' files, run 'svn up' and be done.
TortoiseSVN suggested I should cleanup the tree but this doesn't help.
My SVN makes lots of troubles and
SVN was _not_ broken.
I second that. If you have color.h and it renames to Color.h, windows
will complain. You can always remove color.h and 'svn update'. In the
worst case, you can remove the whole source tree and update.
Cheers,
Bo
Andre Poenitz wrote:
On Sat, Apr 28, 2007 at 10:45:18PM +0200, Abdelrazak Younes wrote:
setPosCache() is also implemented in InsetMathDim which is inherited by
most of the math insets; basically all except for InsetMathChar and
InsetMathSymbol. I've (in my local tree) transferred setPosCache()
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>> What do you think?
Andre> But I do not really want 'name_' in InstBase. _Every_ character
Andre> in math will contain that...
Andre> Of course we could implement name_ several times fuirther down
Andre> in the hierarchy...
Do we
On Sun, Apr 29, 2007 at 01:00:40PM +0200, Jean-Marc Lasgouttes wrote:
> > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> >> What do you think?
>
> Andre> But I do not really want 'name_' in InstBase. _Every_ character
> Andre> in math will contain that...
>
> Andre> Of course we
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>> Do we really need to _set_ the inset name? Couldn'it be just a
>> virtual method returning the name?
Andre> That would be something like the attached [plus renaming of
Andre> InsetBase to Inset].
Good idea.
JMarc
I'm very displeased by the renamng actions you did the last week. This was absolutely unnecessary,
we just have released a second beta and our exercise is to fix the remaining bugs to be able to
release LyX 1.5.0.
Sorry, but why did you mean we have to change our complete infrastructure while
Uwe Stöhr wrote:
I'm very displeased by the renamng actions you did the last week. This
was absolutely unnecessary, we just have released a second beta and our
exercise is to fix the remaining bugs to be able to release LyX 1.5.0.
Please calm down Uwe, the renaming was discussed and approved
On Sun, Apr 29, 2007 at 07:21:34PM +0200, Uwe Stöhr wrote:
> I'm very displeased by the renamng actions you did the last week. This was
> absolutely unnecessary, we just have released a second beta and our
> exercise is to fix the remaining bugs to be able to release LyX 1.5.0.
The idea was to
>> I'm sure that we have introduced new bugs and problems - the third beta
>> will tell.
>
> We will see. Most of the changes were of the type 'safe if it compiles
> afterwards'.
There is a difference between "it compiles" and "it works without any bugs". I mean the dialog
source code merge is
Uwe Stöhr schrieb:
> We will see. Most of the changes were of the type 'safe if it compiles
> afterwards'.
I forgot to mention the SVN problems. You blocked the SVN checkout by "Color.h" and "color.h" some
days ago and now again by "Layout.h" and "layout.h". That an example of the problems
Uwe Stöhr wrote:
Uwe Stöhr schrieb:
> We will see. Most of the changes were of the type 'safe if it compiles
> afterwards'.
I forgot to mention the SVN problems. You blocked the SVN checkout by
"Color.h" and "color.h" some days ago and now again by "Layout.h" and
"layout.h". That an
On Sunday 29 April 2007 18:21:34 Uwe Stöhr wrote:
> I'm very displeased by the renamng actions you did the last week. This was
> absolutely unnecessary, we just have released a second beta and our
> exercise is to fix the remaining bugs to be able to release LyX 1.5.0.
Uwe, this was said before
On Sun, Apr 29, 2007 at 11:38:58PM +0200, Uwe Stöhr wrote:
> Does anybody know this method?
"Anybody"? Yes, obviously...
> But besides this, now also many of the 1.5
> patches in Bugzilla have the be rewritten. For me it was not easy to follow
> e.g. where for example a patch to tabular.C is
On Sun, Apr 29, 2007 at 11:46:17PM +0200, Uwe Stöhr wrote:
> Uwe Stöhr schrieb:
>
> > > We will see. Most of the changes were of the type 'safe if it compiles
> > > afterwards'.
>
> I forgot to mention the SVN problems. You blocked the SVN checkout by
> "Color.h" and "color.h" some days ago and
On Sun, Apr 29, 2007 at 11:50:08PM +0200, Abdelrazak Younes wrote:
> Let's please drop this discussion that will get us nowhere. What's done
> is done. Andre' is obviously a very competent programmer and he knows
> what he is doing.
I sometimes think I know what I am doing.
But the fact that
> SVN was _not_ broken.
>
> Face it.
>
> In fact, you could even manage files with 'case problems' under Windows,
> and you could even _work_ with them if you really wanted. Not on NTFS or
> FAT, of course.
Hä? I couldn't check out/in anything. My SVN makes lots of troubles and after a checkout
On Mon, Apr 30, 2007 at 01:06:18AM +0200, Uwe Stöhr wrote:
> > SVN was _not_ broken.
> >
> > Face it.
> >
> > In fact, you could even manage files with 'case problems' under Windows,
> > and you could even _work_ with them if you really wanted. Not on NTFS or
> > FAT, of course.
>
> Hä? I
Andre Poenitz schrieb:
SVN was _not_ broken.
First, you need not. svn help mv. URL->URL is the interesting part,
just rename one of the 'offending' files, run 'svn up' and be done.
TortoiseSVN suggested I should cleanup the tree but this doesn't help.
My SVN makes lots of troubles and
>>> SVN was _not_ broken.
I second that. If you have color.h and it renames to Color.h, windows
will complain. You can always remove color.h and 'svn update'. In the
worst case, you can remove the whole source tree and update.
Cheers,
Bo
On Fri, Apr 27, 2007 at 11:05:06PM -0500, Bo Peng wrote:
You can have a look at my 'rename summary' post. I think a few more
files need to be renamed.
I propose to rename class InsetOld to Inset, and rename as follows.
The idea is to remove 'InsetOld' entrirely be moving stuff either up
and
On Saturday 28 April 2007 11:50:07 am Andre Poenitz wrote:
I propose to rename class InsetOld to Inset, and rename as follows.
The idea is to remove 'InsetOld' entrirely be moving stuff either up
and down in the inset hierarchy. This is not 1.5.0 business anymore.
I agree with André,
I am happy with the math naming as it is...
Then how about:
src/frontends/Alert.h src/frontends/alert.h
src/frontends/Alert.cpp src/frontends/alert.cpp
src/frontends/Alert_pimpl.cpp src/frontends/alert_pimpl.cpp
src/frontends/controllers/ButtonPolicies.cpp
On Sat, Apr 28, 2007 at 08:38:43AM -0500, Bo Peng wrote:
I am happy with the math naming as it is...
Then how about:
src/insets/InsetEnv.cpp src/insets/InsetEnvironment.cpp
src/insets/InsetEnv.h src/insets/InsetEnvironment.h
This is surely fine.
Andre Poenitz wrote:
On Fri, Apr 27, 2007 at 11:05:06PM -0500, Bo Peng wrote:
You can have a look at my 'rename summary' post. I think a few more
files need to be renamed.
I propose to rename class InsetOld to Inset, and rename as follows.
The idea is to remove 'InsetOld' entrirely be moving
Then how about:
src/insets/InsetEnv.cpp src/insets/InsetEnvironment.cpp
src/insets/InsetEnv.h src/insets/InsetEnvironment.h
ignored
I have renamed these files and classes. There will be no more file
renames from me.
scons update_po will also update POTFILES.in so windows people can
On Sat, Apr 28, 2007 at 10:45:18PM +0200, Abdelrazak Younes wrote:
setPosCache() is also implemented in InsetMathDim which is inherited by
most of the math insets; basically all except for InsetMathChar and
InsetMathSymbol. I've (in my local tree) transferred setPosCache() to
InsetBase for
On Fri, Apr 27, 2007 at 11:05:06PM -0500, Bo Peng wrote:
> >You can have a look at my 'rename summary' post. I think a few more
> >files need to be renamed.
>
> I propose to rename class InsetOld to Inset, and rename as follows.
The idea is to remove 'InsetOld' entrirely be moving stuff either
On Saturday 28 April 2007 11:50:07 am Andre Poenitz wrote:
> > I propose to rename class InsetOld to Inset, and rename as follows.
>
> The idea is to remove 'InsetOld' entrirely be moving stuff either up
> and down in the inset hierarchy. This is not 1.5.0 business anymore.
I agree with André,
I am happy with the math naming as it is...
Then how about:
src/frontends/Alert.h src/frontends/alert.h
src/frontends/Alert.cpp src/frontends/alert.cpp
src/frontends/Alert_pimpl.cpp src/frontends/alert_pimpl.cpp
src/frontends/controllers/ButtonPolicies.cpp
On Sat, Apr 28, 2007 at 08:38:43AM -0500, Bo Peng wrote:
> >I am happy with the math naming as it is...
>
> Then how about:
>
> src/insets/InsetEnv.cpp src/insets/InsetEnvironment.cpp
> src/insets/InsetEnv.h src/insets/InsetEnvironment.h
This is surely fine.
>
Andre Poenitz wrote:
On Fri, Apr 27, 2007 at 11:05:06PM -0500, Bo Peng wrote:
You can have a look at my 'rename summary' post. I think a few more
files need to be renamed.
I propose to rename class InsetOld to Inset, and rename as follows.
The idea is to remove 'InsetOld' entrirely be moving
> Then how about:
>
> src/insets/InsetEnv.cpp src/insets/InsetEnvironment.cpp
> src/insets/InsetEnv.h src/insets/InsetEnvironment.h
I have renamed these files and classes. There will be no more file
renames from me.
scons update_po will also update POTFILES.in so windows people can
finally
On Sat, Apr 28, 2007 at 10:45:18PM +0200, Abdelrazak Younes wrote:
> setPosCache() is also implemented in InsetMathDim which is inherited by
> most of the math insets; basically all except for InsetMathChar and
> InsetMathSymbol. I've (in my local tree) transferred setPosCache() to
> InsetBase
Just for curiosity:
Does anybody intend to make more file/class name changes or can we
consider the code base as stable now?
Michael
Does anybody intend to make more file/class name changes or can we
consider the code base as stable now?
You can have a look at my 'rename summary' post. I think a few more
files need to be renamed.
Bo
You can have a look at my 'rename summary' post. I think a few more
files need to be renamed.
I propose to rename class InsetOld to Inset, and rename as follows.
Basically, files without a class defined are converted to lower cases.
Can I proceed? This will be the last batch of renames from
Just for curiosity:
Does anybody intend to make more file/class name changes or can we
consider the code base as "stable" now?
Michael
Does anybody intend to make more file/class name changes or can we
consider the code base as "stable" now?
You can have a look at my 'rename summary' post. I think a few more
files need to be renamed.
Bo
You can have a look at my 'rename summary' post. I think a few more
files need to be renamed.
I propose to rename class InsetOld to Inset, and rename as follows.
Basically, files without a class defined are converted to lower cases.
Can I proceed? This will be the last batch of renames from
On Wed, Jun 04, 2003 at 12:32:02PM +, Angus Leeming spake thusly:
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
On Wed, Jun 04, 2003 at 12:32:02PM +, Angus Leeming spake thusly:
> 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
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
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...)
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
Lars Gullik Bjnnes 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.
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
|
Lars Gullik Bjnnes wrote:
Angus Leeming [EMAIL PROTECTED] writes:
| Lars Gullik Bjnnes 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
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:
| | |
Lars Gullik Bjnnes 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
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
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
Andre Poenitz wrote:
On Wed, Jun 04, 2003 at 01:20:27PM +0200, Lars Gullik Bjnnes 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
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
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...)
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
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
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
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
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:
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
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
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
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 ;-)
88 matches
Mail list logo
