{5} Assigned, Active Tickets by Owner (Full Description) (28 matches)

It would be helpful if there was a tree view in the IDLDoc directories (produced when you view html frames on the output). A tree view would allow users that have files in many subdirectories to collapse or expand the view for quicker browsing. I suggest that the default be to show the collapsed view. I am not sure of what this would take in terms of effort, but consider it low to medium priority (i.e. it might improve efficiency some and make it nice to use, but isn't preventing users from accessing all that they need now - in my humble opinion).

I think that there is a problem when IDLDoc tries to construct a class definition for a class that just inherits. For example:

pro star_course_vs_time_receiver_request`__`define 
  struct = { star_course_vs_time_receiver_request, $ 
             inherits star_single_receiver_request } 
end

Produces the following error:

IDLDOC: cannot construct definition for class star_course_vs_time_receiver_request

This doesn't seem to happen all of the time, but I can't find a consistent thread to indicate when this problem occurs and when it doesn't.

When a class definition is splitted across multiple files, IDLDOC requires the ":Fields:" keyword to be present nowhere else other than in the descritpion of the "__DEFINE" procedure, but in the produced documentation it places it in the first file (in alphabetical order) relative to that class.

Add an advanced search on the search tab where criterion such as: categories, author, parameters, etc. can be specified separately.

Anything going to doc_system::warning should be remembered and set to a "Runtime warnings" section during output.

Currently, the search phrase is currently found "as a phrase" instead of as individual words (that might be in separate locations in the item). It would be better if items that had each word in the phrase, but not necessarily together, were also found.

A DocBook set of templates would be useful for including in books. Use xinclude to create one large document from all the individual documents.

Doctests are simple tests embedded in the documentation.

Inside a "tests" tag, any line that starts with "IDL> " would be executed and the output compared to the following line(s) that don't start with "IDL> ".

For example:

;+
; Factorial function.
; 
; :Tests:
;    IDL> a = factorial(5)
;    IDL> print, a
;        120
;-

The commands in a single :Tests: tag should run in a single scope (so the a variable above is seen by the second command).

Reported by steven in the  comments for the michaelgalloy.com post on the IDLdoc 3.3 release:

ok, so I just made a copy of the IDL template (template.pro from the examples directory of the IDL installation) into my own source directory, without changing anything.

I generated documentation from it with idldoc 3.3 (from the idl 8.0.0 workbench, and Windows 7).

I ran this command on the workbench console:

idldoc, root=’path_to_my_src_dir’, output=’path_to_my_doc_dir’, $
        format_style=’idl’

I still get a very poor documentation from the generated template.html file.

I get content from only 6 sections (PURPOSE, SIDE EFFECTS, RESTRICTIONS, PROCEDURE, EXAMPLE, and MODIFICATION HISTORY) and that’s all, and even these sections name do not show in the documentation, it’s only their content, so you do not know where this comment comes from…

MODIFICATION HISTORY is displayed as “Author information” which is not really right.

As for the routine parameters and keywords, only their name is given, not the associated comment… (I also tested idldoc with a lot of correctly “idl format” documented routines with a lot of commented parameters, and I got no comment at all for any of the parameters/keywords, which is a real pity)

So, should we not use the “idl” format and only use the “rst” and “idldoc” formats to get a correct result ? Or is there a way to improve the “idl” format result?

I could use the “rst” format, but most of the idl libraries I use (found on the web, like coyote or catalyst...) are documented using the “idl” format...

Currently, a link in an IDldoc code header can't span more than one line. A link to a long URL therefore might exceed 80 characters, in which case the world would end. It would be nice to be able to split the link over more than one line, e.g.,

; Ultimate IDL knowledge can be gained from `michaelgalloy.com
; <http://michaelgalloy.com>`.

I think this would make the header more readable.

IDLdoc should allow unrecognized headers as standard file/routine attributes and pass them through into the documentation. This request was originally from #51.

There should be an flag to set that would report on "suspicious" code.

Suspicious would include:

1. lack of compile_opt strictarr

Comment headers could be spell checked. The warnings page could have a listing of mispellings (with a "did you mean...?").