So I'm a bit late to the TextMate wonderfulness.. I've been using the 30-day trial version for the last week, and got it pretty customized to my liking. Project+, MissingDrawer, SVNMate, bundles, a few custom Templates for my C++ projects, etc. Loving it.
Today I went out and got the latest TextMate2 compile from about 2 days ago, I believe, and wow. That's a huge step backward IMO. No "Projects" that I can see, just look at a Directory (which doesn't work for me, my Directory Structure != Project structure). No support for Templates either, it seems, which I just recently figured out and _really_ love (great to just pull in a template of my base C++ class and "fillin the blanks"). Plus lots of things I customized don't see to be there anymore, or are buried in the new "tm_properties" file.
Basically, I'm trying to figure out what to do next. I was getting ready to buy TextMate1, but if this is what TextMate2 is going to look like maybe I should evaluate some other tools. Is TM1 still "alive"? Or are users urged to start using TM2? Am I just really missing something in TextMate2? I'm a C/C++ developer that also uses Arduino, CMake, Python, and other stuff, so things like CTags, project-specific environment variables, and true "Projects" are important to me.
Agreed, the lack of Projects is my biggest disappointment with TM2.
Yes, yes, I have seen all of the arguments on here about how 'real' code is organized, blah blah blah, and that's a beautiful glittery unicorn dream, but here's reality outside of hobbyists and startups:
Code organization sucks.
I work in a small shop that is mired in legacy code. Hell, it's what we specialize in.
Our main tool is in a single massive CVS directory of a few million lines of code, with 47 sub-directories that analyze and transform 37 programming languages.
At any given time, I have a half dozen client projects I'm working on. Each one affects a small subset of the above code, and has its own hg-controlled client project space.
With TM1, I had a *fantastic* workflow, that looked something like:
1) Make a client project .tmproject 2) Open up the client project space 3) As needed, and only as needed, open up the tool source for bug fixing 4) Save client project
I could easily bounce between states of projects, picking them up and setting them aside, and each project was focused on a particular task. Hell, I got to the point I was creating TM projects for especially gnarly bugs, one per bugzilla entry. *THAT* was a godsend.
Now? It's a ever-loving mess. I have one file browser open to the tool source, and spend way too much damned time bouncing around in there looking for things. Sure, I can keep them open as tabs, but that only works for a handful of items. It doesn't scale. I have another file browser open to the client project, and I have to bounce between the two constantly. I can't plop .tm_properties files willy-nilly through the system, leaving droppings everywhere. But, since I have to check out the same code base multiple times for various projects, I have to replicate those damnedable properties files everywhere locally, each and every time, just to maintain some consistency. It's an absolute mess.
TM2's file browser approach may be cleaner for many people. I get that. I see the upsides of the approach, as a developer, and as far as seeing where it could go. Trust me, I *wish* I had the ability to wave a magic wand and make this system sanely organized.
It isn't. It won't be. This is the reality in every dev shop I've ever been in, from 400k employees to 10 employees. This is the reality that I need TM2 to work well with, and it just plain doesn't.
TM1 was my secret weapon, as the lone Mac user in this place. TM2 is a massive, massive step backwards in this one respect, and it's enough of one alone that I am looking at alternatives, despite having crafted a series of bundles for our proprietary in-house language and build environment.
Please, for the love of god, point me to any approach that approximates the clean, simple, and straightforward organizational tool that was .tm_project files. Don't tell me the new way is better. It's not, in this environment. Don't tell me it has advantages. I see them.
Tell me how to replicate what was, in my opinion, possibly the best practical day to day feature of TM1. After reading this list daily for several years, I'm still not seeing that information coming down the pipe.
On Thu, Sep 20, 2012 at 9:55 AM, Randall Hand randall.hand@gmail.com wrote:
So I'm a bit late to the TextMate wonderfulness.. I've been using the 30-day trial version for the last week, and got it pretty customized to my liking. Project+, MissingDrawer, SVNMate, bundles, a few custom Templates for my C++ projects, etc. Loving it.
Today I went out and got the latest TextMate2 compile from about 2 days ago, I believe, and wow. That's a huge step backward IMO. No "Projects" that I can see, just look at a Directory (which doesn't work for me, my Directory Structure != Project structure). No support for Templates either, it seems, which I just recently figured out and _really_ love (great to just pull in a template of my base C++ class and "fillin the blanks"). Plus lots of things I customized don't see to be there anymore, or are buried in the new "tm_properties" file.
Basically, I'm trying to figure out what to do next. I was getting ready to buy TextMate1, but if this is what TextMate2 is going to look like maybe I should evaluate some other tools. Is TM1 still "alive"? Or are users urged to start using TM2? Am I just really missing something in TextMate2? I'm a C/C++ developer that also uses Arduino, CMake, Python, and other stuff, so things like CTags, project-specific environment variables, and true "Projects" are important to me.
-- Randall Hand http://www.yeraze.com
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
Agreed 100% - I keep going back to TM1 because it just works for my workflow - TM2 has been a huge disappointment. I've also been playing with Sublime 2 and feel it might have potential.
-- dv
-- View this message in context: http://textmate.1073791.n5.nabble.com/TextMate-1-vs-2-tp25768p25771.html Sent from the textmate users mailing list archive at Nabble.com.
If Chocolat ever gets the "magic clean up indenting" command, it's going to be very hard to stick with TextMate.
Walter
On Sep 20, 2012, at 2:25 PM, dvlogic wrote:
Agreed 100% - I keep going back to TM1 because it just works for my workflow
- TM2 has been a huge disappointment. I've also been playing with Sublime 2
and feel it might have potential.
-- dv
-- View this message in context: http://textmate.1073791.n5.nabble.com/TextMate-1-vs-2-tp25768p25771.html Sent from the textmate users mailing list archive at Nabble.com.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
You can make an argument that the point of the filesystem is to organize files/projects and that's how most editors work.
I've been a textmate user for a long time and I've never used "projects", that's not to say that I think it is an unused feature at all, or that some support for those features shouldn't be brought back, but I don't see it as a major feature, and i certainly don't see it as a huge disappointment.
Why not suggest a few ideas for how to bring the feature back, or make it better instead of threatening to switch to another editor.
An ongoing post is already up here: http://wiki.macromates.com/Suggestions/ProjectManagementInTextMate2
I don't think TM2 is a disappointment at all, and everyone has busted ass working on it (at least since it went open source), so maybe keep the negative to a minimal and try to be helpful rather than hurtful
- Mom
On Sep 20, 2012, at 2:32 PM, Walter Lee Davis waltd@wdstudio.com wrote:
If Chocolat ever gets the "magic clean up indenting" command, it's going to be very hard to stick with TextMate.
Walter
On Sep 20, 2012, at 2:25 PM, dvlogic wrote:
Agreed 100% - I keep going back to TM1 because it just works for my workflow
- TM2 has been a huge disappointment. I've also been playing with Sublime 2
and feel it might have potential.
-- dv
-- View this message in context: http://textmate.1073791.n5.nabble.com/TextMate-1-vs-2-tp25768p25771.html Sent from the textmate users mailing list archive at Nabble.com.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
Well, in my (admittedly limited) experience with Textmate 1, it seems textmate2 has fallen into the trap of "Going back to the drawing board" in hopes of making it better, but leaving most of the "boring" pieces behind. I know this problem well, I've done it myself before and paid the price.
More than anything, I just want to know if TM1 is still "Viable"? Is TextMate1 being actively updated and maintained? eg, if OSX 10.8.3 dropped tomorrow and broke something, would someone fix it or would that be the "TM2 release date" ?
If TextMate2 is still in the distant future and there's lots of work to be done, that's great. I just want to know that the $50 I drop on TextMate won't be pointless if the TM2 I saw today becomes the standard official release version tomorrow, and from what I see TM2 just isn't suited to my workstyle.
Travis Dunn mailto:tdunn13@gmail.com September 20, 2012 2:44 PM You can make an argument that the point of the filesystem is to organize files/projects and that's how most editors work.
I've been a textmate user for a long time and I've never used "projects", that's not to say that I think it is an unused feature at all, or that some support for those features shouldn't be brought back, but I don't see it as a major feature, and i certainly don't see it as a huge disappointment.
Why not suggest a few ideas for how to bring the feature back, or make it better instead of threatening to switch to another editor.
An ongoing post is already up here: http://wiki.macromates.com/Suggestions/ProjectManagementInTextMate2
I don't think TM2 is a disappointment at all, and everyone has busted ass working on it (at least since it went open source), so maybe keep the negative to a minimal and try to be helpful rather than hurtful
- Mom
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate Walter Lee Davis mailto:waltd@wdstudio.com September 20, 2012 1:32 PM If Chocolat ever gets the "magic clean up indenting" command, it's going to be very hard to stick with TextMate.
Walter
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate dvlogic mailto:dvlogic@gmail.com September 20, 2012 1:25 PM Agreed 100% - I keep going back to TM1 because it just works for my workflow
- TM2 has been a huge disappointment. I've also been playing with
Sublime 2 and feel it might have potential.
-- dv
-- View this message in context: http://textmate.1073791.n5.nabble.com/TextMate-1-vs-2-tp25768p25771.html Sent from the textmate users mailing list archive at Nabble.com.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate Jason McC. Smith mailto:jason@ncpod.org September 20, 2012 1:03 PM Agreed, the lack of Projects is my biggest disappointment with TM2.
Yes, yes, I have seen all of the arguments on here about how 'real' code is organized, blah blah blah, and that's a beautiful glittery unicorn dream, but here's reality outside of hobbyists and startups:
Code organization sucks.
I work in a small shop that is mired in legacy code. Hell, it's what we specialize in.
Our main tool is in a single massive CVS directory of a few million lines of code, with 47 sub-directories that analyze and transform 37 programming languages.
At any given time, I have a half dozen client projects I'm working on. Each one affects a small subset of the above code, and has its own hg-controlled client project space.
With TM1, I had a *fantastic* workflow, that looked something like:
- Make a client project .tmproject
- Open up the client project space
- As needed, and only as needed, open up the tool source for bug fixing
- Save client project
I could easily bounce between states of projects, picking them up and setting them aside, and each project was focused on a particular task. Hell, I got to the point I was creating TM projects for especially gnarly bugs, one per bugzilla entry. *THAT* was a godsend.
Now? It's a ever-loving mess. I have one file browser open to the tool source, and spend way too much damned time bouncing around in there looking for things. Sure, I can keep them open as tabs, but that only works for a handful of items. It doesn't scale. I have another file browser open to the client project, and I have to bounce between the two constantly. I can't plop .tm_properties files willy-nilly through the system, leaving droppings everywhere. But, since I have to check out the same code base multiple times for various projects, I have to replicate those damnedable properties files everywhere locally, each and every time, just to maintain some consistency. It's an absolute mess.
TM2's file browser approach may be cleaner for many people. I get that. I see the upsides of the approach, as a developer, and as far as seeing where it could go. Trust me, I *wish* I had the ability to wave a magic wand and make this system sanely organized.
It isn't. It won't be. This is the reality in every dev shop I've ever been in, from 400k employees to 10 employees. This is the reality that I need TM2 to work well with, and it just plain doesn't.
TM1 was my secret weapon, as the lone Mac user in this place. TM2 is a massive, massive step backwards in this one respect, and it's enough of one alone that I am looking at alternatives, despite having crafted a series of bundles for our proprietary in-house language and build environment.
Please, for the love of god, point me to any approach that approximates the clean, simple, and straightforward organizational tool that was .tm_project files. Don't tell me the new way is better. It's not, in this environment. Don't tell me it has advantages. I see them.
Tell me how to replicate what was, in my opinion, possibly the best practical day to day feature of TM1. After reading this list daily for several years, I'm still not seeing that information coming down the pipe.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate Randall Hand mailto:randall.hand@gmail.com September 20, 2012 11:55 AM So I'm a bit late to the TextMate wonderfulness.. I've been using the 30-day trial version for the last week, and got it pretty customized to my liking. Project+, MissingDrawer, SVNMate, bundles, a few custom Templates for my C++ projects, etc. Loving it.
Today I went out and got the latest TextMate2 compile from about 2 days ago, I believe, and wow. That's a huge step backward IMO. No "Projects" that I can see, just look at a Directory (which doesn't work for me, my Directory Structure != Project structure). No support for Templates either, it seems, which I just recently figured out and _really_ love (great to just pull in a template of my base C++ class and "fillin the blanks"). Plus lots of things I customized don't see to be there anymore, or are buried in the new "tm_properties" file.
Basically, I'm trying to figure out what to do next. I was getting ready to buy TextMate1, but if this is what TextMate2 is going to look like maybe I should evaluate some other tools. Is TM1 still "alive"? Or are users urged to start using TM2? Am I just really missing something in TextMate2? I'm a C/C++ developer that also uses Arduino, CMake, Python, and other stuff, so things like CTags, project-specific environment variables, and true "Projects" are important to me.
On Thu, Sep 20, 2012 at 12:44 PM, Travis Dunn tdunn13@gmail.com wrote:
You can make an argument that the point of the filesystem is to organize files/projects and that's how most editors work.
And one can also argue that file-level organization and task-level organization are two completely different things. One is for storage and conceptual partitioning, one is for workflow needs in the moment. They are two completely different needs, and TM1 had a beautiful solution for the second. I weep for its loss.
I've been a textmate user for a long time and I've never used "projects", that's not to say that I think it is an unused feature at all, or that some support for those features shouldn't be brought back, but I don't see it as a major feature, and i certainly don't see it as a huge disappointment.
Understood. I do, and I'm not the only one. It was such an insanely simple thing to use, and had a tremendous amount of value for creating dynamic workspaces on the fly, while allowing them to be saved for later retrieval and/or reference.
Why not suggest a few ideas for how to bring the feature back, or make it better instead of threatening to switch to another editor.
It's been tried on here, with little effect other than triggering a chorus of "you're doing it wrong"... annoying.
Perhaps this time will be different?
An ongoing post is already up here: http://wiki.macromates.com/Suggestions/ProjectManagementInTextMate2
Thanks for the pointer, I'll be adding/watching that.
I don't think TM2 is a disappointment at all,
No, not the entirety of TM2 at *all*, just the removal of what was, to me, for my needs, *the* killer feature. The rest is a fantastic bit of kit, and the reason I *haven't* bailed... the question is whether it's enough to keep me from doing so, given my environmental constraints.
And I'm not the only one.
and everyone has busted ass working on it (at least since it went open source), so maybe keep the negative to a minimal and try to be helpful rather than hurtful
I don't see how reporting that what is seen by many as an advance has, in fact, gutted the usefulness for some of us to the point of us looking elsewhere is 'hurtful'. There's nothing personal intended in it. We're bigger than that. (Franky, the reason I have more or less given up on seeing this re-appear is due to some amazingly arrogant responses I've seen on this list, along the lines that anyone who needs projects is simply not a 'serious programmer'... It's been positively eye-rolling to watch unfold.)
- Mom
Is my laundry done yet?
On Sep 20, 2012, at 2:32 PM, Walter Lee Davis waltd@wdstudio.com wrote:
If Chocolat ever gets the "magic clean up indenting" command, it's going to be very hard to stick with TextMate.
Walter
On Sep 20, 2012, at 2:25 PM, dvlogic wrote:
Agreed 100% - I keep going back to TM1 because it just works for my workflow
- TM2 has been a huge disappointment. I've also been playing with Sublime 2
and feel it might have potential.
-- dv
-- View this message in context: http://textmate.1073791.n5.nabble.com/TextMate-1-vs-2-tp25768p25771.html Sent from the textmate users mailing list archive at Nabble.com.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
I can only speak for myself, but my opinion is that if a feature existed in TextMate 1 and it doesn't in TextMate 2, you can't tell someone they are "doing it wrong" because they used the feature as intended. Maybe it wasn't priority to think through how to make it work in TM2, but it was a real feature in v1, so someone thought it was a good idea and people used it.
The real problem (as i understand it) is that the new "file browser" is actually basically a file browser and it wasn't necessarily in TM1. So to get that feature back, a little bit of thinking is needed. I'm gonna re-read your post and see if I can pull out the individual features that you used and how you used them. What we do know is that TM2 supports a .tm_properties file that has a lot of power, have you looked into all of the properties it supports, to at least bring back some of the features you were using? A good list of properties can be found here: https://gist.github.com/1478685
I don't think there's anything personal intended here by anyone, but I also think calling someone's work a "huge disappointment" is rather harsh, and will be taken personal if intended that way or not. Also, generally i just disagree with the approach of "I dont want to switch to another editor but if X isn't implemented/fixed, i'll have to", if you need to switch to something that works better for you, go for it. A single editor is never going to be everything to everyone.
Try to remember that with the project being open sourced and on github now, there are a lot more support requests coming in, so everything is probably spread a bit thin.
Finally, your laundry is done and folded. I brought you a snack pack to eat while you watch Darkwing Duck.
*bow*
On Sep 20, 2012, at 4:11 PM, Jason McC. Smith jason@ncpod.org wrote:
On Thu, Sep 20, 2012 at 12:44 PM, Travis Dunn tdunn13@gmail.com wrote:
You can make an argument that the point of the filesystem is to organize files/projects and that's how most editors work.
And one can also argue that file-level organization and task-level organization are two completely different things. One is for storage and conceptual partitioning, one is for workflow needs in the moment. They are two completely different needs, and TM1 had a beautiful solution for the second. I weep for its loss.
I've been a textmate user for a long time and I've never used "projects", that's not to say that I think it is an unused feature at all, or that some support for those features shouldn't be brought back, but I don't see it as a major feature, and i certainly don't see it as a huge disappointment.
Understood. I do, and I'm not the only one. It was such an insanely simple thing to use, and had a tremendous amount of value for creating dynamic workspaces on the fly, while allowing them to be saved for later retrieval and/or reference.
Why not suggest a few ideas for how to bring the feature back, or make it better instead of threatening to switch to another editor.
It's been tried on here, with little effect other than triggering a chorus of "you're doing it wrong"... annoying.
Perhaps this time will be different?
An ongoing post is already up here: http://wiki.macromates.com/Suggestions/ProjectManagementInTextMate2
Thanks for the pointer, I'll be adding/watching that.
I don't think TM2 is a disappointment at all,
No, not the entirety of TM2 at *all*, just the removal of what was, to me, for my needs, *the* killer feature. The rest is a fantastic bit of kit, and the reason I *haven't* bailed... the question is whether it's enough to keep me from doing so, given my environmental constraints.
And I'm not the only one.
and everyone has busted ass working on it (at least since it went open source), so maybe keep the negative to a minimal and try to be helpful rather than hurtful
I don't see how reporting that what is seen by many as an advance has, in fact, gutted the usefulness for some of us to the point of us looking elsewhere is 'hurtful'. There's nothing personal intended in it. We're bigger than that. (Franky, the reason I have more or less given up on seeing this re-appear is due to some amazingly arrogant responses I've seen on this list, along the lines that anyone who needs projects is simply not a 'serious programmer'... It's been positively eye-rolling to watch unfold.)
- Mom
Is my laundry done yet?
On Sep 20, 2012, at 2:32 PM, Walter Lee Davis waltd@wdstudio.com wrote:
If Chocolat ever gets the "magic clean up indenting" command, it's going to be very hard to stick with TextMate.
Walter
On Sep 20, 2012, at 2:25 PM, dvlogic wrote:
Agreed 100% - I keep going back to TM1 because it just works for my workflow
- TM2 has been a huge disappointment. I've also been playing with Sublime 2
and feel it might have potential.
-- dv
-- View this message in context: http://textmate.1073791.n5.nabble.com/TextMate-1-vs-2-tp25768p25771.html Sent from the textmate users mailing list archive at Nabble.com.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On Thu, Sep 20, 2012 at 2:02 PM, Travis Dunn tdunn13@gmail.com wrote:
I can only speak for myself, but my opinion is that if a feature existed in TextMate 1 and it doesn't in TextMate 2, you can't tell someone they are "doing it wrong" because they used the feature as intended. Maybe it wasn't priority to think through how to make it work in TM2, but it was a real feature in v1, so someone thought it was a good idea and people used it.
Indeed. I think it was one of the more forward-thinking ideas in TM1, at least from the user experience end of things.
The real problem (as i understand it) is that the new "file browser" is actually basically a file browser and it wasn't necessarily in TM1. So to get that feature back, a little bit of thinking is needed.
Agreed. This is not trivial to integrate with the file browser approach, and there are certain questions regarding version control integration, etc, that are made much more simple with the browser than with an ad hoc project approach.
I'm gonna re-read your post and see if I can pull out the individual features that you used and how you used them.
Thanks. I think I can distill it down to:
- A list of files that are needed for a particular task - Those files can be found on any mounted drive on the system
This isn't just a case of selecting out a subset of a particular file hierarchy, I often will have one repository mounted via NFS, another through SMB, and yet more files on my local drive, and I need to bounce between them seamlessly. I think we can all agree that saying "just point your file browser to / and use the include/exclude features" will not scale well in this situation.
I've considered a .tm_project bundle that wraps symlinks, or a file that includes a list of URLs as possibilities, but I'm unsure how those would interact with other desired features such as version control. I lean to the bundle, so it can have an internal .tm_properties file and re-use that capability.
What we do know is that TM2 supports a .tm_properties file that has a lot of power, have you looked into all of the properties it supports, to at least bring back some of the features you were using? A good list of properties can be found here: https://gist.github.com/1478685
Indeed, and if I were able to include those in the version control, it might be a nice step forward for me, but sadly, I can't due to company repository policy. I need a solution that is completely local to my drive, and yet doesn't require me to re-create it from scratch every time I checkout code. The projects allowed me to set a root directory, so I could have a pre-canned task-oriented set of files ready to do, and just aim it at a particular working space as the active tasks changed.
Don't get me wrong. The .tm_properties files are insanely powerful, and are an improvement in general, from a basic infrastructure point of view. They just don't work for what is, really, a rather common work environment constraint: no local config files for a specific developer may pollute the central code repositories.
Remember, many of us are the lone ninja moles in large corporations, surrounded by Windows, Linux, and *shudder* emacs users. We've survived the .DS_Store wars, we're reluctant to start up those battlelines again. :)
I don't think there's anything personal intended here by anyone, but I also think calling someone's work a "huge disappointment" is rather harsh, and will be taken personal if intended that way or not.
Point taken, and I apologize if anyone did take it personally. To recap: I have been using TM since... cripes. Since it came out. It's been my main tool of choice for many years. The *one thing* that makes me cringe is the loss of projects. Everything else is either already stellar, or well on its way with a clearly defined goal. Unfortunately, for me, this one thing was the killer feature in my daily workflow, the one thing that everyone I showed it to wished they had a Mac to run TM. I'm not kidding.
Also, generally i just disagree with the approach of "I dont want to switch to another editor but if X isn't implemented/fixed, i'll have to", if you need to switch to something that works better for you, go for it. A single editor is never going to be everything to everyone.
Nope, and the reason I've stuck around is that TM2 still offers me the best balance so far, but the decision has gone from an absolute no-brainer to stick with TM, to an actual decision to be made. That is unfortunate.
Try to remember that with the project being open sourced and on github now, there are a lot more support requests coming in, so everything is probably spread a bit thin.
I can imagine. On the other hand, I do hope there are more hands to assist as well. (Cue 'and why aren't you helping, Mr. Whinypants?')
Finally, your laundry is done and folded. I brought you a snack pack to eat while you watch Darkwing Duck.
*bow*
Thanks Mom, you're the best!
On Sep 20, 2012, at 4:11 PM, Jason McC. Smith jason@ncpod.org wrote:
On Thu, Sep 20, 2012 at 12:44 PM, Travis Dunn tdunn13@gmail.com wrote:
You can make an argument that the point of the filesystem is to organize files/projects and that's how most editors work.
And one can also argue that file-level organization and task-level organization are two completely different things. One is for storage and conceptual partitioning, one is for workflow needs in the moment. They are two completely different needs, and TM1 had a beautiful solution for the second. I weep for its loss.
I've been a textmate user for a long time and I've never used "projects", that's not to say that I think it is an unused feature at all, or that some support for those features shouldn't be brought back, but I don't see it as a major feature, and i certainly don't see it as a huge disappointment.
Understood. I do, and I'm not the only one. It was such an insanely simple thing to use, and had a tremendous amount of value for creating dynamic workspaces on the fly, while allowing them to be saved for later retrieval and/or reference.
Why not suggest a few ideas for how to bring the feature back, or make it better instead of threatening to switch to another editor.
It's been tried on here, with little effect other than triggering a chorus of "you're doing it wrong"... annoying.
Perhaps this time will be different?
An ongoing post is already up here: http://wiki.macromates.com/Suggestions/ProjectManagementInTextMate2
Thanks for the pointer, I'll be adding/watching that.
I don't think TM2 is a disappointment at all,
No, not the entirety of TM2 at *all*, just the removal of what was, to me, for my needs, *the* killer feature. The rest is a fantastic bit of kit, and the reason I *haven't* bailed... the question is whether it's enough to keep me from doing so, given my environmental constraints.
And I'm not the only one.
and everyone has busted ass working on it (at least since it went open source), so maybe keep the negative to a minimal and try to be helpful rather than hurtful
I don't see how reporting that what is seen by many as an advance has, in fact, gutted the usefulness for some of us to the point of us looking elsewhere is 'hurtful'. There's nothing personal intended in it. We're bigger than that. (Franky, the reason I have more or less given up on seeing this re-appear is due to some amazingly arrogant responses I've seen on this list, along the lines that anyone who needs projects is simply not a 'serious programmer'... It's been positively eye-rolling to watch unfold.)
- Mom
Is my laundry done yet?
On Sep 20, 2012, at 2:32 PM, Walter Lee Davis waltd@wdstudio.com wrote:
If Chocolat ever gets the "magic clean up indenting" command, it's going to be very hard to stick with TextMate.
Walter
On Sep 20, 2012, at 2:25 PM, dvlogic wrote:
Agreed 100% - I keep going back to TM1 because it just works for my workflow
- TM2 has been a huge disappointment. I've also been playing with Sublime 2
and feel it might have potential.
-- dv
-- View this message in context: http://textmate.1073791.n5.nabble.com/TextMate-1-vs-2-tp25768p25771.html Sent from the textmate users mailing list archive at Nabble.com.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On Sep 20, 2012, at 11:21 PM, "Jason McC. Smith" jason@ncpod.org wrote:
[…] The .tm_properties files are insanely powerful, and are an improvement in general, from a basic infrastructure point of view. They just don't work for what is, really, a rather common work environment constraint: no local config files for a specific developer may pollute the central code repositories.
Although a .tm_property file is meant to go to the root of the project, you can still do project specific settings in ~/.tm_properties.
For example the default properties (inside TextMate.app) has the following:
[ "/usr/include/**" ] tabSize = 8
[ "/System/Library/Frameworks/**/Headers/**" ] encoding = "MACROMAN"
Also see http://lists.macromates.com/textmate/2012-September/035480.html where I mention how you can set projectDirectory once and have it apply to multiple directories.
[…] Point taken, and I apologize if anyone did take it personally
Mostly it just means the feedback will be ignored (from those who can actually help improve the situation).
On Thu, Sep 20, 2012 at 2:44 PM, Allan Odgaard mailinglist@textmate.org wrote:
On Sep 20, 2012, at 11:21 PM, "Jason McC. Smith" jason@ncpod.org wrote:
[…] The .tm_properties files are insanely powerful, and are an improvement in general, from a basic infrastructure point of view. They just don't work for what is, really, a rather common work environment constraint: no local config files for a specific developer may pollute the central code repositories.
Although a .tm_property file is meant to go to the root of the project, you can still do project specific settings in ~/.tm_properties.
For example the default properties (inside TextMate.app) has the following:
[ "/usr/include/**" ] tabSize = 8 [ "/System/Library/Frameworks/**/Headers/**" ] encoding = "MACROMAN"Also see http://lists.macromates.com/textmate/2012-September/035480.html where I mention how you can set projectDirectory once and have it apply to multiple directories.
Thanks, I'll take a look at the second bit. I'm not sure how the first bit solves the quick-and-easy aspect of replacing projects though. Ideas?
Although. Hmm. Let me fiddle.
[…] Point taken, and I apologize if anyone did take it personally
Mostly it just means the feedback will be ignored (from those who can actually help improve the situation).
Fair enough. Consider it a personal itch that is in serious need of scratching coupled with annoyance at being told it's Morgellons Syndrome.
Opening up the code on github was a stroke of benevolent genius. Thanks. :)
On Sep 20, 2012, at 4:21 PM, Jason McC. Smith wrote:
The .tm_properties files are insanely powerful, and are an improvement in general, from a basic infrastructure point of view. They just don't work for what is, really, a rather common work environment constraint: no local config files for a specific developer may pollute the central code repositories.
I may be missing something here, but can't you simply add .tm_properties to the appropriate .gitignore/.hgignore/etc. file(s)? I do this rather frequently in cases where I am working with a group in which I'm the only TextMate user.
-- Phil
I can, and do, but there are a couple of added wrinkles:
- I want to have multiple concurrent slices through the same checked out codebase
If I'm working on multiple bugs at the same time, each one may involve up to a dozen files, easily (sometimes double that... I never claimed the code was sane, I came onto the project late). A single .tm_properties at the root to provide a subset would need to be tweaked constantly for the task at hand, quickly eliminating any productivity gains from the effort. There are, at last check just now, 17810 files in the default check out of the main codebase, with 169 folders at the top level alone. That's a lot to work with to separate the interesting bits from the chaff.
- I want to have a list of files associated with a task that I can retarget at different checked out versions
Useful for regression testing, I want to be able to quickly ascertain the state of a task across different client projects, each of which has a working copy of the main code base. (Look, I *said* it isn't well organized... unfortunately, I can't change that without a complete overhaul of our build environment, which I'm working on gaining support for.) I may be able to replicate this with Allan's hint above, but it requires me to set things up each time.
.tmproj files solved both of these at one shot, rather effortlessly.
I might be able to fake some of the above with a symlink to a suite of .tm_properties files, one for each slice, and then use Allan's hint for the retargeting. It just won't be as slick and quick, nor will it provide the ease of setup that I had before. It may be better to set up a series of directories of symlinks into the code bases, and Allan's retargeting hint, but I'm unclear on how that will interact with the version control bundles.
On Thu, Sep 20, 2012 at 3:27 PM, Phil Schumm pschumm@uchicago.edu wrote:
On Sep 20, 2012, at 4:21 PM, Jason McC. Smith wrote:
The .tm_properties files are insanely powerful, and are an improvement in general, from a basic infrastructure point of view. They just don't work for what is, really, a rather common work environment constraint: no local config files for a specific developer may pollute the central code repositories.
I may be missing something here, but can't you simply add .tm_properties to the appropriate .gitignore/.hgignore/etc. file(s)? I do this rather frequently in cases where I am working with a group in which I'm the only TextMate user.
-- Phil
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On Sep 20, 2012, at 6:55 PM, Randall Hand randall.hand@gmail.com wrote:
[…] Is TM1 still "alive"? Or are users urged to start using TM2? Am I just really missing something in TextMate2?
TM 1.x is not being actively maintained, but it still works great for a lot of people.
TM 2.0 is alpha, and I don’t yet link directly to it from macromates.com because I am aware that there are still some things to iron out before I want to actively steer people toward it — particularly the issue of projects and creating new files is something new users often struggle with.
That said, despite the rather negative outbursts in this thread, a lot of people find most aspects of 2.0 vastly superior to 1.x, but the “learning curve” is a little steep, as the UX hasn’t seen any polish and GUI is still lacking for some aspects.
[…] project-specific environment variables, and true "Projects" are important to me.
The first part has IMO been much improved in 2.0 because they are now just text files which can be version controlled, see e.g. http://blog.macromates.com/2011/git-style-configuration/ (although several of the settings mentioned has since received UI).
For the second one, I assume you mean grouping files which are spread out over your disk (and not via symbolic links); this is probably not something I am going to add, but part of the decision for making 2.0 open source was to allow users to add the things I don’t care for.
Is there any comprehensive documentation on what goes in this tm_properties file? I see lots of random snippets scattered around the mailing list, but I haven't come across a full list.
Sent from my iPad
On Sep 20, 2012, at 4:26 PM, Allan Odgaard mailinglist@textmate.org wrote:
On Sep 20, 2012, at 6:55 PM, Randall Hand randall.hand@gmail.com wrote:
[…] Is TM1 still "alive"? Or are users urged to start using TM2? Am I just really missing something in TextMate2?
TM 1.x is not being actively maintained, but it still works great for a lot of people.
TM 2.0 is alpha, and I don’t yet link directly to it from macromates.com because I am aware that there are still some things to iron out before I want to actively steer people toward it — particularly the issue of projects and creating new files is something new users often struggle with.
That said, despite the rather negative outbursts in this thread, a lot of people find most aspects of 2.0 vastly superior to 1.x, but the “learning curve” is a little steep, as the UX hasn’t seen any polish and GUI is still lacking for some aspects.
[…] project-specific environment variables, and true "Projects" are important to me.
The first part has IMO been much improved in 2.0 because they are now just text files which can be version controlled, see e.g. http://blog.macromates.com/2011/git-style-configuration/ (although several of the settings mentioned has since received UI).
For the second one, I assume you mean grouping files which are spread out over your disk (and not via symbolic links); this is probably not something I am going to add, but part of the decision for making 2.0 open source was to allow users to add the things I don’t care for.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
The link Travis posted above is perhaps the best listing I've seen yet.
What I'm more curious about, however, is a comprehensive listing of available scopes, action triggers, etc. I realize it's a dynamically built environment based on the current bundles, but is there some way to get a report from within TM2?
On Thu, Sep 20, 2012 at 4:47 PM, Randall Hand randall.hand@gmail.com wrote:
Is there any comprehensive documentation on what goes in this tm_properties file? I see lots of random snippets scattered around the mailing list, but I haven't come across a full list.
Sent from my iPad
On Sep 20, 2012, at 4:26 PM, Allan Odgaard mailinglist@textmate.org wrote:
On Sep 20, 2012, at 6:55 PM, Randall Hand randall.hand@gmail.com wrote:
[…] Is TM1 still "alive"? Or are users urged to start using TM2? Am I just really missing something in TextMate2?
TM 1.x is not being actively maintained, but it still works great for a lot of people.
TM 2.0 is alpha, and I don’t yet link directly to it from macromates.com because I am aware that there are still some things to iron out before I want to actively steer people toward it — particularly the issue of projects and creating new files is something new users often struggle with.
That said, despite the rather negative outbursts in this thread, a lot of people find most aspects of 2.0 vastly superior to 1.x, but the “learning curve” is a little steep, as the UX hasn’t seen any polish and GUI is still lacking for some aspects.
[…] project-specific environment variables, and true "Projects" are important to me.
The first part has IMO been much improved in 2.0 because they are now just text files which can be version controlled, see e.g. http://blog.macromates.com/2011/git-style-configuration/ (although several of the settings mentioned has since received UI).
For the second one, I assume you mean grouping files which are spread out over your disk (and not via symbolic links); this is probably not something I am going to add, but part of the decision for making 2.0 open source was to allow users to add the things I don’t care for.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
Ok. Tomorrow morning ill see how close I can get to rebuilding my tm1 project this way. I this is the future, I wanna prepare for it early. Who knows, maybe ill save myself $50 :)
Is there anything akin to tm1's Templates?
Sent from my iPad
On Sep 20, 2012, at 6:51 PM, "Jason McC. Smith" jason@ncpod.org wrote:
The link Travis posted above is perhaps the best listing I've seen yet.
What I'm more curious about, however, is a comprehensive listing of available scopes, action triggers, etc. I realize it's a dynamically built environment based on the current bundles, but is there some way to get a report from within TM2?
On Thu, Sep 20, 2012 at 4:47 PM, Randall Hand randall.hand@gmail.com wrote:
Is there any comprehensive documentation on what goes in this tm_properties file? I see lots of random snippets scattered around the mailing list, but I haven't come across a full list.
Sent from my iPad
On Sep 20, 2012, at 4:26 PM, Allan Odgaard mailinglist@textmate.org wrote:
On Sep 20, 2012, at 6:55 PM, Randall Hand randall.hand@gmail.com wrote:
[…] Is TM1 still "alive"? Or are users urged to start using TM2? Am I just really missing something in TextMate2?
TM 1.x is not being actively maintained, but it still works great for a lot of people.
TM 2.0 is alpha, and I don’t yet link directly to it from macromates.com because I am aware that there are still some things to iron out before I want to actively steer people toward it — particularly the issue of projects and creating new files is something new users often struggle with.
That said, despite the rather negative outbursts in this thread, a lot of people find most aspects of 2.0 vastly superior to 1.x, but the “learning curve” is a little steep, as the UX hasn’t seen any polish and GUI is still lacking for some aspects.
[…] project-specific environment variables, and true "Projects" are important to me.
The first part has IMO been much improved in 2.0 because they are now just text files which can be version controlled, see e.g. http://blog.macromates.com/2011/git-style-configuration/ (although several of the settings mentioned has since received UI).
For the second one, I assume you mean grouping files which are spread out over your disk (and not via symbolic links); this is probably not something I am going to add, but part of the decision for making 2.0 open source was to allow users to add the things I don’t care for.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
I'm late to the party.
How did your attempts a replicating TextMate 1 project functionality in TextMate 2 go? Any tips or pointers learned?
Bob
-- View this message in context: http://textmate.1073791.n5.nabble.com/TextMate-1-vs-2-tp25768p26164.html Sent from the textmate users mailing list archive at Nabble.com.
ok, taking the ball :)
Basically to make a project you throw a file named ".tm_properties" the the project root with this content: *projectDirectory = "$CWD"*.
There you can also override settings specifically for your project (take that of textmatehttps://github.com/textmate/textmate/blob/master/.tm_propertiesas a complex example). What you get is that the project equals to a fs folder, you can tweak visibility and behavior but it won't accept "sparse" files and folders as a project. If you miss the clickable project files you should explore the favorites system.
PS. a recent commit made tm2 consider a project every folder explicitly opened via *mate* or UI (without the need for a .tm_properties)
Hope it helps :)
Elia
☁ @elia http://twitter.com/elia ✎ elia@schito.me ☎ (+39) 348/9051393
On Wed, Feb 6, 2013 at 12:49 AM, Jerry lanceboyle@qwest.net wrote:
Wow. The silence is deafening. :-( Jerry
On Feb 2, 2013, at 7:35 AM, bobrocke wrote:
I'm late to the party.
How did your attempts a replicating TextMate 1 project functionality in TextMate 2 go? Any tips or pointers learned?
Bob
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
One of the nice features of TextMate 1 projects was their ability to gather folders from anywhere in the file system. TextMate 2 projects mirror the file system. Is there some way to mimic the v1 projects behavior in v2, or must we just move on? Maybe switch tools if it's a "must have" capability?
Bob
-- View this message in context: http://textmate.1073791.n5.nabble.com/TextMate-1-vs-2-tp25768p26188.html Sent from the textmate users mailing list archive at Nabble.com.
On Feb 6, 2013, at 6:55 AM, bobrocke wrote:
One of the nice features of TextMate 1 projects was their ability to gather folders from anywhere in the file system. TextMate 2 projects mirror the file system. Is there some way to mimic the v1 projects behavior in v2, or must we just move on? Maybe switch tools if it's a "must have" capability?
I haven't followed this issue very carefully; I believe the last word (from Allan) was that while he was not ruling out new features in the future which might replace some of what you could do with TM 1 projects (e.g., additional virtual data sources in the file browser), TM 2 definitely represents a change in design philosophy from TM 1 RE how projects are conceptualized. I know how annoying it can be when someone else tells you that your own use case is not legitimate, and I have no wish to do that. All I will say, however, is that conceptualizing projects in terms of portable directories with their own settings files is a huge help when working with Mercurial, Git, etc., and provides a lot of capabilities that did not exist in TM 1. Also, strategies such as reorganizing files/directories and using sub-repositories combined with appropriate exclusions in your .tm_properties file(s) allow you to mimic some of what you could do with TM 1 projects.
That said, it may be that if you can't live without TM 1 projects, continuing to use TM 1 or using another editor/tool is your only option at the moment. Others can correct me if I am mistaken.
-- Phil
Basically Allan has stated that he will not add similar functionality himself (it has been discussed thoroughly :)). .tm_properties files really do not come close to emulating the project functionality of TM1, but they do offer tons of additional functionality so it's somewhat of a trade-off.
TM2 is now open-source so you could attempt to add some of that functionality back in, or simply switch to something with the features you need. Turns out there has been an explosion of pretty decent IDEs / text editors recently.
On 2013-02-06 06:54, Phil Schumm wrote:
On Feb 6, 2013, at 6:55 AM, bobrocke wrote:
One of the nice features of TextMate 1 projects was their ability to gather folders from anywhere in the file system. TextMate 2 projects mirror the file system. Is there some way to mimic the v1 projects behavior in v2, or must we just move on? Maybe switch tools if it's a "must have" capability?
I haven't followed this issue very carefully; I believe the last word (from Allan) was that while he was not ruling out new features in the future which might replace some of what you could do with TM 1 projects (e.g., additional virtual data sources in the file browser), TM 2 definitely represents a change in design philosophy from TM 1 RE how projects are conceptualized. I know how annoying it can be when someone else tells you that your own use case is not legitimate, and I have no wish to do that. All I will say, however, is that conceptualizing projects in terms of portable directories with their own settings files is a huge help when working with Mercurial, Git, etc., and provides a lot of capabilities that did not exist in TM 1. Also, strategies such as reorganizing files/directories and using sub-repositories combined with appropriate exclusions in your .tm_properties file(s) allow you to mimic some of what you could do with TM 1 projects.
That said, it may be that if you can't live without TM 1 projects, continuing to use TM 1 or using another editor/tool is your only option at the moment. Others can correct me if I am mistaken.
-- Phil
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
No, Allan will not be going back to TM1's project functionality. He also does not appear interested in allowing aliases or symlinks to be traversed like folders as part of the File Browser, either.
So the opportunities to get a Project Manager working in the files pane will either be coded by someone else, or not get done.
I'm not a programmer, so it won't be me. But I can see good examples of the functionality needed in both BBEdit and Sublime text, so there are models for others to emulate.
Bob
-- View this message in context: http://textmate.1073791.n5.nabble.com/TextMate-1-vs-2-tp25768p26191.html Sent from the textmate users mailing list archive at Nabble.com.
On 2012-09-20 23:26, Allan Odgaard wrote:
For the second one, I assume you mean grouping files which are spread out over your disk (and not via symbolic links); this is probably not something I am going to add, but part of the decision for making 2.0 open source was to allow users to add the things I don’t care for.
I never really used this feature in TM1, but in TM1 I could save a project this even though the project had a single folder on disk. Is that possible in TM2?
On Sep 21, 2012, at 2:01 PM, Jacob Carlborg doob@me.com wrote:
[…] in TM1 I could save a project this even though the project had a single folder on disk. Is that possible in TM2?
If your project is a single folder on disk, then it is a perfect match for how 2.0 considers projects. The issue some people have is that their projects are not defined by how the files are organized in the file system.
On 2012-09-21 16:56, Allan Odgaard wrote:
On Sep 21, 2012, at 2:01 PM, Jacob Carlborg doob@me.com wrote:
[…] in TM1 I could save a project this even though the project had a single folder on disk. Is that possible in TM2?
If your project is a single folder on disk, then it is a perfect match for how 2.0 considers projects. The issue some people have is that their projects are not defined by how the files are organized in the file system.
But if I want to create a project file on the desktop, like a shortcut, as I could with TM1, is that possible?
On Sep 21, 2012, at 8:28 PM, Jacob Carlborg doob@me.com wrote:
[…] if I want to create a project file on the desktop, like a shortcut, as I could with TM1, is that possible?
What I recommend is that you right-click the project folder in TextMate and select “Add to Favorites”.
You can open favorites from ⇧⌘T which has abbreviation filtering like ⌘T. In practice favorites are stored (as symbolic links) in ~/Library/Application Support/TextMate/Favorites.
If you prefer the desktop icon, it is possible to create a symbolic link under ~/Desktop that points to your project folder and then drag this link to TextMate. Unfortunately I am not aware of any way to set TextMate as the default application for “opening” the link (even when giving it a package extension).
On 2012-09-21 20:54, Allan Odgaard wrote:
On Sep 21, 2012, at 8:28 PM, Jacob Carlborg doob@me.com wrote:
[…] if I want to create a project file on the desktop, like a shortcut, as I could with TM1, is that possible?
What I recommend is that you right-click the project folder in TextMate and select “Add to Favorites”.
You can open favorites from ⇧⌘T which has abbreviation filtering like ⌘T. In practice favorites are stored (as symbolic links) in ~/Library/Application Support/TextMate/Favorites.
If you prefer the desktop icon, it is possible to create a symbolic link under ~/Desktop that points to your project folder and then drag this link to TextMate. Unfortunately I am not aware of any way to set TextMate as the default application for “opening” the link (even when giving it a package extension).
Ok, I see. Thanks.
-
Allan Odgaard -
bmf -
bobrocke -
dvlogic -
Elia Schito -
George McGinley Smith -
Jacob Carlborg -
Jason McC. Smith -
Jerry -
Phil Schumm -
Randall Hand -
Travis Dunn -
Walter Lee Davis