Lime Text – Open Source Sublime Text alternative (2014)
31–40 of 186 posts
Re: Lime Text – Open Source Sublime Text alternative (2014)
#32Just the straw that finally broke the camel's back . . .
Re: Lime Text – Open Source Sublime Text alternative (2014)
#33As 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...
https://github.com/vim/vim/blob/master/runtime/doc/version8....
Re: Lime Text – Open Source Sublime Text alternative (2014)
#34As 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…
+ 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…
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)
#36Earlier 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.
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)
#37As 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…
In that case I'll assume it's a feature :)
Re: Lime Text – Open Source Sublime Text alternative (2014)
#38As 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…
Re: Lime Text – Open Source Sublime Text alternative (2014)
#39Am 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 . . .
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)
#40Am 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'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.