Vincent van Ravesteijn - TNW wrote:
Abdelrazak Younes wrote:
This is irrelevant, from a user POV.
To most user, yes, you're right. Still the master and all brothers and
sisters are available in the View menu.
Of course, yes. What I meant is: the user do not have to *bother*
about the master, and this really makes a difference when writing
multi-part documents.
Hmm.. I don't really see the major improvement in workflow ;-)..
I use this, too. Say I want to edit chapter two. I open chapter two. All
labels are correct. Macros and bibliography information are correct.
Etc, etc. Previously, you had to open the master, then open the child
from the master. And if you forgot to do this, then none of the
preceding would be correct.
I would myself be happy to see a way of getting that kind of information
into the child even when just compiling it. Otherwise, you have to use
ugly hacks to get your macros into the child in this case. I guess what
we really need is \includeonly support, as several people have said.
Anyhow, the problem I have with the default master setting is that it sets the
absolute path in stead of a relative path to my master (this happens when your
master is one directory up from your child document, which is often the case,
and you use the Browse button to select the master). This means that when you
rename the directory where your master and children are in, you have to
manually update all children to point to the correct master. This also happens
when I open the document from a different location e.g.
//pcvanvincent/C/Master.lyx. In this case all children start complaining that
they can't find the master: C:/Master.lyx.
If it does indeed behave this way, then that should be fixed. There are
lots of places already where we calculate a relative path based on an
absolute path and then use the relative path. I think graphics does
this, e.g.
Richard
