Setting up Sublime Text 2 | Hacker News Reader

Setting up Sublime Text 2

blog.alexmaccaw.com

178 pointsmaccman134 comments

"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.

Yeah, I didn't understand this either. "Sublime's initial look leaves a lot to be desired." Really? I think it looks great.

Here's another post that calls Sublime's default theme "pretty ugly" and "god-awful": http://floatleft.com/notebook/making-sublime-text-2-beautifu...

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.).

It's a bit like a teenies version of Emacs.

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 have the same problem its not as clean cut on a mac as say textmate. On linux windows its a fair bit suited to the environment.

The initial code theme is pretty ugly thank god for themes like tomorrow, soda and similar.

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..

> 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.

Here's a tool that converts images to themes, for those who want something new: https://github.com/mlaugharn/swatch

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.

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 colorscheme is indeed god awful. There's a nice Desert theme for it though http://www.sublimetext.com/forum/viewtopic.php?f=2&t=863

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.

Agreed. I think the icon has changed in Sublime Text 3, though.

Interesting, to me it looks like an 's' key from a keyboard. I've always assumed that's what it's supposed to be.

I never thought it looked like a disk drive. I guess it looks like an external desktop hard drive a bit though.

It not only looks like an S from a keyboard, that's absolutely what it is, no question.

I like the default theme, although I always darken the background and change comments to green. I find the light grey on grey comments pretty painful.

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-...

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).

Maybe some people really hate dark themes?

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.

> [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

Of course you aren't, as long as it is one of the two editors you approve of.

I approve of anything that saves spaces and not tabs.

I'm just not going to use it, and keep wondering why one diverts so much efforts to editors that aren't the One True Editor.

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.

Try helm: https://github.com/emacs-helm/helm and https://github.com/emacs-helm/helm-ls-git

Try projectile: https://github.com/bbatsov/projectile

It fills in the common project search and fuzzy filename search features(amount other things) and otherwise stays out of the way.

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 love Emasc but it can't even do proper full screen. I really wish ST3 has more APIs in the Emacs spirit, but keeping it modern.

  (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)))

That removes the borders? Any way, Unix only...

http://tomayko.com/writings/that-dilbert-cartoon

What's wrong with F11?

  (describe-key (kbd "<f11>"))

<f11> is undefined

Only on OSX maybe? It works perfectly on Windows, not sure about Linux as I'm too lazy to reboot and test right now. Perhaps someone else can check?

Did you use emacs starter kit? Because that binds fullscreen to F11.

It is unbound on linux as well (emacs24)

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.

By toggle do you mean change whether it reloads it?

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.

I, on the other hand, think that the ST behavior is ideal and Notepad++ is full of unneeded dialog boxes.

My favorite example is to use Zen Coding in both.

You could undo the reload.

It only reloads if you haven't made any changes to the file and you can disable it with plugins

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:

  [
    { "keys": ["super+v"], "command": "paste_and_indent" }, 
    { "keys": ["super+shift+v"], "command": "paste" } 
  ]

You just (minimally) changed my world. Thank you sir.

THANK YOU

You're my hero of the day.

A few more Sublime Text plugins worth checking out:

AdvancedNewFile -- easy file/directory creation

Alignment -- shortcut for instant alignment

Emmet -- essential for HTML/CSS

GitGutter -- see diff marks in gutter

Origami -- additional shortcuts for split panes

VintageEx -- emulation of Vim's Ex-mode

The Vim emulation isn't one-to-one, but it's pretty good with Vintage mode enabled and the VintageEx plugin installed.

This helped me a lot when I got started with Sublime http://net.tutsplus.com/articles/news/perfect-workflow-in-su... Good intro to basic configuration, shortcuts & vintage mode

It's also free, and written by someone who actually used ST2 for more than a month.

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 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).

Trimming at the end of line has no effect on python.

But other whitespace does, so globally disabling whitespace in a diff isn't very helpful.

    git diff --ignore-space-at-eol

