2007/9/11, Graham Percival <[EMAIL PROTECTED]>:
> If anybody knows how to do this with TEXINFO, i.e. AUTOMATICALLY
> generating a NEW table of contents whenever we change the sections in
> the TEXINFO MANUAL, please discuss.
That definitely excludes me :(
> Valentin, if your laptop issues have b
John Mandereau wrote:
We could try to make a new node containing only
@contents
I'll give it a try later in the week. However, we'd still have to tweak
the links with a regexp substitution Python script to make it work with
frames. I don't know if the HTML TOC outputted by Makeinfo could be
Le lundi 10 septembre 2007 à 15:32 -0700, Graham Percival a écrit :
> Valentin Villenave wrote:
> > 2007/9/11, Graham Percival <[EMAIL PROTECTED]>:
> >> The idea of a table of comments on the left-hand side of the docs
> >> (whether frames or CSS) is interesting, and I'm not at all opposed to
> >>
Valentin Villenave wrote:
2007/9/11, Graham Percival <[EMAIL PROTECTED]>:
The idea of a table of comments on the left-hand side of the docs
(whether frames or CSS) is interesting, and I'm not at all opposed to
it. However, I don't know how we would go about doing this. If anybody
knows how to
Le lundi 10 septembre 2007 à 11:06 -0700, Graham Percival a écrit :
> Juergen Reuter wrote:
> > Furthermore, I would like to see entries like
> >
> > \displayLilyMusic: Displaying LilyPond notation
> > \displayLilyMusic: Displaying music expressions
> >
> > rather being structured as follows:
2007/9/11, Graham Percival <[EMAIL PROTECTED]>:
>
> The idea of a table of comments on the left-hand side of the docs
> (whether frames or CSS) is interesting, and I'm not at all opposed to
> it. However, I don't know how we would go about doing this. If anybody
> knows how to do this with texinf
To anybody involved in the GDP discussion, please take a few minutes to
look at the documentation for 2.11. There have been a few significant
changes since 2.10; please look at those changes so we avoid reinventing
the wheel. Specifically,
- Manual is only for lilypond input format.
- Progra
John Mandereau wrote:
Tu sum up your suggestion, which I like quite much, I propose the
following section (inside chapter 7 "Decorating musical notation", and
replacing "Special use"):
7.6 Note heads and stems
7.6.1 Stems
7.6.2 Special noteheads
7.6.3 Improvisation
7.6.4 Selecting no
Juergen Reuter wrote:
Furthermore, I would like to see entries like
\displayLilyMusic: Displaying LilyPond notation
\displayLilyMusic: Displaying music expressions
rather being structured as follows:
\displayLilyMusic:
Displaying LilyPond notation
Displaying music expressions
On Mon, 10 Sep 2007, Graham Percival wrote:
To summarize some discussions:
...
- Does anybody _like_ the current layout? If so, speak up now or forever
hold your peace. :)
I am _fine_ with the current layout. However, I agree that for
global searching in the web browser, you need a big
El lun, 10-09-2007 a las 19:25 +0200, Rune Zedeler escribió:
> With frames the toc stays and you only load the pages themself.
> We were talking loading times :-)
>
> -Rune (who likes frames)
>
Please forget the idea of using frames, there are dozens of reasons for
not to use them, in my opinion
Citat Valentin Villenave <[EMAIL PROTECTED]>:
> I think CSS allows to do this without needing an extra (ugly) frame.
It is possible with css, but you would have to redownload the entire toc each
time.
With frames the toc stays and you only load the pages themself.
We were talking loading times :-
Citat Graham Percival <[EMAIL PROTECTED]>:
> The all-in-one HTML page is **5 megs**. I'm astounded that so many
> people (ie more than 0) are choosing to download that monster _every
> time_ they want to look something up in the docs.
We don't.
Browsers have caches, you know :-)
> Let me phrase
Hi Valentin,
I think CSS allows to do this without needing an extra (ugly) frame.
Agreed -- of the many possible options, I definitely prefer valid
XHTML+CSS.
Plus, I always wish the site and the docs could look a bit fancier...
=)
Best,
Kieren.
__
2007/9/10, Kieren MacMillan <[EMAIL PROTECTED]>:
> If the doc index ran along the left-hand side of the page (e.g., in a
> frame, via CSS menus, etc.), might that help people who use the
> monster? I know it helps me when I'm using Java class documentation.
I agree!
I thought I was the only CSS-a
Le lundi 10 septembre 2007 à 05:22 -0700, Graham Percival a écrit :
> Rune Zedeler wrote:
> > Very first I comment on the stuff I wrote below: When I wrote it I
> > didn't really notice / think about the fact the the first five sections
> > are left out. Probably some of my comments are not total
Hi Graham,
- if you currently use the all-in-one HTML page, how could we
organize the non-all-in-one docs such that you use them?
Again, I don't, but OTTOMH...
If the doc index ran along the left-hand side of the page (e.g., in a
frame, via CSS menus, etc.), might that help people who use
2007/9/10, Graham Percival <[EMAIL PROTECTED]>:
> I'd certainly say so... but there's a large element of "the customer is
> always right" here.
>
> The all-in-one HTML page is **5 megs**. I'm astounded that so many
> people (ie more than 0) are choosing to download that monster _every
> time_ the
Kieren MacMillan wrote:
Hi Reinhold,
They are all ornaments to a note.
At the very least, there are more (and more complex) things you can do
with dynamics (in Lilypond), and so that section alone would be long
enough to deserve its own HTML page.
I'd certainly say so... but there's a lar
Hi Reinhold,
They are all ornaments to a note.
Articulations and trills, I buy.
Dynamics are different, IMO.
At the very least, there are more (and more complex) things you can
do with dynamics (in Lilypond), and so that section alone would be
long enough to deserve its own HTML page.
R
Am Montag, 10. September 2007 schrieb Graham Percival:
> My preference is for 2 -- I can't believe that users want to see
> articulations, dynamics, and trills on the same HTML page. .
Why not? They are all ornaments to a note. In particular, if you are not a
professional musician, the distinctio
Le lundi 10 septembre 2007 à 14:37 +0200, Mats Bengtsson a écrit :
> Graham Percival wrote:
> >
> >>>+ 6.6.2 Stems
> >>
> >> Currently, this subsection has nothing to do with polyphony.
> >> Furthermore it is layout specific, and should therefore be postponed.
> >
> > I have _always
Le lundi 10 septembre 2007 à 08:00 -0700, Graham Percival a écrit :
> To summarize some discussions:
> - there seems to be considerable dislike for the current
> "one-short-subsection-per-HTML-page" layout of the manual. That
> surprises me, since I've never had a problem with it, but of course
Hi Graham (et al.):
Does anybody _like_ the current layout?
In some ways, my opinion won't matter, because I don't use (nor do I
really understand why anyone else uses) the HTML manual -- the PDF
documentation is all I ever use because:
1. It's perfect for printing;
2. Full-text s
To summarize some discussions:
- there seems to be considerable dislike for the current
"one-short-subsection-per-HTML-page" layout of the manual. That
surprises me, since I've never had a problem with it, but of course I'm
intimately familiar with the layout of the manual, so I'm happy to
di
Le lundi 10 septembre 2007 à 14:46 +0200, Mats Bengtsson a écrit :
> Yes, I guess my main point was the on-line manual, where the splitting into
> separate HTML pages is a problem in some cases, like Valentin just
> illustrated. As far as I understand, it's the texinfo -> HTML conversion
> that
>
2007/9/10, Graham Percival <[EMAIL PROTECTED]>:
> Err.. we're talking about Changing defaults, a chapter which hasn't been
> significantly changed in the past three years, and which you've
> _already_ complained as being a pile of garbage... and using this as an
> argument for changing the way the
Valentin Villenave wrote:
Just a question...
(by the way, is it really relevant to cross post this entire
discussion to -devel?)
We're talking about some major lilypond development work here.
Documentation is still development. A better question is "is it really
relevant to cross post this
Graham Percival wrote:
+ 6.6.2 Stems
Currently, this subsection has nothing to do with polyphony.
Furthermore it is layout specific, and should therefore be postponed.
I have _always_ hated this section. I remember trying -- and failing
-- to find a home for it when I did
Rune Zedeler wrote:
Very first I comment on the stuff I wrote below: When I wrote it I
didn't really notice / think about the fact the the first five sections
are left out. Probably some of my comments are not totally valid. Well,
I will think some more, and post another message about the overa
Trevor Bača wrote:
~ subsection 8.4.3 "Proportional notation" can be removed completely
in favor of subsection 11.6.5 "Proportional notation"
I'd rather not remove subsections yet; we'll do that when we GDPify that
particular chapter.
~ subsections 8.4.4 "Clusters" and 8.4.5 "Special notehe
Rune Zedeler wrote:
Well, in its current state I find the "each subsection has its own page" version
of the manual unusable, and therefore always uses the one big page manual.
I suggest that we gives each section its own page containing section and all
subsections. Ofcourse each section should st
32 matches
Mail list logo
