Fantastic. Thanks for all the info!
Sent from my iPhone
On Apr 11, 2014, at 2:11 PM, Allan Odgaard mailinglist@textmate.org wrote:
On 11 Apr 2014, at 20:01, John Sturgeon wrote:
- build a project (obj-c)
I assume you’re building a Cocoa application.
For TextMate 1.x I used an Xcode project myself and built it via the `xcodebuild` command line tool, though called from the Xcode bundle, which gave me build output inside TextMate (with clickable warnings/errors).
This is shown at http://blog.macromates.com/2005/html-output-for-commands/
However, `xcodebuild` has probably changed its output a dozen times since then, so I would be surprised if it still works.
Also, I found the workflow cumbersome because I had to go to Xcode when adding and removing files, so for 2.0 I initially used CMake but later did my own build system based on ninja.
I have not kept up with CMake, but this might be a viable alternative to using `xcodebuild`. CMake generates either Makefiles or ninja build files, for which there are TextMate bundles so that the build can be run from within TextMate (I’d recommend setting it up to generate ninja build files over Makefiles).
- show compile errors while editing
Not possible.
- autocomplete
You can use option-escape to complete Cocoa and standard library stuff.
The Cocoa completion also works when implementing (delegate) methods, in this case leave out the return type, e.g.:
- windowWill‸
Pressing option-escape here will show you all the windowWill… methods.
Another useful feature is ⌃H which will give you documentation for the current thing the caret is on. This works on method signatures like above (when the signature is a standard method), constants, types, method calls, C and C++ functions, etc.
- debug?
Nothing here either.
Are these things possible to do within text mate, or perhaps a hybrid of both editors?
I tend to suggest people just use Xcode for Cocoa development because building Cocoa apps have so many steps to it, and I am not familiar with an alternative build system that does not make it the user’s responsibility to manage this complexity.
That said, I am not using Xcode myself and find my own build system much more pleasurable to work with, than how I remember Xcode, for example I never need to manually add or remove files, the build system detects that automatically and when a file is removed, so are the things generated from it in the build directory (so no old resources or public headers will stick around, making you not realize that something depended on the thing you removed, until after next clean build), no fiddling around with UI palettes to harmonize build settings accross your main project and sub-projects representing custom frameworks being used, no custom shell phases that always run because the dependencies can’t be expressed, depending on a framework automatically depending on the succesful run of that framework’s tests, etc.
If it sounds interesting, you can look at the TextMate project at https://github.com/textmate/ — the `target` files are build system declarations, and `bin/gen_build` is responsible for reading them and generating a ninja build file, which will re-run `bin/gen_build` if any of the `target` files changes, or any of the folders from which files are loaded via globs.
Relevant to mention about this is that the “build target” is folder specific (via `.tm_properties`). So if I use ⌘B in a test file, it just builds and tests the target to which the tests belong.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate