[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Thu, 2002-06-20 at 23:02, Grzegorz Adam Hankiewicz wrote:
..
>
> I find it more beautiful than useful, you can't search it from within a
> text editor and is terribly slow to load on the computers I have at hand.
>
> > So I first tried converting any of the other doc formats to the devhelp
> > format (which gives me context sensitive help in the Anjuta editor)
>
> Not really relevant, but I suposed the .info format was for that. At
> least rhide/setedit make an excellent use of the allegro info file.
It gives me help from inside Anjuta, it's the editor I kept for now
after trying some others. It works not that slow for me, I can click on
a function and press ctrl-h to get help for it, or press F1 to open the
documentations list. (Of course, it scans through all the XML files, so
it's not very fast, but I just tried, and it found the description of
set_gfx_mode in about a second, including starting up devhelp from
within anjuta.) Now I just have to figure out how I can also enable the
parameter names to be displayed for Allegro functions, like it does for
libc functions :)
> > but it didn't work. Instead I hacked the makechm.c to output devhelp
> > files directly. It's just a hack for now, as I don't have much time, but
> > it works for me, and I better send the patch here so I don't loose it :)
>
> Remember that using the -N switch of "cvs diff" will include new files
> too, so you can avoid two separate files and have a single diff. I will
> leave it in my low priority queue for now until I can test that devhelp
> viewer. Anyway, what's the meaning of that http://alleg.sf.net/devhelp/
> url you included?
>
Heh, nothing, I just needed some URL to put in. I also didn't know how
to handle the version field, I guess I should include one of the allegro
headers with the version in it.
--
Elias Pschernig