Re: Fwd: [PATCH] different approach to --split html

[janneke]

Eli Zaretskii <address@hidden> writes:

> You don't need to ``buy'' anything: these issues should be discussed.  
> That's why I said ``probably''.

Discussion is good, noi.

> > In
> > general, I dislike this kind of magic.  Why not just use
> > --outfile=dir/foo.html for that, and generate all of the html in a
> > subdirectory
> 
> ??? How will this work for references that point to other documents?  If 
> the target directory is determined at the time the HTML file is 
> generated, and is entirely up to the user, there's no way two different 
> files generated on two different occasions will agree on the place where 
> to look for the files.

Sure.  I was thinking about defaulting to a directory name that is the
basename of the toplevel output file, ie

   @setfilename lilypond.info

outputs for --html:

   lilypond/lilypond.html (Top node, hmm we could name this 'Top.html again')
   lilypond/Node-name.html

> What master index?  We don't have one, at least not until now.

No, until now, texinfo-produced-html files were standalone.  But we
should provide for this, I think.  It'll be up to the debian folks to
make or not make sane use of that.

> > Yes, indeed.  Would it be ok to assume that the other html documents
> > are split if we're split and vice versa?
> 
> I don't think this is a valid assumption, in general.  Imagine a system 
> where some of the HTML files where produced by an old version of makeinfo 
> which didn't support splitting ;-)

Well, you don't get x-refs between those.  I'm not planning*) to include
support for this, in my patch.  Afaik, x-refs between html documents
don't work now, so we won't break anything?

* If someone vetos this, and has a simple solution, I might include
  it, though.

> > You would really like to support DOS?
> 
> DOS is supported until now, and I see no reason to give up on it so 
> easily.  You'd be surprised to learn how many people use Texinfo on DOS.

No, please don't surprise me :-)

> > This could be fixed using a hash, but I'd vote for dropping 8.3 until
> > maybe someone sends a clean patch for it.
> 
> That's okay, but let's not introduce additional obstacles for that 
> someone, by assuming that the DOS port will never run this code.  In 
> particular, replacing a few more characters in file names cannot possibly 
> hurt on Unix.

Ok, sure.

> >      
> > http://appel.lilypond.org/lilypond/links/lilypond-1.3.104/Documentation/user/out-www/Index.html
> > 
> > Or maybe I missed something?
> 
> I thought that the patches you sent are supposed to do everything,

No, they still have rough edges.

> including the index.  Are you saying that some of the changes you used to 
> produce the files for the above URL were absent from the diffs you
> sent?

No, I meant to say that, as far as I can see, the Index works.  So, I
assume that the LilyPond doco has only index references to Nodes.
Anyway, I'll look into this, of course.

> > Especially, I would like to know if I can/should drop the
> > node<number>.html approach
> 
> Probably, but I'd like to hear Karl's opinion.

Ok.

> > or whether (or at what cost) we should support non-splitting html at 
> > all.
> 
> IMHO, we certainly should support --no-split in HTML mode.

Ok, large html files have the advantage of being somewhat searchable.

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org