Sublime Text 3 Build 3080
sublimetext.com
sublimetext.com
Kudos to the Sublime folks.
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.
Or maybe I've just been unlucky/incompetent.
To be fair, Atom requires node.js (recently moved to io.js) to even run (though it's embedded)
For statically-typed code, a text editor can't compete with a refactoring IDE (e.g. VS or Eclipse) IMHO.
Every lint extension I've seen seems to drag a full install of whatever the popular implementation of the language is.
Edit: Checked a bunch of the others, including those for Lua, XML and Python. None of them come bundled with the underlying tool.
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)
Is there a Package Control channel that ONLY lists packages following that noble rule? I'd be a lot more willing to try things out from that.
Just look at the contortions this little package has to go through to apply a color to portions of text: https://github.com/Monnoroch/ColorHighlighter/blob/master/Co...
It has to create and apply a fake theme merged with your current theme so colors can be added "dynamically"[1].
The ancient Emacs (I hate a hate/love relationship with it) can do this is several ways, the "modern" one are overlays IIRC.
[1] As expected, this will lead to bugs related to the users' color schemes: https://github.com/Monnoroch/ColorHighlighter/issues
(But the strategy works for him, so...)
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.
I'm never going back.
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).
Certainly better than FTPS.
Regardless their point was poorly explained/explored.
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.
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).
If you also use ST regularly and can afford it, I highly encourage you to support development and buy a license right now.
The only downside is the learning curve, but you only go through it once.
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]
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.
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.
[1] https://github.com/clojure-emacs/cider
[2] https://github.com/clojure-emacs/clj-refactor.el
The examples in [3] showcase the features of clj-refactor rather neatly.
[3] https://github.com/clojure-emacs/clj-refactor.el/tree/master...
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.
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.
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 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.
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.
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.
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.
N/A
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.
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 "x feels 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.
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 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.
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.
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.
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.
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.
I know that both vim/emacs have very handy package manager, but they don't ship with vim/emacs.
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.
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.
Then stop calling it a beta?
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.
And this is why it's important for your editor to be free software. Emacs isn't going anywhere, and they don't have unjust control over my computing.
I don't understand this. What is unjust about a software author charging for their work? I and many others are happy and willing to pay.
Nothing, but using a nonfree license gives the developer unjust control over you.
"index_files": falseOn 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.
I'm curious what most people are using it for, since the license clearly states that you need to buy a copy for professional use.
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.
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.
"Sublime Text may be downloaded and evaluated for free, however a license must be purchased for continued use."
Personally, I was happy to purchase a license because I think it's a great application, but I admit that it's on the pricey side.
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.
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?
I also have zero doubt that people have been using it for professional purposes in violation of the license.
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.
I tried Atom during the lull and it's gotten really great, but ultimately went back to the plugins/snippets I know and love.
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.
MIN_WORD_SIZE = 3
MAX_WORD_SIZE = 50
MAX_VIEWS = 20
MAX_WORDS_PER_VIEW = 100
MAX_FIX_TIME_SECS_PER_VIEW = 0.01* git: git commands in ST.
* gitgutter: diffs in the margin (+,-, modified)
* 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").
Most of the productivity gains I get from Sublime are from packages like Emmet, DocBlockr and my own custom macros.
On OS X CTRL + SHIFT + UP/DOWN will create a new cursor on the next line up or down. And you can CMD + LMB-click to insert a new cursor anywhere.
I cannot count how much time this feature saves me.
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.
CMD+SHIFT+D is handy, too; it duplicates your current line.
Joking aside, depends on the language somewhat but this helped me get started:
https://realpython.com/blog/python/setting-up-sublime-text-3...
Edit: seems like they will need to be ported [0].
http://www.sublimetext.com/blog/articles/sublime-text-3-beta
It allows you to check which plugins are supported (and which aren't) by copying and pasting the contents of your package control user settings.
http://taoofmac.com/space/blog/2015/02/27/2210#running-subli...
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.
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?*
You'd be surprised.
(I wanted to like Sublime and have a license, but Vintage mode is a too leaky abstraction/emulation for me ;).)
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.
I haven't tried atom it didn't initially release with windows support so I just stayed on brackets.
[1]: http://brackets.io/
https://github.com/atom/atom/search?q=performance&state=open...
If it works for you, great. Hope you contribute and it becomes a great editor someday.
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.
I like Atom's plugin ecosystem, and am rooting for the open source option, but it really is quite slow and buggy.
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!
I guess that they haven't been good at communicating that they are not in hiatus!
But i always get annoyed by how SLOW it is.
I love the concept. Just not enamoured with the execution.
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).
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'
It's still a lot slower than Sublime, but it's fine for me. (im not primarily a developer tho)
I love using atom, and sublime is nice but I haven't found a reason to purchase it and switch over yet.
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 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.