I must have been looking in all the wrong places

[venta]

Does anyone know much about doxygen?

I am generating a whole bunch of html files from some C++ headers. The per-function documentation pages I get out all have the following element:

<div class="navtab">
....
</div>

which forms a sort of sidebar-style index to all the other functions whose docs were generated from the header.

I don't want this to be present. I thought that GENERATE_TREEVIEW=NO in the config file would suppress it, but it doesn't. (At least, it doesn't using doxygen 1.5.4 or 1.7.4, and I can't find any references online to it being broken. So maybe that isn't what that switch is meant to do, though it sounds like it in the docs.)

DISABLE_INDEX=YES also isn't the right answer - that disables a different bit of auto-generated guff which I also don't want.

Does anyone:
(a) know what GENERATE_TREEVIEW actually governs?
(b) know what switch I need to set to suppress this sidebar-index thing?
(c) as a last resort, have any ideas of how to painlessly remove a div element and all its contents from an html document? (I have no experience of Perl or anything like that, though I suspect I may be about to acquire some if (b) cannot be solved.)

Auxiliary comment: no, I can't just hide the div element using CSS. Well, I can, obviously. But it's not good enough. I actually need that element removed from the html.

Comments

[mister-jack.livejournal.com]

I've not done a lot with Doxygen, but I would have expected it to too.

What happens if you have USE_INLINE_TREES=YES and GENERATE_TREEVIEW=NO ? Have you got that?

(Oh, and for (b), a painful regex would suffice).

[venta.livejournal.com]

My doxygen.cfg doesn't seem to have a value set for USE_INLINE_TREES, but adding one (YES) doesn't seem to make any difference.

(Oh, and for (b), a painful regex would suffice).

... I'm not sure I'm capable of producing a regexp that painful!

I could just about get away with just removing the innermost div element, so wouldn't have to deal with nested elements much, but my regexping skills are possibly still not up to the job. Always time to learn, I suppose :)

[mister-jack.livejournal.com]

I meant to suggest USE_INLINE_TREES=NO might fix it if you had USE_INLINE_TREES=YES...

Are the < div >s aligned to the left or is there indenting? Are the contents of the div indented? If not are there nested divs inside it?

[venta.livejournal.com]

I meant to suggest USE_INLINE_TREES=NO might fix it

I did wonder, so I tried that one as well. Neither seemed to make any difference to the HTML output.

The tags are all indented (using spaces, not tabs). The relevant div has nothing but a table (and of course things you'd expect to find in tables) inside it.

[mister-jack.livejournal.com]

I think the regex you will need then is \r?\n <div class="navtab">(.*?)\r?\n </div>

Where the spaces between the \n and and < are the same as whatever indentation it is. If you don't want to worry about the possibility of nested div tags you could just use <div class="navtab">(.*?)</div> and then just stick that into your favourite regex capable text editor and do a replace in files.

[venta.livejournal.com]

I think the regex you will need then is...

Thanks. I'll have a look at that if I don't get any sense from the doxygen forum I also sent the question to earlier today - if not generating the div in the first place is an option, I'd sooner go with that.

do a replace in files

This will have to be done every time the files are autogenerated, from a makefile. So it needs to be a bit less human-assisted than that :) Once I've comprehended that actual regexp, then hopefully I can communicate it to sed and do it that way.

[mister-jack.livejournal.com]

I'd check it works manually first ;)

[venta.livejournal.com]

Nah, what can possibly go wrong...

(That came under the 'comprehending' part ;)

Cheers.

[venta.livejournal.com]

hopefully I can communicate it to sed

This will be a waste of time, Elizabeth. Sed is purely line-based and won't match over linebreaks.

[bateleur.livejournal.com]

Personally I take the view that millions of programmer hours worldwide could be saved if sed was removed from every system by default. That way nobody could every think "I have sed and not perl on this system, so I'll try doing it with sed".

[venta.livejournal.com]

My argument is "I know how to use sed[*] I don't know how to use perl, so I'll try doing it with sed". However, if your plan had been implemented I probably wouldn't be in that situation!

[*] For certain limited values of "know" and "use".