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