El 23/04/2007, a las 14:00, textmate-request@lists.macromates.com escribió:

De: Allan Odgaard throw-away-1@macromates.com Fecha: 23 de abril de 2007 03:03:18 GMT+02:00 Para: TextMate users textmate@lists.macromates.com Asunto: Re: [TxMt] QuickOpen included files Responder a: TextMate users textmate@lists.macromates.com

On 20. Apr 2007, at 20:59, Juan Falgueras wrote:

...

I have change the source of the list of paths for QuickOpen included files. It works fine:

Thanks, seems to work fine here as well. Some comments:

• we should differ between <system> and "user" include paths

actually the script does consider <system> and "user" paths and get first the "user" path not looking for TM_HEADER.. when "user"

if (!$header) { $line =~ /#\s*include\s*([<"])(.*?)[">]/; $local = $1; $header = $2; }

if ($local eq '"') { $t = $ENV{'TM_DIRECTORY'}; if (-f "$t/$header" ) { print "$t/$header"; system("mate -r "$t/$header""); exit 0; } }

• TM_HEADER_SEARCH_PATHS should default to the output from gcc/g+

• (to not require user setup)

I have thought about it but, when? If you ask for echo | g++ -E - v -x c++ - and then analyze the output (with the A.Tomazos perl script, for example), you then don't want any TM_HEADER_SEARCH_PATHS, but instead, to call to the g++ compiler for this. I've thought this must be slow, and the answer to the previous query is near always the same.

• search path could depend on whether we are in source.c or source.c++ (the former has a smaller search path)

yes. The difference is (in my system):

C++ /usr/include/c++/4.0.0 /usr/include/c++/4.0.0/powerpc-apple-darwin8 /usr/include/c++/4.0.0/backward /usr/local/include /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include /usr/include /System/Library/Frameworks /Library/Frameworks

versus

C /usr/local/include /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include /usr/include /System/Library/Frameworks /Library/Frameworks

I have used the most frequently used C++ :)

• additional search paths should be taken from the current Xcode project file, if any (and Xcode’s products build dir should also be a search path for frameworks)

oups! don't use XCode, sorry. I think it must be done asking XCode (via AS) or hacking the XCode project file... (complicated and dirty) :(

• need to handle framework inclusion, e.g. <Cocoa/Cocoa.h>

you are again wright:

% locate Cocoa.h /Developer/ADC Reference Library/documentation/Cocoa/Cocoa.html /Developer/ADC Reference Library/documentation/Cocoa/Conceptual/ CarbonCocoaDoc/Articles/CarbonInCocoa.html /Developer/ADC Reference Library/documentation/Cocoa/Conceptual/ CarbonCocoaDoc/Articles/CarbonUIInCocoa.html /Developer/SDKs/MacOSX10.3.9.sdk/System/Library/Frameworks/ Cocoa.framework/Versions/A/Headers/Cocoa.h /Developer/SDKs/MacOSX10.3.9.sdk/System/Library/Frameworks/ JavaEOCocoa.framework/Versions/A/Headers/EOCocoa.h /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/ Cocoa.framework/Versions/A/Headers/Cocoa.h /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/ JavaEOCocoa.framework/Versions/A/Headers/EOCocoa.h /System/Library/Frameworks/Cocoa.framework/Versions/A/Headers/Cocoa.h

is not found by this simple script and there are:

% find /System/Library/Frameworks/ -iregex ".*/Headers/.*.h" | wc -l 2112

many.

It was not a problem for me since I am working in a UNIX standard programming way...

• need to handle import as well as include (in the regexp)

is is easy to add it

And if I understood Chris correctly, he’d like to optionally search under /Developer/SDKs/«chosen SDK».

As far as I have understood this is included in your Frameworks plus XCode dirs expansion search

Are there other things we’d like to support?

(;