Josef, I work with large LaTex files also and have for several years;
almost all of which contain multiple \input files. My system may not work
for you, but it works well for me. A few things to note about my system:
1. My master document outline is a shell only (no actual content). It
contains only the preamble, document class and anything else that helps to
determine what the document will look like. It's usually auto-created from
a set of standard templates.
2. *All* content resides in separate file outline nodes that might be
anywhere and almost never is in the same place as the master document file.
I generally use either @file (if sentinels are OK) or @clean (if not) for
the content files.
3. The master document outline nodes will have a sectioning environment,
maybe \section{Some Section} followed by \input{"\path\Some_Section.tex"}.
This pulls in the content from Some_File.tex wherever it happens to be.
4. I prefer to *not* include sectioning environments in the content
files because for one document, Some_Section content might be a
\section{Some Section}, where another document might have the same content
as a \subsection{Some Section}.
Good luck and maybe we can share some other ideas to make this work better.
I'm not a Leo expert, but I depend on it a lot for my writing. HTH
Rob........
On Monday, May 29, 2017 at 12:16:14 PM UTC-4, Josef wrote:
>
> Hello Edward,
>
> much of my work involves editing LaTeX files, but I do have to work
> together with others. I tried Leo's @shadow and @thin nodes, for minimal
> interference, with mixed success. The main problem is the way Latex uses
> multi-file input.
>
> As you may remember, the way the rst plugin automatically translates the
> Leo hierarchy into headings came from a tiny piece of code I once
> contributed. So, naturally I also thought about creating a latex plugin
> with automatic hierarchy translation to headings. That would work well as
> long as the Latex file is one single, large file.
>
> Most people writing large Latex documents break them down into different
> chunks and then glue them together with \input. That's where the problems
> start with using Leo: Leo would have to recreate the same file structure in
> order to work well together with others, but that would mean one @file
> statement per .tex file. These @file headings do not necessarily correspond
> to the document structure. The \input can appear anywhere in the text. An
> \input may correspond to a new (sub-)section but it also may not. Not every
> heading will have a corresponding \input either. The Leo tree therefore
> will not only contain section headings, but also @file nodes corresponding
> to \input statements and not necessarily corresponding to the document
> structure.
>
> Also, one must find the master tex file in order to see the complete
> hierarchy. Since the files may be distributed over different directories,
> the importer would have to be told about the master file and would then
> have to look for all the \input statements recursively (and ignoring
> commented out \inputs).
>
> I don't know how to solve this problem yet.
>
> - Josef
>
> On Wednesday, 12 April 2017 17:35:21 UTC+2, Edward K. Ream wrote:
>>
>> On Wed, Apr 12, 2017 at 12:10 AM, Largo84 <[email protected]> wrote:
>>
>>> Hmm, not sure how that would work. It might be relatively easy to invoke
>>> such a script when setting up the node at first, but what happens if/when
>>> you decide to move the node and its level changes?
>>>
>>
>> The situation is much like the rst3 command. I envisage invoking the
>> script manually whenever you change the source tree. That would at least
>> be a good prototype.
>>
>> Edward
>>
>
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
