On Thu, Sep 20, 2012 at 2:02 PM, Travis Dunn <tdunn13(a)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
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
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.
Thanks Mom, you're the best!
On Sep 20, 2012, at 4:11 PM, Jason McC. Smith <jason(a)ncpod.org> wrote:
On Thu, Sep 20, 2012 at 12:44 PM, Travis Dunn
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
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?
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
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.)
Is my laundry done yet?
On Sep 20, 2012, at 2:32 PM, Walter Lee Davis <waltd(a)wdstudio.com> wrote:
If Chocolat ever gets the "magic clean up
indenting" command, it's going to be very hard to stick with TextMate.
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:
> Sent from the textmate users mailing list archive at Nabble.com
> textmate mailing list
textmate mailing list
textmate mailing list
textmate mailing list
textmate mailing list