Why no TextMate for Linux?

[thunk]

I spent some happy development time in "VisualAge" for Smalltalk +
Java and I sure do long for better support than "just an editor".
Seems like Java fit with that IDE amazingly well. So many great
features, and that was 14 years ago now!

So, does anybody know why there is no version of TextMate for Linux?

Seems like they should have a "little brother" version for the rest
of the rest of us?

Thunk

 

[andrew mcelroy]

I spent some happy development time in "VisualAge" for Smalltalk +
Java and I sure do long for better support than "just an editor".
Seems like Java fit with that IDE amazingly well. =A0So many great
features, and that was 14 years ago now!

So, does anybody know why there is no version of TextMate for Linux?

There is, its called redcar and it is built entirely in ruby.
The problem is that i needs more development.
You can get the code on github.

Andrew

 

[andrew mcelroy]

There is, its called redcar and it is built entirely in ruby.
The problem is that it needs more development.
You can get the code on github.

Andrew

Keep in mind that Textmate is not free software.

Andrew

 

[David Masover]

So, does anybody know why there is no version of TextMate for Linux?

Ask the TextMate author. In fact, it's in the FAQ:

http://wiki.macromates.com/Main/FAQ

Keep in mind that TextMate is proprietary, and as far as I know, is not
written in Ruby, so your question is a bit like asking why there's no version
of Photoshop for Linux -- kind of offtopic for this list, and the answer is
that the developer didn't port it.

A better question might be why so much of the Ruby community has embraced a
proprietary editor which is only available for a proprietary OS.

 

[Paul Harrington]

A better question might be why so much of the Ruby community has
embraced a
proprietary editor which is only available for a proprietary OS.

Probably because its very good software on a very good OS? Using
proprietary technology actually does not stop the progress of open
source.

(That being said, I code with Vim in Linux, so...)

 

[Robert Dober]

Probably because its very good software on a very good OS? Using
proprietary technology actually does not stop the progress of open
source.

Because it is derived (completely legally) from one of the soundest
and best open source projects there have ever been, openBSD. I feel
that David's concern is very reasonable in a world in which Apple and
Google are about to rival for domination. I am using gmail, r ight and
I am not criticizing anyone who uses MacOS and Textmate. However
wondering why seems legitimate.
I also feel that I can do much more with gvim than Textmate will ever
be able to do, but I am aware that much, much setup work is needed to
get there. (Probably the same is true for emacs). Textmate is
incredibly powerful out of the starting blocks, but vim is almost like
emacs an OS.
Ruby integration into VIM is very basic but powerful enough to get us
anywhere .
Because after all this ML is about Ruby and not editors (well at least
when I checked back last time)

cheers
R

(That being said, I code with Vim in Linux, so...)

--=20
Learning without thought is labor lost; thought without learning is perilou=
s.=94
--- Confucius

 

[David Masover]

Using
proprietary technology actually does not stop the progress of open
source.

That much is true, most of the time.

There are notable exceptions -- for instance, the fact that people are
starting to incorporate textmate URLs into HTML stacktraces and such, so that
you can just click on something and have it pop up in TextMate, but those
aren't portable at all. Far better would be to come up with some sort of
standard "Go to this line of this file in a text editor" URL scheme that the
open source community could adopt also.

But that's a ridiculously trivial, almost contrived example. Most of the time,
using proprietary technology doesn't cause problems for open source -- so long
as the open source project remains independent of said proprietary technology.

I'm much more interested in it on a personal level. Switching text editors at
this point might be, for most of us, far trickier than switching OSes, and
could be almost as bad as switching keyboard layouts. (Dvorak, anyone?) By
picking a proprietary technology, you're doing several things that I can't
really see being worth the risk:



* You're locked-in to a single provider -- in this case, a single _person_.
- If Allan Odgaard doesn't want to implement a feature you want, you're
SOL.
- If Allan Odgaard can't fix a bug that's annoying you, you're also SOL.
- if Allan Odgaard wants money for a new car, you might find the next
version of TextMate costs significantly more.

