Lime Text – Open Source Sublime Text alternative (2014)
limetext.org
limetext.org
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 that's so slow that most "intelligent" modes end up being piles of half-correct regex hacks.
Not not care about correctness, in general.
Hop to it, dear idealistic genius whiz-kid reader!
Or fund me, overly-$-laden startup lottery winner. I'll take a crack at it.
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.
I'm hoping to find the time to get more comfortable with Rust and try to contribute at some point
Or are you talking out of your ass?
From looking at similar projects, overhead tends to be in the millisecond range per call, so performance depends on the ammount of back and forths.
Add in all the overhead for serialization and IPC and in practice it looks a lot like the round trip in same data center latency here:
https://people.eecs.berkeley.edu/~rcs/research/interactive_l...
If the performance hit is not noticeable, nobody really cares about the waste of CPU cycles. Especially since a text editor uses something like 1/10 the resources a large, complex program uses anyway.
Some IDEs go as far as to offer low power modes where they throttle external plugins.
You actually see this in many IDEs that more features make editing feel more sluggish. This shouldn't happen with this structure.
You can also do it async style and have neither of the drawbacks - if the user types too quickly, the autocomp just doesn't show up.
Both can (and have) been achieved without a client server architecture.
Also I think that the marshalling you need for IPC is not so different than the boxing and conversion that you have under the hood if you write in an interpreted language, e.g. Python or JavaScript.
I changed my mind over two electron editors/IDE. I use RStudio and it is really been getting so fast on my old computer that I can't tell anymore. VS Code by Microsoft is so fast and nimble that I have been using it 75% of the time with no felt overhead. It really is an amazing piece of software in terms of speed, now the ram usage is still much higher but for my uses I don't notice it at all on my 8 year old Dell corporate computer.
It's not an either/or problem though.
https://github.com/vim/vim/blob/master/runtime/doc/version8....
+ 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
In that case I'll assume it's a feature :)
I came to Atom from Sublime because the plugin ecosystem was growing much faster and the community felt more active. I haven't looked back since.
And no, Atom not designed to open 30Mb files. Complaining about this is akin to stomping on a land mine and complaining that your Timberland boots didn't save your foot. Just use Atom for its intended purpose: editing source files written by reasonably reasonable people.
Going through log files and developing software are related, but distinct enterprises. It's no wonder the tools for one are sometimes suboptimal for the other.
Atom is about nice aesthetics, github integration and a plugin ecosystem. It's not trying to solve the problem of reading through massive log files.
Same goes for Sublime. And arguably - Sublime has much better plugin ecosystem. With easier discovery and installation.
tail -f *Let me know when they start advertising atom as a source code editor instead of a text editor.
It takes all of 200ms and a wee bit of inference to figure out that their usage of "text editor" is different from yours.
From the tone of some of these posts, you'd think downloading Atom and subsequently realizing it doesn't suit one's needs caused lasting psychological harm.
Semantics aside, Atom is good at what it does. For 99% of projects it's an excellent, flexible tool.
No lasting harm, but I did invest quite a bit of time to discover that it doesn't suite my needs.
> It takes all of 200ms and a wee bit of inference to figure out that their usage of "text editor" is different from yours.
No it doesn't, it takes experience with the editor. 200ms of googling shows there are some log and tail plugins, which would lead me ot believe it was good at handling large files.
Well, this is simply a bullshit, sorry. This is might be a point of view of someone who never worked on an enterprise project or something of a similar scale.
Atom is good at one thing - opening small js\ruby\python scripts and showing you them in a modern UI. That's it. Anything more than that - he just can't do it.
head -10 myfile.json
i mean we're talking about opening a file that is 1% of typical system memory.
As to why I'm opening such large files: It's not like I chose to do so, but sometimes I have to. It's great to be able to (in Sublime) `<Ctrl+P> log <Ctrl+F> blah` and see immediately what I'm looking for without switching to another tool. I even have a simple syntax highlighting definition for my log file that makes it really nice.
I'd really like to like Atom, but the fundamental problem is that it tries to emulate a text editor widget in a web browser. That works, but creates a certain amount of latency that I can't work with. It's really irritating.
And that's exactly one of it's problems. It's not designed to be a damn text editor. Instead - it's just another "hipster editor". You can find a growing number of useless plugins, but can't open log file sent to you, or connect via proxy without a trouble.
Not to mention the speed and ram usage. My IDEA instance with a large project opened up use less memory than Atom without any files opened (but with a bunch of plugins loaded).
Sorry for the emotional replay, but I just do not understand how people can go from Sublime, which is, in my opinion, almost ideal text editor, to something like this js crap.
since when do you need to edit log files? you don't need an editor for that, you need a log explorer. there are other tools for hat.
what exactly do you mean with proxy problems? i'm behind a proxy at work and didn't have any problems?
> Not to mention the speed and ram usage
that thats its only real problem. especially if you're on a laptop without a power outlet nearby. i tend to just use vim in that situation notice a significant increase in battery life.
> I just do not understand how people can go from Sublime [...] to something like this js crap.
at least its fully extensible. i love the linting, auto-beautification, Markdown Preview, extensible autocompletion, useful autosave, Git-WIP support, extensive git integration and so much more.
its just not meant to be used as anything beside editing small code files. and most people don't have to code monolithic code files beyond a few MB in size.
Any time I want to re-hydrate escaped control sequences like newlines, or explore the log using a host of tools available in a text editor.
> at least its fully extensible
As are most text editors and IDEs. Atom's only difference here is that the extensions must be written in Javascript. Not everyone sees this as a good thing.
> its just not meant to be used as anything beside editing small code files
And that's the problem. Why should a user be forced ahead of time to consider their usecase for editing a file just to choose which gimped file editor they want to use?
No, it's more like having a car that doesn't get to 70mph.
It's useless on the Interstate, and it's also not that good on regular city traffic, because the same limitations that make it unable to reach 70mph also make it clunky at 10mph.
Woah. woah. woah. Back the truck up.
Slowness is most definitely a bug.
Do you mean major as in "large", or as in "possessing some positive quality"? While I'm not commenting on Atom's dev community in particular, the two don't have a causative relationship.
A particular downside I see with Atom is it's performance - the perception of which is in some cases arguably approaching that of its competitors - and hence its energy impact, which affects my battery life.
Compare it with emacs in which I have far more plugins and it still starts fast as a clean install.
Anyway not a big problem eh. For me vimscript is the shitty part of vim.
I mean, I love Emacs and use it daily. But it certainly has plenty of bugs; but what reasonably complicated piece of software doesn't?
Having said that, the very core text editing engine, i.e., the part that's written in C and the basic Elisp editing functions around that are still rock solid as always, and for me this is still the ultimate model of what a text processing engine should be. It handles large files beautifully (and errors gracefully when it cannot), does file locking well, goes to great lengths to ensure the integrity of your file, all of that basic core stuff is just superb and well thought out, by a lot of brilliant people over a long time, and that's all very well optimized. I think the problem is that too many third-party extensions are included with the core release.
On the other hand, I can't really think about a system that fulfills those conditions. But I wouldn't call anything "ultimate" if it doesn't :)
Before that there were years during which there was no way to configure Emacs that I was able to find to refrain from asking the user what coding system he wants to use every time a buffer containing a non-ascii character is saved. Not strictly a bug since maybe there are users who do not mind regularly getting into the same dialog with their text editor, but certainly, so many occurrences of the same monotonous dialog is unusual behavior in a user-facing application in this decade and very tedious at least to this particular user.
One reason Emacs is difficult to debug is because of the widespread use of global variables.
That said, I haven't found anything worth leaving Emacs for. (If I were a web dev, maybe I would've left it for vscode by now, but I don't like how text looks in vscode: I prefer the native OS X text rendering used by almost all text editors except the Electron-based ones.)
Hey, I can dream.
Exactly. Every so often I try to make a half-hearted effort to move to a more moderen editor, or even an IDE, but for all its flaws even nothing comes close to Emacs. Vim is pretty good, but tries to do too many things it's not supposed to; for vi-style editors I prefer Nvi.
https://dlang.org/blog/2016/10/07/project-highlight-dlangui/
It is written in D, a fast (close to C++) language, easy to write code in, runs in a terminal, runs graphically, runs on many systems (I don't know every possible system but I doubt in runs in a Commodore 64), it is open source and I have no idea about it being extensible or not.
It's however the closest thing I have seen to your list of requirements.
If you don't mind the lack of extensions, and are willing to write your own, you may wish to try some of the other emacsen associated with the lisps. Hemlock is CL-based, so likely faster than Emacs, and Edwin and Guile-Emacs are both based on Schemes (edwin is MIT Scheme, Guile Emacs is... Guile). They still suck at some stuff, though, and they don't have the massive plugin ecosystem.
This project looked familiar, and I seem to recall coming across it a while back. As others have pointed out, the blog hasn't been updated since 2014, so it looks like a stalled project. Another points victory to Sublime perhaps? ;)
Blog and website activity are not always indicative of project activity.
And I'm speaking after using Emacs and VIM for 15 years having not seen one other editor concept that was ultimately superior.
Sublime Text was horrible in that it offered an easy refuge so many young and inexperienced people. But ultimately it was a closed source prison that they got pulled into. And yes, I'm a professional developer having founded multiple companies. I'm a capitalist, nothing wrong with selling software. However, having great tools that last a lifetime available is one of the most important point I learned and like to teach to my students (I'm a lecturer, too).
Why lock yourself in? Just because it looks more shiny and is easier in the first week? That's a good reason to use many things, but not your primary driver as a professional software engineer.
Hooray for these new editors that look shiny and are open source. And then, when the students ask how I did those crazy things in Emacs, they still get those huge eyes and want to gobble all the information in. This kind of curiousness happens rarely with people locked into proprietary systems.
Here comes the snark in reply to the snark:
Someone had to come along and show that text editing didn't require the inscrutable complexity of Vim or Emacs, the kind of overwrought, overcomplicated, elitist and impractical user-hostility that absolutely dominates Open Source user interface design.
I'd like to think that the proliferation of Sublime is what caused people to roll up their sleeves and start putting together things like Atom and VSCode and even this project.
But I still use Sublime. Why? Because it's still faster than every competitor, it's still extensible enough to do what I need it to do, and unlike Emacs, doesn't require a PhD to comprehend, and unlike Vim, isn't an evolutionary dead end that pretends the mouse was never invented.
Snark off:
Many users don't consider Open Source to be a selling point. I am one of them. I choose my tools based on their usefulness, not the political status of their code, not intangible theoretical posturing about good and evil in the context of a fucking text editor.
And you'll forgive me for taking issue with weak attempts to shame people for choosing tools that work for them. Perhaps this post reads a bit angry, and this is why.
As for simplicity, there is nothing that I have seen in any editor that is simpler than VIM modal editing or a LISP-machine to do everything. Having a shiny GUI is inherently not simple, but complex.
If you are not familiar with yhe original meanings of these terms, there's a qualified speaker: https://www.infoq.com/presentations/Simple-Made-Easy
That a tool is not easy in the beginning is ultimately irrelevant if it is simple. That is, if you've got enough time to master and profit from it. Which is what every professional software engineer has.
The problem with "you need to invest the time, trust me", I'd the same argument can be used for vim, Emacs, sublime, atom, vscode, eclipse, intellij, and any other editor. I can't invest the time in all of them to become expert.
The difference with Emacs and vim is that they require a sizable time investment just to become competent, as they refuse to fit into the OSes they are running in (in the case of windows and Mac).
While it is highly non-intuitive at first, one can learn the basics in a day or two, from then on it's mostly transferring what you learn to muscle memory. I suppose one can do more advanced stuff in vim that is more complex to learn, but the basics are pretty easy. (Full disclosure: I used to to use vim for a couple of years but switched to emacs about ten years ago. I still use vi for quickly editing a config file on a regular basis.)
This is just wild exaggeration. It doesn't take more than a few weeks or so to become reasonably productive with another text editor. We like to think that the many plugins and shortcuts we build up over years of using an editor adds like 100% speed increases, while at best its increments of a few fractions of a percent.
And most of us developers are probably familiar with at least two editors anyway. Personally I'm intimately familiar and productive with both emacs and sublime, but still prefer sublime. If sublime were to suddenly close down shop and not release their sources, I could switch on a dime.
> As for simplicity, there is nothing that I have seen in any editor that is simpler than VIM modal editing or a LISP-machine to do everything.
In theory, yes. In practice, I've found it much more complex to work with emacs plugins than with Sublime plugins. My conclusion is that overly simple languages like LISP just transfer complexity from the language itself to the code that you're writing.
I'm sure some people find a kind of simplicity there that they like, but people are different.
VIM modal editing is also a thing that may be nice to some people, but personally I find modes to be annoying. It's this state that I always have to keep in sync between me and the editor, and I don't like it. I get the point and the benefits, and I've tried several times, but it just doesn't click for me. So I don't experience that as a simplicity.
> Having a shiny GUI is inherently not simple, but complex.
I wouldn't call Sublimes GUI shiny. In fact it's quite minimalistic. Even more so than Emacs' GUI if you ask me, especially once you've added all the plugins to match functionality.
Again, it's something about the transfer of complexity. In theory, in its base implementation, Emacs is simpler because it makes few assumptions. But this transfers a lot of complexity to plug-in writers, because you get conventions instead, which often causes problems when plug-ins interact.
Can you give some examples please? Python is even simpler than CL however I don't regard it to be transferring any complexity to the programmer.
I'm a Vim user. But it's exactly this kind of thing that pushes newbies away. Yes, Vim is "simple" conceptually. But in this real world we live in, Vim often makes things more complicated. It's one more thing to learn - and a weird one.
On top of that, Vim's architecture is ancient and not everything has aged gracefully.
However, all your points are very correct! That is why I have switched to Emacs where I can still have full VIM modal editing with the other issues you mentioned not being an issue. Emacs has a mode called 'evil' which fully emulates VIM.
Best of both worlds^^
You say that as if Sublime HQ Pty Ltd were to suddenly go out of business, the editor is immediately and completely useless.
This is obviously not the case, in any way, shape or form. It could go out of business tomorrow, and Sublime Text would be perfectly usable (and extensible) until the OSes changed in a way which stopped it from working.
Being open source provides no more guarantee of future development than being closed source does.
So this "lock in" simply does not exist in the case of Sublime.
That naturally leads to the question of "Why it, and not a free alternative?"
I said it elsewhere in this thread, but the main reason I'm on Sublime and not Atom or an equivalent competitor is speed. It's fast, it's developed conservatively, and watching other editors hitch and stutter when they open large files or scrolling or start up or process syntax highlighting probably doesn't have much time impact on my productivity, it does cause a great deal of annoyance, hence stress, which probably does impact productivity in some way.
The other reason is that it lacks in bloat, which to me, means it lacks a ton of features I will never use, something I cannot say about Vim (macros, registers, hundreds of ancillary commands) or Emacs (an entire Lisp vm) and their associated complexity. However, it can be trivially extended with Python, which means any functionality it lacks has likely been worked around by someone in the community.
On top of all that, the author has made indication that he'd rather see the editor go open source than be abandoned[1], but I don't share the common belief that no updates for years means "abandoned" either.
That's a very good point. Longevity and sustainable is important. Let's be honest, OSS is subject to trends. That is, as soon as the thrill is gone the audience is likely to move on and you're left with what? A fax machine?
Sure, a for profit might do the same. But it seems less likely.
The OSS ideal is great. The reality is, like everything else, it has a dark side.
I prefer tools that I can repair myself. Being able to zip directly to the source of any Emacs lisp function is heavenly when learning about things or when debugging something that isn't working. Having lived in that environment for years now, it's not something that I take lightly any more. A new editor has no real chance with me unless I can poke and prod it at will.
I'm currently trying to take up Emacs (I pick up one of vim and Emacs every few years. Not sure why. Feels like a thing I should do). Here is some of my list of Emacs problems.
* The big one. Every other app on my Mac uses the same shortcut keys for cut, copy, paste, save, open, search, search + replace, spell check. That's probably 95-99% of the keys I press, and Emacs has to be special and support none of the standards. I know there are good historical reasons for this, but that's no use to a new user.
* Server mode doesn't seem to "understand" Macs -- when I shut down my Mac it just hangs and I have to force kill it. Without server mode I end up with loads of Emacs which seem to load slower than atom can open a window.
* I like editting text ,(as opposed to code) in a variable width font. Doesn't seem well supported.
* The default settings seem very limited, so then I wonder if I should use something like spaceman's, but that is massive and brings it's own bugs.
I can be comfortable, and fairly productive, instantly in sublime, atom, lime and vscode. Why can't Emacs, by default, have a "be like a Mac app" mode?
Actually some of the things you mentioned are super awesome strengths to me.
1. key bindings. I understand your point and you are right. But hear me out^^
I'm using Emacs on the Mac and Linux daily. Sometimes I fire up Windows for some cross platform app. Those three OSs have usually different key bindings and would have so in a regular GUI tool. Not in Emacs, though. They are all the same. Muscle memory win^^ Plus, I changed _many_ key bindings in Emacs to that they work better for me - across all OSs.
2. Server mode. Hm, I'm not having an issue here, but I cannot say that with confidence, because I rarely shut down, I always suspend (closing the lid on the MBP).
3. Variable Width Font. Have no expertise here. I tried that once, but it messed with how the code looks aligned which seems important to me. Again, sorry, would love to help, but just don't have expertise in this.
4. Default settings. You're right spot on! This is not an accident, but on purpose. The reason is that they are General Text Editors opposed to most others. That means that could do anything if you teach them. The others can do specific things faster. This approach has served me well and I have huge configurations in VIM and Emacs. Now I'm actually doing everything in Emacs, Mail, writing Books, PDFs, Todos and so on. Of course you don't need that to get going. It's just awesome that you can continue to improve your main tool for ever and ever^^
I learned how to do these things by reading other people's config. If you'd like to look at my Emacs config, it has lots of prose documentation for other people to read: https://github.com/munen/emacs.d/blob/master/configuration.o...
I hope some of that was helpful. One more thing, it's OK if you only seem to vaguely get that VIM and Emacs are worth it. Took me a couple tries, too. Same with most things that are worth it. Like getting to know the right Woman^^
Actually the vimium plugin for Chrome is great in that respect. I guess I can do 80% of my work with vim keybindings now.
One of the biggest strengths is just this. I use VIM key bindings everywhere: Chrome, FF, Terminal, even Emacs. Back in the day where I also did much work on Windows, I also had them in Visual Studio and MSSQL Manager.
The difference is that I move the hands off the middle row, and use the cursor keys and the home-end-pageup-pagewn keys, sometimes combined with the ctrl-alt-shift modifiers.
The hands off the middle row! Heresy!
As for the defaults, vanilla emacs is the worst text editor in existence, building your .emacs file is basically a rite of passage, not sure how to solve that problem, starter packs exist but come with their own problems as you say.
But ultimately it's a matter of trade-offs. You can choose to get up and running quickly with a simpler more modern tool, or you can go deep with emacs and hope it'll pay off. I've found that learning emacs has not only payed off the time investment for me, but the benefit is growing the more I use it. Yes, the first week was horrible, the first month was kind of difficult, the first year clumsy, but the next couple of years have given me an unbelievably powerful tool, and a sense of accomplishment for having mastered it's fundamentals. I recently picked up magit and the way I use git has changed now, I am absolutely better at VC now because of emacs. There is no price for that. All of that vastly outweighs any problem like being clunky in a modern environment, it just takes a while for the benefit to kick in. Will OS X even be around in 40 years? Who knows, emacs just might be tough.
1. As others have pointed out, Emacs shortcuts work everywhere. And if you really want those shortcuts, look into cua-mode, which is closer to what you're used to.
2. Yeah... that might be a legitimate issue for you.
3. Emacs isn't about the default settings: if you find them limiting or frustrating, change them! Emacs isn't about shaping yourself to fit it, it's about shaping it to fit you. The only thing that's just about mandatory is learning a little elisp.
If you don't know how to do something, emacswiki and the extensive documentation are good places to look.
(Also, macOS has some of Emacs' default keybindings like Ctrl-A, Ctrl-E, ... in all text editing widgets, which IMHO makes Emacs quite a nice fit on OS X in some ways.)
My crazy previous sentence intends to show the false dichotomy in your arguments.
People can use SublimeText everyday while also using Vim in remote SSH sessions, and I have seen many do precisely that. Others endure Notepad++ and seem happy doing it.
It is an AND world, not and OR world. Learning to use a tool doesn't make me forget the other tools.
Also, both these languages are perfectly fine. They are not closed down, belong to no single entity and can never be made obsolete by not providing more patches.
I see many projects with a similar public perception issues. Pages and blogs need to reflect their activities better.
Even Sublime 2 wasn't that bad you'd want Sublime 3. For heavy projects I use IntelliJ. I was happy to pay for Sublime. I remember switching from Textmate to Sublime because it had compelling arguments.
Sublime is the perfect editor between Notepad and IntelliJ. Anyway I hope this is just as good.
M-x zoneMore apps need boss mode though.
I use vim as editor for system files, but I only use the 1% of its capabilities I really need. All these shortcuts make me sick because I can't remember them and can't easily find them. That's also why I don't like Atom, sublime, Visual and all that kind of editors. I'll give a try to this Lime editor.
The best IDE around, in my humble opinion, is QtCreator because the interface is remarkably simple and intuitive. I regret no one tries to copycat this one.
I gave QtCreator a try just a couple of weeks ago actually. I wanted to give qml a go and expected this to be where it shined. But the create project dialog wouldn't fit on the screen and the create button wouldn't enable for some reason (possible something off screen).
This really reminds of using KDE3.x & QT in general a decade ago or so :)
Video demo: http://youtu.be/FTInd3H7Zec
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.
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.
I'd speculate the main reason people write things like that, and so prominently, is because they hope it will attract contributors who either already know that language or are enthusiastic enough about it to progress the project significantly.
Otherwise someone may just pass it over assuming it's another piece of junk written in <insert-your-least-favourite-language-here>.
For other projects (like this one) I find that the language can be a distraction from the actual value it provides.
[1] https://medium.com/@raphlinus/inside-the-fastest-font-render...
Additionally, on the positive side, some people want to contribute to a project and wish to do so in a certain language. This could be because it's their preferred language, or they may want to exercise a newer skillset or build a contribution portfolio in a new area.
The language doesn't matter much in a pre-compiled application, but when it's an open source application looking to gather and foster a community or build momentum, the language does matter.
Some things I found:
1. You have a much better chance of getting upvotes if you appeal to a popular technology. Had I not mentioned Meteor I suspect I would never have made it to the front page.
2. In my case, most of the initial interest came from those more interested in the underlying technology than the application.
3. I found it very difficult to market the project as an issue tracker as it was already established as a meteor project.
Could not get it to run. Broken with current meteor?
They don't, but they're not 'talking' to users with those statements. For Open Source projects getting contributors is just as important as getting users, and they care what language you're using. Especially on a site like this one there is a decent chance that you can reach people who also want to help out with the development.
Sublime Text was horrible in that it offered an easy refuge to many young and inexperienced people. But ultimately it was a closed source prison that they got pulled into. And yes, I'm a professional developer having founded multiple companies. I'm a capitalist, nothing wrong with selling software. However, having great tools that last a lifetime available is one of the most important point I learned and like to teach to my students (I'm a lecturer, too). Why lock yourself in? Just because it looks more shiny and is easier in the first week? That's a good reason to use many things, but not your primary driver as a professional software engineer.
Hooray for these new editors that look shiny and are open source. And then when the students ask how I did those crazy things in Emacs, they still get those huge eyes and want to gobble all the information in. This kind of curiousness happens rarely with people locked into proprietary systems.
In an open source project, it matters to potential contributors. It might matter to users in terms of what platforms it can be ported to - probably less these days, where "portable" means "runs on Windows, Mac, Linux", but still, it is not irrelevant.
You can write bad/poorly optimized code in any language. But its a lot harder to write polished, efficient, low consumption applications in an electron stack for some application types than it needs to be.
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 modifying it. Maybe this fragment can be improved.
The second half of the sentence actually gives me an idea what problem it is solving and why it exists:
> that aims to be a Free and open-source software successor to Sublime Text.
(Awesome!)
The second paragraph is also very interesting and draws my interest.
I love the "Roadmap" button, neat touch. It shows very clear goals and a reasonable amount of progress.
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 versions of them myself.
I honestly don't have enough to complain about with Sublime that would make switching worth that amount of effort.
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
From the activity graphs, it looks like development on Lime Text has stalled a little. There's some updates in the wiki entries, but not much more. Hopefully things pick up!
In relation to editors, I've been playing around with Spacemacs and evil mode enabled, but so far I haven't found the time to give it an honest chance as my daily editor.
I initially thought, did the author of Sublime open source his work like the author of Textmate? But no, it looks like this looks like an independent project, and since Sublime is still updated, can there be a successor yet?
Same thing is happening with programming languages. There is a new one everyday that doesn't offer anything better than what we had before. Everyone just has their eye on the shiny new toys I guess...
* Preempting the “then send a pull request”: sometimes the flaws are fundamental or otherwise unlikely to change, like VimL, Emacs’s keybindings, Sublime Text’s closed-sourcedness, Atom and VS Code’s Electron bloat…
Seriously though, we need more competition and innovation in text editors. Even Emacs isn't perfect.
My main reason for using Sublime over something like Atom is that Atom is a hog, both in the large (memory) and slow senses of the word.
But how on earth do I start using it? No download, no install, nothing! That is going to be a major hurdle to adoption.
Disclosure: I've worked with Jon previously