From: sl4m Date: 2010-03-11T16:17:02+09:00 Subject: Re: Why no TextMate for Linux? --00504501588e59776b04818133c5 Content-Type: text/plain; charset=ISO-8859-1 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 ). So to give back, the Linux version will be totally free (as in beer)." http://e-texteditor.com/blog/2009/releasing-the-source On Wed, Mar 10, 2010 at 20:55, Seebs wrote: > On 2010-03-11, David Masover wrote: > > 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 > -- > Copyright 2010, all wrongs reversed. Peter Seebach / > usenet-nospam@seebs.net > http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures > http://en.wikipedia.org/wiki/Fair_Game_(Scientology)<-- get educated! > > --00504501588e59776b04818133c5--