On Nov 25, 2007, at 4:07 PM, Kurt Stoll wrote:
Dave,
On Nov 5, 2007, at 11:44 AM, David Ewing wrote: I hope that helps more than it confuses.
I can't speak for the OP, but I found your information to be useful and enlightening. But, I still have some questions that maybe you can clear up.
First, the Xcode User Guide (Chapter 18, page 226) says:
To create your own text macros, you have to create a language specification for the language to which you want to apply the macro. Then, place the language specification in:
~/Library/Application Support/Developer/Shared/Specifications
For examples of language specifications see:
<Xcode>/Applications/Xcode.app/Contents/PlugIns/TextMacros.xctxtmacro
However, when I put my "language specification" in ~/Library/Application Support/Developer/... as directed, I do not see my macros. I also tried putting it in ~/Library/Application/Support/Xcode/Shared/Specifications - to the same effect (or lack thereof). Note that .../Developer/ did not exist on my machine before I created it. When I put it with the other macro files underneath Xcode, though, it worked as expected. My conclusion is that the Xcode User Guide is pointing to the wrong location, but I don't know where the correct location is. I'd rather not put it directly under Xcode for the long term. Can you enlighten me on this?
It sure seems like that directory should work. But this one certainly does:
~/Library/Application Support/Developer/3.0/Xcode/Specifications
Second, you say:
To find a list of all valid values for the IncludeContexts and ExcludeContexts entries you have to look in all the .xclangspec files.
To be fair, you also indicate that we don't need to look at these files, but I'm curious and would like to peruse these files. I may get ambitious enough to create macros for languages not currently supported by Xcode (e.g., Verilog). Where are these files located? (They are not in the Xcode plug-ins directory with the xctxtmacro files.
In the spirit of teaching one to fish, try in Terminal:
find /Developer -name \*.xclangspec
Third, I am having difficulty getting an autocomplete text macro to work at the "file level" - that is, outside of the scope of any function, declaration, string, or comment (although, maybe within the scope of an @interface or @implementation). In fact, even the built-in macros have this problem. For example, the cseparator macro should be valid in these scopes, but typing in 'csep' will not bring up the autocompletion - an <esc> is required to bring up the list. This isn't really a great problem - I don't mind using the <esc> for the few times that I will actually use these macros. On the other hand, it sure seems that there should be a way to set IncludeContexts to be able to have this work properly. Any thoughts?
This isn't an issue with IncludeContexts, this is an intentional subtlety to how automatic completion of macros works. When the completion prefix doesn't match what gets inserted, we won't do the automatic completion. Think about typing "csep", having it turn into "/***...***/", and you keep typing. It would flash back and forth from what you typed, and what it wanted to complete to. Ugly. (Generally, it's good to have the completion prefix be a prefix for the given text macro. But even we don't follow that rule.) Finally, I did find a bug with the autocompletion (I have filed a bug report: 5611963). I don't think it is serious; most people should not encounter it. But, while experimenting trying to understand how the text macros worked, I stumbled on the bug, and felt compelled to track it down. So, I'll give a concise description here in the hopes that I save at least one person from stumbling on this as well.
If you have substitution text (the TextString field) that is shorter than the prefix you type in to the editor to trigger the autocompletion, Xcode will suffer a fatal crash. Again, it's pretty silly to have a substitution that is *shorter* than what you typed in to trigger the macro, so I don't believe its a practical problem. But, my experiments triggered it, so I thought I'd pass it on.
Sounds like a real bug.
Dave
|