* You're tied to an OS which is notorious for breaking backwards-
compatibility.
- The next version of OS X is as likely as not to break the current version
of TextMate. It's entirely up to Allan whether there will be a fix, and how
much such a fix would cost -- maybe it's only available in a new version of
TextMate.
- Once you do upgrade, the new version of TextMate is as likely as not to
refuse to work on old versions of OS X, so you'd better upgrade all your boxes
at once.
- If you don't like the new OS X, for whatever reason, some new version of
TextMate might force you to upgrade anyway.
- Switching OSes -- to Linux, to Windows, to Plan9, to whatever -- is out
of the question for you.

* You're a programmer, yet you can't program your own programming tools.
- I don't care how extensible it is, you don't have the source.
- Look at the tricks tools like Diakonos can do. Can TextMate do that?
- Basically, TextMate may be at the top of the heap now (though there's
certainly room for debate), but if it continues to innovate, you can't be a
part of that. I would hope tools like Diakonos would win out in the long run,
because people who use them would inevitably contribute needed changes -- if
there was ever a "scratch your own itch" app, a text editor is it.

* Again, a SINGLE PERSON is responsible for the destiny of this editor.
- If Allan should be hit by a bus (not that I am wishing this on anyone),
what happens to TextMate development?



Now, I don't personally hack on my own text editor. It's also MUCH less of a
commitment than, say, a framework -- if you were on ASP.NET, for instance,
you'd be tethered to Microsoft for the lifetime of your app or until you port,
and it's much harder to port an entire app than to learn a new text editor.

Still, think about it. Would you choose a proprietary programming language?
Library? Framework? If not, why not, and why would you use a proprietary text
editor, or debugger, or _any_ proprietary programming tool?

I generally don't bother people about developing on OS X. It's annoying, but
most of the Ruby stuff is going to be general Unix stuff anyway, not Mac-
specific. But then, switching OSes is easy when your tools are portable.

But this is just my own curiosity. If you were using IE6, I'd hate you
forever, and this rant would be much longer, and it would never stop until you
stopped using IE6. If you're using TextMate, I think you're making a mistake,
but it really doesn't affect me that much.

 

[andrew mcelroy]

[Note: parts of this message were removed to make it a legal post.]

* Again, a SINGLE PERSON is responsible for the destiny of this editor.
- If Allan should be hit by a bus (not that I am wishing this on anyone),
what happens to TextMate development?

My earlier statements apparently went totally ignored.
Redcar is making a lot of progress. It is a JRuby text editor that is
attempting to be a complete clone and fully compatible with the text mate
snippets. It has been stable enough to begin to code with for a little while
now.

It is a shame that this editor doesn't get more attention. The idea of the
editor its self being ruby is pretty hip.
You could theoretically meta program the editor much in the same way you can
IRB.

Redcar if I am not mistaking is bsd licensed.
Andrew

 

[Seebs]

I'm much more interested in it on a personal level. Switching text editors at
this point might be, for most of us, far trickier than switching OSes, and
could be almost as bad as switching keyboard layouts. (Dvorak, anyone?) By
picking a proprietary technology, you're doing several things that I can't
really see being worth the risk:

Just as a data point, I still use vi as my primary editor (nvi by preference,
I dislike vim). And yet... I have TextMate, and BBEdit, both, on my Mac.

* You're locked-in to a single provider -- in this case, a single _person_.
- If Allan Odgaard doesn't want to implement a feature you want, you're
SOL.
- If Allan Odgaard can't fix a bug that's annoying you, you're also SOL.
- if Allan Odgaard wants money for a new car, you might find the next
version of TextMate costs significantly more.

Sure.

But if the CURRENT version meets my needs, great!

It's not as if most people can realistically get a real feature change
into vi. Even most programmers would be unlikely to find it worth the
time and effort.

* You're tied to an OS which is notorious for breaking backwards-
compatibility.

lolwut? I have things from OS X 10.0, written for PowerPC systems, which
still run on Intel in 10.6.

I'm not seeing a real issue here.

- The next version of OS X is as likely as not to break the current version
of TextMate.

