When I hit Command+O, the directory I'm put in is the one for the project, but I would prefer that the directory match the file that I'm currently editing (which is often in a subdirectory of the project).
I guess that most of the time I open a file, I'm opening a sibling to the file I'm currently editing. I have this behavior with UltraEdit on Windows and find it quite productive.
-Chuck
On May 31, 2007, at 11:11 AM, Chuck Esterbrook wrote:
When I hit Command+O, the directory I'm put in is the one for the project, but I would prefer that the directory match the file that I'm currently editing (which is often in a subdirectory of the project).
I guess that most of the time I open a file, I'm opening a sibling to the file I'm currently editing. I have this behavior with UltraEdit on Windows and find it quite productive.
-Chuck
I'm not quite sure I understand what you're asking. Cmd+O is just a generic open command. The directory you are shown is the last directory that TextMate remembers you opening something from. If you've already got a project open (re: "which is often in a subdirectory of the project") why not use the file drawer to just click the file?
- Cliff
On 31. May 2007, at 19:24, Cliff Pruitt wrote:
[...] I guess that most of the time I open a file, I'm opening a sibling to the file I'm currently editing [...]
[...] If you've already got a project open (re: "which is often in a subdirectory of the project") why not use the file drawer to just click the file?
Or even better: Navigation → Go to File… (⌘T)
On 5/31/07, Allan Odgaard throw-away-1@macromates.com wrote:
On 31. May 2007, at 19:24, Cliff Pruitt wrote:
[...] I guess that most of the time I open a file, I'm opening a sibling to the file I'm currently editing [...]
[...] If you've already got a project open (re: "which is often in a subdirectory of the project") why not use the file drawer to just click the file?
Or even better: Navigation → Go to File… (⌘T)
I guess ⌘T does the trick. I'll just have to break the habit of also using ⌘O.
Okay, on to the next request. :-)
Or maybe this already exists: I would like a list of open files in most-recently-used (MRU) order. ⌘T could probably be tweaked to do this. In fact, many times it at least shows me the very last file I looked at. But sometimes it does not (and I don't know why). And the order of the subsequent files (alphabetized?) isn't particularly useful in a large project.
The utility for an MRU list is that during software development I often flip between the same 2 - 5 files while fixing a bug or adding a feature.
-Chuck
On 6/1/07, Chuck Esterbrook chuck.esterbrook@gmail.com wrote:
On 5/31/07, Allan Odgaard throw-away-1@macromates.com wrote:
On 31. May 2007, at 19:24, Cliff Pruitt wrote:
[...] I guess that most of the time I open a file, I'm opening a sibling to the file I'm currently editing [...]
[...] If you've already got a project open (re: "which is often in a subdirectory of the project") why not use the file drawer to just click the file?
Or even better: Navigation → Go to File… (⌘T)
I guess ⌘T does the trick. I'll just have to break the habit of also using ⌘O.
Okay, on to the next request. :-)
Or maybe this already exists: I would like a list of open files in most-recently-used (MRU) order. ⌘T could probably be tweaked to do this. In fact, many times it at least shows me the very last file I looked at. But sometimes it does not (and I don't know why). And the order of the subsequent files (alphabetized?) isn't particularly useful in a large project.
The utility for an MRU list is that during software development I often flip between the same 2 - 5 files while fixing a bug or adding a feature.
The behavior I'm seeing with ⌘T is that it shows MRU files most of the time, but then every so often it "resets" and just shows an alphabetized list of all project files. I'm not sure what triggers the reset yet. I'm switching a lot between TextMate, Terminal and Safari in my current work. It's not a TextMate quit+launch or project close+open that's causing the reset because I'm not doing those things when it happens.
-Chuck
On 1. Jun 2007, at 15:38, Chuck Esterbrook wrote:
The behavior I'm seeing with ⌘T is that it shows MRU files most of the time, but then every so often it "resets" and just shows an alphabetized list of all project files. I'm not sure what triggers the reset yet [...]
It happens when TM has to rescan the project folder -- it will be better in the future, I also plan to make the MRU list persist after relaunch.
On 6/1/07, Allan Odgaard throw-away-1@macromates.com wrote:
On 1. Jun 2007, at 15:38, Chuck Esterbrook wrote:
The behavior I'm seeing with ⌘T is that it shows MRU files most of the time, but then every so often it "resets" and just shows an alphabetized list of all project files. I'm not sure what triggers the reset yet [...]
It happens when TM has to rescan the project folder -- it will be better in the future, I also plan to make the MRU list persist after relaunch.
Thanks. Those improvements will be a *huge* help.
-Chuck
On Jun 1, 2007, at 9:38 AM, Chuck Esterbrook wrote:
The behavior I'm seeing with ⌘T is that it shows MRU files most of the time, but then every so often it "resets" and just shows an alphabetized list of all project files. I'm not sure what triggers the reset yet. I'm switching a lot between TextMate, Terminal and Safari in my current work. It's not a TextMate quit+launch or project close+open that's causing the reset because I'm not doing those things when it happens.
Feel free to correct me, but best as I've been able to tell TM will change the file history any time a directories contents have been modified by something other than TextMate. So given:
ProjectRoot/ ProjectRoot/css/ ProjectRoot/js/
You can work with files in the /css & /js directories and they will appear at the top of your ⌘T menu. Now, however, if you switch to terminal and make a change, not just to one of the files you were working with, but to anything else in the directory (say you check out new files from svn into your /js directory), TM will have to (apparently) re-scan the directory for changes, and any files in the changed directory (/js) will be removed from the history at the top of your ⌘T list. Any files in the history that are not in the directory that was modified (e.g. all of your .css files) will still be available in the history.
If you close/reopen a project, everything gets reset.
I'd probably use ⌘T more if this was a little smarter about what needed to be shown & remembered but I have no real complaints. I have plenty of Windows co-workers that constantly moan about the lack of TextMate on their OS.
Maybe some good ⌘T stuff is coming in 2.0...
- Cliff
On Jun 1, 2007, at 8:50 AM, Chuck Esterbrook wrote:
The utility for an MRU list is that during software development I often flip between the same 2 - 5 files while fixing a bug or adding a feature.
When I'm doing that, I make sure those 2-5 files are my first set of tabs, then I just use ⌘1 - ⌘5 to access them.
j.
On 6/1/07, Jay Soffian jay-txmt@soffian.org wrote:
On Jun 1, 2007, at 8:50 AM, Chuck Esterbrook wrote:
The utility for an MRU list is that during software development I often flip between the same 2 - 5 files while fixing a bug or adding a feature.
When I'm doing that, I make sure those 2-5 files are my first set of tabs, then I just use ⌘1 - ⌘5 to access them.
If a file is on the "extended menu" (>>) rather than a tab (because there is no space for more tabs), is there a way to get it moved over?
-Chuck
On 6/1/07, Chuck Esterbrook chuck.esterbrook@gmail.com wrote:
On 5/31/07, Allan Odgaard throw-away-1@macromates.com wrote:
On 31. May 2007, at 19:24, Cliff Pruitt wrote:
[...] I guess that most of the time I open a file, I'm opening a sibling to the file I'm currently editing [...]
[...] If you've already got a project open (re: "which is often in a subdirectory of the project") why not use the file drawer to just click the file?
Or even better: Navigation → Go to File… (⌘T)
I guess ⌘T does the trick. I'll just have to break the habit of also using ⌘O.
...
I was wrong. ⌘O still needs improvement. Today I did "mate foo bar" from the command line. Well okay, the first issue is that the two files were put in a file drawer, but not actually opened up. I was expecting to see the contents of at least one of them and preferably have windows or tabs for both.
But getting back to ⌘O, I clicked on "foo" and read through it. I clicked on "bar" and read through it. Then I realized I needed "baz" and hit ⌘O at which point I was looking at some directory totally unrelated to the one that "foo" and "bar" were located in. I had to poke around to get to where "foo" and "bar" were, but after two pokes I said screw it and went back to the command line to type "mate" again.
So my suggestion is that ⌘O set the directory to the directory of the currently edited file. It's more likely to be useful as I've experienced in other applications.
-Chuck
On Jun 11, 2007, at 7:51 AM, Chuck Esterbrook wrote:
I was wrong. ⌘O still needs improvement. Today I did "mate foo bar" from the command line. Well okay, the first issue is that the two files were put in a file drawer, but not actually opened up. I was expecting to see the contents of at least one of them and preferably have windows or tabs for both.
But getting back to ⌘O, I clicked on "foo" and read through it. I clicked on "bar" and read through it. Then I realized I needed "baz" and hit ⌘O at which point I was looking at some directory totally unrelated to the one that "foo" and "bar" were located in. I had to poke around to get to where "foo" and "bar" were, but after two pokes I said screw it and went back to the command line to type "mate" again.
So my suggestion is that ⌘O set the directory to the directory of the currently edited file. It's more likely to be useful as I've experienced in other applications.
-Chuck
As I understand it, the mate command line tool is not at all the same as the TextMate application (its just a little helper utility), so it would not (and really should not) have any bearing on the stored path for opening new folders. Think of it this way:
In its current incarnation text mate expects that you're doing things in a somewhat standard way. If you're in the terminal dinking around then you've probably cd'd to the directory you're working in. If you've opened foo & bar & realize you need baz, just cmd+tab back to terminal & 'mate baz'. If you're the kind of person that uses the open command a lot, TM assumes you're probably still working on whatever you last opened from the open dialog.
What is TM going to show me if I'm working on a new document that hasn't been saved yet? What about something I'm editing using the "Edit in Text Mate" command? What will it show me if nothing is opened? Why would it think I've changed what I'm working on just because I've un-minimized some 30 minute old readme file from the dock that I've since moved into the trash but its still open in TM?
The point is, I can see where you're coming from but I think TM's behavior is correct for most people, most of the time. There are always exceptions and sometimes some people tend to be more of an exception that a rule, but it's not a problem with the app's command itself, its just that it doesn't match your workflow.
But honestly, if you want a solution, why not just do this: Create a new bundle command and give it whatever tab trigger/shortcut/ scope you want and put this into it:
#------------------------------ osascript <<-APPLESCRIPT set TMVar to "${TM_FILEPATH}" tell application "System Events" set openLocation to alias TMVar set filePath to POSIX path of ((choose file default location openLocation) as alias) do shell script "mate " & quoted form of filePath end tell APPLESCRIPT #------------------------------
That command will open a standard open dialog that defaults to your current file's path. It could probably be streamilned & shortened even but I kind of slapped it together. Anyway, it should give you what you need.
- Cliff
Cliff,
I appreciate the thorough response, but I don't think it's on the mark. See below:
On 6/12/07, Cliff Pruitt lists.cpruitt@cliffpruitt.com wrote: ...
As I understand it, the mate command line tool is not at all the same as the TextMate application (its just a little helper utility), so it would not (and really should not) have any bearing on the stored path for opening new folders. ...
Oh, I don't think it should. This was just one particular way to get in that situation. I'm simply asking that ⌘O start in the directory of the current file (if there is one and it has a valid directory).
I can't see any harm caused by this and I can see a lot of good.
Consider this other case: I'm in a project and when I open I see that project directory. Then I hit ⌘` to switch to another TextMate window. Now I hit ⌘O and I'm still seeing the completely unrelated file system directory from that other project! How can that be useful/good?
In its current incarnation text mate expects that you're doing things in a somewhat standard way. If you're in the terminal dinking around then you've probably cd'd to the directory you're working in. If you've opened foo & bar & realize you need baz, just cmd+tab back to terminal & 'mate baz'. If you're the kind of person that uses the open command a lot, TM assumes you're probably still working on whatever you last opened from the open dialog.
Hey now, nothing non-standard about Terminal. It's been around since '89 NeXTstep! "Terminal for life." :-)
Btw I actually consider opening from the current file's directory to be the norm. And also the norm: Home going to the beginning of the text instead of column 1 where all my uninteresting whitespace is. But then "standard behavior" is a funny thing because it really varies based on who you ask and what apps you use.
What is TM going to show me if I'm working on a new document that hasn't been saved yet? What about something I'm editing using the "Edit in Text Mate" command? What will it show me if nothing is opened? Why would it think I've changed what I'm working on just
That answer is *easy*: If there is no current file or the current file has no valid path, then ⌘O would not change the directory. Isn't this like two lines of code?
if ([self curDoc]!=null && [[self curDoc] hasValidDirectory]) [openDialog setDirectory:[[self curDoc] directory]];
(Hope my Obj-C is not *too* rusty; been awhile.) Okay, so a few more lines for -hasValidDirectory and anything I might have forgotten.
because I've un-minimized some 30 minute old readme file from the dock that I've since moved into the trash but its still open in TM?
It wouldn't kill you if ⌘O put you in the directory with the README (or did nothing if the whole directory was gone). You were probably about to open INSTALL or LICENSE anyway. If not, you probably hit ⌘W or ⌘` first. The current file's directory is simply a better guess than "last directory".
The point is, I can see where you're coming from but I think TM's behavior is correct for most people, most of the time.
I don't see how it could be. If you ⌘` to another window, work for 45 minutes and then hit ⌘O, are you really thinking this: "I want to be in the directory of that last window I was working on 45 minutes ago." Very slim chance.
There are always exceptions and sometimes some people tend to be more of an exception that a rule, but it's not a problem with the app's command itself, its just that it doesn't match your workflow.
I agree that type of situation comes up, but I don't think that's the case here (due to my reasons above).
But honestly, if you want a solution, why not just do this: Create a new bundle command and give it whatever tab trigger/shortcut/ scope you want and put this into it:
#------------------------------ osascript <<-APPLESCRIPT set TMVar to "${TM_FILEPATH}" tell application "System Events" set openLocation to alias TMVar set filePath to POSIX path of ((choose file default location openLocation) as alias) do shell script "mate " & quoted form of filePath end tell APPLESCRIPT #------------------------------
That command will open a standard open dialog that defaults to your current file's path. It could probably be streamilned & shortened even but I kind of slapped it together. Anyway, it should give you what you need.
Hey, that's pretty cool and pretty thoughtful. I'll check it out.
-Chuck
Hey Chuck, I do understand your point of view (though I think you might have misunderstood a few of my comments a bit). I personally wouldn't much care if ⌘O defaulted to my iTunes library. I never use it anyway. I'm just trying to outline some of the reasoning (as a completely uneducated/outsider guess) for the current behavior.
Consider the other applications on your HD. Almost all of them behave like TextMate currently does. TextEdit, Photoshop, Illustrator, Script Editor, XCode, Safari, FireFox, Automator, QuickTime Player, Preview, etc... All participate in a standard behavior throughout the OS in which the open dialog defaults to the the last directory that the application currently opened a document from. It's not that changing TM would be counter productive, it's just that it would be a violation of the normal open behavior as generally implemented throughout the OS. The behavior you are describing may indeed be useful, and yes there are obvious development solutions to all the "what if's", but in reality its just a separate command, and should exist alongside of, not as a replacement to, the standard "Open" behavior. Hence, my suggestion that you use a command as an alternative.
As for:
In its current incarnation text mate expects that you're doing thing in a somewhat standard way.
[...]
Hey now, nothing non-standard about Terminal.
I'm definitely not claiming that the terminal is non-standard. I couldn't live without it. "Standard" probably wasn't the best word. Maybe should have been "consistent". I was saying that it makes sense to assume that if you're already in your working directory in terminal and you 'mate Foo.txt' to open it, then you're just as likely to 'mate Bar.txt' to open another file and open your files in a "consistent" way from file to file. There are a lot of people that maybe don't. I for one almost always 'mate' from Terminal or open files from the project drawer so my methods are quite consistent.
I think something you wrote makes a good point of conversation:
Now I hit ⌘O and I'm still seeing the completely unrelated file system directory from that other project! How can that be useful/good?
I think it's your opinion that ⌘O should be "project aware". I can't say it'd be a bad thing per-se, but it's still my opinion that TM has built in support for grouping files into projects so ⌘O should probably be project neutral. If you are working with a project anyway, why not use the drawer? (Use ⌘⌥~ to switch focus to the drawer & Enter to open the selection).
Fortunately TM is very robust in terms of customization, and I've rarely found something I totally needed that I couldn't massage into a command or snippet. Give the previously mentioned command a shot and I think you may not find much of a disadvantage to it.
- Cliff
On 16. Jun 2007, at 21:58, Chuck Esterbrook wrote:
[...] It wouldn't kill you if ⌘O put you in the directory with the README
The current behavior of ⌘O is how I prefer it to work. I use mate a lot from the terminal for all sorts of stuff, I use ⌘T for files in my project, and I use ⌘O for stuff under ~/Documents -- having different “spaces” for each of these things fits my mental model -- it also fits into how neither mate nor ⌘T affect the “Open Recent” menu (though there is an option for mate to make it so).
Anyway, I heard your first request, and there’s a good chance for a hidden option in 2.x, but I won’t change it short-term.
On 6/20/07, Allan Odgaard throw-away-1@macromates.com wrote:
On 16. Jun 2007, at 21:58, Chuck Esterbrook wrote:
[...] It wouldn't kill you if ⌘O put you in the directory with the README
The current behavior of ⌘O is how I prefer it to work. I use mate a lot from the terminal for all sorts of stuff, I use ⌘T for files in my project, and I use ⌘O for stuff under ~/Documents -- having different "spaces" for each of these things fits my mental model -- it also fits into how neither mate nor ⌘T affect the "Open Recent" menu (though there is an option for mate to make it so).
Anyway, I heard your first request, and there's a good chance for a hidden option in 2.x, but I won't change it short-term.
Thanks. Regarding ~/Documents, that could be a project. ;-)
-Chuck
On Jun 1, 2007, at 2:42 AM, Allan Odgaard wrote:
On 31. May 2007, at 19:24, Cliff Pruitt wrote:
[...] I guess that most of the time I open a file, I'm opening a sibling to the file I'm currently editing [...]
[...] If you've already got a project open (re: "which is often in a subdirectory of the project") why not use the file drawer to just click the file?
Or even better: Navigation → Go to File… (⌘T)
Yeah, for some reason I just seem to have issues with using ⌘T. Maybe it just lack of taking the time to get used to it. I mean, it does its job fine, the problem is on my end, not TM. It just doesn't seem to sit so well with the way I organize files. I've got a web- dev framework I created that structures each sub-section of the site as its own "app". Every "app" has a set of commonly named files so if I use ⌘T & filter by "app.controller" I get a whole slew of results. Honestly that's probably something I could write a bundle for since its so specific to my framework. I'm doing fine with the project drawer for now.
On Jun 1, 2007, at 10:32 AM, Ciarán Walsh wrote:
On 1 Jun 2007, at 15:18, Cliff Pruitt wrote:
very "app" has a set of commonly named files
Perhaps ⌥⌘↑ would be useful
In many cases yes it is. I use it where applicable. But in a my situation it doesn't usually apply. When I say that every app has commonly named files I mean every app has an app.controller.asp and every app has an app.config.asp. In that case ⌥⌘↑ wont work unless I'm switching between the because everything inside a single app has the same extension with a different file name and I almost never need to jump from the app.controller.asp in one app to the same file in another.
What I've often wished I could do was tell TM that for certain patterns, use more than just the extension for the ⌥⌘↑ shortcut. For example it would work perfectly for me if I could tell text mate to keep its default behavior unless the file name matched 'app.([^.])+.asp' at which time it should use match #1 instead of the file extension. (Feature request?) I don't know if that's something I can do with a bundle command or not... I suppose I could try it.
- Cliff
On 2. Jun 2007, at 17:55, Cliff Pruitt wrote:
[...] What I've often wished I could do was tell TM that for certain patterns, use more than just the extension for the ⌥⌘↑ shortcut. For example it would work perfectly for me if I could tell text mate to keep its default behavior unless the file name matched 'app.([^.])+.asp' at which time it should use match #1 instead of the file extension. (Feature request?) I don't know if that's something I can do with a bundle command or not... I suppose I could try it.
You could always overload the key sequence in a bundle (limited to text.html.asp probably) and then replicate TM’s logic (when the file does not match your desired pattern).
I am not dismissive of opening up the functionality for customizing, but would need a few examples of what people want, and how they’d prefer to specify it -- looking e.g. at the Rails file switching command, there is a lot of logic which does make it better to just replace the functionality (rather than have TM support “configuration” of the command).
On Jun 5, 2007, at 3:45 AM, Allan Odgaard wrote:
You could always overload the key sequence in a bundle (limited to text.html.asp probably) and then replicate TM’s logic (when the file does not match your desired pattern).
I am not dismissive of opening up the functionality for customizing, but [...] looking e.g. at the Rails file switching command, there is a lot of logic which does make it better to just replace the functionality (rather than have TM support “configuration” of the command).
I kind of reached the same conclusion after thinking about it more. I suppose I was sort of thinking out loud (or thinking in type) with the last email. I had kind of half/noticed while working with the Rails bundle that it seemed to behave differently, but I haven't spent enough time in that bundle to really get what's going on as far as TextMate is concerned. I'll probably look into the rails bundle & see if I can get something like that working for my stuff.
The only real benefit I can see to a configuration option is that you're not repeating the same kinds of bundles all over the place, but in practice I don't think anyone is going to have tons of special cases spanning multiple languages that don't fit the general rules. Its really probably not worth it if you can do the same thing with a bundle.
- Cliff
-
Allan Odgaard -
Chuck Esterbrook -
Ciarán Walsh -
Cliff Pruitt -
Jay Soffian