I have created a wiki page for Project Management under TM2, you can find it here:
http://wiki.macromates.com/Suggestions/ProjectManagementInTextMate2
I wrote Project Management rather than Projects since Allen does not intend to add projects to the 2.0 release (and quite possibly also not at a later date). So my intention was to collect
(1) suggestions on how to improve the file pane, (2) how to replicate/adapt the workflow for people who have previously used projects and (3) reasons why the filesystem-centric approach is not suited to meet their needs.
I'd be happy if other people contribute and add suggestions. Perhaps it can become a handy tool for Allen to collect useful feedback.
Max
Hi, I've noticed some of your comments in the wiki, and thought I'd reply here rather than alter what you've put (as it reads as an "opinion" piece).
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.
Have you tried Preferences > Project > Folders On Top (checkbox)?
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.
Have you tried rmate? http://blog.macromates.com/2011/mate-and-rmate/
Cheers,
David.
On 21/02/2012, at 16.51, Max Lein wrote:
[…] I'd be happy if other people contribute and add suggestions. Perhaps it can become a handy tool for Allen to collect useful feedback.
> Favorites are as of now (r9064) not usable
The main use-case for favorites is to add your various project folders to favorites, then use ⇧⌘O to quickly open a project. Not to use the Favorites folder as your project root.
The dedicated button in the file browser is likely to disappear and ⇧⌘O is likely to be rolled into ⌘T — the basic feature though is quite useful and will remain.
> This Windows Explorer-style way to sort files
As someone else pointed out, this can be changed.
> Sorting files in lexicographical order does usually not reflect the order of importance
If you work on a book with chapters it is not unusual to prefix your file names with a sorting key, e.g. as in: http://svn.textmate.org/trunk/Manual/pages/en/
> Many modern apps are moving away from the strict adherence to the files-folders metaphor [and] have revolutionized photo management/light editing by offering an abstraction layer to the file system
TextMate 1 is not modern but it also abstracted the file system by introducing ⌘T for quickly opening files via abbreviations (in addition to abstracting it via projects, which actually many *old* applications do).
> Other editors such as BBEdit have allowed the user to edit remote files […] directly with no middle man
It has long been stated that integrating (s)ftp is not in the cards for TextMate. Use an (s)ftp file system for (s)ftp mounts. As indicated on this mailing list there are plans to publish API for custom data sources (for the file browser) which could let third parties implement it.
Overall your writings include too much rhetoric (like “useless” and “revolutionized”) and “comparisons added for effect” (like Windows Explorer and BBEdit). I suggest you avoid all this and boil it down to the actual points you are trying to make. Also avoid things like “X abstracted Y and that was good, so TM must abstract X as well” (with no real details about how it should go about doing that or what exactly the advantages are).
Pretty much the only “problem” I acknowledge on that page (with 7-800 words) is that in TextMate 1 you can drag multiple folders to the TextMate icon and get one window with the files combined, where TextMate 2 will open multiple windows. Though it does not mention why this use-case is common (needing to open multiple folders in same window).
On Feb 21, 2012, at 6:45 PM, Allan Odgaard wrote:
On 21/02/2012, at 16.51, Max Lein wrote:
[…] I'd be happy if other people contribute and add suggestions. Perhaps it can become a handy tool for Allen to collect useful feedback.
Favorites are as of now (r9064) not usable
The main use-case for favorites is to add your various project folders to favorites, then use ⇧⌘O to quickly open a project. Not to use the Favorites folder as your project root.
The dedicated button in the file browser is likely to disappear and ⇧⌘O is likely to be rolled into ⌘T — the basic feature though is quite useful and will remain.
This Windows Explorer-style way to sort files
As someone else pointed out, this can be changed.
Sorting files in lexicographical order does usually not reflect the order of importance
If you work on a book with chapters it is not unusual to prefix your file names with a sorting key, e.g. as in: http://svn.textmate.org/trunk/Manual/pages/en/
I'm not writing a book with chapters. Putting prefixes on source file names seems like a bad programming practice, tending towards obfuscate
Many modern apps are moving away from the strict adherence to the files-folders metaphor [and] have revolutionized photo management/light editing by offering an abstraction layer to the file system
TextMate 1 is not modern but it also abstracted the file system by introducing ⌘T for quickly opening files via abbreviations (in addition to abstracting it via projects, which actually many *old* applications do).
Other editors such as BBEdit have allowed the user to edit remote files […] directly with no middle man
It has long been stated that integrating (s)ftp is not in the cards for TextMate. Use an (s)ftp file system for (s)ftp mounts. As indicated on this mailing list there are plans to publish API for custom data sources (for the file browser) which could let third parties implement it.
Overall your writings include too much rhetoric (like “useless” and “revolutionized”) and “comparisons added for effect” (like Windows Explorer and BBEdit). I suggest you avoid all this and boil it down to the actual points you are trying to make. Also avoid things like “X abstracted Y and that was good, so TM must abstract X as well” (with no real details about how it should go about doing that or what exactly the advantages are).
Pretty much the only “problem” I acknowledge on that page (with 7-800 words) is that in TextMate 1 you can drag multiple folders to the TextMate icon and get one window with the files combined, where TextMate 2 will open multiple windows. Though it does not mention why this use-case is common (needing to open multiple folders in same window).
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On Feb 21, 2012, at 6:45 PM, Allan Odgaard wrote:
On 21/02/2012, at 16.51, Max Lein wrote:
[…] I'd be happy if other people contribute and add suggestions. Perhaps it can become a handy tool for Allen to collect useful feedback.
Favorites are as of now (r9064) not usable
The main use-case for favorites is to add your various project folders to favorites, then use ⇧⌘O to quickly open a project. Not to use the Favorites folder as your project root.
The dedicated button in the file browser is likely to disappear and ⇧⌘O is likely to be rolled into ⌘T — the basic feature though is quite useful and will remain.
This Windows Explorer-style way to sort files
As someone else pointed out, this can be changed.
Sorting files in lexicographical order does usually not reflect the order of importance
If you work on a book with chapters it is not unusual to prefix your file names with a sorting key, e.g. as in: http://svn.textmate.org/trunk/Manual/pages/en/
I'm not writing a book with chapters. Putting prefixes on source file names seems like a bad programming practice, tending towards obfuscation. I write mostly in gcc Ada (GNAT) which requires a certain correspondence between file names and package names which appear in the file contents. Changing said file names would require me to edit the code(!) of not only those files but all programs that use them as these programs have to mention the package names of imported packages. If I want to use a particular file in more than one project, I have an untenable version control problem wit the prefixed sources and all files that use them. Also, if one wants to insert a new file in the list, then all the files below it have to be renamed. Similarly for merely wanting to rearrange things a little for clarity. And none of this even addresses the missing handy pseudo-folders which are really great for organizing things.
Many modern apps are moving away from the strict adherence to the files-folders metaphor [and] have revolutionized photo management/light editing by offering an abstraction layer to the file system
Good point. Projects in TM1 are a little like playlists in iTunes, where the "library" is all TM-openable file across the entire file system.
TextMate 1 is not modern but it also abstracted the file system by introducing ⌘T for quickly opening files via abbreviations (in addition to abstracting it via projects, which actually many *old* applications do).
Other editors such as BBEdit have allowed the user to edit remote files […] directly with no middle man
It has long been stated that integrating (s)ftp is not in the cards for TextMate. Use an (s)ftp file system for (s)ftp mounts. As indicated on this mailing list there are plans to publish API for custom data sources (for the file browser) which could let third parties implement it.
Overall your writings include too much rhetoric (like “useless” and “revolutionized”) and “comparisons added for effect” (like Windows Explorer and BBEdit). I suggest you avoid all this and boil it down to the actual points you are trying to make. Also avoid things like “X abstracted Y and that was good, so TM must abstract X as well” (with no real details about how it should go about doing that or what exactly the advantages are).
Pretty much the only “problem” I acknowledge on that page (with 7-800 words) is that in TextMate 1 you can drag multiple folders to the TextMate icon and get one window with the files combined, where TextMate 2 will open multiple windows. Though it does not mention why this use-case is common (needing to open multiple folders in same window).
I can't speak for Max, but I don't expect that he would agree that the only problem is the missing ability to drag a bunch of things to the icon and have them open in one window as a scratch project (although that is pretty neat). It seems to me that he has described a common TM working style using TM1 projects to quickly and intuitively (re)organize scattered source files pretty well ("abstractions" and the like not withstanding).
Jerry
On 22/02/2012, at 14.17, Jerry wrote:
If you work on a book with chapters it is not unusual to prefix your file names with a sorting key, e.g. as in: http://svn.textmate.org/trunk/Manual/pages/en/
I'm not writing a book with chapters. Putting prefixes on source file names seems like a bad programming practice […]
I was responding to the example given for where manual sorting was preferred, for that example, I think my response of prefixing the file names still make sense as it then also show up correctly e.g. on the link I posted to an example where this was carried out.
Your “rebuttal” failed to make me understand what your needs are. It sounds like for your case automated sorting would still be a possibility, you just don’t want the sorting to be based on file names. Similar to how ideally I want an implementation file like “foo.m” to appear before its header “foo.h” — I don’t think manual sorting is the way to solve that problem though (but I do deem it worthy of solving).
On Feb 22, 2012, at 12:27 AM, Allan Odgaard wrote:
On 22/02/2012, at 14.17, Jerry wrote:
If you work on a book with chapters it is not unusual to prefix your file names with a sorting key, e.g. as in: http://svn.textmate.org/trunk/Manual/pages/en/
I'm not writing a book with chapters. Putting prefixes on source file names seems like a bad programming practice […]
I was responding to the example given for where manual sorting was preferred, for that example, I think my response of prefixing the file names still make sense as it then also show up correctly e.g. on the link I posted to an example where this was carried out.
Your “rebuttal” failed to make me understand what your needs are. It sounds like for your case automated sorting would still be a possibility, you just don’t want the sorting to be based on file names. Similar to how ideally I want an implementation file like “foo.m” to appear before its header “foo.h” — I don’t think manual sorting is the way to solve that problem though (but I do deem it worthy of solving).
First of all I apologize for being a little tardy with my answer. I appreciate your patience generally with this subject. And I don't intend my language to be flamey so with that understanding maybe I can just write without trying to finesse every sentence.
I'm not using TM2 in my work yet so my comments might be a little undereducated from low usage of TM2. Part of the reason is that the Ada bundle is broken in TM2 and I didn't write it and so that's a TBD at this point.
And some ad hoc notation: Let "Project" mean a "TM project" which includes a way to organize files. Let "project" mean some piece of work that I am doing e.g. designing an autonomous moon cheese extractor.
I guess I'm having a little trouble telling you what my needs are because it seems so obvious to me that TM 1 is awesome in part because of its project feature--and now I'm explaining it to the guy who made it awesome. Xcode does an awful lot right in this regard (the last time I checked).
Most of my programming is doing numerical calculations and signal processing algorithms and simulations. My main language is Ada but I also use Octave, Pascal, C, and Mathematica and whatever else seems appropriate that I know about. I have written Ada bindings to the PLplot plotter. So I typically link to C plotter libraries, need access to the Ada plotter bindings (which are maintained in a local copy of an SVN repository), I might call an Octave command or two, and I might link to some old Pascal code. It is convenient to have some combination of these and other resources in a Project drawer, and to be able to organize them manually (visually) in any way that makes logical sense for a particular project. This can vary from project to project and Project to Project. Groups (what I previously called pseudo-folders) are wonderful for this kind of project organization. I think in another post I called this process of collecting resources and organizing in whatever way makes sense for a particular project (and Project) "orthogonal" to the OS's file system.
On disk, my code is organized by language, whether I wrote it or someone else wrote it, whether it is code that I use once or whether it is code that I reuse over and over, and whether it is a long-term project or just a one-off quickie which might or might not be related to my current project. I have made a kind of template which includes various build folders (normal, debug) and also product folders, as well as Project file, .tmprog, which is pre-built to reference some of my commonly-used stuff. So when I start a new project I just copy that folder and off I go, dragging into the Project drawer whatever other additional resources that I need.
On my current project, each time I do a run, I can optionally read run parameters from a text file or from keyboard. Each run generates a folder of results and documentation, including a very detailed text file of run parameters and numerical results. The run-results folder also usually contains a PDF of plots and some binary files that can be opened by other applications. After one or several runs that, say, are related to varying a parameter foo, I might organize these run-results folders with the Finder into something sensible, i.e. another folder that might be called "Varying foo". This can be anywhere on disk, but at some point I might want to access at least the text results file from within TM, often running a diff on them to easily see differences rather than trying to spot them by eye.
I sometimes also like to include in a project folders that don't necessarily contain source code but are associated e.g. with third party libraries that I link to, so that I can have quick access to documentation (including source code but not code that is compiled by my project) for those libraries. Groups are handy in this context also because I can drag only readable files from a Finder folder and not be bothered with the non-readable ones inside TextMate.
projects can span years and can take on a rather detailed structure, but with much unneeded structure easily hidden with the disclosure triangles in the Project drawer.
It has been discussed before using aliases to simulate the contents of a Project drawer but (1) I don't relish having to do all this by hand for Projects that I already have set up to (my definition of) perfection, and (2) it just makes much more sense to do much of this organization within TM since one's work at that point is TM-directed, not Finder-directed.
As to the arranging question, the feature of Projects that I love is the ability to arrange things manually so that things that make logical sense together can be put together, whether they be files, Finder folders, or TM groups, or any combination of all of the above. Maybe in a Project where I am updating PLplot bindings, I want the Ada source to be prominent and equally prominent with the C source, but in my cheese extractor work I want the PLplot sources put away since I don't often need to access it.
Yes, sorting would be really nice, too--by alphabetical by name and extension, creation or modification date (especially modification date). So maybe a neat way to combine all of these viewing modes is with a menu that has View by... and then Creation Date, Modification Date, Name, Extension, or Visual Layout, the latter being the way the user last had things arranged--kind of a list-based corollary of the Finder's visual layout mode. I love the Finder's visual layout mode (By Icons) and being able to quickly switch between views with a keystroke. Maybe there could be a user-defined (and/or TM-assisted) sort order so that foo.m does appear before foo.h. If it is extensions that are the problem, just have a draggable list of extensions and make that a secondary sort criterion after filename, creation, etc.
It would be cool to have TM's Project display have a mode like that, where (at each hierarchy level) all the folders and groups can be arranged spatially in two dimensions--that would make it super easy to find stuff without trying to parse a list every time. Maybe it could be in a kind of heads-up display temporarily overlying everything else.
Jerry
-
Allan Odgaard -
David Howden -
Jerry -
Max Lein