You have any evidence for this? I've been using OS X as one of my desktop
platforms for about a decade now, and thus far, I've had VERY few programs
broken by upgrades -- and those were always things which I would have expected
to break, like low-level hacks into the window manager or something similar.

- Once you do upgrade, the new version of TextMate is as likely as not to
refuse to work on old versions of OS X, so you'd better upgrade all your boxes
at once.

Again, this claim "as likely as not" seems pretty implausible to me. It's
extremely unusual for anyone to make a tool like this not work on at least the
two or three most recent revisions.

Do you have any kind of data to back this claim up, or is this just generic
FUD? If we're gonna be doing FUD, how about I warn people that they shouldn't
be relying on Ruby, because a new version of Ruby might break existing
scripts?

Oh, wait. That actually *happens*, so we don't worry about it.

- If you don't like the new OS X, for whatever reason, some new version of
TextMate might force you to upgrade anyway.

But you don't have to get a new version, if the one you have works.

- Switching OSes -- to Linux, to Windows, to Plan9, to whatever -- is out
of the question for you.

I would consider that pretty normal for a lot of tools. I expect to have
to switch tools when I switch OS's. There are exceptions, but by and large,
the default I expect is that any given program will probably be specific
to a target platform.

* You're a programmer, yet you can't program your own programming tools.
- I don't care how extensible it is, you don't have the source.
- Look at the tricks tools like Diakonos can do. Can TextMate do that?
- Basically, TextMate may be at the top of the heap now (though there's
certainly room for debate), but if it continues to innovate, you can't be a
part of that. I would hope tools like Diakonos would win out in the long run,
because people who use them would inevitably contribute needed changes -- if
there was ever a "scratch your own itch" app, a text editor is it.

I have never found myself with any complaints about the available options,
preferences, or features in either BBEdit or TextMate. I use vi because I
like the raw speed, and don't need the flashy stuff, but I've never found
myself wishing to extend either of them.

* Again, a SINGLE PERSON is responsible for the destiny of this editor.
- If Allan should be hit by a bus (not that I am wishing this on anyone),
what happens to TextMate development?

Presumably it goes to the estate. I dunno. I don't see this as a big deal.
Again, if the current version works for me, I don't care about future versions
for a long time.

Still, think about it. Would you choose a proprietary programming language?

If it was the right tool for the job, yes.

Library?

If it was the right tool for the job, yes.

Framework?

If it was the right tool for the job, yes.

I'm making myself an iPhone app. I dunno if I'll ever even get it to the
point where I'd submit it to the app store. I want it for my own use. It
is heavily tied to several proprietary frameworks.

So what? Nothing else lets me do what I want. So I'll use Objective-C (not
technically proprietary, but functionally so), a number of proprietary
libraries, several proprietary frameworks, and a series of proprietary
development tools. Because they let me do what I want.

If not, why not, and why would you use a proprietary text
editor, or debugger, or _any_ proprietary programming tool?

I would use them because they had features I wanted or needed which justified
their cost. If I were doing something that was targeting Intel chips, and
I needed the best possible performance, you BET it'd be using the Intel
proprietary compiler. If I were targeting Cell, and I needed the best
possible performance, you BET it'd be using the IBM compilers. If I had a
short deadline for debugging something, and a proprietary tool had a feature
that would let me debug it, yes, I'd use a proprietary tool. Purify does
stuff that most other allocation checkers I've tried didn't. If I desperately
needed to fix an allocation bug, I might well tell management "get me a
license for Purify or move your schedule". (Well, probably not, since I'm
pretty good at those anyway...)

I don't have a problem with proprietary tools, IF they do their job well
enough to justify the hassles.

I generally don't bother people about developing on OS X. It's annoying, but
most of the Ruby stuff is going to be general Unix stuff anyway, not Mac-
specific. But then, switching OSes is easy when your tools are portable.

It is usually a bit of a tradeoff. I'll accept some non-portability of tools
to get jobs done sooner and with less effort.

I am a moderately experienced Unix geek, but the shared disk used by the
various computers in my house is attached to a box running OS X Server,
because the cost of my time to set all that stuff up correctly is an
order of magnitude more than the cost to have something where I click the
"yes, make this available to Windows too" button. ...Which is gonna go
away now that the two people who had Windows machines have moved out. But
I'll still probably use OS X Server, because it does what I want and stays
out of my face. Good enough.

