We set the name as:
'---/+++ file'
I wanted the display name to suggest a diff without calling it something directly as "file (diff)", so I thought '---/+++' would be a nice and condense way of indicating that.
This is based on the previous commit window code base. It replaces the NSTextView with a OakTextView for entering the commit messages. This allows us to take advantage of some of the git grammar features, e.g., fixup!.
If other SCM bundles are updated in the future to include any specific grammars, these can be used in the commit window by setting the bundle grammar to "text.SCM-commit", where SCM could be hg or svn for example.
Changes to note:
* The Modify row button for the "--action-cmd" commands are now implemented in the action menu and the table context menu.
* The shortcut for committing is ⌘↩ (but fn-return seems to (still) work).
This allows the commit command line tool to open a window as “native”.
We use distributed objects for talking to TextMate and getting a response. For the response, we release the connection in the next iteration of the event loop and then gracefully exit the program. Though it’s not clear if this is enough time for distributed objects to reply the client (if not, an exception is thrown in the client about “connection disappeared while waiting for a reply”).
This means if TextMate is terminated during update, worst-case is that the bundle is gone (which we can detect) rather than potentially leaving a partially deleted bundle on disk.
Also, since we now move in the updated version immediately after removing the old, the time where the disk is in a bad state (compared to our bundle index) has been minimized.
We don’t have a specific element associated with the result being announced so we use the current responder (unless it has accessibility ignored, in which case we do not post any notification).
Using the current responder is not ideal, but I do not know how we can either associate the notification with the find panel or post it as a global notification.
This function makes it easy to set accessibility "labels" for UI elements.
It is flexible - takes care of NSView vs. NSControl case, labels can be
specified directly as a string or as a user interface element.
The standard doesn’t care which side the keyword is placed on, but placing it on the right makes it easier to read types.
E.g. reading “int const* const” from right to left we get “const pointer to const integer”.
This would happen for a command that is set to re-use previous output window (when busy). We would kill the running command and wait (in the main dispatch queue) for it to stop, but since the runner is (now) using GCD as well, and updating the “did exit” status in the main queue, we would wait forever.
Set the `capnp_prefix` variable when calling ./configure.
E.g. build and install cap’n’proto in $HOME/build:
./configure --disable-shared --prefix="$HOME/build"
make -j6 check && make install
Then configure TextMate to find it there:
capnp_prefix="$HOME/build" ./configure
Additionally we expect that any variable the user has set is properly shell escaped. Though this is only relevant if the value contains spaces or escape characters.
Currently bundle commands has not been updated to assume that the variables are already shell escaped, so this commit can cause issues with existing bundles.
The motivation for this change is that we may enable MallocDebug when running tests, which is done via environment variables that we do not want to be passed on to the shell tools we execute.
No file descriptors (other than input/output) should be inherited by our child process. We set FD_CLOEXEC ourself, but system frameworks might not always set it, or there might be a race condition (e.g. with socket(), pipe(), mkstemp(), etc.).
Failure to create a pipe does happen “in the wild” (with the error “too many open files”). Since majority of subprocess executions relate to gathering version control info we can probably ignore the failure, as not having version control info is better than crashing.
OTOH that pipe() fails does seem to be a symptom of a more serious issue.
The io::spawn implementation has also been updated to use io::create_pipe which sets FD_CLOEXEC, so there should be no reason to set this.
