Allan Odgaard <mailinglist@...> writes:
Correct, but you can use $projectDirectory or $CWD.
[…] is this a bug?
The reason is that TM resolves the .tm_properties files and use your setting
for projectDirectory to set
TM_PROJECT_DIRECTORY for command execution. So this variable does not exist
prior to resolving the
files, nor is it set during, as it’s a general-purpose free-form system, and
you set projectDirectory
not TM_PROJECT_DIRECTORY.
Right, that makes sense. If I'm reading correctly, then TM_PROJECT_DIRECTORY is therefore only useful in bundles; in a .tm_properties file it won't have had a chance to be set yet. It would be good to call this out clearly as the documentation evolves. For my part, I'd started with an assumption more like the synchronous linkage of path (shellvar) vs PATH (envvar) as many shells implement.
Digging deeper, with this in ~/.tm_properties:
foo = 'foo' windowTitle = '${TM_DISPLAYNAME}${foo:+ - $foo}'
.. I don't see '- foo' after the display name. Ah right, so this implies that .tm_properties files aren't actually interpreted sequentially. That in turn suggests that there's no way to inspect and act upon a value in ~/.tm_properties that was inherited from a more specific .tm_properties file.
FWIW, $CWD doesn't seem to be very useful for my original purpose. Even when started via the CLI interface on a specific directory, $CWD seems to be set to $HOME. Changing the root of the file browser doesn't appear to affect $CWD either. Given that, $CWD doesn't assist my goal of distinguishing working project windows from one another.
So is there a way to get the current project name into the title bar via end-user configuration? Would it work to create a custom bundle to manage windowTitle?
Thanks, John