You will never have silly diffs because someone accidentally changed some trailing whitespace (because there isn't any).

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.

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.

That sounds great and diligent. Me and commits never seem to sync properly anyway (mostly because I am the sole dev on so many projects I guess).

I turned that feature off because of Markdown. To force a carriage return, you need to have two spaces at the end of the line.

I think it's fine so long as everyone agrees, or as long as people don't strip the whitespace in the same commit as their actual changes.

Half the time the pointless whitespace is introduced by an editor that auto-indents for you.

As opposed to having trailing whitespace and mixed tab/space whitespace polluting your diffs? Configure your diff viewer to ignore whitespace.

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.

Araxis Merge, problem solved?

I don't know it. But unless it's something that comes built into Git it's not useful. It needs to be something everyone has. That's the whole point.

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.

There's no reason to use shitty tools here.

> Until Git can ignore trailing spaces as part of the merge strategy

It can:

    git merge -X ignore-space-at-eol

Great, thanks!

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.

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 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."

In fact Plan9's sam and acme claimed the use of mouse was indeed faster based on studies. See http://plan9.bell-labs.com/wiki/plan9/mouse_vs._keyboard/

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.

2 - That's where relative line numbers come in.

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.

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)

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...

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.

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!

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... :)

How is the buy-the-beta-then-there-is-a-new-version-immediately-you-need-to-pay-for-again reasonable licensing?

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.

This doesn't strike me as wildly unreasonable.

To me this is unreasonable when there is no progress on a bought version.

I actually like that the preferences are stored in JSON. This is one of the features that pulled me in to Sublime Text.

i agree..its easier to edit

I'd love it if they were stored in dotfiles (something I like about Textmate 2), but at least all your config gets stored in a nice User package.

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.

What bootstraps package manager?

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

I actually use a bit of python to do this, but I've dropped that and my .gitignore into a gist. Enjoy!

https://gist.github.com/jreese/5356501

Much appreciated.

I just wish Sublime didn't have a mine of its own. It has a bad habit of rewriting my config with my comments removed.

The only time Sublime rewrites configs is when you change the theme. Maybe you have plugins that do it?

I wish it was yaml. Even the slightly relaxed json (comments!) is still too picky for my taste.

I think TOML [1] would be even more suitable.

[1] https://github.com/mojombo/toml

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.

Another awesome plugin in ST2 is WebInspector https://github.com/sokolovstas/SublimeWebInspector for Web Devs

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.)

That's all fine and good until you're using JADE:

    h1
      | We build 
      span.colored-text scalable 
      | web sites & engineer 
      span.colored-text powerful 
      | platforms

If you delete trailing spaces, you'll have no spaces between any word at the end of the line and the word in the next section.

Point being: trailing spaces can be significant.

So throw a nbsp; in front of the text in your span.colored-text Jade?

I was looking at Sublime Text for Go, and apparently the autocomplete box cannot be expanded so it is unable to display function arguments.

https://github.com/DisposaBoy/GoSublime/issues/212

Probably an issue for other languages as well.

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.

Maybe SugarSync at this point.

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.

Thanks for this. Going to give it a try. Also appreciate that you've got some solution working across multiple OSes.

For you python Sublime users: http://dechols.com/post/40402860395/sublime-text-2-python-de...

> The default website, icon, and theme are ugly to say the least

I find the default icon better looking than the one the author is using, so I guess this is just a matter of taste. Same goes with the color scheme.

I do most of my editing on remote machines (both at work and at home) and haven't really been able to find a setup that works smoothly for this.

Is everyone else developing everything on their local machines?

When I use remote machines I mount them with samba / ssh so I can use an IDE / Sublime

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.

http://wbond.net/sublime_packages/sftp

Yes, most of us use git.

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?

Just delete the line. It should revert back to the default theme.

Also for anyone that uses both Alfred (2.0) and sublime check out https://github.com/Humanoidism/SublimeIt

Sublime 2 rules! Simple, great shortcuts and just plain nice to look at. They even let you use it for free. I bought it shortly after trying it out.

More icon replacements: http://dribbble.com/search?q=sublime

Am I the only one to find Python syntax highlighting pretty poor? Is there any tip, color schemes or plugins to improve this?

Get me block level (vit, cit ...) commands in ST2 and I will switch. They are done very well in Vim.

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.

This is still a very small subset. If you are a moderately advanced Vim user, neither Vintage nor VintageEX are enough, I'm afraid.

Anything that isn't built in you can add yourself...

Versus having it built-in in my current editor?

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!

I'm using BracketHighlighter.

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?

You know, a few months ago I think so, but I could never find the culprit. I've had no issues recently, so maybe they updated it?

I can't believe this many people care about how the icon looks.

Reply on news.ycombinator.com