On 24/09/07 14:36:55, Catalin Marinas wrote:
- Tags generation for C/C++ files shouldn't use the C preprocessor. I
try to use it with the Linux kernel but there is no way I could add the required Linux definitions and includes on the "geany -g" command line, especially when I build the kernel outside the source tree and extra links are required for the include directories. Since geany can
OK. I've only used it for generating tags for installed libraries, e.g. GTK, then I can just pass CFLAGS=`pkg-config gtk+-2.0 --cflags`.
generate the tags from the loaded files directly, I don't understand why it calls cpp when running from the command line. My current
It can be useful - for the GTK example I only have to pass the main gtk.h header file and the preprocessor will include the rest. But I think we could add an option not to preprocess files. I hadn't thought of it before - I assumed that if the preprocessor has errors they can just be ignored - doesn't this work?
[...]
- Allow additional regexp to be specified for tag detection (I do
this with ctags)
Out of interest, when would you use that? Perhaps it's better just to improve the language parsers.
- "find *next* tag definition/declaration" command as it normally
stops at the first definition. There could be others, especially in the Linux kernel when many functions have different implementations depending on the architecture
Sounds good.
- Command to find a tag definition via a dialogue box rather than the
word in an editor
Good again ;-)
- Navigating back after finding a tag should go to the previous
position where the find command was invoked. It currently goes to the beginning of the buffer if the tag was found in the current buffer (more annoying) or returns to one line before the previous position (acceptable, though it would be better to return on the same line and column)
Sorry, I don't really understand this. Do you mean goto tag definition or find? Also I can't reproduce the off-by-one-line problem.
- Some preferences should be per project or file type to accommodate
different coding standards (i.e. Linux kernel work vs some internal company project). I also prefer Python indentation to use spaces and C indentation to use tabs but geany only supports one setting for all
We have been meaning to do this. One workaround is to use different configuration directories with the -c option, but this clearly isn't ideal.
- Remember the opened files per project rather than global (unless no
project was opened). I work on more than one project and start several geany instances
Again, this is planned - but we hadn't updated the TODO to say it(!)
Regards, Nick