From TextMate Wiki

Suggestions: Project Management in TextMate 2: how to improve the file browser and beyond

This page concerns itself with project management in TextMate 2. In TextMate 1, projects could be used to structure files in a way that does not reflect the actual locations in the filesystem. This feature has since been removed in the TextMate 2 public alpha.

In order to improve TextMate 2 by user feedback, this page collects shortcomings of the current implementation and possible work arounds.

Suggestions on how to improve the TM2 file pane

Working with several hierarchies of folders

I found this very confusing so far: without adding the file's directory or parts of it (see e. g. here on how to add the file's directory to the window title) -- especially when you work with many identically named files. It seems to me this option should be on by default (the savvy user can still deactivate it).

Furthermore, it may be useful to make the directory the user opens the lowest directory the user can open in this window, i. e. only this folder and up are available.

FTFF: Fix the Favorites

Favorites are as of now (r9064) not usable: e. g. they cannot be manipulated via drag and drop and clicking in Favorites reveals their location in the file system (~/Library/Application Support/TextMate/Favorites). Since Favorites are a »privileged« folder in the sense that it warrants its own precious icon in the file browser, I don't think the full location should be revealed. This also adds a lot of clutter as TextMate adds 8 (!) other entries to the recent location list (computer > volume > Users > [user name] > Library > Application Support > TextMate > Favorites).

Favorite Files Too

For instance I need to often edit my dev nginx.conf or .zshrc and it would fit well into how I understand Favorites to have them listed there.

Folders first, then files

This Windows Explorer-style way to sort files (first, display folders in lexicographical order, then files in lexicographical order) should at least be optional.

Sorting files and folders manually

Sorting files in lexicographical order does usually not reflect the order of importance. E. g. the file appendix.tex appears before section_1.tex, even though it is more sensible to have the order of the files follow the logical ordering: first the master tex file, then the section files and finally appendix.tex.

Hence, an option to sort files manually would be very helpful.

New File options on right-click menu

"New File" is missing from the project drawer right-click menu on a folder. This was very useful in TM1.

Advantages of projects

Projects are in many instances simpler to create than custom folder settings .tm_properties

Projects were easy to create on TextMate 2 and they allowed one to collect files that are located at very different locations in the file system. Folders in the project could be used to categorize files and subfolders. Only files the user specifically wants to include are included.

To replicate this partially, one has to use the command line and create symlinks. Dragging and dropping is often much quicker.

Projects allow files and folders to be sorted the way the user wants them to be sorted

In projects, files could be arranged in any order, not just alphabetical or based on some other simple criterion (e. g. change date). For instance, it may make more sense to arrange files in the order chapter_1.tex, chapter_2.tex , ..., appendix.tex whereas sorting by file name would put the appendix on top.

Advantages of moving away from adhering to the file system hierarchy

Many modern apps are moving away from the strict adherence to the files-folders metaphor. Apps like Aperture and Lightroom, for instance, have revolutionized photo management/light editing by offering an abstraction layer to the file system.

One possible idea would be that »projects« contain sources which could be files, folders, repositories or files that are located on a remote server.

git repositories/integration with version control software

By sticking to a purely filesystem-based approach, one misses out on the opportunity to simplify the workflow. For instance, currently, if I want to copy code from an older version of the file, I use Gitbox to browse my git repository, then launch FileMerge to check out the difference and then copy bits and pieces from the FileMerge window into TextMate .

If a user could add git repositories to TextMate, the workflow could be simplified substantially. Displaying the files of a git repository (i. e. the content of .git and its subfolders) is not very useful here. Instead, the repository could be loaded as such and one could select older versions of files with ease. If the user adds several (possibly remote) repositories, the result could be pushed to a server.

Working with remote files

Right now, I use CyberDuck + TextMate to edit web pages remotely. Other editors such as BBEdit have allowed the user to edit remote files (accessed via ftp or better sftp) directly with no middle man.

Why not have both?

The primary users of TextMate are developers, who typically favor robustness and configurability over convention. For a smaller firm or an independent project, it might make sense to enforce hierarchy. For a larger firm with a code base that includes thousands of files in which you are interested in 10 of them in various locations in which the only access available is via an ssh mount, enforcing hierarchy is a deal breaker.

Enforcing hierarchy would force many users of the largest tech firms back to vi/emacs and terminal windows (or a different editor!). If both forms are already implemented, why not include both?

Retrieved from
Page last modified on July 11, 2012, at 15:16 UTC