Sublime Text 2.0 Released
sublimetext.com
sublimetext.com
At some point I think I realized that no matter how feature-rich my editor was, the main thing stopping me from writing good and fast code was _thinking_, not configuring my text editor.
As someone with a computer that is horribly unstable (in the process of replacing it over the course of next month), the swap file has saved my ass on a few occasions.
set directory=~/tmp
instead of turning off swap files. All the fun for none of the junk.Vim is capable, out of the box, of everything a more heavyweight editor can do. The only thing really missing is library aware code completion.
This would ring in the back of my head as I spent many hours configuring my editor / shell / terminal setup. It felt like a guilty pleasure.
It dawned on me however, that what had drawn me to programming in the first place was a sublime text editor (TextMate), and that my business is in fact tool-building. My love for computing tools and the experience of using them reflects in the kind of software I build for clients.
On top of this, evaluating and obsessing over hacker's tools isn't confined to picking between models at the hardware store. I have pored over (and patched, however minor) bash, vim, tmux, rxvt-unicode, and many other programs that I use every day.
These things may well be rationalizations, so here's a simpler justification: the time I invest into my tools have made my experience of sitting down in front of a computer incredibly enjoyable. I once lived computer free for three years because I detested the uninspiring (and frustrating) experience of Microsoft Word and Windows 98. If that was what computing was, I wanted nothing to do with it.
I've found that too, asnd it helps me be productive. I run MediaWiki on my PC as my internal documentation system. I used to use it with the default skin, which looks a bit meh, but I recently added my own skin, which looks a lot nicer. I found that every time I looked at the wiki after that, I got a little hit of joy from looking at a nicely-skinned page.
This is the root cause of the endless Vi vs. Emacs debates as well.
But nobody comes to VIm knowing how to use it intuitively. Its features make the investment worthwhile. Same with Sublime Text 2. There are features that instantly save time (the tiny thumbnail of your entire file makes traversal a breeze for me) and others than take a while to get used to (ctrl-P).
The question shouldn't be, "Should I waste time looking at ANY tools?" especially in the ironic context of, "I've used two decades of my life learning VIm and now it ROCKS." It's, "What does this tool have that makes it worth using?" That answer for me so far is speed, flexibility, and features, like the two above. I'd hoped to see more on those topics here.
When I want to use VIm, I do. When I want to use JEdit, I do. As the previous fellow replying says, you don't simply use hammers. Figure out where this tool -- which is a very good one -- fits. Its best feature might be its untimed trial period. Give it a shot.
Actually, someone from design background once told me "Good tools produce great work".
and he also said that your tools protect you.. the day you get a flat tire is exactly the day you put your tools out of the car...
Same goes for a very simple word completion - when the editor already encountered the word in the previous line.
These are just _very_ basic things.
I'm not that fast and to be honest I really don't miss code completion at all.
Another invaluable feature related to this is documentation as you type. I can never remember the order of the arguments to the fold function. Fortunately Visual Studio helps out: https://dl.dropbox.com/u/388822/intellisense.gif (somehow my mouse pointer shows up in white, which makes it hard to see, but if you hover over the variables you get type information & documentation).
I would argue that the autocompletion training wheels for learning a new API are really only useful if you're rarely going to use that API again. If you're going to be using it a lot, there's actual value in spending the extra effort to learn it's functions. It'll stick more. Unless you have a photographic memory your brain will tend to discard information it had to expend no effort on, and autocompletion basically becomes background noise. I theorize that a fast typist will gain the edge after using the API 10+ times, even if they have to look it up the first couple of times, because the additional effort and focus they had to give to the task will commit it to memory (and they will potentially learn more about what the API is doing).
The focus is often on typing the fewest characters, but I think that's the wrong thing to focus on most of the time when choosing an editor.
Only ever using 5 libs does sound incredibly boring. However the toolbox of libraries I've accumulated repeated experience with over the years is in the hundreds, and learning more about them has proven worthwhile. I assume most developers would say the same.
Couldn't agree more with the second sentence: I actually print out a listing of common APIs and take the time to memorize them. But you just described 90% of the APIs in your first sentence. For those APIs having quick access to autocompletion lists (to see which methods an object supports) and quick access to documentation is tremendously useful. As for your theory, common sense would say that how much you learn is proportional to the time spend on it. So if you use the API 10 times by looking it up manually, and you use the API 10 times by looking it up in contextual autocomplete, then yes you're going to learn more with the manual lookup. But this is an unfair comparison: you'd spend much more time on the latter than on the former. In the same time to look up the API 10 times manually, you could have looked it up in contextual autocomplete 30 times and then you'd have memorized it just as well.
I sense a lot of irrational aversion to autocomplete, that it's for slow typists, it's training wheels, and Real Men don't use it. Look at it as an incredibly quick way to look up documentation. In fact unless the method name is really long I do not use autocomplete as autocomplete at all: I fully type the method name instead of hitting a key to accept the completion. It's just a way to short circuit the process of switching to a web browser, searching for and reading the documentation of the relevant class/module, and switching back to the editor.
I don't think autocompleting a call 30 times is nearly as valuable as looking it up for me at least, because since I'm already invested I'll take the time to learn about it. If all I did was tab complete something and it seemed to work I'd be far too lazy to dig any deeper. I don't see why I'd spend any more time on it during consecutive autocompletes either.
Also, when I use a new library chances are very high that I'll be using it over and over and over again. It's more like 10% of APIs that I'll never use again (but still may learn something). I'm speaking purely from experience, and it baffles me that others stated finding so little library re-use. That sounds incredibly frustrating.
It's been my experience having used autocomplete tools in the past (4-5 years ago would be the last time) I don't miss them at all. I don't think they provide me with any real benefits. This is completely thought through and rational IMO. However I will grant you that it's potentially subjective and not everyone would see the same benefits.
These days 99% of all Java/C# coding is in IDE's. And rightly so, because there is no reason to subject yourself to the torture of programming using an text editor. That sort of verbosity and boiler plate should be handled by tools, not humans.
People who code using simple text editors, in highly verbose and boiler plate demanding languages like Java are exceptional few and going by the trend will never be the norm.
I think the trend will actually go the other way though and there'll be less gigantic IDE usage in the future, but I'm not going to put money on it.
1. Ctrl-1: Automatically tries to fix a compile error. I use this a lot to get my imports automatically, and for other random things.
2. Open Declaration: This was touched on by others and is incredibly useful. The IDE can find the right Class even if two have the same name, while search can make this difficult in some cases.
3. Show References: Similar to above, this is just incredibly useful when you are refactoring or need to see how something is used.
4. Generate getters and setters: I know this one is dumb, but it's so convenient. I just hover over the unused warning then click, and i've got the code.
This editor is snazzy and fast but I don't think I can make the switch.
I wouldn't disagree about learning the libraries you use frequently, but I personally work on a huge stack with more than 80 dependencies and memorizing their api's just isn't time well spent.
Or, I work with a REPL. So I write the code there and run it before putting it into my code base, so I know it's correct.
Dynamic languages grant huge power to small programs. Greater power through less code is surely the future.
It is detailed in the later part of this Alan Kay presentation:
https://www.tele-task.de/archive/video/flash/14029/
( around minute 45 or so up, perhaps earlier for more background )
Tool generated code, might be a big thing in the future. Eclipse + Java is already 80% tool generated code.
Editors are vastly more complex than necessary.
I want an editor like google.com. It's simple "sentence" model totally wins. Of course, creation instead of consumption requires additional abstractions.
Three dimensions build an entire universe. An editor built with three choice abstractions could outstrip every other editor conceived. Ever.
Somebody do it.
1. all text is "alive" for the purposes of executing/finding
2. select/execute/find for left/middle/right mouse clicks
3. ed-like command language (sam) plus structural regexes with conditions and loops
The lack of syntax highlighting is a usability problem, but also the fact that there's no good way to integrate it into something like acme is evidence that we're still missing one of these dimensions. The general problem seems to be recovering structure from the text on-the-fly and doing something with it, like highlighting or special structured editing. Emacs gets its "power" by letting the programmer directly manage what's on the screen and what happens for any key press. Editors like SublimeText and TextMate just have keybindings and language grammars, and syntax highlighting is sort of built-in.
If we had a good general solution to this problem and could plug it into acme, acme would really be compelling. But I can't really use an editor that lacks syntax highlighting.
And of sam and how some of the best programmers I know use sam[1] a language that provides even less configurability than acme.
[1]: http://sam.cat-v.org
http://ipn.caerwyn.com/search/label/acme
If I understand correctly, these hinge on 9p; instead of Acme worrying about keypresses, it's some 9p client worrying about characters read. A clever solution, and self-evidently powerful, but with the obvious drawback that most of us aren't running Plan 9 or Inferno. And we still have the problem of syntax highlighting.
http://utcc.utoronto.ca/~cks/space/blog/programming/FancyPro...
set expandtab
au FileType make setlocal noexpandtabYou simply
set filetype plugin on
then put configuration files for a filetype into ~/.vim/ftplugin/$filetype.vim
(for example, python.vim, text.vim or even gitcommit.vim).Within those, you can do things like setting expandtab or the tab/shift width - they are full local subconfigurations which override your global configuration. They are usually not very large (5 lines on average for me), but it sure helps keep things organized and easy to find and change.
If I want to use vim, I can use vim. Heck there are many things these days that will give you the same GUI candy what GUI based text editors give.
Glossy text editors come and go every 2-3 years, Editors like Emacs and vim stay.
The next question then must be: when do we start writing the next generation of tools? Now, or should we wait?
Firstly you are not going to live for the coming 100 years. So lets not worry about impossible scenarios.
Secondly next generation tools for the next hundred years need to be designed such.
36 years × 39 = 1482 more years of Vi.
I know Vim has NerdTree and the equivalent Cmd-T plugin - I have tried them and they don't work out quite the same.
There are still lots of things I like about Vim that aren't there in Sublime but it's all about compromises. I still use Vim for editing single files but use Sublime for any project that requires multiple files to be opened and edited.
Classical pianists don't. Every other kind of professional pianist does it all the time.
Except if you don't consider someone like Keith Jarrett, Herby Hancock or Chick Corea a "professinal pianist".
As for "not supporting all the vim keystrokes", ever heard of the 80/20 rule?
Configuring my text editor isn't the main thing stopping me from writing good and fast code, but a badly configured editor does inhibit it. Working with 0 plugins is not a bad deal, but I am missing the point why I would want to.
Sure I can manually comment/uncomment(nerdtree), manually write nested html(zenconding), manually balance parens when writing clojure/racket(paredit, autoclose), do a :ls and buffer switch(bufexplorer), diff swap file and on disk file and recover accordingly(recover)....etc etc.
These aren't the most important things when it comes to writing good code. That doesn't mean it doesn't help. My .vimrc is 300 lines, and there is nothing in there which I don't need or which doesn't help me write fast code.
These simple abbreviations save me a ton of irritation:
inoremap \1 <%<Space><Space>%><Esc>2hi
inoremap \2 <%=<Space><Space>%><Esc>2hi
inoremap \3 {%<Space><Space>%}<Esc>2hi
inoremap \4 {{<Space><Space>}}<Esc>2hi
No one is contesting you can't type '{{ some_crap }}' repeatedly, but I don't see how doing that is beneficial in any way.Adding simple customization to vimrc is simple. Plugins are even simpler. Committing the shortcuts to muscle memory is not as simple. But if you really need the customization/plugin, that means you will be using it and it will become muscle memory very quickly.
Thinking is the major hurdle when it comes to writing good code, but it isn't the only one. The other factors are important.
When it sunk in for me, I found myself combining operations in new ways without thinking about it. The situations where I really have to think about what I'm doing are usually when it's something weird like encodings or huge blocks of strangely formatted daily-wtf-worthy legacy code.
Sublime Text certainly has a lower upfront commitment cost to productivity, though. I still pop it open occasionally just because Ctrl-D is amazing.
I spend most of my time at a black/white board. Once I've won the chalkboard battle, I've put it into motion with chalk, whiteboard markers, and just wrote the computer code. I recommend the latter, though that still leaves a few options open.
For now, I'll let conciseness win.
Editors seem to raise a lot of religious issues, and not to totally discount the distinctions that can be made between them, but I think it's more important to know your editor well than to worry about "the best editor." (If such a thing exists.) As Hunt & Thomas say in The Pragmatic Programmer: "use a single editor well."[1] You'll be most productive if you learn your editor from head to toe, than if you half-assedly know several. That takes some effort and conscious practice, sitting down and memorizing key combinations and the like. And a cursory glance at any editor might leave you unimpressed until you've gotten somewhat fluent with its features.
Just a couple of suggestions if you do use ST2:
+ get package control: http://wbond.net/sublime_packages/package_control/installati...
+ For rails, a couple of nice packages are RubyTest and SimpleRailsNav
+ Learn the multi-edit commands
+ Familiarize yourself with cmd-P/ctrl-P (osx/win)
+ Keyboard shortcuts: WIN: https://gist.github.com/1925069 OSX: https://gist.github.com/1207002, or look at Default (OS).sublime-keymap
[1] I would amend that to add "and also know vim at least a little" for stuff like sshing in to servers and whatnot.
abc/def/ghi/foo.py
jkl/mno/pqr/foo.py
stu/vwx/yzz/foo.py
...you can type command-P, then "kfo", and you'd get the second foo.py, as it's the only one of the set with "k" in its path.I'm happy so far, but hope they add multi-window support and terminal integration (unless they already have).
edit: Sublime has a CLI, but can't be run inside terminal.
Ideally I'd like the same environment mixed with some nearly "ide-looking" find-and-replace/refactoring support.
ST2 supposedly has these features from what I've read, just haven't dug into em yet.
If this advice is to be taken seriously the only editors you can learn is vim and Emacs.
Shiny editors like Sublime Text come and go every 2-3 years. And putting effort learning them, only brings you back to your statement: "You'll be most productive if you learn your editor from head to toe, than if you half-assedly know several."
"use a single editor well...learn [] vim and Emacs"Case in point: WinRAR, anyone?
EDIT: Just to clarify, I like the pricing model too. I just don't think it works for software in general.
I point out winamp because it is similar in that no new features are unlocked after paying.
I think the nag dial is just about right between casual use/unlimited evaluation and I'm using this editor for real shit.
That is, it's not like, say, Chrome release where it's Dev -> Beta -> Stable. It is (was?) more like Nightly -> Dev -> Beta/Stable.
That right there sold me- no issues at all getting purchase orders at work and regardless of the OS I'm using I still have the same editor.
Of course, it is much harder to learn how to use Emacs properly (navigating with the keyboard, using more obscure commands, writing your own elisp... and so on). However, as everybody has pointed out, your text editor is probably your most important tool; it seems odd to be willing to put down some money on one but not willing to sit down with a tutorial and learn how to use something like Emacs well. Sure it might slow you down for a bit (it took me about a week to get as proficient with Emacs as I was before), but it's completely worth it in the long run. I've been using Emacs for almost three years now, and it's helped me do all sorts of things more efficiently than I would have with another editor.
Don't assume that people are flocking to ST2 because they're not aware of the alternatives. I'm very aware of them. For me, the advantages of ST2 over Emacs were worth the money and I'm glad I bought a license.
That said, I always keep the latest Emacs installed on my laptop and I could jump back into it if ST2 were to disappear off the planet tomorrow. I hope it doesn't, though, because I find ST2 more pleasant to use than Emacs and I hope I can keep using it for a long time.
I don't even click tabs that I have open any more, I just hit Apple + p and start typing say g-l-o for global.css and I know its there, hit enter and voila.
Like you say, multi-platform too, so I get to use it on my little Ubuntu netbook and on my iMac. Love it. Really should buy a licence.
Edit: Scrap that, rush-read - CntrlP doesn't beat Sublime's Apple+P. Honestly, try it and you'll see what I mean.
At one point, the Textmate website mentioned that a follow-mode-like feature was in the works, but 1) I can't find that mention anymore, and 2) even if it is, I'd rather not wait forever for it.
I believe this plugin does what you want: https://github.com/atbell/SublimeSynchroScroll
1) rounded corners on selection boxes
2) nice glowing, fading cursor
3) smooth scrolling with a feeling of velocity/inertia
4) the minimap
I tried the Vim plugin, but so many of the motions that I use daily were missing I had to jump ship. But I'd love it for MacVim to have the same level of visual and UI polish that ST2 does--it really sets a high bar.I do wonder though, if visual attraction is such an issue to you, why in the first place do you use Vim?
But I do think there's probably some vague psychological argument to be made about the elegance and simplicity of your tools mirroring a state of mind conducive to elegance and simplicity in your programming. It's why people are into tools like WriteRoom.
Plus, I feel like the smooth scrolling feature actually does help you preserve an awareness of where you are when you're browsing a file.
Also a lot of the time the thing I'm trying to navigate to is library code that's referenced via require, vs something that's actually in my codebase proper.
It opens a new tab with your search results, and you can double click on a result to be taken to that place in that file.
It's admittedly not as slick as what you're asking, but it serves me well enough in exploring a codebase.
I'm an Intellij power user but tend to use Sublime for Rails & other dynamic languages. Using the same environment all of the time would be nice.
I'm a long-time Java programmer who's spoiled by tools like Intellij, and I cry every time I want to delve into a Ruby library that my code uses, but can't do so because the editor (even Intellij/RubyMine) can't find it. Oh, you want to jump into the "foo.open()" method? Here are 58 choices- pick the one that looks like it might be the one you want.
There is no reason why you must subject yourself to that sort of a torture.
The IDEs are designed to make your life easy for that kind of verbosity and boiler plate.
I don't see anything really fundamental that should stop an improved/better plugin from working, the hooks should be there.
If you had to stand up and sit down in order to open a file menu you would think that was silly, but could make the same argument for it that you did for the mouse.
In the Zeus editor you just have to place the cursor on the name (using the keyboard or mouse) and hit the F12 key.
This reminds me of the times I was tasked with the job of assisting junior programs with their code.
At times their mouse usage habits would drive me nuts!!!
I would say something like cut those three lines and move them outside of the loop.
I would watch them try to mark the three lines of code with the mouse.
That would take a second or two.
Then they would right click on the mouse to bring up the copy popup menu only to accidentally hit the left mouse button and remove the marked area forcing them to start again.
Five or six seconds later the task was still not done and I would say please move and let me jave a go.
A few key strokes later the cut and past is done.
You should probably work on your patience just for the sake of self improvement. That's a little ridiculous.
I'm looking at a Django project right now. At the top, I see something like:
from django.conf.urls.defaults import patterns, url
urlpatterns = patterns('', [...])
Moving to the "patterns()" call, I press command-F3 and it opens "/Users/kirk/.virtualenvs/portal/lib/python2.7/site-packages/Django-1.4-py2.7.egg/django/conf/urls/__init__.py" and puts the cursor on the "def patterns()" line.It works pretty well.
Specifically for programming I cannot see why you would use this as opposed to something like Visual Studio with its context aware auto-complete (massive productivity increase).
But then again I also don't get why someone would use Vim or Emacs when you have GUI based tools available (even freely). Even for non-Windows programming Eclipse exists and has a decent (if slow) context aware auto-complete for many languages.
The only justification I've ever heard for people's continued use of tools like this boil down to either "I know the shortcut keys" or "I don't have to use the mouse."
Which to me is odd within its self as very little of my programming efficiency is lost mousing around, and a lot more lost having to jump around code blocks because auto-complete didn't magically know what an object's members were...
* No CTRL+D duplicate line in VS
* Can't use middle-mouse in VS to select multiple columns
* Can't place your cursor in many multiple locations at once in VS
* You can use ALT+DRAG to select columns in VS but there's no way to put a carat at the end of each of a bunch of lines of varying sizes
* CTRL+J to append the next line to the current one, removing all whitespace. I feel as if this has saved me a year of life.
Those five alone are extremely useful when writing JavaScript and HTML.
* The autocomplete in VS does not "learn" like the sublime text one does.
* No good incremental search in VS (might have changed on the very newest version?)
* CTRL+B opens the current HTML page being edited in my browser on sublime text. There's probably an equivalent in VS though
* highlighting a string of text highlights all similar ones in sublime text. In VS for C# it sorta does this if the string of text is a token
* The ability to sort and shuffle lines in sublime text can be useful at times, though this is usually when preparing data and not when writing code.
* Ctrl + D does copy lines
* you can place the cursor at multiple places since VS 2010
* Extensive search with R# (Search files, classes, methods... * using CamelCase, fuzzy..)
* sort shuffle lines, methods or any blocks with R#.
So ok, it's R#, and I agree that ST2 is amazing out of the box. (LOVE it for the Rails side project I work on) but adding R# (or standalone add-ins) to visual studio will get you there too.
Navigation within a .NET solution will always be better with VS + R# in my opinion.
1. Ctrl+A Select all the lines
2. Ctrl+Shift+L to split into multiple cursors, 1 per line
3. Home/Ctrl+Shift+arrows/etc to select stuff to copy/delete
I find it easier than constructing a regex to pass to find/replace.
so you got some property names like
a
b
c
d
now convert them into ['a', 'b', 'c', 'd']
with ST2, you middle mouse vertical select, ctrl+right, press ', then end, press ,, then del.
You'd get it if you did.
I say this with a carefully crafted and organized .vim folder.
And I have an .emacs.d folder carefully crafted over 20 years.
Looking at the new features in Emacs 24 I expect my config to shrink even more. I am still on Emacs 23 but will switch when it both shows up on Debian Testing and when my workstation needs a reboot.
If only it were that easy. Programming trends change drastically. What is fashion today, isn't tomorrow. You need tools that survive this for years(In case of vim and Emacs its decades).
I am all ears to hear about the 'tools' that you talk about.
emacs lives on every server I have to work on.
emacs works with every language I have to use for work, including C/C++, Fortran, LaTeX, Python, Shell, and every language I like to play around with, including Haskell, Clojure, and Common Lisp.
I switch between tasks often enough that the fact emacs can do all of them (and doesn't crash all the time like Eclipse...) is great.
I use Eclipse for Java, VC++10 for C++, and ST2 for everything else. "Everything else" is a hodgepodge of things; dynamic scripting languages, JSON/CSV files, plain text files, etc. Basically everything one may use Notepad++ for, true; but I've found that I much prefer the ST2 interface, a subjective conclusion on my part. It's fast, it looks nice (to me), and I like the API.
IDEs are valuable when doing what they were designed for (I use Eclipse when I write Android apps, and I'd probably use Visual Studio if I was going to write something for the MS stack), but I'm rarely doing things that fit nicely into their world, and I end up spending more time fighting with them than they are worth.
That's just for me though.
Also: you can get completion in many text editors if you install the right plugins. See the GoSublime extension that I mentioned for example.
Solving the problem at hand in a good way is usually far slower than editing the text in my experience. Maybe I'd think different about that if I went back to using C++, or were coding in Java or another verbose language, but thankfully I don't have to.
But the bigger reason is: They are GUI apps. I do 99% of my work over ssh connections to servers where I have lots of screens open and waiting for me to attach with all the state I want ready and waiting no matter which machine I happen to connect from.
I have shortcuts for a dozen machines or so on my desktop that throws me straight into a screen over ssh, and even in the two cases where those machines are across the Atlantic for me, my screen with my editor windows is open faster than any IDE I've tried will open locally on my machine.
Being limited to local editor-state seems to me to be a huge step backwards.
Auto-complete isn't about typing speed. It's about API exploration.
So I end up compiling with VS and editing code in Emacs, because VS does not have a shortcut to switch between files quickly and because VS does not integrate with Git properly and because VS does not have keyboard macros and because I just don't like VS much.
Funny enough, I used to feel the same way as you do, though. I mean, how can you live without auto completion? But gradually I realized that in fact, I did not miss auto completion any more after a day or two not having it. And I did not miss a method browser either. And a menu bar. And... a mouse.
I think we humans are clever animals and we can adjust to any number of things. Me, I have been through IDEs (XCode, Eclipse, VS), Textmate, Vim and now Emacs. In the end I think it boils down to fun: I can work with pretty much any tool or language you throw at me. But to really get me going I need to have fun. And Emacs is giving me that. I am not quite sure if it really is any more or less efficient than XCode or Visual Studio or ed or whatever, but I know that I am magnitudes more productive when I am having fun than when I don't.
So use what you like best. Just don't forget that it is about having fun! Anyone who tells you otherwise... well, I frankly don't care. Have fun!
Switching between files works best with Visual Assist added. Alt-Shift-o search string will get a list of matching files, and approximates emacs buffer switching.
Regarding the great IDE vs emacs/vim debate, I find using the IDE is best when working with code, and emacs for everything else. Occasionally I'll need to do something more complicated or that can be automated with an emacs macro and I edit the file there instead.
PS: If it got even a basic terminal...
EDIT2: ST2 does have split panes, I just can't run a terminal in them.
1: http://www.sublimetext.com/docs/2/osx_command_line.html 2: https://github.com/misfo/Shell-Turtlestein (or from Package Control)
EDIT: Ahh I see you edited, nevermind! But you can split the windows easily too!
EDIT: There can be only one!
EDIT: Some insane person seems to have done this: https://github.com/wuub/SublimePTY
I have a linux machine at work and use a MacBook for remote work. When I'm remote I just run Sublime locally on my Mac and set up an sshfs mount to my workstation for the source files. Works like a charm.
Note - not at all saying you're doing it wrong :-) just curious if you'd tried this kind of setup and why it didn't work for you?
[1] The other is it's absolute refusal to "fit in" on whatever platform it's on. Fits with the kitchen-sink approach: why interop with [program X] when you can just build it in?
Although I don't want my editor to do all those things, for me the reason emacs wins is because it invites you to learn the (not unpleasant, genuine programming) language in which it is written and then do whatever you want with it. Even if you basically want to keep it simple having that power to hand is nice.
An editor that can't work in a screen session is simply a non-starter for me, especially as there's pretty much no _benefit_ in a GUI for any of the text editors I've tried.
I was using NFS, btw. Never tried sshfs.
There is one thing that ST doesn't do as well though: pasting blocks of code while retaining the formatting/indentation. i.e. if I copy a loop and try and paste it into another function/whatever and the cursor isn't on the same column, the indentation gets messed up.
It's a minor quibble and far from a deal-breaker, but it is a bit of a shock when it happens.
edit: if anyone is curious,
Preferences > Key Bindings > Default [edit: should use User as noted below]
ctrl+f paste, and change
{ "keys": ["super+v"], "command": "paste" },
{ "keys": ["super+shift+v"], "command": "paste_and_indent" },
to { "keys": ["super+shift+v"], "command": "paste" },
{ "keys": ["super+v"], "command": "paste_and_indent" },Using the user file has two advantages:
First, you avoid mishaps when some future version makes changes to the default bindings file.
Second, you can quickly check what are your non-default settings.
This goes for all preferences files in Sublime. Any declarations in the User file overrides Default settings, and Default settings are overwritten on any upgrade. This caveat has bitten me quite a few times with my packages in Package Control.
I'm guessing I'm missing some of the functionality. Is there a tutorial anywhere to show me what I'm missing?
How have you learned about ST2 features (rather than just repeating your old editing habits in a new program)?
Edit: This was posted above... https://news.ycombinator.com/item?id=4162210. Somebody is apparently writing an ebook and the 1st chapter is available.
That one made me laugh!
1. The linting plugin support was woefully broken and often hung up the editor, that may be better now, but it seems to be a single thread for all plugins. For Vim I use syntastic and find it works great.
2. Visual mode (using vintage) isn't great, block selection pretty much didn't work. There was a plugin that could do multiselect based on regex, but for the most part that wasn't what I needed.
3. Speed wasn't great but it was a beta, I'm tempted to give it another go. To be honest though, at least for RoR work Rubymine seems like a better editor if you are looking for IDE features. It had a pretty decent Vim mode too, no worse than Vintage.
4. Split panes were not great either, I need good keyboard shortcuts to open into vertical and horizontal splits quickly and easily or they are basically useless. Almost every new editor fails at this and makes me wonder if the developers have ever used a decently powerful editor.
If editor developers are not going to learn from the "good parts" of Vim and Emacs then I'm afraid we will never really move away from them.
I don't even use a fraction of the power available to me from Vim yet, but to switch editors I have to be able to find sufficient functionality to make up for what I do use. Believe me I'd love to find an editor other than Vim that works for me.
Though it does have some good parts. Map view Speed Multi-select
There's brilliant plugins for decent linter & auto-complete; If you didn't install package manager you didn't spend enough time with sublime.
Stating find & search is sub-par in my opinion means you must have honestly spent less than a day utilizing the program.
Search:
Ctrl+P
Ctrl+shift+p
ctrl+f
ctrl+shift+f
ctrl+shift+f alt+r (Supports regex)
ctrl+h
Separate console window? As in you can't remove it from the sublime window? Else ctrl+`
As a text editor, ST2 is great. The editor has a project system where you just add whichever directories you care about, which is simple but effective for many jobs.
As an IDE replacement, I don't think the combination of available packages is even close to sufficient yet. If you want to start looking at things like code navigation, code completion, refactoring, and integration with external tools for build/test/analysis/source control, you need a bit more flexibility than the default project system. The catch is that for this kind of tool, it has to be done so that it plays nicely with arbitrary plug-ins in arbitrary languages, and without descending into the kind of abomination that is configuring a project in most IDEs.
That's a very tough problem to solve well. If you work on projects using multiple programming languages, I'm not sure anyone has actually solved it yet. But for single languages, IDEs do a lot more than what ST2's default project system can support, and if anyone has built a plug-in that gets anywhere near what I think would be necessary, I've never found it so far.
1. Multiple cursors. This is the only reason I ever use ST2 now. They're sort of like vim's visual block mode, except on steroids. For example, if you have multiple cursors, you can start typing and each cursor will behave as in insert point. Each cursor can also move independently, which means you can do things like moving word-wise or line-wise over lines which are not heterogeneous. Using Cmd + D, you can add selections, and then they're multiple cursors. This ends up replacing things like find-replace for me, because it's so fast and easy.
I should make a video of me using multiple cursors, because I feel I'm not explaining it well at all.
2. Cmd+p/goto-anything. Suppose I want to go to the getUser method of the auth class. All I have to do is hit Cmd + p, then type “Au@getUser”. As I type, a window appears with filenames, so first I type, “Au”, and then seeing that “Auth.php” is at the top, I type an @, which tells ST2 I'm now looking for a method, it then starts searching for methods within Auth.php.
Now, with vim I use Cmd-T, but that only gets me to the file, and it's kind of a bitch to get it working. It also has a thing to navigate methods, but I have to use something called tags, which means a) I have to figure out what the hell that is and b) I have to fiddle with getting it all setup. All that time could be spent programming. Mmmm, programming. I understand ctrlp makes some of this better, but I haven't tried it yet.
3. Better platform integration. With vim, there's a bunch of weird shit I have to do to get the clipboard working properly (including recompiling vim o_O), and the mouse seems janky. I mostly never use the mouse anyway, but the clipboard issues are annoying.
4. Python API vs vimscript. I wrote a couple of small plugins for ST2, which was nice and easy, because everybody knows python, and the API is modern and well thought out. With vim, I feel like it's a whole different matter, starting with learning a new programming language.
Well. I'm not exactly old, but seeing someone say that about tags has made me feel rather ancient.
There are better ways to navigate code than tags. For Emacs, for example, my setup uses Rope to navigate Python code.
People who grew up coding C had to learn to use ctags, whereas, people who start out in interpreted languages are much less likely to encounter such.
>involves the extra overhead of learning things like tags or rope even.
Rope has no learning overhead. It works the same as any IDE. You use the functionality it provides like "go-to definition" or refactoring.
Tags are just a file you generate using a command and the editor uses it to provide a "go-to definition" faculty.
Edited my comment to better reflect the content and mood I wanted to convey.
Thanks for the feedback.
I'm talking specifically about tags, because it's the tool I'd need to use to get goto-anything functionality in vim using command-t or ctrlp.
Whenever there's a debate about something like ST2 or an IDE vs vim/emacs, the argument is always “well you can do all that stuff with vim, just install x, y and z plugins", and I was making the point that with ST2, the out-of-the-box goto-anything functionality is really excellent. I love vim, and can't see myself ever going back on that, but I certainly appreciated with ST2 that the baked-in, absolutely-zero-effort-required goto-anything functionality was really excellent.
That might be true for vim, but it isn't for Emacs. Most of what you need is built-in, with the occasional plugin only coming in when you want hardcore IDE functionality or something uber language specific. It supports virtually every language, VCS, use-case, etc. out of the box though.
Has it ever occurred to you that people who've been programming for decades have a reason for putting forth the advantages of editors like Emacs and vim?
Of course--I stated clearly that I'm a vim user and that I love it, and couldn't see myself going back. But I still appreciate the out of the box functionality and ease-of-use of ST2.
You can bolt vi/vim on top of it if you really want the modal editing though.
I'd love to have this explained better with good examples of where it's useful, other than just changing variable names.
I understand this is one of the most used features but I have a hard time seeing a lot of use for it, but that's probably because I come from a single-cursor editor background.
What I'm still missing in vintage-mode is search/replace (mostly ':s' and ':%s') and block visual mode (^V in vim). The latter habit I could probably break, but the search/replace stuff gets me all the time.
Is there perhaps a plugin/workaround already to get Vim-style search/replace or do I have to hold out for another version?
Giving Sublime a whirl now. If nothing else it's going to be an interesting discovery of which Vim features I really use in my daily workflow.
Edit: Sadly bumped right into the next issue. It seems in addition to the lack of Vim's visual-block-mode the native multi-select (Ctrl-Shift-L) doesn't work in vintage either. No multi-line editing at all is a bit of a showstopper.
Anyway, there's always a next version, I'm not giving up hope. :)
E.g. make visual selection, shift-I = prepend text to all selected lines. This is the same functionality as sublime multi-line editing. The problem is that neither seems to work in vintage-mode (or I'm just too dense to figure out how).
Edit: Nevermind, it works now after I started over with a fresh config. Apparently I had something bad stuck in there from earlier experiments. Thanks for the replies!
Try selecting several lines in vintage mode, then hitting Ctrl+l?
* Search/replace: ctrl-f will do find (and you can use a reg-ex, case insensitive, etc, based on the little toggles to the left of the find bar. Then hit "Find all" on the right, and everything in that file will be highlighted and you'll have multiple cursors. So from there, just type what you want to replace all the words with, or really do whatever you want with your multiple cursors.
* "bulk edit actions": Works just fine for me in vintage mode. Highlight each line you want (or repeatedly press ctrl-l to add a line to your selection), hit ctrl-shift-l to get multiple cursors, and then do what you want from there. Example:
You're in vintage/command mode. Highlight three lines. Hit ctrl-l to flesh out the top and bottom lines (so the whole line is in the selection, and not just where you started and ended your mouse drag). Hit ctrl-shift-l for multiple cursors. Now you have three separate cursors, each in command mode. So you can hit "I", and you will go into insert mode three times simultaneously with three cursors at the beginning of three lines. Type "blah", and it will appear at the beginning of each of the three lines.
Rather than spend a few hours before abandoning, do you think and advanced vim user could successfully make the jump?
Of the features you list, you can record macros into a buffer (qa...q, @a works) but you can't "ap to edit them. Text object support is pretty solid. I don't use pathname completion in vim so no idea, switching panes is reasonable (at least on OS X) but you can rebind to something more vim-like without too much trouble.
It's taken me about 9 months to migrate, the big holdup for was correct text objects (any multiline object was linewise for a while...) and ctrl-i/ctrl-o support. For the latter, I found a plugin that mostly did what I wanted and patched Vintage in about a half hour. Vim compatibility has improved greatly since guillermoo and msfio started hacking on the Vintage repo.
As for whether to switch, the advatage of ST is better plugin API, which matters to me since I do write my own plugins and first-class support for a lot of the things I had as plugins in Vim (snippets, project drawer, autoclose/surround, project fuzzy search). I keep meaning to do a vim-incompatible Vintage "s for select" plugin which would do text objectish multicursor selection but other projects have been more pressing.
I'd also love to see a "cheat-sheet" for shortcut keys.
Anyway you can find a great cheat sheet on the links below:
For anyone looking to try out ST2 with SFTP, I've written a plugin to import server settings from FileZilla[1], makes it much quicker to get up and running. Should be in ST2's Package Control any day now.
With the need to maintain backwards compatibility with a stable version 2.0, that's not going to happen now. :(
http://sublimetext.userecho.com/topic/19331-better-or-custom...
Allow me to recommend the SublimeLinter plugin. Its name should be self explanatory.
https://github.com/SublimeLinter/SublimeLinter
Also, for those asking about discovering functionality, have a browse of the default key binding definition files, it is enlightening.
+ Syntastic [https://github.com/scrooloose/syntastic/] eclipse-like real-time linter. Gives me compile errors and warnings.
+ Tag bar [http://majutsushi.github.com/tagbar/] navigate tags in the code
+ Not as essential, but EasyMotion is pretty awesome [https://github.com/Lokaltog/vim-easymotion]
CTags https://github.com/SublimeText/CTags
Similar to EasyMotion https://bitbucket.org/sublimator/volcanoes
More plugins http://wbond.net/sublime_packages/community
although less mature editors like TextEdit or http://vicoapp.com or http://chocolatapp.com (beta) and http://activestate.com/komodo (IDE) don't have any problems with bidi and rtl texts
other OS X editors that could't show bidi and rtl texts:
TextMate 1 (http://macromates.com)
MacVim 7.4-64 (http://code.google.com/p/macvim)
Anyone know of libraries that can automate the creation of these kind of animations?
http://mue.tideland.biz/2012/06/using-sublime-text-2-with-go...
Sublime Text 2 is really a wonderful piece of software. I can't live without multiple cursors anymore. Of course it can improve (anything can), but in my opinion is the best text editor available.
The only additional package I use is the Dark Soda Theme, is there any others that people would recommend for Rails development? The default editor seems to provide a lot. I tried SublimeCodeIntel but it kept crashing.
and Rails Nav: https://github.com/noklesta/SublimeRailsNav which gives you a pretty neat way navigating your app. Much like the common vi plugins.
Apparently, there's some sort of binding thing going on, which I overlooked and now can't find a way to examine/redo? Additionally, some prefs are plists, some are python, and some look like they might be Textmate preferences.
Give it a try. It is not as bad as it looks on first sight. You'll get used to it and probably appreciate it a bit in no time.
From where I sit, I can work with 6 different OS'es (yeah, it's a jungle) all from the comfort of OS X.
I get that this is a programmer's editor and so maybe a certain amount of "roughness" in design is appropriate. But I'd rather spend my time customizing my own apps than trying to figure out how to change one setting in my editor.
I can also understand if ST just isn't there yet as far as preferences go. Each OS or flavor thereof has it's own convoluted methods of writing that piece of the UI, but it's an important piece as far as OS X goes. Without it, ST will always feel like an incomplete product (in the half-baked sense, not the future development sense).
Sorry, but first impressions matter. Up against BBEdit and even old Textmate, ST seems to only have one thing going for it (the visual navigator) and that's not nearly enough to make me even more than momentarily interested.
This looks and feels very much like an alpha product or charitably, even a beta. But it definitely doesn't feel like something that should be a version 2 and charging $60 for the privilege of using it.
That being said, this is not the first time I've heard this line of criticism.
I remember when I was argueing just the way you are now. Maybe you will follow my steps. Maybe you won't. Anyway, I wish you the best of luck in your own bubble of happiness.
https://gist.github.com/2996448
It was the one feature in Sublime that was missing for me, and the one I needed most at the time (cataracts suck).
I just hope that it keeps getting new features, the thing I'm really really missing is a terminal that runs in a ST2 tab.
For example I can't hit tab to auto complete. I'm also missing all the zsh awesomeness, so a real terminal running in some tab would be the best solution!
Edit: Strike that. Nothing in their EULA expresses this. It simply seems like an open-ended "trial period." So, yes, it appears they're sticking to the guilt model, but unlike WinRAR, won't bug you about it.
They do bug you (albeit less frequently). As mentioned in another post here, they ask you to pay occasionally when you try to save.
http://ec2-174-129-28-157.compute-1.amazonaws.com/2012/06/25...
the inline parsing of CSS & javascript seems like a huge productivity gain.
You can also Command+Shift+P and "Discover packages"
( just see what happened when TextMate got stagnated, there must be other examples )
It's my hammer, it must be open source if possible.
ST seemed to be going in the right direction, but it was nowhere near as complete as even an uncustomized workaday Emacs clone.
[speaking with 30+ years of Emacs, and as a user of many, many other editors in environments that didn't support Emacs: ST seemed to be like using VMS's EDT -- a fairly capable editor, but not one I'd bring home to Mom]
But if you're like me... Well, Emacs is a way of life and it does a whole lot more than just editing text. I would love to have smooth scrolling and multiple cursors and slick animations and a cursor that can be off-screen. But at the end of the day, I prefer magit and org-mode and keyboard-only navigation and macros and so on. It still is awesome though. Do give it a try!
Maybe in a few decades it will have accumulated enough awesomeness to compare to our beloved Emacs.
(global-set-key "\M-n" "\C-u1\C-v")
(global-set-key "\M-p" "\C-u1\M-v")It will send you back to work after the forth refresh.
It's good for a windows user?
Incidentally, why is it that so much software on Windows is "under-designed"?
Jussi Jumppanen
Author: Zeus Editor
Compare that to the 7 day trial of Coda 2. Nowhere near enough time to evaluate an editor, let alone wait for the next bugfix if you run into any issues.
Enable Vintage and then install VintageEx from https://github.com/SublimeText/VintageEx
Very simple - and brilliant!