Live data from Hacker News

Lime Text – Open Source Sublime Text alternative (2014)

limetext.org

31–40 of 186 posts

Re: Lime Text – Open Source Sublime Text alternative (2014)

#32
Am I the only one sick of projects declaring, "written in rust", "primarily developed in go", etc? Why do your users care about your implementation language? Do you have any features worth mentioning? If your main selling point is that you used the shiny new language, I'm already doubting the usefulness of the endeavor.

Just the straw that finally broke the camel's back . . .

Re: Lime Text – Open Source Sublime Text alternative (2014)

#33
post #28
post #21

As an emacs addict/user, what I really want is a credible alternative to that cockroach of editors. Price of admission: run in a terminal, run graphically, run on every possible system, be open source, be ridiculously, easily extensible. What a successor might add: Not be riddled with bugs. Not be ridiculously, terribly bad at actually displaying text (quickly, smoothly, large amounts). Not be extended in a language…

As a Vim addict/user. All I really want is a bit more modernization. I mean single threaded text editor in 2016.. NeoVim is supposed to be the savior.. But I don't feel like it gets a lot of support...

In Vim8 vim gained asynchronous I/O support

https://github.com/vim/vim/blob/master/runtime/doc/version8....

Re: Lime Text – Open Source Sublime Text alternative (2014)

#34
post #21

As an emacs addict/user, what I really want is a credible alternative to that cockroach of editors. Price of admission: run in a terminal, run graphically, run on every possible system, be open source, be ridiculously, easily extensible. What a successor might add: Not be riddled with bugs. Not be ridiculously, terribly bad at actually displaying text (quickly, smoothly, large amounts). Not be extended in a language…

Atom (hear me out):

+ runs graphically

+ runs linux, macos, windows (nothing else?)

+ open source

+ ridiculously, easily extensible

+ not riddled with bugs (slowness is not a bug)

+ for small files, comparably quick to Sublime on my machine

+ major dev community; already much better than 6 months ago

- slow in some instances, esp. large files

- doesn't run in terminal

- doesn't run in less-popular OSes

+/- moderate RAM usage, decreasing

Re: Lime Text – Open Source Sublime Text alternative (2014)

#35

> Lime Text is a powerful and elegant text editor primarily developed in Go It's very interesting to me that this is the most important statement the creators can make about their project. Of course anyone making a text editor will say it is powerful and elegant. As an end-user, I rarely care what language a text editor is written in. At least not right up front. It might matter if I'm interested in extending or modi…

For the people they are targeting by calling it a successor to Sublime, the language actually does matter. Many, likely most, Sublime users are taking advantage of the myriad of plugins written for Sublime in Python. I immediately discounted the usefulness of this product simply because it is written in Go, which would mean I need to find new equivalents for the plugins I use on a day to day basis, or write Go versio…

For what it's worth, it does aim to be (mostly) compatible with the Sublime Text Python API[0]. The base editor is written in Go, but the plugins are Python (much like Sublime itself is C++, but uses Python plugins).

That said, I wouldn't get too excited about this - not much has really happened on it since April 2015.

[0]: It's the fifth point on the roadmap: https://github.com/limetext/lime/wiki/Goals

Re: Lime Text – Open Source Sublime Text alternative (2014)

#36
post #29

Earlier quoted context omitted.

A possible (very early) start for this could be https://github.com/google/xi-editor UIs and actual functionality are completely separate implementations. Loading and displaying text are entirely decoupled, so the display doesn't have to care if the actual file is 10kb or 2gb in size.

super-early-days, but this looks philosophically very much in the right place.

There's a talk about it, too, if interested: https://www.youtube.com/watch?v=SKtQgFBRUvQ

I'm hoping to find the time to get more comfortable with Rust and try to contribute at some point

Re: Lime Text – Open Source Sublime Text alternative (2014)

#37
post #21

As an emacs addict/user, what I really want is a credible alternative to that cockroach of editors. Price of admission: run in a terminal, run graphically, run on every possible system, be open source, be ridiculously, easily extensible. What a successor might add: Not be riddled with bugs. Not be ridiculously, terribly bad at actually displaying text (quickly, smoothly, large amounts). Not be extended in a language…

Atom (hear me out): + runs graphically + runs linux, macos, windows (nothing else?) + open source + ridiculously, easily extensible + not riddled with bugs (slowness is not a bug) + for small files, comparably quick to Sublime on my machine + major dev community; already much better than 6 months ago - slow in some instances, esp. large files - doesn't run in terminal - doesn't run in less-popular OSes +/- moderate R…

+ not riddled with bugs (slowness is not a bug)

In that case I'll assume it's a feature :)

Re: Lime Text – Open Source Sublime Text alternative (2014)

#38
post #21

As an emacs addict/user, what I really want is a credible alternative to that cockroach of editors. Price of admission: run in a terminal, run graphically, run on every possible system, be open source, be ridiculously, easily extensible. What a successor might add: Not be riddled with bugs. Not be ridiculously, terribly bad at actually displaying text (quickly, smoothly, large amounts). Not be extended in a language…

Which of those does vim not hit?

Re: Lime Text – Open Source Sublime Text alternative (2014)

#39

Am I the only one sick of projects declaring, "written in rust", "primarily developed in go", etc? Why do your users care about your implementation language? Do you have any features worth mentioning? If your main selling point is that you used the shiny new language, I'm already doubting the usefulness of the endeavor. Just the straw that finally broke the camel's back . . .

I care about it whether it pulls in big dependencies. So I tend to avoid things in Java or Node.js, and on Unix I would avoid .Net (Mono). On Windows I'm fine with .Net, but would want to avoid Python.

For languages like Go and Rust which compile to native code, I don't give a damn -- except to note that it is such a language.

Re: Lime Text – Open Source Sublime Text alternative (2014)

#40

Am I the only one sick of projects declaring, "written in rust", "primarily developed in go", etc? Why do your users care about your implementation language? Do you have any features worth mentioning? If your main selling point is that you used the shiny new language, I'm already doubting the usefulness of the endeavor. Just the straw that finally broke the camel's back . . .

Interestingly, I am tired of most projects declaring the language in which they were written upfront, especially when they are a copy of something else, "but written in ${language}!" - however, I am interested in the language a text editor is written in. Or, rather, the language it's extensible in.

I'm a long-time Emacs user, but have been growing increasingly tired of it. Whichever incarnation of Emacs I turn to, it just seems old-fashioned and outdated. And yet, whenever I try another editor, I end up coming back to Emacs. And one of the reasons is often the language (or ability at all) with which to extend it.

Post reply on HN