Sublime Text 3.0
sublimetext.com
sublimetext.com
I use packages from ST almost every day and plus I wouldn't have gotten my first job without Will (thanks for hiring me even after seeing all that terrible code I wrote), so I can actually say my life would be a lot different without his influence. I'm really happy he's officially part of the team.
[0] https://packagecontrol.io/
[1] https://www.sublimetext.com/blog/articles/sublime-text-3-bui...
https://github.com/jisaacks/GitGutter
Doesn't even appear in the installable list now. Hopefully he'll get some of these hickups with package manager sorted.
This update appears to have broken a lot of plugins.
Package Control is open source and contributions are welcome! We finally get to rip out support for ST2 and Python 2.6 now also!
https://github.com/jisaacks/GitGutter/issues/444
It was still installed... but broken.
- It's fast and responsive, can handle large files and personally I've never seen it leaking memory or crashing
- Love the goto anything and command palette, brilliant
- Text editing is great and can be easily enhanced with existing plugins
- Theming is great
- Project handling is a bit weird, but once you get the hang of it it's fantastic
I don't do use IDE-like features (auto-complete, linting, compiling, etc.) nor integration features (version control for example) so I can't say how it fares in that aspect.
Recently I tried VSCode and Atom. They are portable and feature rich out of the box, but God are they slow and memory hungry. I can definitely see the appeal for web devs but it doesn't work for me, I value responsiveness above all else (that's the main reason I avoid dedicated IDEs)
With this package, you can set Sublime to be your git editor like this:
$ cat ~/.gitconfig
[core]
editor = subl -w
...As far as git is concerned, I use it from the command line an cannot understand why anyone would want to interact with git from VSCode or any other text editor.
That said, and I hate to be this guy (not really), but... Emacs?
* Performance: Acceptable on modern day
* Goto Anything: Helm/Projectile, command palette = M-x
* Text Editing: It is what emacs does best as a program
* Themes: Yes
* Project Handling: Projectile
* IDE Features: These exist
* Source Control Integration: Many people use emacs purely because of Magit, it is a great git UI that people won't know about in general because it is runs on emacs
I copy my ~/.emacs.d to a server, literally my whole environment minus some tty nuisances just works. Everything. All my package versions. Emacs is stable enough that not many things break between big versions 23/24/25.
There are two areas ST wins: Out of the box configuration and performance on very big things. It is true the learning curve to settle all of these features I am mentioning is non-trivial, but Emacs is open source and, like I mentioned, very stable. It has gotten enough right in its initial concept that it will always be a fine environment to mangle up some text in files into whatever you want.
This brings me to my next point, there is nothing really new under the sun regarding text editing. Atom/VS Code/Eclipse/IntelliJ/Emacs -- you want to edit a bunch of files in a directory structure, navigate quickly and easily between files and get context important information about the code. Everything else is just flavors of those same chores, often specialized to a few programming languages or whatever new things are popular at the time (JavaScript / Can we build an editor in JavaScript).
I have seen very little innovation in the field of text editing. Light table was interesting, and its no surprise it is very Clojure/Lisp oriented. I am in a giant lisp machine when editing code in emacs, I can whack out a lisp expression anywhere and emacs will faithfully evaluate it for me.
Next point: If you work in a language or big project you need a way to navigate and generate lots of boiler plate in some languages (Java). IDEs help there, but...
Final point: The speed with which we write text as programmers is not the limiting factor of how much software we can produce and never has been.
My conclusion was to invest in one editor that has been around a long time and just not worry too much about it. I can use emacs in 20 years probably. Who knows about atom or vs code or whatever. So it isn't a pro emacs, you should use emacs reply to you, but that over the long run, using the same system to edit text is probably worth it. Stick with one thing and ignore everything else unless you are forced to use some IDE, and even then really try to avoid it. Even then I am pretty sure I could do my job with Gedit or Notepad without much of a productivity hit.
edit: formatting
But for many people, the initial learning curve just isn't worth it. Sublime, Atom and VS Code are all very popular because you just install them and start coding.
I'd love to see someone shake up the space with a "modern" take on emacs and vim: native, fast, powerful, very configurable, terminal based, but also with a conscious view on the initial learning curve and out of the box usefulness.
I run emacs over ssh/tmux. I love it, emacs never shuts down, all my shells run through emacs as well. I can use any machine with my sshkey and be back to work immediately. I can increase the size of the machine, have public access to my dev box if needed. If I have a bad internet connection it doesnt matter since its just sending low bandwidth over ssh. All the real bandwidth comes from DigitalOcean and is super fast.
I would generally agree with your point, especially on the discoverability front - this is why emacs and vim have an often dreaded learning curve. But OTOH, there are also a couple of rather nice benefits to the terminal focus that I don't currently see in more GUI focused editors. It would certainly be doable to replicate them, but it seems like no one's trying currently.
So I would hold off on forgetting about the terminal until there's a viable alternative around.
Oh, and: I've seen my fair share of botched remote access solutions on the Windows side of things and would probably use any TUI editor short of ed over any IDE in those situations. At least SSH is responsive.
This sounds like the micro text editor. I've committed a few features to it and use it daily:
https://github.com/zyedidia/micro
You might be interested in checking it out.
This does a great disservice to the quality and functionality of Sublime.
I was a fluent vim user before switching to Sublime and have never looked back. The smooth (i.e. not line-by-line) scrolling and powerful multi-cursors were enough to draw me. The little things like a beautiful file explorer sidebar with icons-per-filetype, great package manager you can launch, search, and install from right in the editor, and yes, occasionally even the mini-map, all keep me here.
There's a pervasive meme on HN that Sublime took off because of its lesser learning curve, and that if you're a professional programmer you should make the investment to learn vim and emacs. But this ignores that a lot of people who have already made that investment still find Sublime to be a better editor.
While I can understand the importance of using an open source editor, that particular argument doesn't sway me since I'm happy enough using Sublime for now. If it stops getting updates or whatever, I can always switch back to vim, but for now I will use what I feel is the best editor for the job.
If I install emacs it is just okay. It probably has syntax highlighting, depending on the Linux distribution. It probably doesn't have any quality of life improvements for language X. I can drop in a theme and colorize it pretty quickly to my liking. From there, emacs is still very powerful, but there are a lot of things I really love for long and deep editing sessions when I am going through a lot of files on a code review or what not.
As an aside I found the Leo editor not too long ago. http://leoeditor.com/ -- one of the few editors that made me think "that is a little new". Leo is implemented in Python.
I wish there was a modern equivalent of emacs, only all Python. :)
I don't believe that. The people who snub Vim and Emacs, but are willing to sink time into learning new editors, new languages, and new frameworks have no excuse. If they were less susceptible to marketing, then they'd be able to learn something old every once in a while.
I'd love to see someone shake up the space with a "modern" take on emacs and vim: native, fast, powerful, very configurable, terminal based, but also with a conscious view on the initial learning curve and out of the box usefulness.
People have been attempting this for years with little success. The only projects I know of that have traction are Spacemacs and Neovim. The former is just an Emacs distribution and the latter is backwards compatible with Vim.
This is still a project in its early stages. The Mac build has basic editing functionality (it was used to write this README), but looks very spare and is still missing essentials such as auto-indent. At the moment, it’s expected that its main community will be developers interested in hacking on a text editor.
* simple and non-tedious to use by default,
* can run via terminal and ssh,
* supports vim themes,
* full support for Language Server Protocol,
---* (Can work with clangd)
* fast and polished
I love vscode, but agreed, it's bog-slow sometimes, especially when I run in ubuntu. I'm looking around at emacs and I like what I'm seeing, but something that perhaps seems silly is still a bit of a turn off for me - it's pretty effing ugly. I don't mean in the theme sense, I mean in all the stuff cluttering the codepanes.
In VScode I usually ctrl+k z for "zen mode," where the only thing you see is the tabs of your open files, and the code. ctrl+shift+e opens my file explorer when I need it, ctrl+b puts it away (or ctrl+p to go straight to a filename). Same for terminal, ctrl+`, do a git thing, ctrl+` buh bye. Anything similar for emacs? That level of quick control over the UI?
Throw this in your init.el
(scroll-bar-mode -1)
(tool-bar-mode -1)
(menu-bar-mode -1)
(global-linum-mode 0)
And it will instantly look a lot cleaner. If you want to toggle it you can turn it into a function and bind it to a key.
...what? You're gonna take away the scrollbar just like that? Implying that the scrollbar is worthless? Scrollbar is very important to me at least, (especially a well-implemented one). It gives me a quick and instant visual understanding of how big the file is, where I am currently in the file, etc. The only improvement I have seen on the scrollbar is Sublime's minimap... I knew there exist emacs methods to get it working, but I could not get it to work (on Windows) in less than a few days so that's of no use to me.
C-x C-f opens files, but will also open a file explorer if the path is a directory. The 'q' key will immediately close the file explorer. I'm not sure about git interaction. I usually just use the Emacs shell to enter git commands.
I don't worry about it cause I just backup my .emacs.d and restore it anywhere I plan on editing very long. My whole .emacs.d with tons of modes and add ons is 73MB.
There /is/ something to be said with not making a mess of your initialization file and customizations. It is also very possible to keep glomming addons in and eventually get to a difficult place where various elements of extensions/modes/packages are fighting and that can be frustrating and I can see why many turn to well tuned emacs distributions.
Line numbers on the left and two lines at the bottom. One for the status bar and one for the "mini buffer" (where you put commands, search text, and receive short messages). Everything else is just the buffer (file) I am editing. You could turn the line numbers off with a simple configuration and key binding if you wanted, along with all the other UI elements.
This goes to the "Zen" of my emacs config. Its always just the buffer I am editing unless I need another dialog or UI element. The trick to making this work with no tree based folder explorers are Projectile and Helm. Projectile adds "project" concept to emacs and Helm adds fuzzy searching of everything almost everywhere that matters. Both can be taught to work around git repos. So you can say, whack some keys and see a list of files in your project. Then start fuzzy matching in the helm buffer that results by typing say three letters of a file. If its unique you press enter. File is open. If I really need a tree or explore a directory there is `dired` mode which lets you walk around the file system. There are even tree modes that I find pointless after using helm and projectile.
There is nothing built in by default. That is the biggest problem with emacs. You don't just sit down at it one day and get a polished environment that fits with what you like. It is something that is worked at. You eventually learn at least a little elisp and your customization powers keep growing. Eventually you either quit emacs or are good enough at lisp and configuring it that it becomes obvious, if not trivial, to do most things other editors can do.
Generally speaking it is almost certain you can customize it if you are asking a question like, "Can I do X.". Everything in emacs, even configuration dialogs are just text buffers. You just teach emacs how to interpret different text buffers in different ways to implement special functionality. Most of the heavy lifting of integration with most languages is already done if your language is remotely popular.
This was a long answer, but that goes to the heart of emacs. If you want a zen mode, emacs is there for you. You want a mode with weird little widgets and build output things everywhere, emacs has your back. :)
I agree. I've been a vim user for over a decade, but a few years ago I decided to try mapping capslock to ctrl and have never looked back. It's a much more natural place for a key that gets used as often as ctrl, while capslock is a key that is rarely used (as a matter of fact, my keymap doesn't even have a capslock at all anymore, and I haven't missed it!). Anyone who uses ctrl more often than capslock ought to give it a try, but beware:
> On other computers IT IS NOT UNCOMMON FOR ME TO END UP TYPING IN CAPS.
It's a real danger!
The shortcuts make it a non-starter for me.
Having to configure stuff even more so.
Sublime isn't perfect and it still requires tinkering from time to time, but its power vs. time investment equation is absolutely fantastic. It's a very get-shit-done style of editor. Emacs/vim are amazingly powerful but they are also big time sinks, both in terms of the initial learning curve and later customization.
The philosophy of using it is that eventually, in the long long term, the productivity gains should be reasonable or at least competitive with any other editor or environment. It should be a joy to use. Since I know I will probably only ever make a living crafting text I view it as an imperative to deeply master my primary tool. The other aspect is that it is free and old and stable. I can't ever achieve an RMS level of using open source things, but everywhere I can, I want the truly open thing, even if it isn't practical. I run Linux for this reason, even though it was a giant time sink making it behave and getting everything just so. But I can make things just so.
This fits in also with creating a distraction free environment. i3wm, emacs, I barely even see application menus these days, but I still use a GUI, I am not crazy. But it fits with my philosophy/religion of computing, so I am going to do it this way. If others agree, great. If they want to know about it, I will share. If they think it's crazy, from their perspective they may be right!
Let's do this in realtime. I downloaded the latest Spacemacs.
1) Opening. Hmm, it's a zip not a DMG. Already losing me, but I'll stick, I'm not that shallow.
2) Hmm, it's just a bunch of source files? I guess the prominent "Download" link just gives you the configuration, not a bundled editor. I have to get Emacs from somewhere else. Grr... Lemme check their "Quickstart".
3) Yeah... the Quickstart link just gives you some BS that assumes you already know how to install this, and the "Install" button just gives a git command line to clone their repo. Back to square 1.
4) Fuck it, I'll use brew to install Emacs. Spacemacs doesn't even say which version of Emacs it works best with. I'll risk with what brew gives me.
5) Brew installation ends fine, with a caveat: "Please try the Cask for a better-supported Cocoa version". Now you tell me?
6) Anyway, I have an emacs, lemme git clone spacemacs now. OK, comes up, nice logo. Now, I have a huge emacs window -- so why is it asking me "first time" config questions in a tiny space at the bottom? And why doesn't it explain better what the various options (distro flavors) entail?
7) Let it do its install, then play around a bit. Close the window in evil mode (q!). I open emacs again, greeted with this:
Found 1 new package(s) to install...
--> refreshing package archive: gnu... [3/3]
--> installing package: evil-unimpaired@spacemacs-evil... [1/1]
An error occurred while installing evil-unimpaired (error: (wrong-type-
argument package-desc nil))
Warnings:
- Cannot find any of the specified fonts (Source Code Pro)! Font settings
may not be correct.
Error (use-package): helm :config: Symbol’s value as
variable is void: helm-bookmark-map
similarly, once you get to know the language quirks, it's a decent language that is basically a DSL for text editing. The power you get from being able to lookup how something was implemented by the text editor developers easily is extremely powerful.
If you like vim's idea of modal editing, emacs is 100% all about that. languages are major modes, minor modes are functions and keybindings that can be enabled and grouped together at will. transient buffers are used to send output to and are treated as normal buffers that you can do things to. The architecture and extensiblity of emacs is pretty amazing actually. Every key press is just a function and every key can be rebound based on current context using things like mode maps that get layered on top of everything and have precedence based on where you inserted the binding with sensible fallbacks when required.
Disclaimer: I love vim as a concept but hate viml and the plugins that were hampered by the lame programming language that was designed by bram.
if you have not tried magit and org mode you just don't really understand the power of emacs and the power of having everything be a function. spacemacs just makes setting up that powerful environment fairly painless but it's still a very old architecture with some warts.
However, the people generally working with/on emacs are not looking for that, they are looking for an editor optimized for customisation. They have already gone through the experience of setting it up, so why would they spend most of their time making it easier out of the box?
There is a cost to everything, and so far most people on emacs side have decided to spend their time on improving it's power, not it's ease of use.
you clicked on download instead of install. now, to be fair, download shouldn't be on the main screen imo but still install is more in line with what you were looking to do so it should have been the thing you clicked on. Cloning the repo is installing it if you have emacs installed already.
It's open source so this can verbiage can be fixed. It's not a stand alone editor as it's a bunch of configurations to emacs.
https://github.com/syl20bnr/spacemacs has better onboarding docs than the homepage does.
At the end of the day it's a question of how much customization you want out of an editor. Reading the tone in your comment seems like you didn't want it to be successful at all anyway.
But when you're on Windows, boy you have to do a LOT to get it to just work. I tried it (and spacemacs, as I'm quite familiar with vim) last month for doing some python work on Windows... I just gave up after 2 days.
But after that it was relatively plain-sailing for me. What else was troubling you? Note: it's possible that we've got totally different workloads and needs - not saying you're doing anything wrong, I'm just curious
[0] - OK you don't have to dig far, (it's on https://www.gnu.org/software/emacs/download.html) but it still annoys me a tiny bit
This may be true in for single heroic innovations, but sometimes the 'new' can emerge from successive refinement. I find this to be the case for IntelliJ. Working in it in static languages (at least the ones it knows well) just feels to me quite different from merely 'editing text'. The depth of code intelligence, combined with hundreds of small refinements in the way commands like refactoring work, affords a sense of working with syntax and structure, not 'text'.
> The speed with which we write text as programmers is not the limiting factor of how much software we can produce and never has been.
Again what IntelliJ adds for me isn't 'speed', but a cognitive sense of moving up the abstraction hierarchy. I'm thinking in terms of things like 'add a parameter to all call sites' much more than I am editing 'text'.
(caveat: I did use vim quite extensively many years ago, but never got beyond the learning shortcuts phase with emacs. It's possible either of the big 2 have similar refactoring and code intelligence packages available now)
Having worked extensively with primareliu Java in IDEA, I have come to consider syntax something that is more a presentation layer issue than something actually important to the core differences between languages.
I suspect that this shift in what I consider important parts of a language is at least partially down to an IDE that for the most part lets me think about the concepts I am expressing, rather than their superficial expression as text on a computer screen.
These days, out-of-process, editor-agnostic code analysis engines or "language servers" provide many IDE-like features to any text editor that is scriptable and can do basic IPC. Examples include:
* Tern for Javascript
* rtags for C and C++ (I use this all day, every day, at work, it's remarkable how good it is)
* Go's oracle tool
* racer for Rust
* tools.nrepl for Clojure
All of these have solid editor support; at the very least, a good package is available for Vim, Emacs, and Sublime Text.
IDEs tend to be all or nothing. I'll open one on occasion for a particularly nasty debugging session. I wish, though, that half the development effort going into IDEs were instead directed towards better editor-agnostic tooling.
> I wish, though, that half the development effort going into IDEs were instead directed towards better editor-agnostic tooling.
In principle I agree. I like the thought of composable tools. But I wonder in practise. I'm trying to picture the vast array of facilities integrated in IntelliJ (analyses, many refactorings, syntax-aware snippets, amazing code navigation, structural search & replace, data flow anaylysis, syntax-aware select, omnipresent code generation, etc) integrated into a text editor via external tools. I suppose it could be done, but it seems unwieldy. And with how much work (setup and maintenance) on the part of the user? How often would things clash or need fixing? And with how much discoverability (a critical feature of IntelliJ)?
What I do know is that working with code (not mere text!) in IntelliJ is quite a joy for me. For now, I'm glad someone has built it, even if the 'ultimate' composable set of tools might have some advantages.
I intentionally didn't include console editors, totally different beasts. Never used emacs, only learned vim and only touched the surface, mostly use it when I ssh to remote machines. The pinnacle of flexibility and responsiveness but the learning curve... it's just too much for me.
You're right though, it's a great investment and as the years pass and mouse usage takes its toll on my right hand fingers, keyboard only editors look even more appealing. Whenever though I sit down and try to code in vim I find my productivity plummeting. I know once I ride the curve things will improve but unfortunately I find it hard to persevere
You don't say what editor or IDE you're currently using [ed: unless you mean ST? Which would be odd, because it doesn't need a mouse for anything], but few require mouse usage for much nowadays. You might be better off, at least in the first instance, just learning the keyboard shortcuts for the tool you're currently using.
I think if you work on servers a lot, then it's a major advantage to use something like emacs or vim, because your editing environment is 'just there'. But heaps of developers rarely, if ever, find themselves in a terminal, so the portability advantage just isn't there for them.
This isn't as a knock on ST, which I also like, and might even sometimes prefer for pure writing or temporary notes. But it doesn't even have printing out of the box, come on. For me that's too modern.. plugins are nice, but I guess I prefer UE to ST like I preferred old Opera to Firefox.
Maybe it is different now, but UE used to require an internet connection for the registration... or you had to email your info for offline codes.
I have a bunch of isolated machines at work, physical and virtual, and got tired of dealing with UE and its registration requirements. Especially when ST gave a license key file I could copy around as needed.
So I switched. But yeah, I remember UE was a really good editor. Now I'm happy with ST.
A long time ago (>10 years) but then I mostly used IDEs for development. Didn't know it was still out there, I'll may give it another try, thanks
I mostly do it when I'm examining modules in a codebase I'm unfamiliar with.
Theoretically I really like the idea of reviewing code on paper.
But typically, if I'm trying to familiarize myself with a codebase, we're talking dozens of files. Usually I'm going through three, four, five levels of code to see how a request is served up, and then my search will fan out sideways into even more files as I attempt to see what other processes in the application might affect the data I'm concerned with.
To paper? Never. To PDF? I've printed to pdf to get nice looking formatted code for presentations.
I see print as more a brute force bazooka feature to get nice vector graphics out of apps.
* c/p in a gist
* when looking at the gist, print the page in your browser
* save to PDF
I love its core functionality: speed and stability, search, command palette, file navigation, Goto. I've used a number of editors over the years, and none have felt as fundamentally sound as Sublime Text.
The best feature of all is the Python plugin API. Sublime lacks some OOTB functionality of newer editors, but the plugin ecosystem makes this a non-issue if you're willing to invest in extending your editor. If you write code 6+ hours a day, you should be. Git integration (GitGutter and GitSavvy) is awesome, as is linting (SublimeLinter) and project management (ProjectManager).
I wrote an HTTP client plugin for Sublime called Requester (https://github.com/kylebebak/Requester) in a few thousand lines of code. It matches Postman, Insomnia, Paw et al. on features, and in my opinion handily beats them on usability. It's the plugin API that makes this possible.
Here's my guess on what Jon Skinner set out to do with Sublime Text: build a rock-solid text editor and make it as extensible as possible. Until someone does this better, Sublime is the best editor out there.
When it comes to editors, there's definitely a big spectrum of how much it does vs how lightweight/simple it is, and I think Sublime Text, for a majority of my usecases at least, is in the sweet spot.
Don't get me wrong, full fledged IDEs are useful sometimes too, but every time I go to use them, I always spend half my time searching and fighting the program instead of being productive. That's what I mean by Sublime making programming fun. Things don't get in your way and everything is very clean. Sure it may do less, but at least it doesn't drown you in features you don't use either.
MarkdownEditing (https://github.com/SublimeText-Markdown/MarkdownEditing), optionally combined with Distraction Free mode, is my preferred setup for anything that's not code: docs, blog posts, prose, etc.
Looks like I'm going to have to. Only free upgrades to people to bought after 2013...
Same here... In fact, I just did plunk down my money again.
But now that 3 is out of beta, I'll take another look and once again hope for an exhaustive, complete, up-to-date and comprehensive documentation of plugin development
Examples often say more in 10 lines of code than a page of docs, but I didn't find this to be an issue. To write Requester, I cloned plugins with features I wanted to implement (e.g. GitSavvy) and used them to complement the docs.
I think the docs could be improved with examples of small useful plugins that touch on various areas of the API. This might be a good project for the community.
Major kudos to these guys for distributing their software properly on Linux!
Major kudos to these guys for enduring distributing their software properly on Linux!
There is a lot more than just creating a package.
I do prefer what Sublime Text is doing here though. Kudos to them, it's a lot of work.
See https://github.com/tonsky/FiraCode
It's a superficial reason, but I've gotten very used to them in Emacs, IntelliJ IDEA, VS Code and Atom, yes, I'm still using all of them interchangeably :-(
Interesting. TIL
It even looks like TextMate implemented the individual copy/paste buffer for each cursor correctly as well, something that VSCode had horribly wrong the last time I tried to use it.
Do you know if this only worked with the cmd+click cursors, or did it also support the cmd+d mode to select the same word in multiple places?
Regardless, kudos to TextMate as well :)
Multiple Selections were one of the earliest core features built for Sublime Text, and weren't inspired from other software. I don't think TextMate existed when I implemented this.
Multiple-select was indeed one of the key reasons to use it, as a programmers editor, even though it was intended for more general-purpose word processing tasks.
Anecdotal experience: my first unboxing of ST2 led to the proclamation: "finally, someone has done multi-select cursors again, almost as good as PC-Write back in the day!"
TextMate 1 had multiple column editing, but true multi caret editing was not until TextMate 2 in 2011.
... Unlike most of Sublime Text which was a close copy of TM features except for the ability for users to edit customizations, making the Sublime community a giant leech that sucked all of the air out of TextMate bundle development without ever contributing anything back.
Sad history.
I rely so much on sublime for my day to day work and I fear the $80 or whatever I paid for it whenever ago is too cheap for the amount of value I'm getting out of it, and I'd hate to see this magnificent piece of software fall by the wayside because of an unsustainable business model.
Of course, if the business is perfectly sustainable then you know, carry on as you where.
I started with Textmate during the Rails craze and transitioned to Sublime due to the portability of themes etc. I think I'm still using my 10 year old TM theme.
Thank you for the continued dedication to this project.
Here is the screenshot: https://i.imgur.com/JvDEBk7.png
Here is the theme: http://fl-mwhalen-dev.s3.amazonaws.com/Made%20of%20Code.tmTh...
I'd entertain such a model as OP to ensure the ongoing viability of the app.
I feel ST could have a checkbox during checkout to add an additional $50 or something in that range. "I'd like to be a supporter for an extra $50". I'm pretty sure I would opt-in to that, but maybe I'm just saying that now because there isn't such an option....
I really do appreciate the classic software pricing.
It could be a higher fee, or more frequent but I'm really tired of all the Recurring costs!
But the issue you talk about is where major version upgrades come in. Sublime text could cease all development tomorrow and not pay another cent towards development, should people have to continue to pay to keep using it? If new major feature are requested then that is grounds for charging and upgrade fee, otherwise I don't see why people should pay.
ST3 is continuously improved. They are developers. They eat. They have families. Just like you receive a salary, because the software you work on, probably is never done. Why would anyone feel entitled to improvements for a flat rate? Is that not greedy?
You already paid by buying a faster computer. Some don't want to upgrade their computer; in this case, sublime is well worth its price.
Speak for yourself.
People who don't have no says whatsoever in this particular subthread discussion.
So no, he doesn't speak for the people who use ST.
The generalization that implies that the OP is a person who codes for a living is far from "completely unwarranted".
No reason to tell everyone about it.
If someone comments: "It's not much to pay $70 for something you use professionally, and get value out of it everyday etc" -- it only adds noise to chime in "I don't use it professionally" or "I don't use it everyday".
It's a conditional sentence (even if implicit). If one is not on that category, then yes, obviously the argument doesn't apply to them.
It's a way better deal (and arguably a better tool) than what you get with Sublime.
Assuming 4hs net per day, 20 days/month, 12 months .. thats 960 hours/year
And that's assuming that you spent all those 4 hours _entirely_ on your text editor; no cli, no browser, no nothing.. only text editor.
I'd say that on avg we should be doing ~200 hours per year.. Are there any study about this?
Obviously not everyone will be using their editor more than half the time, but many do. And many often use their editor outside of work too.
So, this leaves me of two minds about a hypothetical subscription model. If it meant that ST's developers had an ongoing income that allowed them to work full-time on the project, set a regular release schedule, and be more open with communication, it would be worth it. But if users had been asked to pay, say, $49 a year for the last five years with ST3 on an "um, they pop up once a year to say they're still working on it, I guess" schedule, I'm pretty confident it would have gone over even more poorly than what actually happened.
I'm worried about using the hosted version of KeeWeb, also it doesn't seems as practical as a standalone app. But I'll definitely try to host myself (or use locally on the phone?) and give a try. Thanks.
The danger of the one-off model is that it sometimes creates the wrong incentives. Features and even bug fixes get pushed into newer versions, which may even delay their release until there's enough of them to justify a new version.
A good example of this going awry is the RAW file processing for Photoshop (pre-subscription). Newer cameras would get added to new versions of the Camera Raw plugin but you needed a new version of Photoshop to use the newer Camera Raw versions.
I honestly don't mind the subscription model and I think Jetbrains has about the best one of all: you get constant acess to upgrades. When you choose to stop subscribing, that simply locks in the latest version you can use (ie you don't lose access entirely).
The problem is many companies price subscriptions wrong. They say "our software costs $600 so we should charge $50/month". Because, you know, recouping that cost in a year is somehow reasonable.
I can't say I recognize that wrong incentives in real life and I've yet to find a single piece of software that I'm willing to pay a subscription for.
It all comes down to business ethics, are you trying to rip off your customers? Most can't afford to piss off their paying users so they play nice (and I hope that is not the only reason they are being reasonable).
But rather that companies that don't offer subscriptions can't game on features and bug-fixes just to fish for upgrade fees before people feel (rightly so) ripped off. There is an implicit agreement on the support provided and if the company fails to deliver that people won't play along.
Also, if you loose access when you stop subscribing that is actually much harder to do compared to not paying for an upgrade if you "own" a license of the software.
It's easier to cancel a subscription than get a refund on a license.
Statements like this ignore the costs of creating it in the first place.
Software is something that needs to be continuously developed and maintained. Charging a one-time fee is a fundamentally unsustainable approach. We all have to face reality and start paying for software as a subscription.
Now, that will likely end the bubble of "I can buy 100 apps, most of which I'll never use", which we have been in for the last 20 years or so. But perhaps the few apps that people will pay for will become better as a result. I'm hoping for it.
Not always. Sometimes software is "done" and warrants no further changes or maintenance. I have run into this issue with mobile apps that worked perfectly to my satisfaction until the authors decided to "redesign" or "improve" it. I think subscription is a valid use case for customers who want active maintenance, but it should be opt-in. I detest the forced-subscription model that JetBrains attempted ("Didn't pay the latest subscription? We'll brick the application you've installed and are running on your hardware").
They never attempted that. You were always able to use the version you paid for, even if you stopped your subscription.
Oh, but they did[1]. You might have missed the initial drama as it transpired because of their quick U-turn (to their credit). I have reason to doubt the subscription plans they published which clearly stated that failure to keep up with the subscription would lead to bricked IDEs. JetBrains only backtracked[2] after receiving sustained pushback. There were HN posts for the initial bricking plan[3] and the backtrack[4].
1. http://bytecrafter.blogspot.com/2015/09/how-jetbrains-lost-y...
2. https://blog.jetbrains.com/blog/2015/09/18/final-update-on-t...
Charging a one time fee works just fine for lots of folks out there making software. It's especially good for anyone who's doing it in their spare time as they don't have to provide updates for every little niggle someone may find. Some offer a subscription alongside the one-off model, which is the best of both worlds if the developer(s) are continuously working on it. Others ask you to purchase the major upgrades but give minor upgrades for free.
There are lots of payment models out there, and the developers should pick what works for both them and their customers. There's no way most of my colleagues who have a license would have purchased sublime if it was a rolling cost, so that model seems to be working in their favor right now, at least for single developer purchases.
I am not even talking about adding some special features, just enable people to pay more than the normal price and perhaps just add a nice 'Thanks for your extra support' badge to the 'Info' menu.
If there was a subscription available that offered some amount of extra features, I probably wouldn't have purchased anything at all.
I'm not flaming, I genuinely want to know. I've tried Gedit, Atom, VS Code, Notepad++ and I fail to see what Sublime offers over those to justify the price.
It's better than Gedit in every way, it's way faster and more lightweight than Atom and VS Code, and it has a far better plugin ecosystem and functionality than Notepad++.
I'd pay triple the price.
Now you've got me wondering why editor speed is actually a thing.
Not sure about the first.
I care about speed because I like to use "large" files. I prefer a few large files to many small files.
An editor is not as simple as displaying lines of text a la Notepad, different editors optimize for different use cases.
2. http://blog.atom.io/2017/06/22/a-new-approach-to-text-render...
edit: not sure I correctly understood the parent
I don't want to see freezes for 2-3 seconds for some GC run, I don't want the letters to appear several 100ms after I've typed, I don't want to wait minutes for it to parse a large-ish file or update the autocomplete suggestions.
Of course the extent to which this happens is the whole reason there are different editors. If all you want to do is write text with zero features, then speed isn't an issue at all and you can just write directly in your terminal to a single file with pico or something.
[0] https://code.visualstudio.com/blogs/2017/02/08/syntax-highli...
I was troubleshooting something with a colleague who was using Atom, and every time he opened a new file, it'd take somewhere between 1 and 2 seconds before the syntax highlighting was applied. As someone who's in and out of files all day, that'd drive me bananas.
Thing is, same is true for any other good IDE, of which there are plenty.
Personally, it always blows my mind that people don't use VIM :) if they actually spent 5-20hours learning VIM correctly they would not touch these inferior pretty looking UIs
For file-inefficient environments (e.g. Java/Android -- 79 files for a "hello world" Android app!) I have to grudgingly use an IDE because I have no idea how to update the 78 other manifest/gradle/workspace/resource/etc. files based on the 1 file I change and the IDE takes care of the magic, as much as I hate that way of working.
Bret Viktor's oft-quoted "Inventing on Principle" talk touches on this subject where a lot of research has shown that bimodal editors are worse. While I can't argue for how true that statement is, it's certainly been my experience. I always find it jarring to think I'm in command mode but I'm actually in edit mode or vice versa. Any vim user has had the experience of pasting text in command mode. I just absolutely hate bimodal editors.
Additionally, staunch vim (and emacs) users I know seem to spend an inordinate amount of time screwing around with plugins to get some pale version of behaviour you get out the box on any halfway decent IDE or even text editor.
I feel the same way about learning yet another series of keyboard shortcuts for, say, tmux/screen.
You could argue the mouse is slower. I'm not sure if this actually holds up to empirical measurement (or at least not to the degree that's claimed) but the point is, the barrier for entry is so much lower. You can just click around and find things. If you find yourself doing something a lot, you can find out what the keyboard shortcut is.
Thus you don't need to spend 50 hours upfront on a GUI editor.
But I'd like to say that I cannot honestly recall an instance where I was in normal mode and ended up pasting something -- I assume you mean Ctrl-V-ing and having the paste interpreted as commands? -- once I got used to it after leaving Sublime Text, which I'd say took me a couple of weeks of hating myself. It's a matter of how much effort one thinks it makes sense to put into learning the editor, but IME there is a significant payoff, even if it is hard-won.
I'm not sure if it's harder for some people to internalize (which is by no means a value judgment; it's why Emacs/ST/Atom/whatever exist and are powerful) but once that is done, one never gets confused about what mode you're in simply because one is almost never in insert mode! "Probabilistically" speaking, you are in insert mode for 0 time. ;)
In any case, I don't hate non-bimodal editors, just hope that the subset of those using them who have not seen Vim for what it is yet do so quickly. (And, of course, there are those who are genuinely repulsed by modal editing, and that's fine!)
I can't speak to "inordinate amount of time screwing around with plugins": I have a plugin for each language I use, and perhaps four or five others. The rest of my init.vim (I use Neovim) is about ... 30 lines long? It's my experience that most (Neo)vi(m) users use little of the power of plain vi -- I know that because I myself was like that for almost three or four years after I started using Vim. (This is ignoring, e.g. large Java projects, where IDE-style code navigation is basically a requirement if you want to get anything done.) But there is definitely a culture where a customized-to-the-hilt editor is seen as something to be proud of, and why shouldn't it? It's what you "live in", isn't it? :)
5 shortcuts is a paltry investment for a pretty sweet gain.
And unlike an IDE, this can be readily available on any machine you SSH into. Which is also what makes VIM so handy.
It is slower, and does hold up to empirical measurement. Yes, if you want 'ease of onboarding', then vim is not for you. It's a powerful tool for professionals, and like a lot of such tools, it requires some training. No-one ever complains that Photoshop requires training, yet a brand new user to Photoshop is completely befuddled and it takes a long time before they're proficient.
I think this is a really good analogy to using pro-level text editing tools (e.g. Emacs or Vi). A mouse is great for poking around menus and operating sliders in a new or unfamiliar program, but Emacs and especially Vim are so fast to use without a mouse that it pains me to watch other programmers editing while using one.
ST is a fine editor, and I use IntelliJ for Java, but I've already spent the time (years) learning Emacs. Is it worth it for me to start over? No. I use IntelliJ for Java programming, but I use only its basic Emacs keybindings and the mouse for everything else (befuddled like I am in Photoshop).
There are some really great vim plugins for Sublime Text, including one that uses NeoVim. For me, Sublime Text is basically Vim with an nice UI and some IDE features built in. And Goto Anything. I wouldn't want to live without Goto Anything.
{ "keys": ["j", "k"], "args": {"key": "<esc>"}, "context": [{ "key": "setting.actual_intercept", "operand": true }], "command": "actual_keypress" },
On the backend, it's using NeoVim... So it's literally just vim. You can even use vim plugins. There really shouldn't be any missing features.
e.g. Goto anything you can use the Ctrl-P plugin.
I will often use sed or other CLI tools to parse through giant files (1GB+), but sublime only takes a short bit to load in a pretty hefty file, or a do regex search across entire projects with multiple-GB of files, and it works natively on Mac and Windows, so even when I'm forced to work on something on my Windows 10 laptop, I can be productive.
Well worth whatever I paid for it 4 years ago.
And it's fast, it's small, and it's got a lot of packages. What more do you want?
Not to mention if you hit ctrl-f and search for something in the file. Another lock-up for a few minutes while it tries to figure out highlighting. This is something I've reported to them. I have never considered Sublime to be a good handler of large files.
And the excellent Python plugin API, which has made the plugin ecosystem so vibrant. Here's one I wrote, https://github.com/kylebebak/Requester, an HTTP client that goes toe to toe with Paw and Postman on features and outdoes them on usability.
I couldn't have have written something like this for any other editor, or any other platform.
I'm in a situation where if I had $10 or $80 extra, I would use it to buy baby supplies, not software. Many others are in the same situation, or worse (thinking of those in developing countries where $80 represent a week's worth of savings).
That isn't necessarily bad; it's a great editor and I've been happy to pay for all versions of it.
But if I am paying an ongoing, continual fee, I expect rapid delivery of updates and new features. I pay for an IDE from JetBrains, and they deliver solid incremental improvements and bug fixes, continuously. So I feel the continual fee is acceptable.
Sublime Text is known for going on hiatus for months at a stretch, with no or negligible updates. That would irritate me as a paying subscriber to the software; it doesn't bug me when I pay a lump sum for the big milestone releases.
I just wanted to put these points across since a single price probably may not well serve all user classes and the developer/company.
(Some pretty great replies too – thanks!)
I'm not a ST dev, I have no financial interests in ST becoming more expensive or changing to a (for the company) more lucrative business model. I have tried alternative editors, anything from vi and emacs to VSCode and Atom, but nothing hits the marks for me as ST does. It has – in my opinion – great UX, its speed and efficiency is unmatched in the GUI editor space, and my favorite feature: it has rock solid buffer persistence.
I can't tell how many times ST has saved me from system crashes and just me being an idiot and restarting everything before saving anything, or removing a file but ST keeping a buffer. I've come to rely on this, and it's rock solid. Not once in the years since I started using it (I believe I bought my first license in 2012) have I encountered a situation where ST lost my data. I've never experienced this with any other editor (I'm sure vi and emacs can do this, but in years of trying, I can't come to grips with their UX – they're just not for me) and this feature alone has paid for the price of admission for me, many many times over.
In short – I don't care that there are FOSS alternatives. I don't care that there are alternatives that are "better" by some measure. Until they can match these three things, in increasing order of importance, they will never compete with ST for me:
- Great UX
- Speed and efficieny
- Rock solid buffer persistance, even for unsaved files
Someone in this thread suggested I buy licenses and donate to a local high school. I'm going to seriously look into this as a viable way to both support the company producing ST, as well as hopefully enabling kids to learn programming, or write novels, or whatever they want to do with the software.
For me, the UI paradigms are certainly more cohesive… but most importantly I don't think any platform has the quality software that OS X has when it comes to attention to detail/usability. Like many with Sublime, I'm happy to pay for other commercial software if its notably better than the free options.
Ubuntu is probably leaner, but in an age of i7s and 16GB ram not sure that matters as much. OS X is aggressive at using what you can throw at it, which generally has made things feel faster than me, but I came from Windows in 2004.
It generally strikes the balance of what I deem the finest commercial software, with a very great open source ecosystem 90% as good as Linux. Makes for a very good dev environment, and the hardware is unbeatable (which is made possible by the software integration)
> the hardware is unbeatable
The new macbook pros are gobsmackingly expensive in much of the world, marginally less so in the US. Apple's obdurate refusal to use touch screens puts them far behind the mainstream leading edge now. I understand their reasoning, but haven't yet met anyone with a touchscreen laptop who would go back to using one without.
And the coup de grace is the new fake keyboard, which is unusable for all-row touch typists. My next laptop will most likely be a Dell XPS 15 with one flavour or other of Linux. I'd prefer macOS, but the hardware isn't worth living with.
Have you ever considered open-sourcing SLT? This is your only route to immortalize this amazing piece of software. I'm sure you'd receive immense community contributions and widespread support. If you switch to a donation model + enterprise support plans, I think you're likely to earn greatly more than you currently do.
I love SLT and have used it throughout my career, but I still feel more comfortable depending on Atom because I know it will be supported by the community in the event that something bad happens with the ownership. If you don't open-source SLT, I sadly believe that open alternatives like Atom will outlive it.
Of course, with a team backing the project that changes the dynamic a bit
Of Coz it wont be a small amount. It could be 25,000 copies. But then lot of companies, whom may like Sublime, could spend and join the race.
They won't. Projects like Atom and VSCode thrives because they have big companies behind them. Remove them - and the project will die.
There are tons of abandoned text editors on GiHub.
You're not loosing any income - honest people will continue to buy the license, and those who are not honest or cannot afford it will continue to not buy a license. But people will be put at ease about the bus factor. We will learn a lot about how to produce a snappy app with a multiplatform toolkit. And I'm sure people will contribute back great features.
I'm curious as to what your evidence to back this statement up is. As is, most donation-ware ends up getting next to nothing in donations.
Then VSCode came out and I loved every second of it. It does take more up more memory and is a bit slower but they are quality software and the difference to me is negligible. I cannot see myself going back. SublimeHQ lost me when they stopped updating the software regularly. I know it was rock solid software but the project seemed to be a standstill and VSCode grabbed my attention. Now it has many more features and better support from MS. I cannot imagine a reason to switch unless ST3 gets the same level of love.
If you have a Mac laying around the office install Xcode and the Simulator to test and debug iOS devices.
I do wonder sometimes how much the app makes and/or how much someone would have to pay the developer to open source it.
It's still not exactly the same as using pure VIM, since some of the commands overlap with Sublime commands, and I tend to use a hybrid of both (for instance, Sublime's Ctrl-D command to make multiple cursors, which is incredibly useful when I'm editing HTML and have to wrap several lines in anchor tags).
Going into "pure VIM" is just to make sure I don't get too reliant on Sublime niceties, particularly as my day job requires spending a great deal of time SSH'd into random RHEL/CentOS boxes.
For example, take the updated homepage, the licence upgrade process, the proper integration into linux package managers and more.
Couple that with the perception of users of things being "stable" having more reliability and them more likely trying it out and finding rare bugs or issues. Just looking at the forum today revealed a couple issues that nobody on the dev releases has discovered or reported.
That said, you still have to release a stable version every once in a while and they knew that. Unfortunately it took longer than anticipated.
(My favorite editor is an Emacs clone called Epsilon. It hasn't been updated in a decade, but it still works great. On the other hand, it hasn't been updated in a decade and I think the writing is on the walls, and I'll have to move to something else. 25 years of muscle memory are hard to deal with, though. I'd definitely throw some money the author's way if he ever decided to do a new release).
Epsilon is still a fantastic tool and you can customize the crap out of it, but there are some things (like multiple native windows) that you can't do, that I'd really like to have. Ah well.
I haven't touched it in a while. How do these two editors compare lately?
I'm not sure if this addresses files bigger than 10mb though.
[0] - https://github.com/Microsoft/vscode/issues/6474#issuecomment...
Wheee, I'm not the only one bothered by this! It's bad on Windows too, though Linux is fine. It affects all Electron based programs, including Chrome itself.
VSCode is free, (mostly) MIT, has a unified debugger, great git support, integrated terminal emulator, and a nice healthy extension community.
Sublime is cheap for how often you'll use it, but not free. It's proprietary. Git support even with paid plugins is lacking, especially compared to VS Code.
I'm glad I bought Sublime when I did, but I'm also glad I found VSCode when I did. If there's a choice between FOSS and proprietary, and the FOSS project already works better, the proprietary option is unlikely to make a comeback for me.
Sublime is indeed faster and more lightweight but that's not enough for me to keep using it.
I love Sublime and used it for many years. It's fast, it looks good, and it's a great editor. It's hard to find an extension ecosystem like VSCode, though. I doubt I'll be returning to Sublime.
"Vintageous has been discontinued."
I wouldn't blame the problem you had on Sublime. I can start up Sublime with all my plugins, press '{' and it works as expected.
ST is still a lot faster, but now that VSCode has introduced multi-folder workspaces there aren't a lot of features I miss anymore.
VSCode is that IDE - long live Sublime.
It'll take a while to switch over but the writing is on the wall as far as I'm concerned - Sublime will be fondly remembered for it's novel features.
Wow, that's nice! Since it's not the default, if you hadn't mentioned it, I wouldn't even know about it.
What's with the "/" 'icon' next to many files? I'm not sure what it's supposed to indicate. As you can see in the screenshot in the announcement, some files have a rectangular 'document' icon (unrecognized format?), some have a '<>' icon (html/markdown-type format?), and some have a '/' icon... no idea? Is that supposed to mean "source code"? I am not a fan.
Just use the theme you prefer, nobody forces the default one on you, right?
Hah. Just noticed that myself. It's the icon for "shell script", I think, which includes a wide variety of file types. If you cmd-shift-p and pick "install package", and then install "A File Icon", then that peculiarity is instantly and permanently replaced with meaningful icons (for all the types that I happen to use in my dayjob, at least).
I can override it rationally but there's some serious cognitive dissonance going on. It's configurable, although that's in the bowels of ST3 not in the usual settings, and this won't really help for pair work. Not a great decision I feel.
I for one swapped the mapping of paste and paste and indent because I want the latter's behavior to be default.
I also use a proportional font and love it. Something I can't get vim to do.
I like gitgutter though it doesn't refresh properly always.
What are your favorite plugins?
AutoFileName is surprisingly useful, it autocompletes file names.
Gitignored File Excluder is a bit of a hack but is very nice.
I'd love to get sublime linter up and running, but I haven't yet.
Also I use a small plugin to add terminal commands to the command palette which is very useful. Can't remember is name though.
Sublime makes cross-platform development easy, and it's so much faster than the alternatives.
Not really surprised, after 6 mos I don't think I've used the touch bar for anything other than mute / volume.
I hope to see Sublime eventually released under a free software license. I'd donate to that project.
I'd be able to function without intellij ultimate but it would be incredibly painful and I'd permanently be slower.
I still use VIM often enough to stay proficient with it, mostly via SSH, but I'll happily use the closed source IDEA editors when they are available.
Depends what you're doing, I suppose. If you're doing web development, Python, Ruby, PHP, C, JavaScript, etc... I don't think being on any particular OS is more important than your tools.
If you are like my parents that can't get on the internet if the browser icon disappears from their desktop, then there might be a problem.
When you use emacs or vim, which import their 1970s / early 1980s OS conventions with their keyboard shortcuts, you realize you can be dropped into a very foreign 'defaults' context, and they can conflict.
Purchased the upgrade license at and incredibly modest price of $30.
Unless I'm way underestimating the subscriber base and associated economies of scale, and they really can afford to drive the upgrade rate by making it this cheap, seems like they're leaving a lot of cash on the table. That's actually a touch worrisome, naturally, because it reduces their ability to fund the business through downtimes and make investments into the product (etc). I depend on their product enough that I want their company to be robust and healthy, even if I have to pay more for that to happen. I know they only have a few people to pay today, and I could be wrong about my core assumption, but I don't think they're anywhere near what the market will bear.
I would have paid almost four times as much without thinking myself poorly used. I originally bought sometime in late 2012 and used version 3 since sometime in 2013... which means I've been getting many of the benefits of the upgrade for close to four years. To be honest, I would have even understood if I had been asked to pay the full license fee again and would have done so without pause.
There are just so many times I need to SSH into a machine. I know Emacs has some remote file editing capabilities but for some reason I never liked it (I can't recall why now... I think it was the need to sudo).
So I'm wondering what sublime text fans do for remote editing?
Once you set some flags like sshfs -o auto_cache,reconnect,defer_permissions,negative_vncache,noappledouble user@host:/ /path/to/local/ it's pretty robust.
I can then edit files remotely but still use Sublime Text :)
But a lot of the time, I am running vim on the remote server... no simple substitute unless you install some sort of channel to be able to edit locally, or have it available via SFTP (especially with sudo, that's often not possible).
Some people use plugins to edit code over a tunnel using sftp. One of my coworkers edits locally and has aliases to rsync and run his code on the remote machine.
Tramp (https://www.gnu.org/software/tramp/tramp-emacs.html) enables seamless remote editing over ssh/scp. By default it asks for your password all the time but you can cache that. Add to your ~/.emacs
(require 'tramp)
(setq tramp-default-method "scp")
(setq password-cache-expiry 1800)With Ctrl+P I've never needed the sidebar. Also I like it better if the entire screen is dark. So I'm always in fullscreen with the sidebar hidden.
"workbench.sideBar.location": "right"i know i know, to monetize selling free software is impossible (when people say they're monetizing selling free software they're actually selling services related to that free software, not the software itself), but one can dream...
edit-> some people are confusing the term "free software", i'd like to clarify that i mean free as in free speech, not free as in free beer.
Key words for Google search: Emacs Prelude, or Spacemacs
TODO: search for vim equivalents
I don't understand why so many developers are willing to pay thousands to upgrade their hardware frequently, but then aren't willing to pay $80 (or $30 to upgrade) once every what, 5 years?, for software that they use in the realm of 30+hrs per week. Sublime text has easily saved me enough time to earn that back.
about the reasons to be "more free" (as in free spech): collaborative development
I wish we had a way of collectively and continuously funding open source software. Developers absolutely need to be paid, but it seems that software is better off when it's free.
(With that said, Sublime is one of the few remaining non-open-source applications that I'm more than happy to buy.)
But.
Its slow progress over the last few years reminded me of the risks of trusting proprietary software for my main work tools - especially when that software has a very low bus factor. That doesn't mean I won't use closed software or that I dislike the authors or anything, but that if I'm going to invest hundreds of hours into solidly learning and customizing something, I want to have faith that it's not going anywhere. That's why I waved a sad goodbye to the otherwise excellent Sublime Text and went back to [open source editor].
That's the least important part of my editor honestly. Would expect it be a lot more low-key.
I mean, Atom is nice. The package management is all there and frequent updates are great, but...I don't write JS/HTML/CSS/PHP. I typically write Python, Go, Java, and heck even Prolog. Reading the changelog you can clearly see that they have a target audience, and I am not in it.
On the performance side (you knew it was coming!) I am mostly fine except for opening a project directory. I swear Atom has a coded in `sleep` whenever you try to open a file explorer. At first, I thought that this was a cute little quirk that would disappear after an update one day. But that update never came.
So I'll download Sublime again. Spend a morning to get it "just so" for, at the very least, Python and Go. I can easily see Sublime winning me back if I reinvest in it.
However, both VS Code and Atom stand no chance against ST regarding startup time. Thus I keep coming back to ST.
That said, ST is still significantly better for many other tasks and I end up using it daily, so you should definitely try it out. I'm just saying don't judge it solely on how well it handles Go because you may be disappointed coming from Atom.
http://damnwidget.github.io/anaconda/
Though when I did Python I used one of the PEP8 plugins and the enhanced autocomplete plugin (soo highly recommend it).
Also check out:
https://realpython.com/blog/python/setting-up-sublime-text-3...
A bit dated but some of those plugins are definitely worth it, especially Git Gutter.
If software developers don't value software, there is something very wrong with our industry.
And it's not even an expensive specialized software you just use once every few weeks. Sublime Text is literally the first program I start in the morning and the last one I close in the evening. I bought a license in 2011 or 2012 and have used it daily since then. And now I can upgrade for just $30? This is easily the best value-for-money of all the things I ever bought in my whole life
Oh, they value it, all right. They just don’t want to buy it, at least not in the customary fashion. They’re more than happy to pay for software using bug fixes, feature contributions, community engagement, or even their own software. Maybe, just maybe, software for software developers isn’t a good product to be sold the way software is usually sold?
However, most people just use Sublime Text. If the software were expensive I probably wouldn't feel so strongly. Looking for and fixing bugs in Sublime Text would be a terrible use of my time. For many of us, $80 represents an hour or two of work.
And now it starts even faster.
Also, Will: I apologize for being one of those assholes with a moderately popular plugin that still hasn't updated the thing to follow Package Control best practices.
I'm sure you guys have discussed it somewhere in the past, but would you comment on where you see Sublime heading feature wise now that there is, arguably, some competition in the same general editor market (vs code, atom, etc...)? I don't like comparing stuff and saying "why can you just do that" but some of those editors, even with all their shortcomings, have massively benefited from good debugger support (vs code), and a pretty well though out set of features to support plugin developers (dependency management, testing, etc...).
One thing that I don't understand is though, when I buy ST, what do I buy? I've only seen others use full versions but as far as I can tell it's only the [UNREGISTERED] bit in the titlebar and the random "please buy me" popup. It's understandable that one would pay merely to sustain its development but is there any actual differences?
Most, if not all, of the new features of the 3.0 release were present in the latest dev version (the dev builds get updated much more frequently, as opposed to the public build, which was last updated Sep 2016).
Not the case. You can set it to match existing file indents if you wish (with a notification when an indent style is matched). And you can have individual project-scoped or multiple IDE-scoped language code style presets.
One question: How is sublime sustainable economically? I mean alternatives like Atom is free & open source, supported by a big company. With a infinite free trial model, how can sublime survive?
I didn't say it's not worth it, I said it's not cheap. It's not.
A lot of software is very under priced in terms of value. The App Store and SaaS copycats pricing doesn't reflect the value or the cost of software - you need big volumes and many go bust due to no profits.
I paid for ST2 in 2012. Five years later the upgrade price is only $30. Should have been more.
There are AFAIK only two full-time employees (Jon Skinner and Will Bond) so they don't need to sell a ton of licenses.
If they sell 6,000 licenses a year that nets them nearly $500K/year in revenue.
Please note that the "6,000" there was totally invented by me. I just estimated how many licenses they need to sell to reach half a mil. I don't know if they sell 1,000 a year or 100,000 a year... I'd be really curious to know how many they sell.
On the rare occasion that something breaks (Seti_UI theme, mostly. But to be fair, I installed it when it wasn't stable yet), fixes are often published the next day or at most in the next handful of days. In the meantime you can just disable a plugin and go ahead. But again, it happened rarely to me.
The only problem (that I'm aware of, correct me if I'm wrong) they ran into was the whole deal with Kite basically paying some plugin devs to hide spyware into their code. But that has been handled and solved, and lead to the creation of basic guidelines for plugin developments and extensive discussion of the forum. Devs were very responsive.
Discovering sublime text was crucial to my early development as a programmer, I can easily see myself losing interest in it without having such a powerful, efficient, intuitive, and FUN tool at my fingertips. Yeah I said it: fun. Sublime text is fun for me. I even type my emails and web form responses in it, just because.
Anyway, congrats on the release, I love sublime text, you already have my money but seriously, I'll give you more
If you wish this to be fixed, please comment the related forum post: https://forum.sublimetext.com/t/macos-window-restoration-to-...
I enjoy a lot of the nice UI based workflows Sublime provides - but always felt that mastering VIM / emacs would provide me a far better pay out. Does any body else agree ?
About ten years ago I got a job that required me to edit multiple languages on multiple platforms and I was using about three different editors: Oxygen XML, Eclipse, VS, Python Charm and I just thought this is getting ridiculous. I switched to Emacs because it is cross-platform, fast, and you can edit any kind of file in it. I never looked back. I have edited about a dozen programming languages in it, and used it for markdown, and DocBook and DITA XML editing. Today I am still happily using it. On my latest gig I had to edit TeX - no problem in Emacs. I learn new tricks in it all the time. I have a colour scheme that works really well. Having built in ansi-term and being able to do M-! and then run a shell command save a lot of time in the workflow. There are thousands of features and tweaks you can do. The incremental forward and back search is lightning fast. I use C-r a lot in Bash too. On the whole I'm very pleased with my switch to Emacs. By the way I usually only use the text-only version of Emacs (emacs-nox on Linux). I do keep a copy of AquaMacs installed on my Mac too, but work mostly on the command line.
I did actually try Sublime a few years back and have a licence, but I found myself just firing up Emacs on the command line and C-x C-f to fast load a file more often than not.
I would say, yes, go for Vim or Emacs, but it depends really what you need from an editor.
One of the things that I love about VIM is that because I use very few plugins I can edit text just as efficiently on any remote machine without complicated plugin installation.
I need to install VIM style movement in whatever IDE I use (IntelliJ these days) because otherwise I find moving around the text painfully slow.
If you are going for mastery level, that implies you would also learn Sublime's programming model inside and out. If you get to that level of expertise, you are probably going to be more efficient than most when it comes to editing text.
If you are going to be using one of those editors a lot anyway (because you will be ssh'ing into a Linux machine or rely on org-mode, for example), then perhaps that would shift the landscape.
At least part of that efficiency (apart from Emacs being awesome) is that I've been able to keep getting better at using my editor rather than having to change tools every so often as less configurable editors get overtaken by ones with new features.
Emacs is pretty deep (I keep discovering new things) and configurable in the extreme. I think it's very likely that it will last for decades yet - any killer innovation that another editor comes up with is likely to be quickly copied into Emacs.
Just bought it.
I found it was just easier to have one app to do everything.
Even though I don't have certain nice text formatting features, I use Code Comments to make certain lines distinct.
That's how you know you LOVE a product, when you still prefer to use it even for things it isn't designed for.
After using ST for five years I felt like I should probably purchase a licence :) I feel guilty for not doing it sooner.
Since then it has been my main editor, cross platform for php, then python, then ruby, to java (...yup), and now clojure and racket. And of course all the SQL, shell scripts, and config file munging in between.
Maybe one day I will learn emacs, but for the meantime I am happy and productive.
This is a big reason why I still use sublime over atom.
edit: correction, the beta of minecraft lasted only a year, so it definitely felt longer to me. Weird memory tricks eh.
IME, vim actually loses in performance too when editing multiple lines.
I work in XML and SQL in my everyday work activities and its highlighting features are stupid good.
Although there is still no blinking block caret. The size can be changed but it's a solid color, not transparent.
Also I wonder if I could change the background color of the brace matching highlight.
Enscript[1] is my (the?) preferred way and a plugin would be a fine tay to achieve this. Will format code in almost any way you could ever imagine.
See relevant discussion on Stack Exchange: https://unix.stackexchange.com/questions/139254/why-cant-vim...
Sublime Text is imo near perfect, only thing I miss is the ability to edit multi-GB files (on a reasonably priced laptop).. sadly I believe it will be near impossible for Sublime Text to ever support this.
- Is there a way to lookup documentation while using the editor (contextual help)?
- Is there a way to access most features without key bindings and to learn the key bindings while doing so?
I also have SidebarEnhancements, Calculate, Alignment, EditorConfig, and Default File Type installed. None of them make a major impact, but they all make the experience a tad nicer.
There are numerous 3rd party packages to improve on this for specific languages. Hopefully the Language Server effort takes off and reduces the rampant duplication of effort between them.
Many kudos and one day I will definitely buy a LICENSE.
They should just compare the startup time of stock versions of 2 and 3 and post those.
Using a single percentage would probably be more misleading than just saying "significantly improved".
Seriously, this release took ages...
Thank you for it.
What are the deep conceptual differences, the strongly held opinions?
I myself started with evil after a long time with vi(m) and then made the switch to a more "pure" (for the lack of a better word) Emacs experience.
I am still very proficient with vim, even though Emacs has been my daily driver for 4 years.
The only thing I've had to do was to map <C-x><C-s> in vim to ":w".
Personally I'm not too big of a fan of the styling there, but it's far from a critical issue.