-s

 

[David Masover]

Redcar is making a lot of progress. It is a JRuby text editor that is
attempting to be a complete clone and fully compatible with the text mate
snippets. It has been stable enough to begin to code with for a little
while now.

Looks interesting.

The only reason I mention Diakonos is that if I was going to start learning a
new editor, I might want a console one if I can make that work -- it'd be
something I can actually run over SSH, on remote machines, without having to
mount the filesystems first via sshfs.

Right now, I just use Kate, and vim when I have to ssh.

You could theoretically meta program the editor much in the same way you
can IRB.

That's the idea.

And yes, more power to Redcar, and Diakonos, and anything else. My rant was
specifically against relying on a single piece of proprietary software for
your development -- if there's actually a reasonable replacement by now, so be
it, though if I went that route, I'd suggest Redcar on OS X as well.

 

[sl4m]

[Note: parts of this message were removed to make it a legal post.]

While I have not tried, the linux version of e-texteditor (originally only
for Windows) is free and available here:
http://wiki.github.com/etexteditor/e/.

It takes advantage of TextMate's bundles and is one of the editors I use on
Windows. You just have to build it.

"The editor could not have been build[sic] without the support of a lot of
open source projects (most notably wxWidgets <http://wxwidgets.org/>). So to
give back, the Linux version will be totally free (as in beer)."

http://e-texteditor.com/blog/2009/releasing-the-source

 

[Rimantas Liubertas]

hey, I agree with the whole post of yours, but this is the key message:

But if the CURRENT version meets my needs, great!

Fear of some bad thing to happen (and most of which are not very
likely) should not
stop you from using the tool you consider best for the job right now.
And most of us a probably using several editors anyway, so switching to some
alternative already familiair won't be that huge cost.

Regards,
Rimantas

 

[Seebs]

Fear of some bad thing to happen (and most of which are not very
likely) should not
stop you from using the tool you consider best for the job right now.

In general, yes. The key thing there is that, no matter what happens
to TextMate in the future, I can use the current version. Contrast with,
say, the recent kerfluffle with Ubisoft introducing a "DRM" scheme whereby,
if their servers go down, the program you ALREADY HAVE stops working. In
that case, it's certainly quite reasonable to be concerned.

The key thing to evaluate is what happens to you in the case where things
go "poof". If the guy selling TextMate goes away tomorrow, I still have
an editor that does a bunch of stuff pretty well and which I find basically
friendly. I can live with that.

-s

 

[Charles Roper]

While I have not tried, the linux version of e-texteditor (originally only
for Windows) is free and available here:
http://wiki.github.com/etexteditor/e/.

Another vote for E Text Editor here. It's coming along nicely on Linux:

http://e-texteditor.com/blog/2009/linux-progress
http://e-texteditor.com/blog/2009/building-e-on-fedora-10
http://www.e-texteditor.com/forum/viewforum.php?f=11

Read about the author's own unique style of open source here, which is
an interesting story in its own right:

http://e-texteditor.com/blog/2009/opencompany

A better question might be why so much of the Ruby community has
embraced a proprietary editor which is only available for a
proprietary OS.

I think that could be a classic case of a 'Tipping Point'[1] moment. The
original Rails screencasts by David were done in TextMate on a Mac. At
the time, I remember being allured and wowed by the editor as much as
Rails (and Ruby) itself. I had already come across Ruby before, but this
frankly /sexy/ demonstration was what swung me over to it
wholeheartedly. From there - that original sales pitch - the epidemic
spread through the mavens and connectors (bloggers and influential 'web
2.0' people). To get on board and be like David one had to have TextMate
and, of course, a Mac. I suppose, in a way, it's a bit like kids wanting
the same boots as their favourite soccer stars.

Having said that, I still don't have either a Mac or TextMate, so go
figure.

[1] http://en.wikipedia.org/wiki/The_Tipping_Point

Charles

 

[Diego Virasoro]

I'm much more interested in it on a personal level. Switching text editors at

this point might be, for most of us, far trickier than switching OSes, and
could be almost as bad as switching keyboard layouts. (Dvorak, anyone?) By
picking a proprietary technology, you're doing several things that I can't
really see being worth the risk:

To be honest with you I find your arguments weak at best. At the end
of the day the data it spits out (the files you work on) are simple
text files. How you got there doesn't matter, and I don't see why it
should. Yes, it may cost some retraining time to move to another text
editor but so what: should I stop using it on the off chance that the
developer takes it in a direction I don't like? Personally I didn't
buy textmate for what will be added in 1 year, but for what it is now.
And just like I moved to Textmate even though I wasted a few hours
learning to be comfortable in it, so I will in the future if I have
strong objections.

Do you make your own car on the off chance that the car makers will
make a car you won't like? Or maybe create your own mobile phone
because you are worried that tomorrow Nokia et al. will produce phones
you don't like?

Everytime you move from one product to another you need to retrain
yourself. Those of us who bought Textmate did it for what it is, and
that will not change. And as any other complex product in life if the
future Textmate will not be good enough, we will not buy it and get
something else.

Diego

 

[Roger Pack]

While I have not tried, the linux version of e-texteditor (originally
only
for Windows) is free and available here:
http://wiki.github.com/etexteditor/e/.

It is free but unless you register will give you a popup at startup time
saying "your license has expired" (then allowing you to continue)

The only open source textmate clone I'm aware of is Redcar. It just
released a new version with snippets now

http://redcareditor.com/2010/03/redcar-034dev-released/

-r

 

[sl4m]

[Note: parts of this message were removed to make it a legal post.]

I'm going to keep a watchful eye on Redcar, thanks.

 

[David Masover]

To be honest with you I find your arguments weak at best. At the end
of the day the data it spits out (the files you work on) are simple
text files.

Yes, I acknowledged this, and it's why I care much more about people using IE
than people using TextMate.

Yes, it may cost some retraining time to move to another text
editor but so what:

So, that's a nuisance and a cost, and depending on how much you find yourself
relying on a given tool, it may start to be significant.

Do you make your own car on the off chance that the car makers will
make a car you won't like?

Bad analogy -- I don't have to "make my own car," there's things like RedCar,
Diakonos, and others.

But there isn't really a lot of choice in cars. If I want a decent car at an
affordable price, I pretty much want something manufactured, probably
something used. It's entirely impractical to build it myself.

If you want a better car analogy for this sort of thing, I recommend Neal
Stephenson's "In the beginning was the command line":

 

[David Masover]

Sorry for the double-post... accidentally hit ctrl+enter before it was
finished.

Yes, I acknowledged this, and it's why I care much more about people using
IE than people using TextMate.


So, that's a nuisance and a cost, and depending on how much you find
yourself relying on a given tool, it may start to be significant.


Bad analogy -- I don't have to "make my own car," there's things like
RedCar, Diakonos, and others.

But there isn't really a lot of choice in cars. If I want a decent car at
an affordable price, I pretty much want something manufactured, probably
something used. It's entirely impractical to build it myself.

If you want a better car analogy for this sort of thing, I recommend Neal

Stephenson's "In the beginning was the command line":
http://www.cryptonomicon.com/beginning.html

Again, I don't have to create my own -- but Android helps. I wouldn't buy an
iPhone, for instance, no matter what it can do now.

 

[David Masover]

But if the CURRENT version meets my needs, great!

So long as the current version continues to work.

It's not as if most people can realistically get a real feature change
into vi. Even most programmers would be unlikely to find it worth the
time and effort.

Most likely -- but having the ability is important.

I'm unlikely to ever want to, say, burn an American flag, but it is important
to me that I have that right.

lolwut? I have things from OS X 10.0, written for PowerPC systems, which
still run on Intel in 10.6.

And I've seen things break from 10.3 to 10.4 to 10.5.

You have any evidence for this? I've been using OS X as one of my desktop
platforms for about a decade now, and thus far, I've had VERY few programs
broken by upgrades -- and those were always things which I would have
expected to break, like low-level hacks into the window manager or
something similar.

It's been long enough since I've used OS X that it's possible I'm remembering
low-level hacks. Then again, I remember even things like VLC would require at
least 10.3, and this is when 10.4 was the latest. So...

Again, this claim "as likely as not" seems pretty implausible to me. It's
extremely unusual for anyone to make a tool like this not work on at least
the two or three most recent revisions.

Two or three is nice, still means you're going to have to upgrade when it's
four, five, or six revisions out of date -- either the program or the OS.

Again, I don't mind this so much in open source, because in cases where an old
version had some merit, and we think they screwed up the new version too much,
we can fork the old version and maintain it. In particular:

Do you have any kind of data to back this claim up, or is this just generic
FUD? If we're gonna be doing FUD, how about I warn people that they
shouldn't be relying on Ruby, because a new version of Ruby might break
existing scripts?

1.9 might, yes. But Ruby is open source. Don't like 1.9? Fork 1.8.7, or even
1.8.6. I believe someone is currently maintaining a stable 1.8.6.

With proprietary software, that's not an option -- Microsoft wanted to force
Vista on everyone, so they threatened to pull support for XP. That would've
meant security vulnerabilities, among other things, making life difficult for
those of us wanting to stay on XP -- no chance of any bugfixes. Microsoft
maintains support for old version of Windows, but to a point -- beyond which,
the community CANNOT take over.

Now consider the case of a killer app developed by a single individual. What
are the chances he's going to expend significant time and energy maintaining
old versions of TextMate when he could be working on a new version (and
charging for it) instead?

Can you see why I might be more inclined to trust a popular open-source
project developed by dozens (hundreds?) of people around the world, rather
than a proprietary project developed by a single person?

I would consider that pretty normal for a lot of tools. I expect to have
to switch tools when I switch OS's. There are exceptions,

My text editor of choice right now is Kate, and the entire KDE project is
cross-platform. My other text editor of choice is vim, and it even runs on
Windows, with some help. For school, I'm forced to use Java, so I use Eclipse,
which is also cross-platform. Ruby is cross-platform. Rails is cross-platform.

My web browser of choice is Google Chrome, which is cross-platform. My other
web browser of choice is Firefox, which is cross-platform. Third would be
Konqueror, which is as portable as KDE.

For writing and publishing, I'm using OpenOffice and Scribus, which are both
cross-platform.

For image editing, Krita or Gimp -- cross-platform, and cross-platform.

For remote management, I use ssh and rdesktop -- cross-platform, and... oh,
there it is. I bet rdesktop doesn't have a Windows version, huh? That's OK, I
can use Windows' native Remote Desktop client.

Whew. That was hard to find the one tool which isn't portable, and I'm not
even sure about that -- it might run under Cygwin!

If it was the right tool for the job, yes.

I'm making myself an iPhone app. I dunno if I'll ever even get it to the
point where I'd submit it to the app store. I want it for my own use. It
is heavily tied to several proprietary frameworks.

So what? Nothing else lets me do what I want.

Really? Android doesn't? That's interesting.

I don't have a problem with proprietary tools, IF they do their job well
enough to justify the hassles.

I tend to agree, yet I notice, again, a trend where people like that
everything Ruby is open source, yet don't care to look for the same in their
OS or editor.

And that is a big if...

It is usually a bit of a tradeoff. I'll accept some non-portability of
tools to get jobs done sooner and with less effort.

I'll do that, if it's enough sooner and enough less effort to justify the loss
of flexibility. I'd much rather spend a bit more time and get it right the
first time, using portable, flexible, open tools, so that I don't have to
completely redo it if something needs to be changed.

There's always a tradeoff, I just find it interesting where people draw the
line. For example:

I am a moderately experienced Unix geek, but the shared disk used by the
various computers in my house is attached to a box running OS X Server,
because the cost of my time to set all that stuff up correctly is an
order of magnitude more than the cost to have something where I click the
"yes, make this available to Windows too" button.

sudo apt-get install samba

A fileserver is about the easiest thing to set up. I have to ask how much
you're being paid where half an hour or so of your time is more valuable than
the hardware markup for an OS X server.