--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 <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


On Wed, Mar 10, 2010 at 20:55, Seebs <usenet-nospam / seebs.net> wrote:

> On 2010-03-11, David Masover <ninja / slaphack.com> 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)<http://en.wikipedia.org/wiki/Fair_Game_%28Scientology%29><-- get educated!
>
>

--00504501588e59776b04818133c5--