As much as this is refreshing, Sublime just works though.
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.
Do any of these text editors you mention include a screensaver? I was just trying BREEZE for MS-DOS today and found that feature really appealing. I came back to my desk and the entire UI had just vanished and turned into a field of twinkling stars. I would love it if one of my more modern text editors did that.
Does anyone use desktop screen savers anymore? It used to be amazing how much customization some people put into to something that only appeared when they weren't using it.
VS Code is great. But if I start using VS Code, it's because I want more than Sublime, and so I end up just doing it in IntelliJ because, to me, it's the best there is.
> 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 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.
I also want to know why it's better than the myriad of other text editors out there. Evaluating a text editor and it's extensibility is a time consuming task.
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 versions of them myself.
I honestly don't have enough to complain about with Sublime that would make switching worth that amount of effort.
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.
That's understandable, but maddening. Why are scripts that control/operate with an editor limited to the particular choice of the editor? Back in the Amiga days, useful things had an ARexx port, and while that meant most scripting was done in ARexx itself anything could send commands and get information back via those ports. You could write scripts in assembler, BASIC, or whatever variant language you wanted.
Looks interesting. I'd recommend packaging some installation options instead of just source. I plan to check it out later, but it would sit higher on my queue if it were easier to try out.
Textmate, Atom and Sublime were been successful editors, I've seen limeeditor since 2008 or something they've been there for windows only, and now trying to do with cross platform, very interesting.... the roadmap looks promising too. Hope we wil be able to get an nice editor soon
Funny - Sublime has been taking a pounding from all angles over the years, but still seems to be bouncing back off the ropes and swinging hard.
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? ;)
It's hard for these other Electron based editors to completely replace Sublime when they are so much slower. People say that they don't notice how slow Atom or VS Code are, but try running them on a 5+ year old laptop like mine.
I use VS Code on an x220 every day. If an old machine is the only thing keeping you stuck with Sublime you should invest in a new machine. Hardware is cheap compared to productivity gains.
If you took some time to check the commit histories of the two most important repositories (backend and lime-qml), you'd see that they both have commits as recently as August.
Blog and website activity are not always indicative of project activity.
Really, this is more like [NeoVim](https://github.com/neovim/neovim), in the way it's structured and with its aim to rebuild its namesake in a modular fashion with swappable UIs.
As an old prgrammer feeling the limit of neuron counts and possible premise of alzheimer, I avoid tools where you have to know by hart all the commands or have to read a long help text to find what you need.
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.
Vim is a language, not a bunch of commands to remember. A sufficient vim user would probably be unable to tell you how exactly they accomplished something.
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).
Something about the phrase "Successor to Sublime" rubs me the wrong way. It's condescending and misleading.
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?
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.
Yet another with a client server architecture. It makes no sense in a desktop application to add the performance overhead of IPC and serialization to every user interaction.
> even if the performance is not noticeable it's a waste of cpu cycles.
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.
It's important to note that here the client server architecture is asynchronous and multiple.
This allows it to actually decouple slow interactions as auto-completion from things that need low latency such as typing.
You actually see this in many IDEs that more features make editing feel more sluggish. This shouldn't happen with this structure.
Is auto completion really useful, if it's a lot slower than the rest of the program? Maybe if a part is too slow, you should either optimize it or get rid of it?
Well, considering that as far as developer tools are concerned many of the best sellers are IDEs with Intellisense (intelligent code completion, based on syntax and semantics)...
Sometimes you want the autocompletion, sometimes you don't. You can do it in synchronous style, where you have 2 choices: a) delay the typing when the user doesn't care about the autocomp, b) require an extra action to activate autocomp when the user wants it.
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.
I'd take the overhead of a client-server architecture over the overhead of rendering the whole UI in HTML (electron apps) any time.
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.
Serialization alone is like, at least one order of magnitude slower than dynamic typing, and IPC has other os-specific overheads on top of that. Remote calls are so costly the whole architecture of a system has to be designed with them in mind.
I was 100% in your boat after experiencing Atom. I have a 8 year old re-purposed Linux box (OpenSUSE) for work. That took a LONG time to be okay with our Windows based IT Department.
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.
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...
-most of the bug reports I've done in my life is for atom and atom-related extensions - they're the most buggy softwares I've ever used. Btw non of the issues got a fix...
-can't handle large files and slower than sublime/vim/emacs etc.
-weak dev community
-terrible ram/vcard usage, unusable in a virtualbox
Honestly I don't get the Atom hate. It's a great editor.
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.
Let me know when this distinction is anything other than pedantry.
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.
> 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.
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.
> For 99% of projects it's an excellent, flexible tool.
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.
I just want to be able to look at the first 10 lines of a 15MB JSON I downloaded of the internet without having the entire application crash. It doesn't seem like too much to ask. There's a big difference between asking for a 15MB file and a 500MB file. 15MB is a pretty reasonable size for a text editor to be able to open without crashing, IMO. Unfortunately, I have to peek at those in Vim instead. Nothing wrong with Vim, but I hate having to switch editors to look at one file.
I don't know now what goes into these apps or why newer apps can't handle it but I still keep TextWrangler around for huge files. It's not really a "modern" editor I guess but it screams.
Last time I checked (I might be wrong), Atom didn't have default behavior of auto save and it made me to lose some work. Not that I am saying that this can't be the default behavior but that expectation should be cleared to the users.
Though it is not too much to ask for to be able to edit large files. 30MB should easily fit in memory, even with metadata like syntax highlighting. And if it really doesn't fit, only load a portion of the file into memory (maybe scan the whole file for newlines once) - that was a solved problem already 20 years ago.
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.
> 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.
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?
>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.
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.
- ELECTRON.
I just cannot get over it. Tried VSCode few days ago, it is great, much better than Atom, but still not there. There is nothing that Atom does better than Emacs, it looks better only, but that's not the point. I find Atom to be more WebDev and Fronted Dev oriented editor.
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.
The second half of that line seemed to be alluding to something else. I'm not saying it's fast, but I've never encountered it's speed being a problem in practice.
I just want to say that it's likely not the amount of plugins it's the weight each have, likely you have a few heavy ones causing your boot to be slow. I use ~20 plugins and startup time is still under a second when opening a 35000 line file, try using --startuptime
That sounds like an issue with specific plugins not loading on demand. Though it's not always avoidable, like when you open vim with specific files which triggers the lazy loading.
The effect can be seen in the highlighter sometimes. If there are too many rules to parse the file correctly, sometimes it will parse just a few lines before the screen. This can randomly result in the first line being highlighted like it's a part of some string. And the whole highlighter/parser is a really bizarre world of regexes and almost-tokens.
i've only flirted with vim, but my experience is that while it was admirably fast on medium and small files, it fell over completely on large files or even normal-sized files with long lines.
Isn't the emacs core (excluding packages) known to be very stable? At least I've only had one crash in a year or so, most likely due to some package misbehaving.
Emacs has long been riddled with bugs that can cause daemonized emacs to crash if the display disconnects (yes, even with the Lucid toolkit). term-mode is hacks on hacks on hacks; and slow ones at that. There's a bug in Emacs 24's sh-mode that can cause it to deadlock if you move the point to a wrong place in an incomplete if/while/for block start (IDK if it's fixed in Emacs 25). All point-releases of Emacs 24 shipped with a TRAMP mode with broken /sudo:: that can cause /dev/null to become an ordinary file, causing the entire OS to slowly and mysteriously break (Fun on servers! Fixed in Emacs 25). I have a collection of emacs core dumps on one of my servers (where I use it like screen/tmux) that I have yet to try to diagnose.
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?
Emacs 19 was a model of low-defect, stable software, and my experiences reinforced that widespread notion. Over time and subsequent major releases, it grew and grew, and the complexity got too big to perform adequate QA, now nearing the point of unmaintainability. I also love it and use it daily, but I really wish the developers would show some restraint when considering whether to add new features (i.e., packages).
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.
I'd argue that in 2016 a well designed system has a way to make sure that its extensions can't slow it down, can't bring it down and can't step on each other's toes.
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 :)
Well, I'm sure you'd concede that read-file-name is part of Emacs's core, and its been buggy for years. (Have not checked to see yet if it is still buggy in version 25.) Specifically, if the current buffer is visiting an image file, pressing down arrow during a read-file-name will often cause read-file-name to try to insert the whole image as a text string into the minibuffer after the prompt, which will make Emacs unresponsive for a few seconds and will sometimes crash Emacs.
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.)
> That said, I haven't found anything worth leaving Emacs for.
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.
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.
Emacs is still the best for most of that. Text display works most of the time (although it sucks), there are intelligent modes that aren't a pile of half-correct regex hacks (semantic, most of the modes for the Lisp family), and the base is fairly stable (some of the packages may not be). OTOH, it could be better.
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.
Given that the goal for the plugins API is "I’ll probably never implement this 100%, only the api bits I need for the plugins I use." [0] I don't see this getting traction. Piggypacking off an existing ecosystem is a great way to bootstrap a project but so long as it's wack-a-mole to discover if all your plugins work, this remains a pet project in my mind.
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.
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.
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>.
If the language is relevant to the innovation then I think it's fine to mention it. For example, a font renderer in Rust that is faster than FreeType[1]. There is also Servo[2], which is a web rendering engine that will be able to eliminate memory corruption bugs.
For other projects (like this one) I find that the language can be a distraction from the actual value it provides.
Some people avoid projects because of the language it's developed in, unfair as it may seem. This could be because they've used a similar project with performance or maintainability issues written in some other language. That could be because the project itself, or it might be that the language isn't particularly suited to the problem space. I know of a few projects for which I'm personally awaiting more performant alternatives. Others aren't particularly fond of the package managers and build systems that accompany certain languages. And, at the end of a day, the bias could be even less reasonable than that. Language bias is a unfortunate reality, but as long as it doesn't start a flamewar, it's not a big issue.
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.
I've been guilty of this. When meteor.js was new, I made an issue tracker, and proudly submitted it to HN with a title something like "Issue tracker made with Meteor".
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.
Why do your users care about your implementation language?
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.
The headline on the Landing Page says "Elegant Free Open-Source". I for one applaud these great selling propositions. And I'm speaking after using Emacs and VIM for 15 years.
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.
> Why do your users care about your implementation language?
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.
at this point, its one of the first things I check for if it isn't declared publicly. Why? because I'm sick of every application being written in js/electron, even when it's a huge hinderance to performance.
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.
Don't enough text-editors exists, things are getting outta control now. Vim, Emacs, Sublime, Atom, Lime... Shit, pick one of the four and be happy damn.
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...
You’re not obligated to use it. All existing editors (and languages) also have their flaws* and room for improvement, and I’m happy to see people try.
* 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…
To be fair, this was back in 2014 when people thought sublime was dead and abandoned by Jon.
However now that's not the case and the dev team are rolling out releases again, and expect a stable v3 to come out soon
I'm a very happy Sublime Text user, but I wish it were open source. I don't mind paying, since I get so much value out of it. If it were open, others could make contributions, and I wouldn't have concerns of my favorite editor dying off.
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.
Being open source has really small relation to project not dying off. In your own example Lime Text stalled even tho its open sourced, same with textmate which went open source.
The headline on the Landing Page says "Elegant Free Open-Source". I for one applaud these great selling propositions.
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.
Last I checked, Sublime is easily extensible with Python. What is this "lock in" you speak of? What "prison"? This reads like FSF.org hyperbole.
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.
Good luck my good friend with having tied your professional fortune to a small company that you are not affiliated with. This is not politics, this is simply dangerous and I do feel that way every time I see someone with a copy of Sublime. Since I'm a lecturer, I see this issue of lock-in and easy vs. simple/powerful a lot. I'm not taking this lightly, I want the best for my fellow professionals that are just too young to know better. You personally, might be older and more experienced, and I do not have a grudge with your opinion. I was simply stating mine for the reasons given without trying to step on your foot.
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.
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.
VIM's modal editing isn't remotely simple. There is a huge language to learn, and most keys do not form useful patterns which are easy to remember.
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).
Well, to make a long story and potential flame war short: My original post was not about VIM or Emacs. It was stating happiness about an editor (Lime) that tries to be easy to get started, yet is open source.
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.)
> Good luck my good friend with having tied your professional fortune to a small company that you are not affiliated with. This is not politics, this is simply dangerous and I do feel that way every time I see someone with a copy of Sublime.
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.
> 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.
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.
I concur. That's why the only good thing that I said about VIM is the modal editing which is the most pleasing and efficient mode of editing text that I have ever seen.
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.
> Good luck my good friend with having tied your professional fortune to a small company that you are not affiliated with
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.
That's just it - I've done nothing of the sort. Sublime has no "unique" features that don't have equivalents in form and function on other editors.
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.
"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."
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.
> 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…
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.
The problem with Emacs and vim, to me, is that they don't fit in.
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?
My post wasn't to be about Emacs, but let's give it a try. I'm happy to help.
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 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^^
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.
Emacs isn't trying to be special by having it's own keybindings, it's just that it's the same age as Apple the company(1976). Most editors back then were line editors, meaning you would give it a command to change a line, then you would ask it to print the line you just edited so you can see what you did. So yes, it's annoying to new users, but the fact that we have a system that's had 40 years of thought and effort put into it is pretty cool. I'll likely be using it until the end of my career(hopefully many decades from now) or until we stop using keyboards to program these damn machines. I think it's absolutely amazing that a system can survive for that long and have such a long future ahead of it and not because it's parasitic and it's too expensive to get rid of it like most legacy systems, but because it's actually still useful? That's a rare thing.
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.
As an emacs user, I can see that. Allow me to counter:
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.
IIRC, Aquamacs tries to remedy some of these problems for Mac users. I don't how how well, though. :-/
(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.)
Why lock yourself into learning Spanish if you already can do everything with English? /s
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.
Well, I'd learn Spanish precisely, because you cannot do everything in English.
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 am afraid this is project is stalling. I would like open source alternative to Sublime. I use Emacs as of now, but it is funny how so many years down the line, we can't make good, robust editor that is focused on performance. Sure eye candy should be present in some degree (I am bitch about colors and nice UI, since I spend a lot of time in it, I like to make it look cool to me, but I always put performance and function on first place). Xi looks like it has potential, but it is pretty early in development. I just hope Ralf sticks to it, and in few years I think we will have great editor, with right technology, right philosophy and hopefully right community.
185 comments
[ 4.6 ms ] story [ 271 ms ] threadhttps://github.com/limetext/backend
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.
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.
More apps need boss mode though.
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
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.
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
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?
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 :)
-runs on linux and mac with problems, barely usable on windows
-keyboard mapping issues on various non-US keyboards
-ridiculously unextensible - coffeescript? really?
-most of the bug reports I've done in my life is for atom and atom-related extensions - they're the most buggy softwares I've ever used. Btw non of the issues got a fix...
-can't handle large files and slower than sublime/vim/emacs etc.
-weak dev community
-terrible ram/vcard usage, unusable in a virtualbox
+some themes looks nice on it
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.
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
tail — https://linux.die.net/man/1/tail
less — https://linux.die.net/man/1/less
i mean we're talking about opening a file that is 1% of typical system memory.
(1) https://en.wikipedia.org/wiki/Bang_snaps
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.
[0] https://github.com/limetext/lime/wiki/Goals
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...
[2] https://servo.org
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.
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.
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.
But how on earth do I start using it? No download, no install, nothing! That is going to be a major hurdle to adoption.
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.
[1] https://forum.sublimetext.com/t/whats-happening/139/9
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.
https://news.ycombinator.com/item?id=8196245