According to the manual: Closing Tabs
A common problem is being left with too many open tabs. In an attempt to counter that, TextMate will automatically close tabs that hasn’t been used in a while, when the tab bar overflows.
Is there any way of disabling this behaviour via a .tm_properties or defaults command?
Ed
On 24 May 2014, at 1:07, Ed Wong wrote:
According to the manual […] TextMate will automatically close tabs that hasn’t been used in a while […]
Is there any way of disabling this behaviour via a .tm_properties or defaults command?
You can disable it for specific tabs by right-clicking and selecting “sticky”. It only closes tabs when the tab bar overflows, so it doesn’t seem that useful to have TextMate build up an overflow menu of dozens of (non-visible) files, as you can already see a list of what you recently worked with via Go to File… (⌘T).
Thanks Allan. I was aware of the “sticky” feature. It’s more that I need all files I open to stay around since it’s how I’ve always kept track of which files I’ve edited during development that I’ll need to move to production when the feature/bug is done. Even if I sticky some, other may be closed when it overflows.
Then it’s really easy to Shift-Ctrl-O to open the terminal at the path of the file to ssh copy the file to the production servers.
I’ll look into seeing if ⌘T will suffice but a default to turn it off would be great.
Ed
From: Allan Odgaard mailinglist@textmate.org Reply: TextMate users textmate@lists.macromates.com Date: May 26, 2014 at 2:45:22 AM To: TextMate users textmate@lists.macromates.com Subject: [TxMt] Re: Textmate 2: Disable auto closing of tabs
On 24 May 2014, at 1:07, Ed Wong wrote:
According to the manual […] TextMate will automatically close tabs that hasn’t been used in a while […]
Is there any way of disabling this behaviour via a .tm_properties or defaults command?
You can disable it for specific tabs by right-clicking and selecting “sticky”. It only closes tabs when the tab bar overflows, so it doesn’t seem that useful to have TextMate build up an overflow menu of dozens of (non-visible) files, as you can already see a list of what you recently worked with via Go to File… (⌘T).
_______________________________________________ textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On Mon, May 26, 2014 at 3:55 PM, Ed Wong scampy@me.com wrote:
it’s how I’ve always kept track of which files I’ve edited during development that I’ll need to move to production when the feature/bug is done.
Probably not the place for this, but you really should be using a version control system for this. Git commit,and git push locally, then git pull on the server and your changes are there. Even if you don't have access to a git/svn/etc server and it's a private project (so you can't use github) you can still use git locally to track your development.
Agreed; I thought of saying this too. Nevertheless I also agree that a radical intrusion of this sort by TextMate into the user's world should be a preference. It will be great for some users and anathema to others, or useful sometimes but not at other times. A checkbox solves the whole issue. m.
On May 27, 2014, at 6:30 AM, George McGinley Smith george@gsgd.co.uk wrote:
On Mon, May 26, 2014 at 3:55 PM, Ed Wong scampy@me.com wrote: it’s how I’ve always kept track of which files I’ve edited during development that I’ll need to move to production when the feature/bug is done.
Probably not the place for this, but you really should be using a version control system for this. Git commit,and git push locally, then git pull on the server and your changes are there. Even if you don't have access to a git/svn/etc server and it's a private project (so you can't use github) you can still use git locally to track your development.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
-- matt neuburg, phd = http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 7! http://shop.oreilly.com/product/0636920031017.do iOS 7 Fundamentals! http://shop.oreilly.com/product/0636920032465.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
From: Matt Neuburg matt@tidbits.com Agreed; I thought of saying this too. Nevertheless I also agree that a radical intrusion of this sort by TextMate into the user's world should be a preference. It will be great for some users and anathema to others, or useful sometimes but not at other times. A checkbox solves the whole issue. m.
Imagine my surprise when tabs started disappearing before I knew about this feature. I hope my neighbours weren’t within earshot. :-)
Ed Wong
On Mon, May 26, 2014 at 3:55 PM, Ed Wong scampy@me.com wrote: it’s how I’ve always kept track of which files I’ve edited during development that I’ll need to move to production when the feature/bug is done.
Probably not the place for this, but you really should be using a version control system for this. Git commit,and git push locally, then git pull on the server and your changes are there. Even if you don't have access to a git/svn/etc server and it's a private project (so you can't use github) you can still use git locally to track your development.
Thanks for the tip George. I do use Git on occasion, mostly when the project is a team effort or when I use Xcode and when Git is available on the production servers.
In other cases, particularly with legacy servers. Git or any other code repository is not an option unfortunately.
Not using Git locally is mostly out of habits that I’ve developed over the past 35 years. (I’m not really that old but started coding when I was 13… ok I’m old).
Plus I’ve had some bad experiences with damaged or lost files due to Git commands gone wild, merges, reset, revert etc. probably due to newbie misunderstanding on what the command actually does on my part.
Maybe I’ll fully convert to Git if I can’t keep track of files my usual way.
Ed Wong
Well, yes, it's off-topic here, but nonetheless...
Ed Wong wrote (Tue, 27 May 2014 11:23:06 -0400):
it’s how I’ve always kept track of which files I’ve edited during development that I’ll need to move to production when the feature/bug is done. (...) Thanks for the tip George. I do use Git on occasion, mostly when the project is a team effort or when I use Xcode and when Git is available on the production servers.
In other cases, particularly with legacy servers. Git or any other code repository is not an option unfortunately.
Not using Git locally is mostly out of habits that I’ve developed over the past 35 years.
If you don't want to or can't use Git/Subversion etc (although I agree that this is the best solution), why don't you just use an FTP client that is capable of syncing when you move the files to production?
You can tell the FTP client (e.g. YummyFTP, Transmit or as far as I know even the free Cyberduck) only to move the files that are newer than their counterparts on the server, or that have a different file size.
That way, you don't even have to keep track manually.
Kind regards, Tobias Jung
From: Tobias Jung newsgr@tobiasjung.net
If you don't want to or can't use Git/Subversion etc (although I agree that this is the best solution), why don't you just use an FTP client that is capable of syncing when you move the files to production?
You can tell the FTP client (e.g. YummyFTP, Transmit or as far as I know even the free Cyberduck) only to move the files that are newer than their counterparts on the server, or that have a different file size.
That way, you don't even have to keep track manually.
For a single feature or bugs that are worked on sequentially this would work well.
Unfortunately, I often have more than 1 issue on the go (average is probably 5, i.e. one is in alpha, another in beta, another one is on hold etc.) with the same code base. This method would still require me to keep track somehow of which files belong to which issue.
Also my project code bases are often large, in the thousands of files (we’re talking big legacy stuff). Doing any sort of comparison over the full project would take an extraordinary amount of time, I’d think. I’ve really only used Transmit and Cyberduck for a few clients who’s server only allows FTP so I’m not sure how quick these programs are with that sort of stuff - mostly I go command line FTP.
I much prefer scp. I have many scripts created that I use to upload with scp so I’d like to continue with them.
Thanks for the suggestion though. If I’ve missed on how I can work on multiple issues with FTP please let me know.
Ed
Unfortunately, I often have more than 1 issue on the go
Also my project code bases are often large, in the thousands of files
These are both really convincing arguments to be using git :)
I dont know how anyone can even think of using ftp or scp in 2014. No offence but its horribly archaic
From: Carpii UK carpii.uk@gmail.com
I dont know how anyone can even think of using ftp or scp in 2014. No offence but its horribly archaic
Yeah, no arguments there, lol.
Ed
From: Tobias Jung newsgr@tobiasjung.net
Carpii UK wrote (Tue, 27 May 2014 21:21:21 +0100):
I dont know how anyone can even think of using ftp or scp in 2014.
Well obviously you're in an environment where you're not forced to use it. I seriously envy you...
Back in 1994-95, I wrote one of the first graphical FTP clients for a suite of Internet tools called “Columbus" for Windows 95 - I know, shoot me now.
Since then I’ve had a love/hate relationship with any sort of file transfer tool including code repositories like svn and git. I’ve seen files get messed up so many times I now try to KISS (keep it simple stupid) - hence I use discrete programs that perform one task very well and scp is my tool of choice for file transfers and it’s ubiquitous on *nix boxes.
Ed Wong
-
Allan Odgaard -
Carpii UK -
Ed Wong -
George McGinley Smith -
Matt Neuburg -
Tobias Jung