After years of using it, I finally just bought a Sublime license. It's about as close to perfect as an editor gets for me - fast, stable, powerful, extensible, portable, and very low cognitive overhead.
I'm the opposite - bought a license years ago but don't actually use it for much except plaintext.
In my experience the core editor is fast and rock solid, but I think every single extension I've tried has been somewhere between glitchy and completely broken, and debugging/fixing them has soaked up more time than they'd save if they worked perfectly.
Part of the problem may be that extensions seem remarkably keen to take giant dependencies. I think one wanted a full node.js install to do JS linting.
Atom is finally getting to the point that I feel it's competitive with ST. If you haven't lately, give it a try. There is a huge ecosystem of excellent plugins, too.
For plaintext/markdown/HTML/JS/CSS I basically use vanilla Sublime as a better Notepad. It's not ideal; I bought WebStorm a while back but never got around to trying it.
For statically-typed code, a text editor can't compete with a refactoring IDE (e.g. VS or Eclipse) IMHO.
All the ones I use (cppcheck, jshint, jsxhint, ruby, clang) require that you have the toolchains already installed. Seems like a pretty consistent design. Those are the official linters [1], though.
Edit: Checked a bunch of the others, including those for Lua, XML and Python. None of them come bundled with the underlying tool.
> seems to drag a full install of whatever the popular implementation of the language is.
This is the biggest problem with sublime plugins. dependencies. It is also 100% why I refuse to add non-python dependencies to any plugins I write (which has really just been JsFormat thus far)
Likewise - It was over the winter, when I was back home in Canada, and remarked that I still hadn't purchased a license, but, in the last 6 months, had probably spent 3-4 hours/day in Sublime. In particular, making a lot of use of Sublimerge to do fast visual diffs, really won me over. Even though on remote hosts I still live in vim, I really, really love this tool when working locally.
Hopefully I'll be a little faster to purchase an upgrade license when a new version of Sublime is released. Probably One of the most important software tools I've used in the last year from a personal productivity perspective.
SFTP is as secure as any other SSH connection and people use those extremely regularly to remotely administer hosts which lack a VPN.
Aside from terrible Windows support SFTP is likely one of the best secure remote file transfer protocols around (in particular for freeform file transfers, rather than structured like AS2 or similar).
That's still a silly point. For security reasons a lot of people don't hook their source control directly into production web-servers, and instead deploy from a secured environment hooked into secure control onto production (which would still require something like e.g. SFTP for the actual transfer).
Regardless their point was poorly explained/explored.
Correct, workflow. Even with the tools themselves, rather than "best practice" it seems mind boggling using SFTP within the editor. With things like SASS, bower, grunt, npm and the like - it doesn't even seem like it'd be compatible.
Well I use a dev virtual server instead of a local vm. I enjoy working in a windows environment, but would rather not struggle with the discrepancies between running an app on windows with something like xampp vs apache on centos which are my web servers.
I use a sftp atom plugin to workin on/save to my dev server and just use ssh to do git/etc right on the server. I don't see how this workflow is very different than working locally and using a command prompt for all of your tools.
I develop from multiple machines depending on where I am. The dev server that then does all the version control bits as if it were the local server. It's also a lot beefier than my laptop. Also bear in mind these are my own one-man-job projects and websites. Made do with what I have else I'll spend years setting up the perfect system and have created nothing
I do, and to be honest with you it is more fractured than it has ever been.
Back in the 90s "everyone" used FTP. Now the methods of deployment vary wildly including but not limited to:
- FTP (over VPN), "Shared Folders" (SMB, over VPN), RDC/RDP (seriously, often not over VPN)
- Git clients (and other source control, controlled over SSH), SFTP, FTPS, CMS (over HTTP/S), SCP, rsync/robocopy (over VPN)
- Virtualisation trickery: Like cloning, snapshots, and shared data storage.
The "best" way depends on a lot of factors. For example are you doing staging? Do you even have source control? How many servers? Etc. There is no one size fits all solution.
For a small host or personal site, you can likely do what everyone else does: SFTP on Linux/BSD, and FTPS on Windows (via Filezilla Server).
We use git and have branches designated as Dev, Test, Prod (etc) with webhooks or other scripts that automatically deploy the branches based on the workflow. At my last job (small webshop) it was automated, but my current job is more "Enterprisey" and we have separation of duties and other work flow constraints which mean that I never push anything to production myself (or test for that matter).
lmao i actually used to do that once but the overhead was too much (i save frequently), so i just bought a desktop and i x11 over ssh on the remote's sublime. SFTP was a really good extension though.
Besides Firefox, Sublime Text is the application I use the most in my day-to-day professional life. It is faster and easier to configure than any other code editor I've used in the past. I would say it's one of the few pieces of software I've encountered that is a joy to use.
If you also use ST regularly and can afford it, I highly encourage you to support development and buy a license right now.
I purchased the licence years ago and used it almost exclusively until I got familiarized with vim. It's way more powerful and can do anything that sublime can. Plus more.
The only downside is the learning curve, but you only go through it once.
FYI For the people running dev-builds (like myself) and are wondering why they don't get an update notification from 3079:
If you're already using dev build 3079, then there's no need to update
- 3080 is identical, except it will give update
notifications for beta builds only, rather than dev builds.[1]
Sorry for bring this up , but this is my honest question , why should I use sublime ? what is specific about it ? Let me explain , If I wanna text editor there is Emacs ( and vim for vim user's ) , and if I want to have specific feature like IDE's have (auto complete , GUI debugger etc ) , then I can use Qt Creator/Code Blocks/etc (which I don't need , Because I am not IDE user) , then Why should I use sublime , It does not fit in my either use cases.It is ide or text editor , If it is just text editor , what it provide which Emacs ( or vim) could not provide ?
p.s. my comment should look like bias opinion , but it is not really. It is just question I have in my mind.
Good question.
From my perspective, it's a text editor done properly which doesn't get in your way. You almost don't feel it.
Put it another way - there are very few annoyances that I've noticed about it.
It's very fast, it's configurable, it takes me 2 minutes to set it up on a new machine and have the same environment, regardless of the OS.
Here's a story:
I've recently started learning Clojure and I've been looking into editors which are best suited for it - I've tried LightTable, looks nice, but still rough around edges and slow, I've given a (new) shot to Emacs, but got discouraged when I realised I'd still have to learn all the shortcuts and stuff in addition to Clojure, IntelliJ Idea....
But then it struck me - does Sublime have a Clojure REPL ? It sure does and it's very nice.. 10 minutes later I was hacking away with a split screen and REPL, just like in Emacs.
And I didn't have to do anything complicated, no files to edit, no environment vars to set up, it was easy.
This sounds like a compelling way to get non-emacs users to start hacking clojure!
Then, sorry if it sounds nit-picky, but hacking some clojure with a split-screen and REPL is not just like emacs. Cider [1] has like a million features that elevate it above just a repl + code. Then there's clojure refactor mode [2] which lets you rename files and keep the namespaces in sync, unwind threaded forms, and 30+ other things.
If you're happy with emacs or vim then you probably shouldn't use it. Many people aren't comfortable with those two or prefer a mouse based approach without the overhead of an IDE in which case Sublime is a pretty good choice with lots of customizability and available plugins.
Edit: For me I do my coding/most everything in vim but if I get a new project I have to learn about I find it much more easy to navigate an unknown project in Sublime while I get it sorted in my mind.
I really disagree with the characterisation that it is for people who "prefer a mouse based approach." I hardly ever touch the mouse while using it.
For me, the thing that sets sublime apart from vim and emacs is the fact that it is a full gui app. Things like go to definition, autocomplete, build panel, command pallete, sidebar, context menus, are all technically possible in vim, but hacking these features into a command line interface always ends up seeming clunky, confusing and slow.
This also helps discoverability of features. If I want to do something, 99% of the time I can just search for the command in the menu or in the command pallete. Then they keyboard shortcut is clearly visible, and if it is a feature that I expect to use often I will make note of it. In vim (for me at least) this would require searching online for how to do something plus 10 minutes memorising the obscure commands to type into the command line.
Compared to IDE's, sublime has most of their features that I use on a regular basis, but is comparatively light to use. I'd much rather pop open sublime to quickly edit a file than launch eclipse.
>For me, the thing that sets sublime apart from vim and emacs is the fact that it is a full gui app. Things like go to definition, autocomplete, build panel, command pallete, sidebar, context menus, are all technically possible in vim, but hacking these features into a command line interface always ends up seeming clunky, confusing and slow.
I can't speak for vim, but Emacs is also a "full gui app." It has go to definition (in fact, I wouldn't be surprised if this idea was invented in some incarnation of Emacs), autocompletion, and various other such features like gdb integration and build message hyperlinking. The discoverability argument applies as well.
I disagree, Emacs isn't a "full gui app" even if it has a gui with menus and can show images etc.; because almost all kind of interaction happens inside buffers opened in (new) windows. there are no proper dialogs/popups (they're not used even if it's possible), so Emacs is not a proper GUI app as anyone would expect.
I don't claim it's a good or bad thing, a lot of people love emacs because of it's buffer/window centric approach, but it's not even remotely close to what you would expect from a modern gui, so Emacs is still oddball when compared to all the other gui's, which is why new users still struggle with it even though on paper Emacs has all the features other gui editors have.
So all in context, it sounds to me like you're saying that what sets Sublime Text apart from Emacs is simply that it uses a familiar user interface. I suppose that's fair enough.
What I wouldn't say is fair, though, is characterizing something as incomplete and especially improper simply for being different from what you're used to.
It's not just a familiar interface. It's a better interface. Smooth scrolling is better than line-based scrolling. A popup is better at alerting the user that input is needed than a small prompt at the bottom of the screen. The command pallete, which is clearly visually distinguished from the surrounding text by a gui border, is better design than yet more lines of text indistinguishable from the rest. Current selection highlighted in a bright, theme-able colour is better than just toggling the background colour. Little graphical icons next to lines indicating changes, breakpoints, etc is better than a random text character put before the line. Smooth animations are better at conveying change than instantaneous changes to text. Filesystem trees with pixel-wide connector lines and icons indicating file type, displayed in a smaller font than the main text are better than a file tree drawn with ASCII art. The fact that key bindings can interfere with your terminal emulator or shell's keybindings is an annoying restriction.
If all these things weren't objectively better in some way, then the gui app could just draw lines of text instead of windows, borders, selections, themes, images, and animations. But it doesn't, because lines of text is a worse interface for almost everything except the actual buffer you are editing.
I know vim very well. But I only use it out of necessity now when I'm on remote machines, because it is worse than a good gui app, precisely because it is restricted to its grid of text interface.
>It's not just a familiar interface. It's a better interface. Smooth scrolling is better than line-based scrolling. A popup is better at alerting the user that input is needed than a small prompt at the bottom of the screen. The command pallete, which is clearly visually distinguished from the surrounding text by a gui border, is better design than yet more lines of text indistinguishable from the rest. Current selection highlighted in a bright, theme-able colour is better than just toggling the background colour. Little graphical icons next to lines indicating changes, breakpoints, etc is better than a random text character put before the line. Smooth animations are better at conveying change than instantaneous changes to text. Filesystem trees with pixel-wide connector lines and icons indicating file type, displayed in a smaller font than the main text are better than a file tree drawn with ASCII art. The fact that key bindings can interfere with your terminal emulator or shell's keybindings is an annoying restriction.
I agree with almost all of this, which is why I use Emacs' graphical interface instead of its terminal interface.
> I agree with almost all of this, which is why I use Emacs' graphical interface instead of its terminal interface.
You can't be seriously saying this because Emacs' graphical interface lacks half of them. Here is a breakdown:
> Smooth scrolling is better than line-based scrolling.
I can't see any smoothness in scrolling of Emacs' graphical interface in Linux.
> A pop-up is better at alerting the user that input is needed than a small prompt at the bottom of the screen.
Only a handful of 3rd party packages use some badly-imitated pop-ups and I've never seen anything even resembling a pop-up in Emacs' graphical interface (maybe except the GTK+ open file dialog)
> The command palette, which is clearly visually distinguished from the surrounding text by a gui border, is better design than yet more lines of text indistinguishable from the rest.
I can't see anything resembling the command palette Emacs' graphical interface. Everything is either use the minibuffer or open a new window.
> Current selection highlighted in a bright, theme-able colour is better than just toggling the background colour. Little graphical icons next to lines indicating changes, breakpoints, etc is better than a random text character put before the line. Smooth animations are better at conveying change than instantaneous changes to text.
I guess we have those.
> Filesystem trees with pixel-wide connector lines and icons indicating file type, displayed in a smaller font than the main text are better than a file tree drawn with ASCII art.
Speedbar isn't even close.
> The fact that key bindings can interfere with your terminal emulator or shell's keybindings is an annoying restriction.
>I can't see any smoothness in scrolling of Emacs' graphical interface in Linux.
I'll grant that Emacs doesn't have this. Most programs don't either, though, and in the few I've seen that do (e.g., Firefox), it slows scrolling down so much as to make it practically unusable, even if it does make it easier to track the text with your eyes.
The real usability problem with Emacs' scrolling, in my opinion, is that the default scroll increment is too large. That's easily fixed. Some people also don't like that keying the cursor past the top or bottom of the window causing a large jump as the displayed region recenters around the point, but again, that's easily fixed.
>Only a handful of 3rd party packages use some badly-imitated pop-ups and I've never seen anything even resembling a pop-up in Emacs' graphical interface (maybe except the GTK+ open file dialog)
Most prompts (e.g., yes-or-no prompts, the password prompt for auth-sources) initiated with the mouse use pop-ups. Between that and the file chooser, what exactly is missing?
As for alerting the user that input is needed, Emacs doesn't generally require input from the user except when the user has just deliberately issued a command which requires input, in which case they don't need to be alerted (the one exception I can think of is when opening an auth-source may fail, and Emacs does use a pop-up for authorization then). What's more important in the long run is how easy the input method is to use, and unless you're already using the mouse (in which case Emacs does use pop-ups, as noted above), pop-ups are not easier to use.
>I can't see anything resembling the command palette Emacs' graphical interface. Everything is either use the minibuffer or open a new window.
The command palette looks a lot like helm-M-x to me.
>Speedbar isn't even close.
I didn't say it was. Now, I don't know about connector lines, but direx looks the same to me as Sublime's file tree sidebar and neotree even has icons.
> The real usability problem with Emacs' scrolling, in my opinion, is that the default scroll increment is too large. That's easily fixed. Some people also don't like that keying the cursor past the top or bottom of the window causing a large jump as the displayed region recenters around the point, but again, that's easily fixed.
You're right on spot with that one but I'm not sure it's that easy. I mean, I know there are some variables for it, but I'll try to explain with my anecdote. The scrolling issues you mentioned was felt so alien in my first try of Emacs, so it was the first thing I set out to fix in my second try. I found the relevant page in Emacs wiki, and damn, there was like 10 or more solutions, some similar, some not, each with their own issues (according to the wiki page, not that I've tried all). Then I went further with a Google search, and there was even more different solutions. As a result, I gave up on it and I still use the defaults even though I hate it with passion.
Setting a sane default for such a user facing thing must be top priority, not less.
> Most prompts (e.g., yes-or-no prompts, the password prompt for auth-sources) initiated with the mouse use pop-ups. Between that and the file chooser, what exactly is missing?
(I don't know what unfamiliar had in mind so I'll try to explain my own thoughts on the this.)
Things like search/replace/goto doesn't use pop-ups. But you're right that they don't need to, thanks for clarifying that. I was actually thinking about things more like dialogs rather than yes/no prompts. Again the window-centric approach I mentioned elsewhere in this thread. I don't have exact things in my mind, but yeah, command palette again. I would much prefer C-x C-b to show a dialog/popup which immediately gets focus, and in which I can either easily select the buffer or discard the dialog easily in case I change my mind. Or the About Emacs screen. I know it's not a functional thing but still one would expect it to show a dialog window instead of a buffer. Or the menu bar menus. I don't have a specific pain point with it but the whole thing still feels very odd. There is a lot of commands there, some are checkboxes, some fire up some prompts etc. I'm not sure but I guess some of them would be hidden under a dialog window in a more traditional gui application.
I don't think I'll be able to get more specific in this issue as it falls into the realms of "xfeels better but I don't know why". The only thing I know is the extreme use of windows and buffers and it doesn't feel right. I'm sure it feels just right to Emacs veterans but as a newbie I can tell it doesn't to the rest.
> The command palette looks a lot like helm-M-x to me.
I've looked at it and it seems nice. Thanks.
>>Speedbar isn't even close.
> I didn't say it was. Now, I don't know about connector lines, but direx looks the same to me as Sublime's file tree sidebar and neotree even has icons.
I checked both of them and I'm sure none of them are what unfamiliar had in his mind when talking about "Filesystem trees with pixel-wide connector lines and icons indicating file type, displayed in a smaller font than the main text are better than a file tree drawn with ASCII art." Both as ASCII art as it gets. Both are still rendered inside a buffer and they use a different font than the other gui elements in the system. The only different thing is neotree can display icons and that's all. Both are only marginally better than speedbar and they're joke when evaluated according to unfamiliar's criterias above.
> What I wouldn't say is fair, though, is characterizing something as incomplete and especially improper simply for being different from what you're used to.
I didn't tell them to offense Emacs fans, so sorry if you're offended. And the point is not being different from what I am used to, it's being different from what the rest of the world used to, only the Emacs users are accustomed to the Emacs convention of graphical ui's, and the way Emacs does it is not a proper gui in the sense that they invented their own conventions and they're different from every other GUI convention in the world. I'm not implying anything insulting here.
Incomplete GUI is another thing, yes, Emacs gui is incomplete because it does not use all existing GUI facilities and conventions to the full extent, and prefer existing Emacs ui facilities instead of gui toolkit's. Again, being incomplete is their choice, that doesn't mean it's a bad thing as I said in my previous comment (and a lot of people actually love it), but if you find that offensive I can't help with that.
I'm not offended or insulted by what you said. I don't even disagree with most of it, except maybe how you're using the terms "complete" and "proper." Saying that something isn't complete or proper generally really isn't compatible with a claim of impartiality.
I really have no problem with criticism of Emacs (provided that it's true, and now that you've expanded a little, I think what you're saying is true), but if you feel that familiarity (whether everyone's or just someone's) really sets Emacs and Sublime Text apart, call it criticism! :)
I want to explain the terms again. First of all "not proper" or "incomplete" isn't the adjectives I've used for Emacs itself, but the GUI of Emacs. I did use proper in the sense of common GUI idioms and conventions, and I'm not a native speaker, so if you think that was not a right choice, you're probably right.
For the incomplete, again we are not talking if Emacs is complete or not, we are debating if Emacs is a "full gui app" or not, and since I don't think it is using gui facilities to full extent (and instead it just creates a basic gui window, shows some menus and prompt dialogs here and there, and then handles everything with it's own mechanisms like windows and buffers), it's not a "full gui app". Again, if you have a better word of choice for it than the words I chose, I'd be happy to accept them. Sorry it caused trouble more than it worth.
I am using Sublime for programming and here is why i use it over Vim or Emacs or an IDE.
Vim is "way to go" editor for me on remote connections to server. But on my local machine, vim requires lots of configuration in order to let me be productive (at least for me). For example, Vim's regex engine is slow comparing to Sublime, which will be freezing for 2-3 seconds when you are doing some complex search and replace. This can be fixed by some config, but Sublime doesn't have this problem at all.
Sublime is easy to use from dummy programmers to experts. Not Emacs or Vim.
IDEs are mostly specific to a programming language, if not, they are memory hog to handle everything and takes around a minute to get ready for me to start typing code.
One of the best features of Sublime is that, it lets to decide if you want a text editor or a IDE like experience from it. Customise it however you want.
Of course it is not for everyone, I guess the best is to give it a try and see yourself.
For me, Sublime Text feels like an editor with the ethos of Vim/Emacs, but designed in the 21st century, without all the legacy baggage.
The key-bindings are based on modern GUI standards. The configuration uses simple JSON files. It provides most commonly used features as standard.
Vim/Emacs are still probably more powerful once learned, but after using vim for a few years (admittedly not trying that hard to improve), I felt I was able to get to the same efficiency in Sublime in a few weeks.
You don't, really. It's just a solid editor in a GUI environment, not as heavy as an IDE, not as esoteric or hard to learn (sorry guys) as emacs or vim.
I've used it pretty much full time for three years programming JS. Autocomplete is non-existent in JS, and WebStorm was just too bulky / laggy for me. The SublimeLinter plugin was enough error handling for me, and there was a Grunt listener running at all times running other validations and doing autorefresh.
I don't see why you are getting downvoted, this is a legitimate question.
Sublime is certainly not an IDE. AFAIK it can not do any of the things that make IDEs worth using : automatic refactoring, statistical analysis of your code, ... (not that it tries to).
It is a text editor with plugins. The barrier to entry is way lower than for something like vi or Emacs and that's it.
This question is pretty much like a vim user asking why he should use emacs (or viceversa). Sure, they cover a lot of common features each, plus their big differences.
Sublime is just another alternative. No real reason to use it if you prefer what you already have. It's just a matter of trying it out and seeing how it works for you.
Note: I no longer use sublime. vim+ctrlp+other plugins has replaced it for me.
IMHO, sublime is a lazy yet flexible editor, it has very fancy out-of-box experience, you don't have to download a lot of stuff from the internet and make your own customizations before you can finally gets started with what you intended to do few hours earlier.
I know that both vim/emacs have very handy package manager, but they don't ship with vim/emacs.
I give ST a try for a few months a year or so ago. Maybe this is no longer true, but at the time, the first thing everyone did with ST is download and install Package Control, which is no more integrated with ST and doesn't really work any better than the Emacs equivalent (can't speak to Vim).
My impression was ST gives you something that is almost as powerful as Emacs or Vim without requiring nearly as big of a shift in how you deal with text in the other applications you use all the time. That and the fact that it looks prettier and more like a platform-native application I think explains the appeal. The amount of customization needed didn't seem all that much less to me.
I've found Package Control to be pretty painless. I can go from "Huh, I need syntax support for this language" back to editing in a few seconds.
The other thing is that when I do want to customise something in ST, it will usually just involve editing a single obvious value in a JSON file, rather than hunting through docs to find out what keywords I needed to add to my vimrc.
Certainly there are more powerful tools (emacs and vim - or 3dMAX and Rhino, when comparing with Sketchup) but Sublime/Sketchup are so fast and easy to use from first day by amateurs and professionals making them very hard to beat.
I don't use them everyday but I can be quite productive with both. It would take ages to be productive with Emacs or 3dMAX using them only every other week.
This problem doesn't seem tractable in anything approaching the near term. There are just too many dynamic layers, each with their own competing product ecosystems, which in turn each are controlled by competing interests. Perhaps at some point in the future the entire stack from hardware to application level APIs will become commodity products that nobody benefits from differentiating. At that time, perhaps software can just be finished once it arrives at feature maturity. Until then, UX, architectural, security and other assumptions made about the application environment will continue to age poorly, and software products will become outmoded unless actively developed.
I've been running the last stable build happily since August. Running this new build causes all four cores in my rmbp to spin up to 99% repeatedly (Activity Monitor says it's Sublime) and the fans to go wild. Is this happening to anyone else? I had to revert to the previous version which fixed it :(
I ran into this too. It's because of the index that Sublime builds for its Goto Anything feature. If you never use Goto Anything, in your User Settings:
On every file change ST status bar says - indexing files. And it takes > 10s (I have a lot of files). When it does that - 2 CPU cores are loaded at 99%.
Opened the console (@jskinner suggested to enter sublime.log_indexing(True)) and there was a message that index is corrupted and I have to remove it. Index is located in:
/Users/bumbu/Library/Application Support/Sublime Text 3/Index
Removing all the files from that folder did the trick.
http://www.sublimetext.com/forum is a better place for this, but as a stopgap you can disable file indexing via the index_files setting. You can also find out more about what indexing is taking place by entering sublime.log_indexing(True) in Sublime Text's console.
For me it was trying to index a huge folder containing images, you can use project settings to exclude some folders with the folder_exclude_patterns setting.
I used to simply ignore that nag screen, but decided to buy a license of ST3 since I use it every day - best investment in a while. I hope to see a stable ST3 build soon and some nice new features soon :)!
I love the 'Goto Symbol (in Project)...' feature, but I really wish the input would be populated with text you have selected in the editor. This way you could jump to a function/whatever underneath the cursor by doing something like: Cmd-D, Cmd-(Shift-)R, Enter - instead of copy-pasting, or retyping the symbol. I added this to the mass of suggestions in the ST forum, but I guess it has been lost or rejected :(
I've found that I pay much more attention to the terms of use for projects supported by smaller teams -- it's hard to feel like I'm ripping off a giant company like Adobe, but I have a hard time telling a small shop basically "HA! Thanks for trusting me stupid, good luck developing your great product with no money."
I buy every piece of software that I find I love and use almost everyday. For me this has become JetBrains and Atlassian products. I love their stuff.
In response to the post topic, I don't use Sublime. It's really good, definitely prefer a real native application over Atom. I do wish it was open source and the author still sold it. I hate using software where there's a sole author and if he gets hit by a bus, it's up in the air what happens next.
I use PyCharm and Vi in my workflow. I've always found I use two editors. One more focused on my programming at hand, and another for general files to reference, notes and so forth.
So when I remote into a server, it's Vi again. I like PyCharm because it has a Vi mode and everything just works. If you're using Python at least, it's a top tier environment to work in.
That's reasonable, but particularly in a business context, if Photoshop is helping you make money then Adobe deserves your money as much as anyone else.
Not to mention that if you're a startup and you plan to grow into a large company or get bought by a large company (i.e. all startups) you are going to have to get your house in order at some point.
They don't incentivize purchasing in any other way than displaying a popup reminder once a day. It's a fully-featured product without the license, so there's not much motivation to buy it unless you view the purchase as a donation of sorts.
Most of the people I know have never bought a Windows license for their desktops.
Heck, TBH, the only people I know personally that have licensed windows copies have them on their laptops. (and I know plenty of people who use Windows).
Why would it surprise you that people use sublime in non-compliance with its EULA?
The guy said he will be coming back with more, and the most delay between updates was like 8-9 months -- something that happens all the time for commercial projects where you might or might not see an update in 1 or even 2 years.
In the last 2 months, he has been publishing an update dev release every 1 week or so.
August 2014 beta build was a really small update and the only one in year 2014. To be honest, my feeling also was that project has been abandoned. ST3 was silent for about a year and is supported by the single developer (as far as I understand it). No updates (except for one in August) in the times of Atom release, this looked like there was no more motivation for the Sublime Text developer. I am really happy that it's not true and Sublime is active again in 2015.
From the look of it, it seems that the dev works very intermittently on Sublime.
For my part, I would like to see something like LimeText (open source sublime clone) gain some traction. ST development cycle does not inspire me a lot of confidence.
I agree, that's why I say it was almost inactive for about a year, not 15 months. The point is, the real delay was bigger than 6-9 months, at least it's how the one could think about it.
For registered users it has been active again for the past two months—this is just the first stable release from that work. There was a noticeable silence from October through January, but lots of activity ever since. Hopefully it continues.
I tried Atom during the lull and it's gotten really great, but ultimately went back to the plugins/snippets I know and love.
In case anyone isn't aware, Package Control[0] adds an incredibly simple package manager to Sublime in order to automatically install/update plugins. After that's been installed, I'd recommend browsing the popular packages (already linked in another comment) or just hitting Ctrl+Shift+P, "Install", and searching for the names of languages/tools you use.
One plugin I'd recommend for anyone is All Autocomplete. It extends Sublime's autocomplete detection to match across any open file, and not only the current file.
Also Ctrl+Shift+P searches through all of Sublime's and your plugins available actions. Ctrl+P allows you to switch files without your mouse.
* github: direct access to the remote github directory (issues, pull requests, etc.)
There's also a ton of language specific packages (lint, color scheme, etc.)
My main productivity tip would be to use the "ctrl + p" search command a lot. It matches searches very nicely (partial matching). One can look for files in the project, specific line in the active file (if you start with ":"), specific methods (if you start the search with "@"). ST3 also has a symbol lookup command which is really powerful ("ctrl + shift +r").
Obviously loads of good plugins out there but I can highly recommend settings the "save_files_on_focus_lost" preference or whatever its called to true. Such an improved workflow for webdev and suchlike.
CTRL+D (Might be CMD on Mac) will also select the next occurrence of a symbol/selection. And Ctrl+U will undo a selection from this method or the parent post's method.
Aside from being able to simultaneously write in multiple places, you can copy-paste across multiple cursors; highlight 5 variables, copy, create 5 new lines with cursors, paste. Each line will have one of your copied variables. Try using Find with regex and alt+enter to select all matches with separate cursors.
Many plugins also support or add onto this feature. I love TextPastry to easily insert number ranges and patterns across multiple cursors.
I still have issues on my desktop where sometimes I can't interact with the text area of sublime using my mouse. I can still use the mouse with the menus and stuff, but scrolling and clicking in the text does nothing and I have to use my keyboard only. Still not sure what is causing this issue as it doesn't happen all the time. The fix is usually just rebooting my PC which is rather annoying.
You can use Sublime to remotely edit files on your Raspberry Pi. Running Sublime directly on the Pi is not supported officially and it will probably be too slow anyway.
Run Command has been replaced with "Build With" command,
Why wasn't it was kept at its place and additionally "Build With" was introduced? Some disturbance is created.
Honestly, I've never seen another product here getting a post for every minor build! Nice to see such a die-hard fan base! But, please, face the reality - many have moved over to Atom already and are not looking back. Atom is alive, the ecosystem is already huge, atom-shell is getting popular as well. Unless Sublime gets open-sourced, it's in a slow agony. Remember TextMate? It had a huge loyal user base, but who is using it now? It got open-sourced, but a bit too late!
>But, please, face the reality - many have moved over to Atom already and are not looking back.
I seriously doubt it.
First, people kept using TextMate when it was dead for 3 years or so. The most ST3 has been idle was 6-7 months, and before and after that the update pace (for dev releases) was great.
Second, it's not like anything major was missing from the editor even 2 years ago, or that it stopped working or anything. People use Vim which is a 30 years old codebase that hasn't had major updates in a great while, so not sure were the pressure for ST is.
Third, I doubt Atom has that much adoption. For one, it is and will always be slower, due to the language and rendering model (custom C++ vs Javascript and ultimately, the DOM).
As an anecdotal point, most people at work use either Vim or ST3. Nobody uses Atom.
>* Remember TextMate? It had a huge loyal user base, but who is using it now?*
Atom may always be slower, but the speed difference could eventually become negligible. If ST3, in it's current form, existed 20 years ago, people would have been making the same argument about Vim vs. ST3.
Actually, rendering is often faster in Sublime Text than in vim. I am a vim user and use the 'cursorline' and 'relativenumber' options and until recently I could notice rendering slowness on OS X and Linux. Things seem to have gotten better recently (either in vim or due to hardware advancing), but I never saw such slowness in Sublime text.
(I wanted to like Sublime and have a license, but Vintage mode is a too leaky abstraction/emulation for me ;).)
I hope so, but it'll require significant improvement. From the command line, "subl ." loads almost immediately, whereas "atom" can take 10+ seconds. (on a MBP with 16gb + SSD)
Atom is not that slow in practice... except the slow startup, for daily business it's fine - I'm using it with a full suite of linters and autocomplete plugins on the older MacBook Air and it's not laggy.
I've made a few attempts to use Atom on a daily basis. Unfortunately, I continued to experience crashes with the linter, autocomplete, and Haskell-related plugins--or the plugins would work, only to break during the next Atom update. It also wasn't possible to use my favorite ligature-based font without breaking the cursor position. Not to mention the rendering/performance issues.
There's a lot to admire about Atom. But Sublime is stable and silky smooth. And I continue to use Vim happily every day without issue, despite its ~25 year age.
If you're that interested to try the atom browser might I suggest having a look at Brackets[1]? It was out before atom and I have been using it to replace ST3 just because I liked the idea of it.
I haven't tried atom it didn't initially release with windows support so I just stayed on brackets.
It does some weird things in full screen, especially if you have multiple windows going. I've closed one window, but the save dialog pops up on another... but when I swipe over, that dialog goes away, and the modal that I can't click on blocks the rest of the UI. Nothing but a force kill can resolve it. I've been using it 4-12 hours a day for several months, so I'm rooting for it, but losing work will always trump whatever OSS cred it has.
My impression when looking at HN is that people are not that impressed with Atom. Nobody I know in the real world uses atom, but I'm a poor data point.
The reason why everybody is up in arms about every minor update is that a lot of people see every little peep from the dev as (hopeful) proof that the project isn't dead.
People here still get excited about LISP, too. I can understand Clojure, but Lisp, come on! It was in the 80s and 90s when I used LISP for AI and my favorite muLISP, but it's 2015 already! So, this is a boutique community, don't make generalization from it. Atom is doing pretty well for its infancy!
I was super excited about Intype in the past - much more excited about anybody could be about Sublime. After many, many years and ruined potential, I gave up. Just recently found that it's still alive. I remember e as well. It got open-sourced... and what? There are many editors, but Atom has all indications that's it's here to stay! I'm not so sure about Sublime given the patterns. A loyal community is not enough - a dedicated development team is what's most important!
Didn't know HN means Historian News. People just are so excited about LISP here, because of some loyalty to Paul Graham. Smalltalk and Forth get a lot less attention than LISP although they share a lot of its beauty - simple yet powerful syntax. Well, sometimes I also wonder if this is Haskell News, too. :)
I tried it once and had the same experience. I'm really just waiting to meet even a single person who uses it as their daily IDE in a work environment (or even at home - I still haven't seen that.) At that point I'll consider trying it again.
I love the concept. Just not enamoured with the execution.
I use it daily as my IDE. I find that startup time is indeed slow as a dog, but once it is up and running (and it's typically open all of the time, so startup time isn't a real issue) it runs fast enough. At certain times I notice small delays on more complex ops compared to sublime, but nothing significant. The main pro's for Atom, for me, are the way the eco-system is developing, the open-source nature of it, and I'm slightly more happy with the interface. If push came to shove though, I could be happy in either sublime or atom.
The difference in speed in these editors is so small that, if you find it's having a measurable effect on your productivity when coding, you may want to re-look at how you measure productivity or indeed how much time you're churning out code versus other development activities (thinking, planning, testing, talking).
The issue with speed in an editor isn't so much that if your editor is slow that it makes you code faster, but that if your editor pauses, it interrupts your thinking and prevents it becoming very natural and quick to use, like an extension of your mind.
So it's not so much '60 seconds of waiting for the editor in a day', as '2s delay opening that file so my brain switched to thinking about something else, slowing me down for 10+ mins'
I do use it as my daily IDE. It is MUCH slower than Sublime, but I'm trying to ride with it through its bugs and builds. I occasionally use Sublime still, and go through periods of time where I use RubyMine.
I am using Atom daily and I'm super happy. It's missing a thing or two from ST 3, but I got more than I had taken away, honestly. I have paid for Sublime unlike most here who gang up to silence me. I've bought a bunch of plugins for Sublime, too, so, I've invested more than $100 in the ecosystem.
I use my text editor for a bunch of ad-hoc edits, not just working on projects, but you are right. Speed is less important than buggy behavior (I say this not as a hater, but as someone who is working in Atom all day)
I've only experienced bugs in the early days where you couldn't precisely select a character with the mouse and everything else I've experienced is usually third-party plugins. At least Atom does a great job identifying with plugins are causing issues and collects deprecations and exceptions, and those can be reported by one click. That's why I think Atom brings unique solutions to common problems and, yes, it's a bit slower, but if it becomes popular, maybe it can get a native renderer - who knows. It's too early to predict its fate! So far, given it's infancy age, I think it's done a great job!
I guess I don't really really notice it being slow (I'm on a new mb air nothing fancy), I've been using atom for 6 months now without any problems. I hear people often speak about it being slow and buggy, when specifically is it running slow so I can compare it to my own environment?
I love using atom, and sublime is nice but I haven't found a reason to purchase it and switch over yet.
Over the years I've gone back and forth between Sublime, vim and emacs. Atom is the first editor I really love. I've been using is for about a month now for serious haskell development. Yes it's still a bit slow to start up and a little buggy but it's not even at version 1.0 yet. I just really like the UI and the simplicity of installing and configuring packages.
Imho slow is one thing (I could probably even live with the performance) - the other thing is that font rendering in Atom is horrible. At least for me on Windows the text is blurry as hell. No comparison to the clearness in Sublime Text or other native editors (Visual Studio, Eclipse, Notepad, ...).
Brackets is better in that regard. Both brackets and Atom provide better extensability APIs than Sublime - but that doesn't help when the performance is worse than complete IDEs.
You've never wanted to open a multi-megabyte data file in a text editor before?
"You shouldn't be opening large files in it anyhow" is a cop-out. My text editor needs to edit whatever text files I throw at it. Choking on too-large a file is a showstopper.
Automatic code generators have a nasty habit of spitting out huge source and header files, I'm routinely digging around in such files (ASN.1 to C++, multiple files 10MB and up) and switching editors to do that would be completely unacceptable. It would be more of a hassle if the compiler split up the output.
That sucks, but it's not the common case. I personally wouldn't use even Sublime for these either as you can't do anything productive with a 30MB XML document in a text editor anyway.
I need to view and edit CSV files which are consistently hundreds of MB, sometimes a couple of GB. It's the way it is, I can't help the format in which vendors send us files...
True. You have to agree though that this is unfair to Atom. It's new, yes, it uses WebKit now, but it may have native rendering tomorrow. To shoot it down in the early beginning given it's doing many things right (like native package management) - it's not the right thing to do in this forum!
I tried Atom and to me, the editor just feels slow. I've been using Sublime Text for a long while now and last week I decided to "bite the bullet" and buy a license. It's just too nice of an editor for languages like Ruby, Markdown and even C# (with the OmniSharp plugin).
Kudos to the Sublime folks.