Synopsis - Issue Tracker

I processed the current stable GGI includes (works fine now!), and output using the html formatter.

The generated html does show a lot of information about the API, but a number of things strike me as being completely irrelevant to outputting C (and I'm not sure there are HTML formatter options for fixing this as-is):
- anonymous typedefs (if that is the correct term) can be common in C code, eg. typedef enum { /* ...*/ } simple_name; In output, this gets shown as  a typedef of eg. "`0011" to simple_name. However, looking at docs for `0011 is rather unhelpful without knowing what it actually is. There needs to be a 'collapse-anonymous' or similar option, which somehow shows the typedef'ed name instead of the anonymous id (presumably `0011?).
- selecting a file doesn't really do much, not sure why? The only useful browsing interface is the Global namespace or the Name index.
- C output is probably best grouped using files, code-groups and globally; there are currently no explicit groups, so this doesn't help, but I'm not sure why the above file links don't work. You might want to group per-API, sub-API, internal/external functions. 
- C doesn't have inheritance :)

I'm not sure if you envisage multi-language code being browsed in the same interface? I suspect a C-specific formatter would be the way forward, or perhaps a hierarchy with a 'basic' one and then C/C++/...-specific language extensions. These could maybe automagically attach themselves based on labelling of the different structures in the .syn files.

Anyhow, there's some initial ideas.

For reference, I currently have the generated tree via the command-line:
 linux32 synopsis -p C -o html -f HTML -I /home/neil/synopsis/ggi/include/ include/ggi/*.h
at:
 http://www.kepiernet.f2s.com/ggi/html/

I have just checked in some enhancements to the C parser (rev:1912). Among the enhancements is support for what you call anonymous typedefs, i.e. there is a new processor 'TypedefFolder' that allows to fold the two logical declarations from

typedef struct {} Foo;

into one, making it look like it had been written

struct Foo {};

Let me know whether this is helpful. (And if you get a chance, please update your GGI docs so we can try to fix any remaining bugs. Thanks !

(What is 'linux32' ?)

OK, figured it out. I have put a new manual here:
http://synopsis.fresco.org/ggi/
(and will keep it updated as I make more enhancements).

Use '-l TypedefFolder' to see the effect of typedef folding.

I've not looked at this for a long time.

In terms of fixing the specific issue you fixed, without looking at the code in question, I'm intrigued why it doesn't do anything for `0172, `0173, `0174, which were the typical form for ones not working in the past, I think. Apparently its helped but not completely, comparing:
a)http://www.kepiernet.f2s.com/ggi/html/NameIndex#96
b)http://synopsis.fresco.org/ggi/NameIndex.html#96

In terms of resolving the namespace issue, GGI and a lot of other libs are quite good at using prefixes for functions and so on. Based on that, it might be useful to artificially 'group' functions (maybe variables, macros etc too) based on a prefix. For example, you might define a namespace based on --define-namespace-prefix='ggi' or somesuch.

Also, some change since I used it seems to have lost some useful indenting?

1) I'm not sure about the missed names. I'll look into it.
2) Yes, synthesizing modules from common prefixes is a good idea, and can easily be done by means of scripting. I'm not sure this is worth a processor 
in the core code, though.
3) Can you point me at some output you think isn't formatted right ?

Thanks,

I believe I fixed 1). There are still some anonymous 
types left ("union { char c; int i;} my_union;"). 
I'm not sure whether there is any better way to
format them without becoming ambiguous. May be the label could be '<anonymous>', but the actual name used to construct the URLs etc. could remain what it is ?

Please have a look at http://synopsis.fresco.org/ggi, I just updated it.

Thanks,

The issues reported here are all solved. (Well, documentation could always be better.)