"The default website, icon, and theme are ugly to say the least" I can't be the only one who completely, utterly disagrees with this? I absolutely love the default theme and I think the icon looks great (much better than the alternative provided). That being said, I don't want to start a whole pointless discussion about taste here, it just kind of bothered me to read something like that in a blog post that talks about setting up a text editor.
I think ST2's chrome is functionally bad, rather than aesthetically, and I'm not sure it can be fixed with themes. The way the sidebar and the tab bar interact to show which document is active can be extremely confusing.
> I find the blog post with a title "setting up sublime" that doesnt cover the package manager for plugins pretty laughable. Its kind of the best part.
Installing package control is basically the first thing this post covers.
I love the icon. I don't have an opinion about the default theme except to say that part of the whole point of Sublime (to me) is to find a custom color theme for your code. It's like css for your workspace!
I use a modified Cobalt that has much more green in it. Honestly I love that Sublime allows you to fulfill that urge to express yourself while you're expressing yourself (yo dawg etc.).
Funny to see that listed in the article. I've experienced the same thing. Had a lot of trouble hunting it down when switching apps. I've been using this replacement from Dmitry Svetlichny: http://dribbble.com/shots/468176-Sublime-Text-2-icon-you-can...
Don't absolutely love it, but after a month or so it's definitely helped me find the app easier.
The default is pretty horrid I think. The sidebar's blue draws way too much attention. Folders and files aren't differentiated nearly enough. The tabs also draw too much attention to themselves. Honestly it looks like the most barebones Mac app that there is, which is exactly what it is. The icon isn't much better. Looks very generic and 99 Design-y, doesn't express what Sublime is about at all. I personally prefer this one: http://dribbble.com/shots/311515-A-Sublime-Text-2-Icon-that-...
Looking at the default icon a bit more closely, the gradient kind of messes with my eyes and makes the S look fuzzy. If you compare it to other common icons, you'll notice none of them transition quite so harshly that the gradient produces more contrast than the other shapes in the picture. The new icon provided simplifies it a lot, and makes the S more readable, but at the expense of throwing away any hint about what the app is for. I think it'd be best to just tweak the original icon's colors so it looks more clear, while keeping the keyboard key look to it.
I think the main problem with the ST2 icon is that it looks like a disk drive. I often ignore it because in my brain, I assume it's a disk and not an editor.
Yeah, I like the default theme. About the only thing I changed was the tab behaviour to highlight modified files ("highlight_modified_tabs": true) and make the folder labels bold in the left-hand menu ("bold_folder_labels": true).
I tried to like Sublime, I really did. Bought a license and used it for four months, before going back to Emacs.
Sublime is nice, and easy to extend, but it only extends so far, while Emacs is infinitely extensible.
You can practically live in Emacs[1]; some things I wanted to do in Emacs were hard to pull off, but I'm yet to find something it can't do. And it does so for years.
Fashionable editors come and go, but Emacs forever stands; and if there is one thing I don't think I'll be able to ever do again, is learn another set of editor shortcuts. Those I used were drilled there ~10 years ago, and I don't think they'll ever come out.
Also, author seems to take great deal about changing the editor theme and icon. Why should you ever care about that, outside a screenshot contest?
Editor should look good by rendering a nice font at a size you find comfortable, highlighted in colors you find easy on the eyes. If you look at the chrome, well, you're not spending enough effort editing.
[1] I'm not the one to start wars. vi might be just as good, but I'm not going to learn it this side of the river Styx.
What I'm about to say comes down more to philosophical differences than differences of opinion about Sublime Text 2.
I do not have extensive experience with Emacs. However, I've often heard it described as an infinitely extensible system, or as you put it "you can practically live in Emacs."
I find that a bit odd, because it's like building an OS inside an OS. I already have an infinitely extensible system, namely my actual OS (*nix). I want a tool that nicely fits within that system, not supplants it. And then I want that tool to be the best possible tool at what it is (in this case, a code editor). If I need other operations/actions, then I will use other tools.
The problem with this argument is that the OS doesn't provide you with the mesh that integrates all these tools together under a consistent interface. That's what Emacs and Emacs Lisp provide. I can jump from code to documentation to org-mode (todos) to music player to git... and all the while I'm switching from tool to tool, the shortcuts are the same, the graphical interface is the same, and I never need to change windows. An Operating System doesn't give you that seamlessness... the seams are all too visible.
Emacs was designed to work extremely well with Unix, or any other host operating system, and provide a way to easily gather tools (or fairly quickly replicate them in an os agnostic/portable manner) and provide a cohesive and expressive user interface to work with the output of those tools.
You find Emacs "a bit odd" because it's necessary to put in about a week of diligent study in, that's the barrier to entry, STUDY.
Other editors are just editors, that may or may not have extensions, Emacs is a textual environment.
If you look at it from the perspective of games, It's kind of the difference between Pac Man and Minecraft.
I suspect there is far more of a flavour of elitism in ones use of a text editor than any true benefit in real world productivity.
I tried ST2 to see what all the fuss was about. I still use it occasionally (mainly for its layout view on the right hand side), but Notepad++ is my main editor as ST2 has a particular problem that you can't toggle the reloading of a changed file.
I use Vim for huge files.
In any case, when I am programming I spend more time thinking than typing and unless I am doing heavy re-factoring of code, more powerful text editors are just a non issue for me.
Basically, yes, but with a prompt. Notepad++ will prompt you that a loaded file has changed and do you want to update it. ST2 will just load the file as soon as it realizes the file has changed.
The NP++ behaviour is ideal and a feature I use a lot. Unless something has changed very recently in ST2, there is no way to duplicate this behaviour. I believe there are some circumstances where ST2 will prompt you. IIRC if the file name has changed, but this is only part of the problem for me.
What do you use to replace command-T in ST2 in Emacs? I recently picked up Emacs because I'm doing a clojure project (I can't get ST2 to work with nrepl) but I am having a hard time without the command-T fuzzy search.
I have ido and find-file-in-project installed but neither of them seem to include directories in the fuzzy search. So if I search 'custcore' it won't match 'customer/core.clj'. If I instead search 'core' it is too broad of a term. I really need very little out of an editor, but this is one of those things.
(defun full-screen ()
"Indicate to the window manager that this frame should be full screen"
(interactive)
(x-send-client-message nil 0 nil "_NET_WM_STATE" 32 '(2 "_NET_WM_STATE_FULLSCREEN" 0)))
One setting I find invaluable is to use Paste and Indent for ⌘V instead of the standard Paste. This adjusts your indentation to automatically match the context it's pasted in.
To do this, put the following in your Key Bindings - User file:
You shouldn't set "trim_trailing_white_space_on_save": true unless you work alone, otherwise you're going to have random whitespace changes polluting your diffs.
Our coding guidelines at Stripe specify that whitespace is to be stripped. It works if everyone does it.
On the occasion where whitespace does pollute the diff, GitHub has a convenient feature where you can append '?w=1' to any diff URL and whitespace changes will be omitted.
The problem with universal whitespace removal isn't the output of the diff, imo, but the spurious conflicts in merges. A change should be minimal to allow easier merging.
Ideally whitespace would be trimmed from lines that have otherwise changed, thus ensuring a gradual (though probably never completing) repair of the code.
The number of pull requests I get where the diffs are completely unreadable because someone has this feature enabled is insane. On certain whitespace dependent languages (I'm looking at you Python) simply supressing the whitespace in the diff is not an option.
What are the arguments for having whitespace removal as a coding standard?
It's dead easy to accidentally add (or remove) trailing whitespace, which you find out at git diff time. Unless you want to have whitespace changes in your commit, you have to manually revert those edits back.
Having the editor just trim those automatically is just delegating the trailing whitespace care to a piece of software with a simple rule: no whitespace allowed.
If the entire team working on a project agrees to this rule, everything's peachy, and it's really easy to convert an existing repo to it - whenever you touch a file, if there are whitespace changes, commit them to a separate commit.
At the end of the day, it's just standard, so doing invasive changes to a project that doesn't follow that standard (as in the pull reqs you descibed) is wrong, but that doesn't mean the rule itself is bad.
As for ST2, it allows easy per-project settings so you can easily enable it globally and disable on a specific project if needed (or vice versa).
we also have a rule that when possible (like you've opened up an old file with whitespace issues), that you should clean it and do a whitespace changes only commit before getting to work. It makes everyone's life easier if they're not looking for the "real diff" in your commit.
It only pollutes your diffs if you're using a crappy diff tool. Whatever tool you use should have full control over showing leading, trailing, consecutive, or all whitespace differences.
No, the main problem is that it screws up merges. Until Git can ignore trailing spaces as part of the merge strategy, it will be a problem when someone removes trailing spaces in one patch and someone else modifies (with real code) those same lines. If you have a largeish number of changes it will be a nightmare.
Nah. Use araxis merge and all your issues go away forever. If other devs want to use shitty tools then that's their fault. If you have a repo and are trying to merge pull requests then you definitely should stop using shitty tools. Even if you don't trim whitespace you should have non-shitty tools for local usage.
I find it odd that Sublime is so widely loved. It seems like a way-station between Notepad and Vim/Emacs. The extensions are nice, and the GUI is easy on the eyes, but it seems that most of my peers outgrew their Sublime Text/Notepad++/Textmate stage by the time they completed their first year of undergrad. I would hate to be stuck in the slow world of Sublime Text limbo as a result of being too lazy to learn and customize Vim/Emacs.
I find it odd that Emacs is so widely loved. It seems like a way-station between Notepad and a proper text editor that fits in with all the other software on my system, using familiar keyboard and mouse commands so I can get things done instead of having to look up arcane rituals worthy of Git to do any moderately powerful editing task and learning a failed programming language to do any sort of scripting or customisation instead of using a modern one I already know. I would hate to be stuck in the slow world of Emacs limbo because it took so damn long to customise everything instead of just setting it up in a few minutes and then getting on with real work.
Disclaimer: Yes, this post is a sarcastic parody of the parent. Mostly...
You find it odd that Sublime Text is so widely loved? Seriously? It combines the greatness of some of the best editors out there into a single one that is approachable and sexy and you can't see how it appeals to the masses?
Let's list out some of my favorite features of Sublime Text (please keep in mind I switched FROM vim to Sublime):
1.) VIntage mode that allows for 99% of day-to-day vim stuff
2.) A plugin system that uses Python and offers a full-featured API (vimscript anyone? pfft)
3.) Full mouse/windows support (i.e. it's not ghetto mouse support thrown over a terminal window from the '70s)
4.) Textmate-style themes that even allows tweaking to the UI
5.) Native Linux, MacOS, and Windows versions
The only negative is that it isn't open-source, which I hate, but the licensing is very reasonable (it's per person, not machine, so you can install it on as many devices as you use)
I'd really like to see you give a real-world example of how it's slow compared to vim/emacs, because maybe I'm missing something. I've been using Sublime Text for over a year and have only had to break out vim a couple of times for some crazy vim-style search/replacing or to quickly open some super-large text files (I think better large-file handling is in the works for sublime though...).
Oh, and one of Sublime Text's best feature? It doesn't come with the elitist attitude that a lot of vim and emacs users seem to get... :)
As someone who purchased Sublime Text 2 over a year ago, I'll have to pay a $30 upgrade fee. Someone who purchases v2 now (or any time after the announcement of v3) will get the upgrade free. Anyone who purchased v2 in the 90-day period before v3 was announced will be able to upgrade for only $11.
Interesting that you pin it down to laziness. In my opinion it has more to do with the fact that the learning curve of Vim/Emacs outweighs their usefulness.
I can understand their use being much more of a necessity in previous years, but I think their time of unparalleled performance and productivity are over. Having used Vim for a few years (having studied it for many hours) and then switching to Sublime Text - I don't see any productivity decrease.
That being said, if you are happy using Emacs - by all means continue to do so!
It shouldn't be that surprising. I tried vim for a while, but I prefer sublime text. It's true that vim is more powerful, but for me that power seems to mostly theoretical. It doesn't seem to make me significantly faster in the real world. On the other hand, the basic text navigation keys in sublime text are the same as they are elsewhere in my os, so I don't have to switch in and out of "text editing mode" frequently. In any case, congratulations on advanced text editing learning curve.
A bit off topic, but the big win with Vim (and, from what I hear, emacs) isn't the speed per se; it's the lack of cognitive load. "I need to replace everything after the equals sign", for example, takes less concentration than "I need to move my cursor to the beginning of the word after the equals sign, hold shift, move it to the end of the line, and then hit backspace". Once I got past the terrible learning curve, being able to use those kind of abstractions made a noticeable difference in how much program state I can hold in my head while I'm changing it.
I think vi speed is much more theoretical than practical. v5j to select the 5 lines below? Sure, I can't think of a faster mode. BUT in reality
1. you have to check if you're in insert mode or not. Or you think you are, you're not, write vf5, press esc, press u to undo, retype vf5. Or you don't know and you press esc before it, so it's actually esc+v5j, and esc is not the easiest reachable key
2. you have to know you want to go down 5 lines. In reality, you know you want to go "a bit" down, so in a real world situation you either count (slow), make a subtraction with line numbers (slow) try to guess a number of lines, check what you've reached, keep retyping. This is all but "cognitive free". What is cognitive free (although requires more keystroke) is just press shift+down+down+down+down+down, for me.
I see your perspective, but I disagree that vi speed is mostly theoretical.
1. you have to check if you're in insert mode or not.
You should always be in normal mode unless you're actively inserting, so this shouldn't be something you really have to think about.
2. you have to know you want to go down 5 lines....
Since your example assumes that line numbers are visible, you could just type vnG, where n is the line number you're trying to put the cursor before. No subtraction needed. Depending of the shape of the text, there are probably other intuitive approaches as well.
Does the "tao" of vi take time to internalize? Sure. But once you've done that, you can be blazing fast.
There's nothing wrong with typing Vjjjjj until it looks right, and you can still click and drag if that's what seems easiest to you. But if you're thinking of it in lines and characters you're missing the real advantage.
You're still mentally translating a what into a how. You almost certainly don't want to highlight 5 lines down for its own sake, you probably want to highlight, say, the body of a function. Vim provides a command to just do that directly.
I have a love/hate relationship with Vim due to that sort of thing. In theory I agree with you; in practice I find it very easy to mis-navigate in Vim and find myself next to the wrong equals sign, or on the wrong side of the equals sign, or what have you. And in my experience, recovering from one of those errors, as quick as it is, makes me wonder why I didn't just use the mouse (or trackball, in my case) to click next to the damn equals sign in the first place. (Keyboard jockeys -- which I'm frequently one of, to be fair -- often underestimate how fast using the mouse actually is, I suspect, because we think of it as, "Oh, I have to move my hand all the way over there and move something and then move back, that's nuts!" Again in practice, I suspect the mouse removes a great deal of the cognitive load involved in navigation, and that may balance out more often than we're inclined to give it credit for.)
Incidentally, in Sublime Text -- as well as Emacs and most Mac OS X applications, as this is a system-wide keyboard binding -- you could just hit ^K after the equals sign for "delete everything from here to the end of the line."
Minus of course the 3 months of concerted efforts and years thereafter learning the intricacies of vim/emacs to make such edits automatic.
Vim and Emacs are both such strange editors- I'd be quite happy if some other open source editor replaced them both as the default editor (that made better decisions in terms of plugins and abstruse key sequences).
I used Sublime for a while, then switched to Emacs for a while. I ended up switching back because, while I really liked Emacs, I didn't like being stuck in a terminal and I couldn't do effective pair programming.
The best bit about Emacs is the configuration, and I could give or take the awkward keybindings. Maybe if LightTable supported configuration with ClojureScript and offered a comprehensive API for it there'd be a more modern equivalent.
Some users, like myself, used and customised vim before moving to sublime text.I'm not saying you, or anyone else, shouldn't use vim, but some of us feel more productive in ST than vim.T alking about "the slow world of sublime text limbo" seems unnecessarily insulting.
I found ST2 a great tool for learning Vim actually. It has a Vim mode and although it's not a complete Vim emulation it gets most of the movement/editing right with key bindings.
I've learned a lot and I'm actually at a point where I feel the need to move on to Vim (due to the limitations of ST2's mimicry of Vim)
Actually, things are stored in a few directories. It took a while to figure out where Sublime stores everything so I could write a dotfiles script for it.
Having to set things up through Package Manager is a pain. Not sure why that's the first step whenever I read an article on Sublime. A simple package file script that git clones/pulls plugins is more maintainable.
I keep my ST2 package manager config stored in my dotfiles repo, so setting up a new Sublime instance is as easy as just opening ST2 for the first time and letting the package manager fetch the appropriate plugins automatically.
Sorry, I keep that whole plugin as part of my dotfile repo. When the plugin upgrades itself, I just commit that upgrade. When I install my dotfile repo on a new machine, I have a script that symlinks everything to the repo, including my ST2 data. I then have my .gitignore set up to ignore all the plugins that get installed, but specifically track changes to the package manager plugin, as well as any other custom plugins I write for myself.
My bash-fu isn't great, can you point me at an example of a script which does this (yours or someone else's)? I was literally thinking about moving my ST2 config into my dotfiles repo the other day
If you use ST2 for working on Django projects, try https://github.com/dobarkod/DjangoNoseTestRunner (installable also via Package Control) for running only the test under cursor. It's probably saved us hours of (cumulative) time already.
The TrailingSpaces plugin isn't necessary. ST2 has an option in the default preferences to trim whitespace at the end of the line - just enable it. Not to come down too hard on the article or anything, but there are many other, far better resources for setting up and learning how to be productive in ST2. This book is good https://leanpub.com/sublime-productivity (I have no affiliation with the book.)
What's the easiest way to keep my Sublime configuration synchronized between machines? I've found that I sometimes have some plugins on one machine, and not another. It would be nice to be able to pull some file/files from GIT or something to keep configuration synced.
I recommend this approach to sync config files over Dropbox to get exactly the same editing environment from Win, Mac, and Linux:
1) move the /User folder under "Sublime Text 2/Packages" over to Dropbox/ST2/User
2) in Win goto CMD and from the %APPDATA%\Sublime Text 2\Packages folder enter: mklink /D "User" "path to\My Dropbox\ST2\User"
3) in Mac OSX/Linux goto the Packages folder (you can find the location under >Preferences>Browse Preferences) and enter: ln -s pathto/Dropbox/Sublime\ Text\ 2/User ./User
The fantastic thing with this setup is that in any new machines, Package Control will automatically take care of installing any missing plugins.
You could try the SFTP package. With it, you can mirror a remote directory locally and the package will automatically upload the change in the background. It has some other useful features for working on remote files.
I tried switching to the Soda theme as directed, didn't like it. And I'm dumb, and forgot to back up the original prefs file. Could someone remind me what the default theme is called?
Vintage mode (which comes with ST) supports most common vim commands and either way there's plugins for most things and you can write your own for pretty much anything at all.
what plugin do people use for highlighting brackets and parentheses? the default underline mode is faint and not very helpful. i have heard of one or two, but i'm curious to hear what people on HN use. thanks!
cool, thanks. that's one i saw before, but some people complained about performance degradation. have you seen any performance hit after installing the plug-in?
