The Python files that create the index and the search database for the help viewer should be run as make targets

This should be made part of the Makefile.in/makefile.win in help/resources

Putting this on the Buffy train.

The Python script misses quite a few SDX anchors in the html files. I tried to look into, and there are multiple causes: - If 2 (or more) SDX anchors are on the same line, then you miss the second one (regexp?) - It seems it misses all the SDX anchors with a colon in it (regexp?) - There are some other ones that are missed as well, but I can't find why (eg, QuickLaunchSDX and Quick_LaunchSDX in cs_prefs_nav_advandced.html) (no clue) My Python knowledge is nil, so somebody else will need to look into it. Alternatively, I have some home-brewn sh scripts that do almost the same (for the purpose of the french translation), if you're interested.

Milestone needs updated, any new status?

moving stuff over to an outside-the-firewall email for the time being, looking for people to pick these Help and doc bugs up for me.

mass reassign of all of Ian Oeschger's bugs to me (R.J. Keller).

Brant, what do you think of this? It would save a lot of time for us, but it's out of my expertise. If you want it, take it, otherwise just put helpwanted keyword and leave it open.

I think we can do this, but we need to wait until Help gets integrated with the regular tree and the content pack issues get sorted out.

What do you think about Seamonkey? I have no clue how to fix this one, so if you have the knowledge, then do it.

I'm beginning to disagree with fixing this. I like having control over the TOC and Index.

I've been thinking about this bug a bit lately, and how about we generate the TOC using the build system but not the index? The index (especially in the XHTML help docs) is very difficult to generate from a build system. The TOC would be a piece of cake once the XHTML docs are moved over. Brant, if you got an idea for this bug, feel free to tell me. :) Maybe a perl script or something.

It's difficult to generate the index now since there's not always IDX at the end of corresponding tags. With those, it was a piece of cake, especially for translations.

True, but I'd prefer not to do that. There's too many anchors that do nothing becuase of that. I'd rather have the index not generated by the build system, and since search-db.rdf is long gone, no need to worry about that. The glossary could probably be generated. The TOC would be a piece of cake with the XHTML documentation because it has <h1 id="">, <h2 id="">, etc.

Re TOC: when a top-level category is in a whole file, yes. When it's split in a couple files (as it is now for eg certs_prefs_help.html), I don't see how you plan to do the reparenting. On a more general approach, I agree with moving towards a way to do it with a script/program. For the index, how about using all anchors, ie giving each one a category? That'll solve the automatic part. Or are there some that you don't want to see in the index? How do you plan on generating the glossary? You need the definitions somehow... (or was it glossary.rdf from glossary.html?)

> For the index, how about using all anchors, ie giving each one a category? > That'll solve the automatic part. Or are there some that you don't want to see > in the index? No, it's the opposite. I have some areas of the index (plugins, for example) that I would like to appear multiple times. For example, there should be a "Editor" index entry and a "Composer" index entry. I do not want multiple anchors (which would throw off the TOC generation anyway). > How do you plan on generating the glossary? You need the definitions somehow... > (or was it glossary.rdf from glossary.html?) Same way you would get the titles for the TOC and index. Currently, the glossary has <b id="my_definition">My Definition</b>, just like how the TOC has <h1 id="my_title">My Title</h1>.

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

The last (real) comments in this bug are from 2003, so way before we switched to the Toolkit Help viewer (which we did between SM 1.1 and 2.0). The old XPFE Help viewer had a sidebar with multiple vertical tabs (like the browser sidebar): Glossary, Index, Search, and Contents. In the new setup, the tabs have been (re)moved: Glossary is only linked from Help contents, i.e. it has no place of it own anymore. Index is gone (!), so is the need to create it. Search is now a search field (top right edge of the window). Only Contents is left unchanged. The search uses an index file that is actively maintained, i.e. it should *not* be generated automatically. The same applies to Contents (different file, same idea). As such this bug should probably be marked WONTFIX. Ian, is the above analysis correct?

> As such this bug should probably be marked WONTFIX. Done.