Lime Text: Open Source Sublime Text clone
limetext.org
limetext.org
Also, I think it's weird that the fact that it's made in Go is part of the pitch. I mean, unless I'm contributing... I don't care. You could write it in brainfuck if it does the job.
They did announced something recently, like getting ready for ST 4. And 3 is not even a major upgrade from ST2, IMHO.
Anyways, theres no satisfying HN. When Atom came out, the consensus was that they should've come out and said it was an ST clone upfront. Now someone does that and it seems the tide has changed.
While we're on Atom, since switching I've found its everything ST should've been. Its open source and has a huge community developing very useful plugins (not to mention, they're well integrated from a usability perspective - git/terminal status/linter/etc). Also, I have yet to run into a serious bug/versioning issue which ST plugins were rife with before I dropped it.
Not that it matters much, but it's actually $70 now: http://www.sublimetext.com/buy
Yeah, they do. It's very hard to do in both cases, for different reasons - licensing for Emacs, code quality/style for Vim - but it happens. For Emacs just read this: http://www.gnu.org/software/emacs/manual/html_node/emacs/Ant... and this: http://www.gnu.org/software/emacs/manual/html_node/elisp/Ant... (or look at normal changelog, but I kind of like this "backwards in time" format, it's fun :)) to get a feeling for what you'd miss by not doing a "major upgrade".
I understand software development isn't cheap but it's kind of annoying that $60 doesn't include free upgrades.
Expiration Date
Licenses purchased for Sublime Text 3 do not expire, however
an upgrade fee will be required for Sublime Text 4.
From a development standpoint it likely was. Doing a plug-in rewrite is a ton of work.
And how does that make a difference? You could already contribute plugins to both to add/remove/alter functionality, so other than a warm fuzzy feeling, what does Open Source add to your productivity?
I used closed and open source software. It just feels much better if I see a bug, fix it, place a pull request and be done with it, than discuss with some devs in a bug tracker if and when they want to fix a bug I hate.
It's no surprise that most open source software is clunky and hard to use whereas closed products always have that visual polish.
Creating a Pull Request doesn't mean that the developer of the open source project has to accept it verbatim if it doesn't fit with the 'vision.'
[Also, I'm pretty sure that the parent to your post was talking about bugs that probably don't involve visuals.]
And often big projects have, similar to closed source software, rather ugly workflows where you have to discuss stuff before you're assigned to a bug and then have to send it patches and what not.
A good review process is important or else everything ends in chaos.
A lot of open/free projects are indeed "hobby" projects (and not in a good way) -- but to claim that all of them are bad? Compared to what? The shareware scene from the 90s?
Closed products always have that visual polish
What makes you so sure of that?
> At work that makes little difference to me.
Clearly implying that Open Source is a productivity increase. I am asking why.
I'd put what you're saying in the "warm fuzzy feeling" department as in the real world the majority of developers, even if Sublime Text died, would just sit by patiently and wait for someone else to release a replacement. Most lack the skills, time, or both to develop a project like Sublime Text.
If something breaks or development stalls or he wants new features and the developer has abandoned the project he can then pick it up himself if he wants.
That said, I agree that just because people can contribute to software doesn't mean they will. I'm certainly guilty of just living with bugs or functionality gaps in open source software that I use, lazily waiting for someone else to address it the same way I would if it were something developed privately.
Open Source doesn't imply that there's a productivity gain. For obvious reasons I'm a lot more comfortable using OS tools at work.
The product itself may be relatively bug-free, but that is not really the issue. RHEL7Beta was relatively bug-free, but I would not advise you to use it for most purposes.
I think I'll do so now for exactly this reason.
It's ridiculous in my strong opinion.
This is like someone trying to get me to buy a domain on Godaddy just because I like to use Heroku for hosting. I don't use Paypal.
Alternative Payment Methods PayPal is currently the only way to purchase a license for Sublime Text. However, for most countries a PayPal account is not required; you can purchase as a guest using a credit card. Unfortunately, PayPal requires users in some countries, such as New Zealand, to create an account.
As for price, I was happy to pay for the editor, even though I use vim most of the time, I am happy to support modern editors and use them.
Its competition. Thats the market segment they are aiming to attract and serve. They aren't claiming to be Sublime Text, they are claiming they want to be better than it. Its the market leader in that area, and if that is the segment they are interested in serving, imho it wouldn't make sense to not compare themselves to Sublime Text.
> Also, I think it's weird that the fact that it's made in Go is part of the pitch. I mean, unless I'm contributing... I don't care.
Play the other side. You're interested in an open source alternative to Sublime Text, and you love working in Go. Is it relevant now? Because I'm willing to bet by its open source nature, they are as interested in attracting committers as they are users at this point.
Pretty close, calling your project Lime text is pretty sketchy IMHO.
> it wouldn't make sense to not compare themselves to Sublime Text
But they aren't comparing themselves, that would be a feature page showing how many features they have. Instead they are branding themselves in a very similar way.
Sure, but, they're using sublime text's brand to draw attention to their own project. If they called themselves, say, "Cherry edit" and just had a comparison matrix to sublime text without saying "we want to be sublime", I bet this wouldn't have made it to the front page. They're piggybacking off the other projects success by invoking its name and lineage, while positioning themselves as a competitor by undercutting the price (in this case: free).
That's what I mean. It's not illegal or whatever, it just feels like poor sportsmanship.
They aren't claiming to be associated with Sublime - they're saying that they're trying to make something _like_ Sublime. And that is actually a pretty good way to explain it. When I first found LimeText (about a year ago) I was searching for an "open source ST2 clone". I already knew that I wanted something like Sublime, I just wanted it to be open source so I could contribute to it. Having to compare the features of LimeText to the ubiquitous features of Sublime would have just made it harder for me to "get" what LimeText is.
> because he has the gall to charge $60
I don't think that the 60USD was a big deal. I was fine with that, I just wanted something that's open-source.
> weird that the fact that it's made in Go is part of the pitch
I think that the reason why is because LimeText is marketed towards people who want to contribute to their editor. Sublime is probably a more stable solution for people looking for something like Sublime, so right now the big feature is that it's open-source.
* Also, I should note that I've never used LimeText... I ended up switching to Atom instead. My primary experience with it is just finding it and evaluating it as an alternative to Sublime.
They use wordplay on the sublime editor to name themselves.
It's up to trademark lawyers to prove if the name is associated with Sublime Text or not.
It once again brings attention to the most important "bus factor" [0]
Apparently some people, still believe the theory that all you need to know about a product is on the price tag, which is absolutely false (e.g. emacs/vim have no price but are exceptional programmig editors, hardly matched by payware solutions).
Anyway, it's good to have choices.
IIRC -- and I was never a TM user but was following it from the outside -- search for a TM replacement started before the open-sourcing; once TM became popular, people started looking for a cross-platform equivalent (because even lots of people who are primarily OSX users don't do all their editing there) and as the perceptions was that development was stalling, an even more people were searching for alternatives. The open-sourcing was sometime after that.
I don't think ST has been adopted because it is payware (that is, I don't think a significant force in its adoption is a preference for paid over free software), I think its been widely adopted because its features well match what a lot of people are looking for in an editor, and they are willing to pay for it.
I understand the idea that "development may have stopped", but there are not any glaring bugs, sublime text 3 is super fast, and there is a huge community building sublime plugins.
The editor was built in such a way where it allows the entire community to keep moving it forward even if the original developer has moved onto other things, and I happen to think that is great.
I'm not sure that editors like vi and emacs receive regular updates. It seems that emacs releases can have up to 2 years between versions, and I can't find the last time that vi was updated. Those do have the advantage of being open sourced, but unless there are glaring holes in Sublime then I don't see this as a big problem.
Besides all that it DOES look as though there are plans for the future of Sublime as someone mentioned in a forum post on here. If it is true that development has been focused on improving the payment system for purchasing Sublime then I am all for that.
http://en.wikipedia.org/wiki/GNU_Emacs#Release_history
http://en.wikipedia.org/wiki/Vim_%28text_editor%29#Release_h...
In between major releases they have tons and tons of bug fixes (Vim probably has hundreds per release).
Editors can suffer a lot from code rot since they have to integrate with a lot of things. An Open Source version could be quite interesting from Sublime's community point of view. I don't know about the developer's income while this happens, though.
Honestly though. Emacs was first released almost half a century ago. Its core is fairly feature-complete. It doesn't need intense development and constant releases.
Besides, at least for Emacs, one of the main driving principles is for it to have a good & stable core, and have all the bells and whistles delivered via extensions and packages. And those extensions gets updated continuously. Often from git commit to git commit, depending on author.
When you have decades worth of customizations and ecosystem-code to consider, keeping the core stable is the only strategy you can possibly choose.
Your comparison isn't apples to oranges, it's 40 years old whisky to diet coke.
Edit: Half a century, not decade. Thanks dragonwriter.
Closer to half a century, which I guess reinforces your point.
I regularly have 15+ projects open, all of which I work on regularly, and I probably have 30+ projects that I work on regularly that I don't bother to keep open, simply because the window menu grows too long. I use the next/previous window commands to cycle, but sometimes I have so many projects open I have to use the window menu, which coincidentally seems to be randomly ordered, so it takes a long time, relatively speaking, to scan.
There is no way to quickly switch between per-window projects. I tried to write a plugin for this (giving you a cmd-P-style project switcher), but it turns out the API doesn't support switching windows; you can find a window, but focusing it doesn't do anything if it's not the current window (something I consider a bug, but the developer never responded to my bug report). You can't create new windows, either.
Some other things:
* Sublime is fast, but it could easily be faster. Large files are quite slow to open, even in ST3.
* The sidebar needs work. SidebarEnhancements is great, but not enough. There's no Git integration, for one. No mode flags. Renaming and moving files is cumbersome. No multiple selection.
* The global file search functionality is pretty bad. It opens up a new buffer, but it appends to the current one if there is one. You can only double-click on the match, not on the context lines. My wish list item is for the search results to be a live view into the matching files, so that I can actually edit within the results buffer.
* Package Control needs to be moved into the editor and become a first-class citizen. It's weird that it has to be added manually.
* Syntax highlighting per file-pattern, not extension. For example, .js.erb is an ERB template containing JavaScript, but there is no way to tell Sublime this; syntaxes can only be associated with the last extension.
* Lots of tiny things. For example, Sublime doesn't have a built-in way to filter a selection through a Unix command (eg., "sort"). Turns out process management in a plugin is awkward.
I could probably think of a bunch more.
> My wish list item is for the search results to be a live view into the matching files, so that I can actually edit within the results buffer.
There's a plugin[1] for that btw, but I'm not certain it's completely safe for use. Last time I checked you could only modify the search results once.
>Syntax highlighting per file-pattern, not extension.
Luckily, there's a plugin[2] for that too.
>Turns out process management in a plugin is awkward.
I've never had a problem with that. Are you new to Python?
[1]: https://sublime.wbond.net/packages/FindResultsApplyChanges [2]: https://sublime.wbond.net/packages/ApplySyntax
I'm not at all new to Python. Forking processes is simple enough, the problem is about how Sublime manages the plugin thread; you have to jump through hoops with sublime.set_timeout() etc. At the time, I was having huge issues waiting for a process and then afterwards interacting with the editor; it seemed buggy. I'm sure it's possible given enough trial and error.
I don't follow your argument here. To qualify as "Open Source" rather than "source available", people have to be free to modify and redistribute the source code. So even if you charge for a license, there's nothing to stop the first licensee redistributing for free. In other words, if it's open source, people can use the program for free without violating your license.
Seems to work for XChat: http://en.wikipedia.org/wiki/XChat#Shareware_controversy
http://opensource.org/osd-annotated
> The program must include source code, and must allow distribution in source code as well as compiled form.
...
> The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
...
> The license must explicitly permit distribution of software built from modified source code.
And "physical things stopping you" from running/distributing software are pretty much irrelevant/nonexistent always, this is all about legal restrictions and licensing, not physical things.
Or you're saying it could be considered an open source license if it allowed people to distribute, but not run, executable binaries? Yeah, I don't think most people would consider that open source.
"...but if you want to execute a compiled result of that source code I can still ask you to pay me for it."
It's quite popular in the Android space, where many publish source code on github but distribute free software binaries on Play Store for pay. Somehow it doesn't seem to have catched on for desktop software, although I suspect some of the pay-for-support free software is in fact organizations who aren't really interested in the support agreements per se.
I wonder what features makes sublime text so much valuable...
* edited to remove the word "most" which seems to be upsetting some people.
WHAT? Where?
UK, USA, Canada, Australia, New Zealand, Netherlands, Germany, Austria, all of Scandinavia
Much sad :(
While my boss charges something like EUR100 an hour, I make less than 25% of that (after taxes).
O.t.o.h.: The salary is quite competitive around here (41k EUR a year, 40hrs/wk, 25 days off)
Edit: Note that this 41k/year pretax salary in The Netherlands does not include the contributions your employer makes for you to your social security/pension/disability insurance, etc. That being said, even after all those it's not yet near 60 bucks an hour.
https://www.google.nl/webhp?sourceid=chrome-instant&ion=1&es...
Outsourced projects have a strong tendency to either completely go down in flames, or end up being rewritten (if you're smart about it) or "fixed" (if you're stupid about it and want to spend ten times as much) by the guys making $240k.
So it more than pays for itself every 2 days, and makes working more enjoyable. I'd happily pay more than $60 for it.
For instance, I've probably sunk $800 into my current editor over the years. It's been completely worth it, and I don't regret a single penny.
Another tool (for visual diffing) was about $300, 15 years or so ago. Totally worth it; it's paid for itself many times over.
In both cases the open source alternatives were awkward and borderline broken. Sure, I could have saved a few bucks by using them, or even spent some time improving them, but it's just not worth my time. I have other things to do.
Agreed that Sublime Text looks like abandonware now. It's a fine editor (not great), and the price seems okay, but I'm guessing there will be a mass exodus when ST 3.0 turns out to be not much better than previous versions.
It hasn't been updated in quite some time, but it's a very capable editor, and many of the heavies I've worked with in the past decade or so have also been power-users of it.
Epsilon is arguably more abandonware-like than Sublime Text, but it's also a much more mature product (with way better documentation). I'd love to have some new features (multi-window editing would be great, and multi-selections, and support for collapsing regions of text), but on the whole I'm happy with it.
I remember in the 90's, the big editors Visual SlickEdit and BBEdit were like $200 each!
It would be excellent if they were compatible with Lime...
The best alternative I've seen is Adobe Brackets (http://brackets.io/). This is Adobe's IDE that gets regular builds and is essentially the nightly build of their new Edge Code IDE (https://creative.adobe.com/products/code). The newest plugins come out on Brackets first, then make their way to Edge.
The best thing about Brackets is its built in HTML,JS and CSS so it opens up a huge development community for plugins.
Interesting that WebStorm is only $49.99 for a single license and $29.99 to renew versus ST2 is $70 for a single license and the upgrade cost I believe is $70 as well?
Emacs is everywhere. Windows. Linux. GUIed. And in a terminal where I've SSHed into a remote host.
TextMate? Nope. Sublime text? Nope. Atom? Nope. LightTable? No chance.
These modern GUI-only editors is IMO a major step back considering the Unix-y audience they are targeting: Any decent Unix-editor needs to work on my console. No exceptions.
Not everyone feels that way. For example, I used Emacs in text mode for over 15 years, but now that I have tried editing text in a GUI, I do not ever want to go back.
Also, network access isn't equivalent to console-accessible for quite a few use cases--fixing networking on the target box for starters.
Also, you can and should support / give some money to open source developers as well.
For me UI is almost as important as the engine. I'm a very clean/minimalist/organized person and if the software (or text editor in this case) does not, or cannot reflect that then there will be issues.
There's a rich history of piggybacking on dead software, and I (and many others) clicked this link because of that piggybacking.
I completely support and admire someone who is trying to further the development of Sublime without having the original code base.
This isn't correct, at least according to the author. This was posted in the ST forum on Mar. 18, 2014 [1]:
"From the Sublime office: We are not selling to Github, we are not stopping development of Sublime. As noted by another poster, this is effectively a one man band (I'm here to answer sales questions, process your refunds and get the mail so Jon doesn't have to). The past few months of silence on the development front have been a combination of boring back end work (taxes, new payment platform) as well as a break for the man driving this whole operation. No, we don't currently have a loud internet presence, which is can be an understandable cause for concern-something we intend to address once we move into the production version of 3. There is a vision for continued growth and development, there is momentum behind Sublime Text; it is not dead, just slow.
I'm happy to field any specific questions you might have about the Sublime's future: sales@sublimetext.com."
[1]: https://www.sublimetext.com/forum/viewtopic.php?f=2&t=15477&...
No one has to "actively develop it". It's a fully capable editor. It has a great plugin framework and ecosystem. Pending some incompatible OS change, I can use it for the next 30 years (using ST-3 from the early alphas, and it has been rock solid).
For comparison, I also use Vim, and it's not like I use any "new features" in Vim or anything. The most "current" features I use in it are like 10-15 years old.
People seem to forget this quite quickly, but what else is needed in ST3 right now? Very little in my day-to-day experience that isn't either solved via a plugin, or mostly trivial. I'd prefer a much more stable piece of software rather than one that's having upgrades thrown at it every month to maintain an 'actively developed' project status.
The only features I'd really love to add to TextMate are the rmate remote launching feature (which didn't work for me when I tried TextMate 2 a couple of months ago) and syntax highlighting for Perl 6 (which as far as I know no editor has yet).
You mean, besides standard vim 7.3? Also, here's[1] an emacs mode.
Lots of people thought editors were "fully capable" before the "go-to any symbol" functionality was introduced (possibly by Sublime). Now they can't live without it.
But besides all that, Sublime has lots of bugs that impact daily work. If it were in bug-fix mode, where plugins were adding new features, that would be fine. That's not the case.
Well, most people don't update their editor that often. People use Vim and Emacs, even decade old versions of them. Adding plugins, yes, that happens (again, not all the time, except for fiddly people like us I guess). But ST has a fully capable plugin system.
>Lots of people thought editors were "fully capable" before the "go-to any symbol" functionality was introduced (possibly by Sublime). Now they can't live without it
Well, yes, ST3 added that, and I know about it, and I seldom use it. On the other hand, that doesn't mean if I a new feature I like in Emacs or some other editor, I'll change editors just like that.
One of the most impressive goals on the roadmap is to implement a terminal frontend as well as a QT frontend, which I'm quite excited to see.
Arch users can install Lime from AUR: https://aur.archlinux.org/packages/lime-git/
I'm also interested to see this. I've said before that I think Go could be a really interesting language to develop GUI software in, however the existing QML package is "alpha quality". I've considered writing GUI software in Go, but at this point I think it would be a mistake given that most, if not all, GUI bindings in Go (and please correct me if I'm wrong) are considered experimental or alpha quality. In theory this will mean the author's progress will be somewhat dependent on the go-qml project, and may involve fixing bugs upstream.
If it were me, I would probably choose another language just based on the maturity of Go's current GUI bindings.
If that isn't right, there must be untold frustrations in the path of using this editor for me that I don't care to discover.
Why not use something in a terminal with almost no interface then, say emacs or vi. All they require you to have is a mental model of what you are working on which you should have anyway/
(require 'multiple-cursors) (global-unset-key (kbd "M-<down-mouse-1>")) (global-set-key (kbd "M-<mouse-1>") 'mc/add-cursor-on-click)
* Tree view
* Split window with synchronized views when showing the same file
* Regex search over file or selection, results can be turned into multicursors (!)
* Regex search over multiple files or directories
* Multicursors at each line for a selection
* Auto-update of views when file underneath changes (editor should ask what to do in case of edits)
I'm sure all of this can be achieved with Emacs - my question is: How long will it take me to set up? Will the result be portable, e.g. can I copy some config file unto any POSIX machine and use it from there in an ssh terminal? That last point would be the main draw for me on why to switch to Emacs, since with Sublime I have to mount the drives (with Expandrive) which works well for the essential things, however there are details like the treeview not updating in that case.
> Tree View
This i fully understand (and exisits in emacs) but I think not necessary either for my workflow. A treeview does already exist in a format called folders and files ;) I prefer to know the structure of the directories I'm working in and rarely require a reference to them visually
> Split window with synchronized views when showing the same file
I do too and this is a very basic emacs feature
> Regex
Emacs has a massive number of regex and non regex search options. Though usually i simply use Ctrl-Z; grep; fg, which is less efficient but fits my mental model better.
But ctrl-h a <regex> has ~ 34 commands on my machine. Including things like dired-do-isearch-regexp
> Multicursors at each line for a selection
No idea what this means sadly!
> Auto-update of views when file underneath changes (editor should ask what to do in case of edits)
I doubt any editor handles this stuff as well as emacs and is invoked in my environments daily.
Apart from multicursor stuff (that i do not see the point of for my workflow) everything you mention is a very very old basic emacs feature.
And sorry, but if you don't know about multicursors, I'm not sure whether you get what I mean with "Regex search over file or selection, results can be turned into multicursors". Just have a look at the animations in above URL. Can emacs do that without turning this into a big modding project?
gif2: I typically do this kind of stuff with CUA-rectangles: http://trey-jackson.blogspot.no/2008/10/emacs-tip-26-cua-mod... Looks about the same.
gif3: looks like M-x, though there are newer alternatives to M-x like smex that do more fancy matching: http://www.emacswiki.org/emacs/Smex I feel like I'm faster with plain M-x, though haven't really given smex much of a chance
gif4: There's a million packages that do this in various different ways (using recent files, VC-tracked files, bookmarks, Meta-dot with TAGS or parsers to go from symbols to definitions, etc.). I suppose people have different preferences for how to navigate quickly to other files.
gif5: M-x occur is built-in. There's also multi-occur to show over several files, or occur-edit to edit directly from the list of hits without going into the file itself, etc.
gif6: regex-replace also has been built-in forever, mc/mark-all-in-region-regexp seems to match this UI more closely though.
But I'm sure lots of the newer Emacs packages have been inspired by Sublime or TextMate (or vim!) :-)
My .emacs is portable and I use it across Linux, OS X and Windows. Of course it's based on my personal preferences (vim emulation anyone?) and I seldom see people sharing the same config except maybe Bozhidar's Emacs prelude https://github.com/bbatsov/prelude
Regex search over file or selection, results can be turned into multicursors (!)
? GP described 'require multicursors', which I presume is an emacs package. Does it come with regex search integration?
M-x mc/mark-all-in-region-regexp
though I just installed multiple-cursors now, have never tried Sublime so no idea what the deal is with these multiple cursors
Love the problem space. Look around. Listen to input from good counsellors, ignore the negative "it already exists your reinventing the wheel" and the "i'll try it when it has x".
Here's what the author got as initial feedback. If he had let that negativity get to him we wouldn't have sublime. http://www.sublimetext.com/blog/articles/anatomy-of-a-next-g...
I suggest a high pass filter on comments on your current project: smart people with helpful comments know how to give valuable feedback to even the worst idea without negativity.
Cheers, and march on! GLTA F
John, the author, has been clear in the past that if for some reason he no longer wants to continue developing Sublime Text, he'd open-source it so it wouldn't rot in the bit graveyard.
Yes, GIMP rides the coattails of Photoshop, and LibreOffice rides the coattails of Microsoft Office; but these are commercial applications that are supported and paid for by consumers. Sublime Text is optional. Sublime Text is free, but you can pay for it - if you like.
Change the tag-line and keep the name.
I'm also curious about this vim reimplementation some guys are working on. I'll go and check that out right now!
This is a deal breaker for an IDE, IMHO. Then again, it is a really young editor and has a lot of room to grow and mature. So, here's to both Lime Text & Atom. May our text processing future be bright!
http://blog.atom.io/2014/07/02/moving-atom-to-react.html
Beyond that, there are also more performance optimizations coming:
https://github.com/atom/atom/pull/3154
The only two things I miss from Sublime are "find in project" and "go to symbol in project". Atom's implementations of those need some work. But everything else is as good or better than Sublime. And it's really easy to contribute and get pull requests merged.
As far as I can tell from watching development, GitHub has at least 4 full-time engineers working on Atom.
You can do pretty much any UI you can imagine using a website in some way and Atom allows you to do exactly that. You can modify the entire UI and this is what I was always missing in ST: The ability to modify the UI more extensivly.
Sadly, this all leads to the very downside that everyone knows: Performance. Computers will eventually get to the point where Atom feels as fast as Sublime, because 1) the coding was improved and more significantly, and 2) CPUs will get good enough for Atom that a human can't see differences between Atom and ST's performance, despite ST being way faster still. It's always been like that.
In fact, why does Lime reference Sublime Text at all?
- Compatible with Textmate color schemes (which is what ST is using) - Compatible with Textmate syntax definitions (which again is what ST is using) - Compatible with Textmate snippets - Compatible with Sublime Text’s python plugin API. I’ll probably never implement this 100%, only the api bits I need for the plugins I use. - Compatible with Sublime Text’s keybindings and settings (think most of it is working) - Compatible with Sublime Text snippets - Sublime Text’s Goto anything panel
Personally, I pick a single text editor and use it for all my plain text editing needs.
I don't print very often, but when I do, I do it for a reason. Just the other day, I was creating some offline study information for my child. Printing was my only option.
I was editing away in Sublime and then when I went to print, I opened up the File menu and looked a second before I remembered... "Oh yeah, this application knows better than I do about my need to print". Muttering to myself, I copy/pasted the document into Word and continued on my way.
Personally I am using Sublime still but the next time I have to pay for a license won't be for sublime. Most likely going the IntelliJ Idea route.
Name for Lime Text is shameless :-) Come on you could have come up with something original !
You know software developers are dirt poor ( or really cheap ) when they cannot shell out 60 dollars for a piece of software they use everyday. Sublime puts so many expensive IDEs to shame and it costs a fraction ( as a donation ) and people still are up in arms about it.
It is not about cost. It is about freedom. And there is no way I'm giving someone money to take away my software freedoms if I have an alternative. And I will always give the free alternative the money I would have spent on the proprietary one.
One problem that raise here is that we haven't find a way to ensure that open source projects can bring an incomes to their maintainers, even if there is many users.
Yes, they have feature and focus differences (which is why I say Atom and LT aren't clones of ST), and one of those is Light Table's having inline evaluation as a central feature.
there are lot of free options too, like NetBeans
(This is an Open Source koan)