Jean-Marc Lasgouttes wrote:
> The master has to be set explicitly (like the old ParentInset
> mechanism we used to have?), right?
Yes.
> Then it is OK. However, I would be
> against a mechanism to remember multiple parents. Much too complicated
> for little gain.
This needed further discussion
Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
> It fixes several drawbacks of our current unidirectional child document
> handling. Since the document has now always access to the master buffer
> (previously, this was only the case if the child was opened from the master),
> it can retrieve in
[EMAIL PROTECTED] wrote:
On Sat, 26 Apr 2008, Jürgen Spitzmüller wrote:
Here is an attempt to provide a child document with some knowledge
about its master.
Just a thought I had while reading Juergen's post:... do we have a
feature that can show a representation of the files that are used to
On Sat, 26 Apr 2008, Jürgen Spitzmüller wrote:
Here is an attempt to provide a child document with some knowledge about
its master.
Just a thought I had while reading Juergen's post:... do we have a feature
that can show a representation of the files that are used to produce a
document? The
Abdelrazak Younes wrote:
> Well, then we should add a \child_doc tag to indicate the childness of
> the document. Then, if LyX doesn't find a master in the session info,
> it will ask you to browse for one. So yes, it won't be as straight
> forward as putting the parent filename in the format, and
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
When closing a child document, we can write that this document was a
child of this other document. We would use a vector of strings so that
multiple parent documents can be registered.
Then when opening again this child document directly (as
Abdelrazak Younes wrote:
> When closing a child document, we can write that this document was a
> child of this other document. We would use a vector of strings so that
> multiple parent documents can be registered.
> Then when opening again this child document directly (as opposed with
> 'together
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I really often have "shared" child document (actually almost all my
documents are like this); so as long as I am not forced to use this
feature, I am fine with it.
No, you're not forced to use it.
But thinking more about it, I feel
Abdelrazak Younes wrote:
> I really often have "shared" child document (actually almost all my
> documents are like this); so as long as I am not forced to use this
> feature, I am fine with it.
No, you're not forced to use it.
Jürgen
Jürgen Spitzmüller wrote:
Here is an attempt to provide a child document with some knowledge about its
master.
It fixes several drawbacks of our current unidirectional child document
handling. Since the document has now always access to the master buffer
(previously, this was only the case if
Jürgen Spitzmüller wrote:
rgheck wrote:
In general, this would be very nice. You really have to hack things at
present to make the bibliography, for example, work. What's not clear to
me is how this works with, say, math macros present in the master. Does
the master automatically get opened w
rgheck wrote:
> In general, this would be very nice. You really have to hack things at
> present to make the bibliography, for example, work. What's not clear to
> me is how this works with, say, math macros present in the master. Does
> the master automatically get opened when the child does? If n
Jürgen Spitzmüller wrote:
Here is an attempt to provide a child document with some knowledge about its
master.
It fixes several drawbacks of our current unidirectional child document
handling. Since the document has now always access to the master buffer
(previously, this was only the case if
Here is an attempt to provide a child document with some knowledge about its
master.
It fixes several drawbacks of our current unidirectional child document
handling. Since the document has now always access to the master buffer
(previously, this was only the case if the child was opened from t
14 matches
Mail list logo
