If you use a dark color scheme, you should install a theme that has a similarly dark background for the sidebar.
The "Soda Dark" theme goes well with the default color scheme. (The ui theme is separate from the syntax highlighting color scheme, you don't have to use the text colors seen on the github examples)
Not a plugin, but if you haven't realised it yet, know that the multiple cursors each come with their own separate clipboard. Learning how to combine this with the move and select by word and the parenthesis-movement commands is what will make the vim users eventually respect you.
Oh and you can hack your language syntax definition files to make more things apart from function definitions turn up in the function browser. This is especially useful for ruby DSLs, sinatra etc.
Back in the day, that's all we had. Microsoft editors were all white-on-blue and Borland editors were all yellow-on-blue. We didn't even have syntax highlighting. And some of us liked it that way. Get off my lawn!
pfft, you had blue? ;) I was happy to finally, one day, have a CURSOR! Oh crap, it blinks! Wow, high tech type!
Well, all this fun talk of SublimeText2, and my .2c .. I have been using ST2 for a long time now as an editor for MOAI, in which facility it really works well and .. well I've come to really love the editor, like love it, but am a vim user, 100%, and often get sad when I switch back and forth .. ;(
ST2, for MOAI and the Lua language, actually is really a sublime IDE experience, and imho the word sublime can be applied to this experience: I am using the same editor on both editor'ish platforms (osx, linux), and then building an app with its own language/VM wordspace that runs on .. everything .. iOS/OSX/Linux/Win/NCl/etc.
Right now in space-cadet mode, hacking on a laptop in some cafe, I sit in SublimeText2 .. hit alt-R, the MOAI app runs, its great, I commit to repo, the buildserver builds and runs the very same app on the nexus7, iphone5, pandora, osx, linux desktops, and various other sundry devices around the place.
In this capacity, ST2 has mastered my needs for integrated development. I guess I should learn how to read HN with it, next ..
I'm a big fan of the Nil theme (https://github.com/nilium/st2-nil-theme). I really love the modified indicator on the tabs. Just be sure to follow the instructions when installing, because you have to turn on a sublime setting. Also, be sure to restart when switching themes, sometimes not everything works right unless you do. This goes for every theme though.
Seconded; GoSublime gives you a nice REPL for Go's build and test commands, package completion and linting. It is the second Sublime Package I install, after Package Control and before my own Antiki.
Why I love ST2: multi-platform, fuzzy search, plugins, multiple cursors, JSON config files.
My setup:
- Package Control plugin: the very first thing you should setup after installing ST2 (it should really be a part of ST2)
- Next step sync config files over Dropbox to get exactly the same editing environment from Win, Mac, and Linux
- move the /User folder under "Sublime Text 2/Packages" over to Dropbox/ST2/User
- in Win goto CMD and from the %APPDATA%\Sublime Text 2\Packages folder enter: mklink /D "User" "path to\My Dropbox\ST2\User"
- 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
- Keybindings: tons of customizations to suit what I am used to and work across all OS's
- Theme: Soda Dark
- Colors: Made of Code
- My favorite plugins:
Alignment,
Bracket Highlighter,
Emmett,
FileDiffs,
SublimeCodeIntel,
SublimeLinter,
Tag
ST2 is the best investment I have made in software apart from open source.
This is interesting. I guess it's so that if you cat a file, it doesn't clobber your cursor? I've always noticed that git will say "No new line at end of file", but I've never really known if that's a bad or good thing, or why it matters.
When someone opens up a file created with Sublime Text 2 with vim or emacs and saves it, it clutters the commit messages. It's clutter whether the file contains other changes or not. It still shows up in diffs unless you suppress whitespace.
I would argue that the person with their vim set up to create that clutter is to blame here. If there's no objective reason to fix it other then "well, this is what vim does", then fix vim.
If i'm not mistaken, it is the lack of inserting a newline on sublimes part that is to blame here. It doesn't just break vim, but other software such as cat, git, etc.
Some might argue that when you save a file that hasn't changed that should be a no-op. I don't think so, though. I appreciate a program that does exactly what I tell it to do.
First it's obvious (but hardly anyone ever cares about it) that that such trivial things are still issues just show how much our diff tools are still in the stone age (for a start they should be able to figure out that the two source file: one with the ending and the other without are semantically identical)... But I'll bite.
First the parent mentioned "if you're on Unx". What makes you think you* are the one correct with your text editor's behavior and that the traditional Unxy way of doing it is not correct? (and OS X is a Unx variant).
Then it's trivial to modify Emacs so that it exhibit the behavior you want. Is it trivial to modify Sublime Text Editor 2 to that it behaves on Un*x like vim and Emacs do?
I'll never ever understand "programmers" who aren't using a programmable text editor.
But I don't care: time is on my side. Emacs was there 35 years and still shall exist long after all these glorified Notepad shall long be dead ; )
"I'll never ever understand "programmers" who aren't using a programmable text editor."
I'll never understand people that want to spend hours configuring their text editor, despite how much more productive they say it makes them. Sublime is perfectly programmable through judicious use of plugins and snippets anyway.
A subset of that, I'll never understand emacs users.
You can use both Emacs and vim in this "judicious use of plugins" style, and there's such an abundance of starter kits and battle tested configurations that the default of either is nothing you need to spend hours configuring your way out of.... There's a reason why these tools are so long lasting, and both absorb every new feature displayed by new editors. TextMate is clearly surpassed by Sublime, even though you could feasibly mod it to adopt those features which make ST2 better.
Emacs (and possibly Vim) could also implement any feature you could reasonably expect from a text editor, and in many cases it already has them, you maybe just don't know.
But this is 2013, and you're not alone, people all around the world are improving Emacs all the time, and have been for 30 years+ ... you don't HAVE to do all the work, you can just use it.
As the man says, Emacs and Vim will be here long after John Skinner has got tired of ST2 and quits developing it.
The diff tools can ignore the reality of the files, but it would be a foolish default.
It's right because the vast majority of newcomers believe that they are adopting UNIX and having a newline and the end of a file is an important tradition. There are some good places to upset the status quo but this is not one of them.
>First it's obvious (but hardly anyone ever cares about it) that that such trivial things are still issues just show how much our diff tools are still in the stone age (for a start they should be able to figure out that the two source file: one with the ending and the other without are semantically identical).
As long as you (or anyone else) doesn't write any new cooler diffs (though part of what you ask already exists), what they "should do" doesn't matter and doesn't change the fact at all.
I still have a habit, even in vim, of putting a newline at the end of the file (such that now I end up with two newlines). Old habits die hard, I guess.
Not to go all Stallmanesque here, but doesn't it bother you to use a proprietary text editor when there are so many excellent free/open-source ones around?
Not at all. Speaking for myself here, but while I much prefer open source to proprietary software, I find Sublime Text 2 blows any other editor I've used out of the water and I'm not going to not use it just because it's proprietary (same reason I use OS X, Photoshop (versus GIMP), etc).
The "problem" with Emacs and Vim is their out the box state is a bit daunting, if you allow a little time to get used to and configure Emacs, it'll blow the shit out of any editor you've ever used. ... Grab ocodo/emacsd from GitHub, it's a very sublime like setup.
This question really only makes sense to me from a Stallmanesque standpoint though (unless you don't have much money for some reason, in which case the financial considerations come into play.)
Surely unless you have some ideological reason to pick a FOSS editor, you'll simply use the best one available.
I'm certainly not Stallmanesque and I've got money -- in fact, I'm a registered owner of Sublime Text 2, but there is at least one real-world practical way in which ST2 being OSS would be preferable for me. I increasingly do my coding on ARM-based Linux devices as opposed to x86-based ones and ST2 has no ARM build, and repeated requests asking for one are, as far as I've seen, summarily ignored by the author.
If ST2 were OSS I could build it for ARM/Linux myself, everything it relies on is already available on those platforms. But it isn't, so I've had to quit using it and recommending it to others.
Yeah maybe a bit, but to me full Stallmanesque would be avoiding proprietary software even when the free alternative is non-existent or significantly less functional. That is not the situation with text editors, unless I am missing something big that Sublime Text can uniquely do.
Emacs can do all that. I wouldn't be surprised if Vim could too... The point about these two editors is that no matter what feature shows up in an editor, both of them could implement it.
Emacs lets you easily write plugins in python? It's been a while since I used it, but I remember an awful lot of parens any time I wanted to customize something.
Well, the lisp factor is obviously an issue, for people who aren't interested in learning another language, but that's knowledge friction.
It's not particularly difficult to learn Lisp, it needs a nice syntax highlighter to dim away all the parens, but really, it's a very simple language. I'm sure you could write some bad-ass shit if you gave it a little attention.
There are python -> emacslisp bindings available, but I can't speak to that, regarding completeness / stability etc. Frankly I wouldn't suggest anyone waste their time doing that.
But really with such a HUGE resource of functions / libraries, (and some of the cooler features of Lisp, I mean have you seen the loop macro!?) ... it's a bit of a waste to pass it up over its "(( big ears ))"
> Not to go all Stallmanesque here, but doesn't it bother you to use a proprietary text editor when there are so many excellent free/open-source ones around?
Use the best tool for the job. Screw extreme philosophies.
I don't feel like preferring a FOSS solution in a situation where there are plenty of good choices is that extreme. That's why I asked.
If anything, I feel like "Use the best tool for the job and ignore all other factors" is an "extreme" stance. (although Stallman's obviously is as well)
People decide which philosophies are extreme. As individuals (for themselves) and as groups (for their society, group, company, neighbourhood, etc).
Are you of the "anything goes" thinking? I for one, find that attitude TOO extreme. I don't wish to accept (or even tolerate) "anything" just because someone else finds it OK.
Ninja IDE for Python is trying to match up to ST2 (and it feels more IDE-like than ST). Until it succeeds, SublimeText remains a very attractive option.
> When those free/open-source editors come into the 21th century with regards to native integration/UI I might reconsider.
Though both vim and emacs have gui interfaces, most of the users use them inside a terminal. You can wait till 22nd century, but as long as your definition of 21st century isn't the same as developers definition, not much is going to happen.
BTW what century are terminals? If I have to take a bet, I would say come back in 22nd century, and terminals would still be around and kicking. If it was that black and white(ooh, gui is here; let's switch), the switch would have happened. Personally, vim is part of my work environment(terminator running tmux/screen; vim on 0; repl on 1; dbconsole on 2; running tests on 3; ...) and I don't see how a gui editor is supposed to replace that.
>Though both vim and emacs have gui interfaces, most of the users use them inside a terminal.
The overwhelming majority of developers edits in a GUI editor though, be it in Visual Studio, XCode, IntelliJ, Eclipse or Vim / Emacs / TextMate / ST2 etc.
>You can wait till 22nd century, but as long as your definition of 21st century isn't the same as developers definition, not much is going to happen.
I don't have to wait. Plenty of other developers live in your "22th century" and offer nice and functional native editors already.
>BTW what century are terminals?
Mid-20th century.
I don't mind the terminal (I use one everyday and have done so since the day's Sun OS was SUN's offering), but it's also another technology stuck in the past.
Not because of the textual nature etc. Because most of the components are crappy old time things, from terminal emulators to userland unix commands, etc.
Bad support for millions of colors, bad support for Unicode, no support for a structured type (e.g JSON), ad-hoc implementations for lots of things given in the desktop. Where's a proper autocompletion in the shell that behaves like in a native app? Where's spell checking with wiggle lines?
Only ZSH and Fish tried a few things to take us further, but still very short of what a desktop could be.
I mean tmux/screen borking the scroll buffer? Is this 2013?
> The overwhelming majority of developers edits in a GUI editor though, be it in Visual Studio, XCode, IntelliJ, Eclipse or Vim / Emacs / TextMate / ST2 etc.
The overwhelming majority of vim/emacs developers use it in a terminal, and are pretty happy with it. When you mentioned open source editors catching up, it isn't going to happen because your requirements are not universal. "Only if it looked shiny" is very low on todo list of vim/emacs users/developers.
> I don't have to wait. Plenty of other developers live in your "22th century" and offer nice and functional native editors already.
My comment about waiting was with respect to vim/emacs(as examples of other open source editors). You can wait till 22nd century; it probably still won't happen. Users are mostly happy; developers don't care.
> Bad support for millions of colors, bad support for Unicode,
My terminal(terminator) does that fine.
> no support for a structured type (e.g JSON), ad-hoc implementations for lots of things given in the desktop.
Why and how would a terminal support JSON? What are those ad-hoc desktop things?
> Where's a proper autocompletion in the shell that behaves like in a native app?
shell has to support autocomplete in million things, compared to your native app which only does one thing say Java. Whether shell offers completion or not depends on the external tool as well. You install some utility shit_load. How on earth is shell going to complete "shit_load -<TAB>".
> I mean tmux/screen borking the scroll buffer? Is this 2013?
tmux/screen scroll buffers work fine. You are just making shit up.
>The overwhelming majority of vim/emacs developers use it in a terminal, and are pretty happy with it. When you mentioned open source editors catching up, it isn't going to happen because your requirements are not universal. "Only if it looked shiny" is very low on todo list of vim/emacs users/developers.
Way to fuck up the discussion in a disingenuous and insulting way by summing down my arguments to "I like shiny things".
I specifically talked about native integration. That has myriads of aspects, of which "oh, shiny" is just an insignificant part of.
As for the "overwhelming majority of vim/emacs" users using them in the terminal, citation needed.
My anecdotal data tell me that they use them in both in both terminal and GUI form (terminal for working on stuff remotely, admin stuff etc, GUI for long term programming sessions).
Plus, no matter what the "overwhelming majority of vim/emacs" do, those do not represent the future or cutting edge of programming editor use in any conceivable way. And that is precisely what we are discussing.
>bad support for Unicode
>>My terminal(terminator) does that fine.
Does that answer mean that you don't have the mental capacity to follow the discussion? Maybe you're too tired or something?
Isn't it obvious from my comment that I mean Unicode support THROUGHOUT the system? That one or ten terminals has got it doesn't mean a thing if there are 200 other components involved in doing unicode CLI work. For example GNU/BSD unix userland programs supporting full unicode capabilities. Unicode and font-rendering without X-running, etc etc.
>Why and how would a terminal support JSON? What are those ad-hoc desktop things?
What is this stupid notion that I talk about terminal emulators ONLY? I specifically bloody state that I complain about all terminal-side stuff "from terminal emulators to userland unix commands".
In this case, what I ask for (when giving JSON as an example) is a structured way of communication between userland commands, to go beyond '70s style pipes. Microsoft's Powershell AFAIK has some of that built-in.
>shell has to support autocomplete in million things, compared to your native app which only does one thing say Java.
You'd be surprised. And context-sensitive autocomplete is so solved that it's not even a problem...
>You install some utility shit_load. How on earth is shell going to complete "shit_load -<TAB>".
See how luck of imagination and blind acceptance of what's there cripples programmers?
Off the top of my head: programs could come with definition files for their autocompletion. Adding a program adds those to your shell (in the same way programs come with man-pages).
I seriously hope you don't work in R&D.
>tmux/screen scroll buffers work fine. You are just making shit up.
Only if "switching in copy-mode to scroll, instead of transparently incorporating the terminal scroll buffer" fits your definition of "fine".
I switched to vim a year ago, and I fucking love it. The one thing I miss from ST2 is column editing/multiple cursors. Column editing fulfills the same kind of need as basic usage of vim macros, I think (i.e., applying some kind of sequence of edits to multiple rows), but it's visual and you get instant feedback (across all rows), which makes it easier and something you can sort of feel out iteratively.
For example, supposed I have a row like (making up these names as I go, and suppose the list is longer):
and I want to insert after the first underscore the word class, so I'd get Controller_Class_Section and so on (this is a contrived example, but one has to do these kinds of things sometimes.)
In vim, I think I'd record a macro, but I'd probably forget some parts (like moving to the next line at the end) and have to undo and whatnot (could use a regex too, but that's a bit harder--I'm practicing recently to be able to do it more effortlessly.)
In ST2, what you do first is create a cursor at the beginning of each row (option + down arrow on OS X.) Then you move ahead one word (Opt + Right arrow on OS X.) Now the cursor is right before the underscore, even though the underscore is in a different position on each row. You can see that it's in the right place on each row, so it's hard to make a mistake, and if you need to do something more complicated, that remains true. Then, you just type _Class, and it types live on each row, once again making it so you get instant feedback, and it's hard to make a mistake.
That to me is the biggest actual advantage of ST2 over VIM, but there are other reason to not switch, like vim's steeper learning curve (when most of us are already busy, and learning other stuff at the same time), and the fact that some people prefer the mouse, which behaves strangely in vim.
Multiple cursors sound cool! In vim, you can do something more limited by using visual block mode (C-v) to insert on multiple lines, but you're restricted to insertion on the same column.
The perhaps the closest thing I can think of for your example would be this (starting in normal mode with the cursor at the beginning of your list):
f_i_Class<Esc>+;.+;.
("Move forward to the next '_', enter insert mode, insert '_Class', leave insert mode, move down one line to the first non-blank character, repeat the forward motion, repeat the insertion, repeat forward motion, repeat insertion." Vim does have word motions, but it includes underscores as parts of words.)
Edit - formatting and a clarification that it's the closest I can think of (I'm doubtful it's the closest you can get).
Yeah, that's totally what you'd do, in either editor. But my broader point is that there are situations where the immediate feedback and interactivity of using multiple cursors is valuable.
How is immediate feedback and interactivity going to help if the changes span more than one page? If you are going to extrapolate(looks fine on this page, must be fine elsewhere), you can very well extrapolate from a smaller sample size(run :s/some_crap/some_other_crap/gc, check one or two occurrences, then do 'a' for all).
Rather than replaying it line by line, you can play it over a range. If you do this in your vimrc:
vnoremap @q :normal @q<CR>
You can record the macro in q register, select the visual range, and then do @q to run it over the range. The advantage of doing it thus is you don't have to run the macro manually on every line, and you can undo all change with one u.
Also, normal takes ranges(and not just visual ranges). If you want to run the macro recorded in q over lines 15,49, you can do:
:15,49normal @q<CR>
I use the same trick for repeating commands over a range too.
vnoremap . normal .<CR>
As usual, it doesn't have to be visual range. But I mostly use visual ranges, and so I have defined shortcuts for visual ranges.
Macros are the way I solve this as well. A little practice, and you won't even notice the difference. Just hit `Esc j` before ending the macro recording and moving down a line is no longer a problem :)
To do the task you mentioned in vim I would move the cursor to the first letter of the word Section in the first line. Then I'd insert "Class_" and go back to normal mode. After that I'd move the cursor to the first letter in the word Model in the second line. And then I'd press the dot key and do the same with the other lines in supposedly longer list.
> And then I'd press the dot key and do the same with the other lines in supposedly longer list.
I am posting this again(posted above about running a macro on a range), but I guess lot of people don't know about this.You need not manually press . on every line. You can run . operator on a range. Do a visual select and then
:'<,'>normal .<CR>
The range('<,'>) is inserted automatically when : is pressed from visual mode. So it boils down to visual mode, select, :normal . <CR>
You can have any ranges you want.
:15,49normal .<CR>
I have a shortcut for visual range defined in my vimrc
I do that with Sublime Text 2 using the vim plugin (vintage). I would've never switched from vim if not for this plugin. Now I have (most) of the best of both worlds.
I use Sublime Text 2 for its GUI powers: proportional-width fonts (I use Verdana), the code minimap, and the pretty file-browser sidebar with easy-to-click disclosure triangles.
I also like that it’s easier to remember most Sublime Text 2 commands – the Command Palette (⇧⌘P) lets you fuzzy search all commands. So you can search for “syntru” and find the option “Set Syntax: Ruby” instead of having to remember Vim’s “:setf ruby”.
Finally, I use Expand Selection to Word (⌘D) to quickly select multiple instances of a variable whose name I want to change – it’s slightly more convenient than it would be in Vim.
On the other hand, I miss Vim’s editing model. It’s a lot more cumbersome to edit line-wise or move the cursor with Sublime Text’s keyboard shortcuts. And Sublime Text’s “Vintage” Vim emulation mode is a poor substitute. As another commenter said, Vintage is in the uncanny valley. Every now and then you run into a Vim command that just doesn’t work and it breaks your flow. For example, Escape is overloaded as both “go from Insert mode to Normal mode” and “collapse multiple carets into one”, and I never remember which it will do when I have a multiple selection in Insert mode.
I've been in the process of switching from Vim to ST2 for a couple months (custom plugins in both, not in a hurry) and the main reason for doing it is because Python and the extension API are MUCH better than the Vim equivalents. If you don't do custom plugins, it really doesn't matter.
Part of the reason for the delay is the lack of equivalent Vim workflows in Vintage. This has been improving a lot thanks to the people working on Vintage and at this point the only holes in my set are c-i/c-o and surround.vim shortcuts. I had to re-train myself to go from Esc to ctrl-[ since Esc conflicts heavily in ST2 but I've been meaning to do that for years in Vim anyway so I consider that a benefit.
I tried this after learning vim, and it seemed to suffer from an uncanny valley problem. Once you get into the flow of things, you'll start treating it like vim, and then when something suddenly behaves slightly different or doesn't work at all, it's very disruptive. I can't think of a specific example right now unfortunately, as that was a while ago, but it happened regularly.
Uh, I'm in the same boat as the person you responded to and I am still confused. What are the advantages of sublime over vim (rather than ways that Sublime can emulate vim)?
You might also want to try (my plugin) BrowserRefresh: Save the file you are working on and refresh your browser (or many browsers) with one keystroke.
Sublime Text 2 plugin writing is surprisingly easy via python. I recently wrote a plugin (SublimeJump https://github.com/tednaleid/SublimeJump) to let you jump to any visible character with a couple of keystrokes. It's similar to AceJump (emacs) or EasyMotion (vim) if you're familiar with those.
You can also check Tuts+ free tutorial about ST2. It contains a list of interesting plugins (most of them mentionned in this article) alongside others I find quite useful.
I would avoid Prefixr like the plague as it's broken to the point of being destructive, and not maintained. Installed it today before I saw this post, stopped using it immediately.
He earned a 6 month holiday considering the workrate he put in on those early builds, and the amount of cash he must have made in the intervening time.
It's not like the thing is riddled with outstanding issues.
I'd love to see that, too! Jon's been putting out updates way too fast [0] to be able to keep that up forever, though. The API[1] is good enough that generations of plugins could be considered future versions. I'm glad it's successful enough that he can afford a vacation.
Speaking as the developer of the Git plugin on that list, the only thing I feel is missing from the API is a way to add colors or labels to filenames in tabs and the sidebar. Otherwise it's been pretty great.
I really like the general way of working with SublimeText, but there's one major reason I simply cannot use it for the job: it is terribly slow with large files. One of the things we have to do often is open a >10mb logfile on a cifs share and quickly search through it. It takes ST2 over 10seconds to open the file. The same for each refresh of the file. Even wordpad on Windows loads the file faster, so there seems to be something quite off at the core side of things.
I have the same issues regarding load speed on large files. I am a long time UltraEdit user and it is the fastest editor on Windows for working with large files that I have found. Unfortunately UltraEdit has a pretty awful UX compared to modern software. It is still very much a Windows 9x app which kind of sucks. Also it has some annoying as hell Unicode issues which is why I ended up switching to Sublime Text for 99% of my work and just keep UltraEdit around for those one a month moments.
well I'm using Notepad++ atm and it's fast as well. It also has the awesome feature (Opera also has it) that you can close tabs by doubleclicking them. Once you get used to that it's extremely hard to not use it everywhere..
This also bothers me. It gets even worse when using a linter plugin. Sometimes when I open a complex file (for example a huge minified JS library), the whole editor will just crash because of the linter plugin. :/
It's spelled "Emmet" (docs.emmet.io) and it's more widely known as "Zen Coding". (I asked the author about the name change and forgot why now - some sort of trademark dispute).
Yeah, it seems like Emmet removed one of my favorite features with Zencoding. I could hop into a string of HTML attributes and hit "." or "#" and it would create a new attribute of class="|" or id="|" respectively, and place the cursor in between the quotes.
I never had to use a hotkey in the past. I do for regular expansion, and I haven't looked into why koans stopped working, but I imagine that is hotkey related.
Does it have decent SFTP out of the box or as a free plugin? I'd like one of those persistent SFTP browsers, not the default one which does not follow the principle of least astonishment - it uses a custom interface where I have to select the SFTP server every time I want to open another file and there is no multiple selection. It looks like an original UI design invented by a programmer with no UI design experience, reinventing the wheel.
I found SublimeCodeIntel to be unreliable, so I use SublimeCTags[1]. I've also bound mouse3 to navigate to a function definition in my User .sublime-mousemap file:
I've never gotten that plugin to work well with my PHP code. Code complete is awful. I've switched over to PhpStorm for PHP code because it has static analysis and refactoring.
I tried using ST2, but it lacks one basic feature that is essential to me. It will automatically update a loaded file with any changes made externally. This is fine, except when you don't want it to do this and then discover there is no way to toggle this behaviour.
It should just be a simple configuration option but until it is added then this is a deal breaker.
BUT it seems that this doesn't always work. I just tested with a newly created file and for some reason there was no warning, it just reloaded the file.
These are all really cool, and I look forward to checking them out!
On a side note:
Does anybody know of a plugin for ST2, or another editor that works well for coding that allows for a semi-transparent/transparent background? (for Windows) I've been searching for the last few weeks to no avail, and was hoping that somebody here might have encountered something.
Does it support REPL for various interpreters? (emacs has ESS for R, SLIME for LISP, surely others.)
I couldn't find anything about this in the docs (just quick browsing) and nothing was apparent in the menus after I've tried to install it. So.. just asking, not trying to start a flame war :)
I've always struggled to get SublimeCodeIntel to work under Linux, and when I've seen it work, it's not very good.
CTags is absolutely fantastic though, I live and die by it in large code bases. It's backed by ctags on the system too, so it has an impressive list of supported languages.
Does anyone know of a plugin that allows Sublime to handle XML files correctly? By correctly I'm mainly talking about auto-formatting and generally understanding how XML is indented.
I used SublimeCodeIntel some time ago and while it worked as advertised, I ended up having to remove it since it was causing ST2 to hang especially on large codebases.
For everyone using SublimeLinter - I'm curious if you've tried sublimelint (the parent project) recently and if there's any reason you chose SublimeLinter over it.
I find Coda to have too much stuff. I don't want something that has a bunch of fancy icons and I have to scroll left/right to find my files and has 15 different areas all with extra garbage you don't need (such as the entire right bar which is mostly useless too me).
However the project control part of Coda is amazing.
So it's a matter of how experienced web developer and what exactly do you do? If you do mostly HTML/CSS/JS, then Coda is for you. If you do mostly other stuff hardcore JS, ruby, php, lua, blah blah blah. I'd say sublime.
Oh yeah, I meant stepping through code.
I'm used to debugging in IDEs (Eclipse, Visual Studio), so command-line debugging using GDB is a major pain in the ass.
What's the fuss with multiple cursor? Emacs has these too (of course) but seriously WTF!?
Who programs in languages so mediocre that there are repetition everywhere and that working is so repetitive that having multiple cursors actually helps?
Do you really have to enter the same thing so often that having "multiple cursors" makes you more productive and is considered a "killer feature"!?
All I see is that if you need that you have way too much repetition in your "code".
I don't like repetitive stuff. That's what computers are good for. That's what I do as a programmer: I carefully craft my tools so that all the stupid repetitive tasks are done by my programs (or by my programmable text editor).
I'm going to give you the benefit of the doubt and assume you're not just trolling.
Multiple cursors can be useful for doing things like quick renames, which itself is already useful in a general text editor that is used with many different file formats.
However, for me, they are often more useful because you can pick out general patterns of text/symbols and do the same thing to all of them. Want an extra <th></th> just after each <tr> in four lines of an HTML file? No problem. Want to split a list of function parameters onto separate lines when they don't fit on one any more, or the other way around? No problem.
Sure, in many cases you could do these things with a find-and-replace as well, but that might involve making a selection to limit the scope of the replace operation, setting up some sort of regex to make sure you only find the copies of the original text you actually want, setting up another regex to do the replacement without disrupting anything else nearby, and so on. Using multiple cursors is often much more efficient.
For programming, I don't find the multiple cursor thing very useful, but for markup (especially html), it's extremely useful, particularly when working with legacy systems that don't have very powerful server-based building of HTML from templates. In these cases, HTML can be very repetitive, and grabbing a set of <li>s that you want to add a class to is as simple as highlighting the first <li>, hitting Cmd-D a few times, and then editing them all at once.
Whoa, whoa, whoa... hey, buddy, calm down. Some people liking the ol' multi-cursor does not scream volumes about about their programming style, or "mediocre" language of choice. You sir, are just being ridiculous.
I'll say this about multi-cursor, it is one of those things that until you have it, you don't know you missed it.
When I first tried sublime my thought pattern went "Wha? Multi-cursor? When will I ever use -- Oh my god how did I live without this!?"
Simple use case that comes to mind: quick refactorings. I'm a believer in self documenting code, so I'm often changing the names of my function calls as I get deeper into the domain of the problem. With Sublime Text, I highlight the function in question, spam `ctrl + d` a bunch of times to set the multicursors in position, and from there, I'm free to type away whilst the multicursors edit my entire document.
The "Soda Dark" theme goes well with the default color scheme. (The ui theme is separate from the syntax highlighting color scheme, you don't have to use the text colors seen on the github examples)
https://github.com/buymeasoda/soda-theme/
In terms of plugins, apart from the ones mentioned here, Quick File Creator is indispensable: https://github.com/noklesta/SublimeQuickFileCreator
Not a plugin, but if you haven't realised it yet, know that the multiple cursors each come with their own separate clipboard. Learning how to combine this with the move and select by word and the parenthesis-movement commands is what will make the vim users eventually respect you.
Oh and you can hack your language syntax definition files to make more things apart from function definitions turn up in the function browser. This is especially useful for ruby DSLs, sinatra etc.