Hm, Am I the only one who spends hours in vim each day with ~15 lines in my .vimrc and almost zero plugins?
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.
I continue to be haunted by something a good artist friend used to say: "Don't obsess over your tools. They are not the goal".
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.
> the time I invest into my tools have made my experience of sitting down in front of a computer incredibly enjoyable
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.
Similarly, that's why almost always, the first thing I do when building a web app is to design it, because it makes those 40+ hours far more enjoyable to be staring at an attractive program.
I've once watched a group of sculptors argue about the merits of various drills for a whole evening. So yes, artists also obsess over their tools just like we do over ours.
Well, the poster said a "good artist" told him that. Even so, perhaps your group were good artists but misguided on just this one issue. Another anecdote, I saw a thing on ice sculptors; there were two really amazing artists and they were arguing about which one used better tools. One artist used an angle grinder exclusively for almost everything and the other used hand chisels exclusively for detail. It doesn't seem like the tool matters that much as long as it is fits a certain percentage of needs.
I don't think these were thinking that a particular tool is necessary for creating good art, either. It is more about the fact that any craftsman becomes quite attached to their particular tools.
This is the root cause of the endless Vi vs. Emacs debates as well.
Fair, though the question is less, "Do we need good tools?" than "What makes a great tool?" VIm and Emacs both make great tools.
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.
For mechanical things, I think your father is exactly right. For programming and text editing, I think it is different. If you don't have the right sized socket wrench, probably all you are going to do is destroy whatever you are working on. With programming, i.e. editing text, it's a different story.
I think, in these days, it is not too much to ask for the intelligent completion, e.g. when you type dot or arrow, to get corresponding members of class/struct - the information is just there and the editor has enough power to parse it...
Same goes for a very simple word completion - when the editor already encountered the word in the previous line.
But it's not. In fact intelligent completion is incredibly hard for dynamically typed languages. Those IDE that do perform intellisense or autocomplete with dynamic languages do it with very basic ability. In a real world dynamically written code file the editor simply has no way of knowing the members of a class. Or if it is even a "class".
I started programming on VB3 and spent many years doing Visual C++ and C# as well as quite a bit of Java with IntelliJ. I depended deeply on IntelliSense/autocomplete. Years later, I don't remember how I ever got anything done with that stupid distracting drop down box. It's just so easy to arrow up/down through that list and hope to stumble upon the correct method to call. On the rare occasion that I type that member accessor dot and don't know what I want, I much prefer full-sized documentation in a browser that I can cmd+f on.
Using it as an alternative to documentation is a small part. First of all you get a confirmation that what you have up to that point is somewhat correct. If the dropdown doesn't show then something's wrong - sometimes that's ok and expected. You also get a type confirmation and actual completion as in type one or two characters and have the rest filled out for you.
It's just a different style of working, but I almost never type long symbols. I go to their definition site, yank them into a buffer, and paste them into place.
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.
Actually, Eclipse's Python support is decent. You can infer a lot about what a type is by what methods and properties are accessed. It's not perfect, but it can do a decent job of it in a lot of cases.
I am still looking for a Perl IDE which offers autocomplete - or at least the option to jump to where the currently selected method is defined. Something like the Groovy/Grails-support in IntelliJ - but of course, Groovy is somewhat easier to autocomplete because of the underlying Java class system.
IntelliJ does really impressive type inference in Groovy. I can write all sorts of dynamic code and it autocompletes surprisingly well. Not as great as Java, obviously, but impressive nonetheless.
It all depends on your average typing / coding speed. Autocompletion doesn't offer a lot to someone who knows the language framework really well and type 90+ wpm. You may even find it's annoying more than helpful most of the time.
I'm not that fast and to be honest I really don't miss code completion at all.
It's not so much about typing less as it is about interactively learning to use an API or codebase. Suppose you have a comment object and you want to get the body text of that comment. With autocompletion you can just type `comment.` and you'll immediately see whether it's called "body" or "text" or something else, instead of having to browse around the codebase (which incidentally is also easier in an IDE that understands your code, because you can put your cursor on the class name and press a "go to definition" key instead of having to find it manually).
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).
To me what you're describing are imagined problems. They aren't real problems for someone who eschews autocompletion tools. No offence intended.
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.
> 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.
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 wasn't using the term "training wheels" in any sort of derogatory way. You described autocomplete as a learning tool to get you up and running fast with a new API. Training wheels seemed like a good analogy. Nothing macho about it.
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.
You are arguing against a lost cause. Using a text editor to work with languages like Java/C# was the trend of the 90's.
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.
You're probably right. The last time I touched Java was about 4 years ago. Even then I was using a basic text editor (Eclipse was a monster at the time that took forever to launch and hemorrhaged memory), but it wasn't so bad in the Spring (and Guice) world because you were mostly working with POJOs and didn't need any of the Eclipse autocomplete and refactoring tools.
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.
I tried to use Sublime for Java (w/ Spring/Hibernate) for a day and found several things I can't live without:
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.
Why waste the mental space, especially with something you don't know you'll be using again? Not to mention the fact that api documentation can be difficult to find or may not exist at all. The Autocomplete knows exactly what methods are available.
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.
Most APIs I use I don't intend to use many times again. If I'd be coding against the same 5 libs over and over again, chances are big I'm coding roughly the same thing over and over again. That sounds very boring. (that, or i'm coding something low-level like a db or a protocol - but are you?)
Most APIs I use, I end up using over and over and over again in different projects / applications.
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.
> 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.
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:
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.
In my experience, Sublime Text hits that exact niche you're describing. It does the things important to programmers, or people who work with lots of text, well enough that you don't have to worry about any plugins, etc. But it also offers a great plugin ecosystem for just about anything you want. Turning on "vintage" mode is a great plus, too, especially coming from vim.
And, like every vim emulator ever (with the possible exception of Emacs' spawn), it doesn't support all the vim keystrokes I use daily. My brain knows vim, and I'll code in vim. You don't see professional pianists perform on electric keyboards.
That's what I used to think. Then I started using Sublime text and it's project management features (together with Ctrl-P/Cmd-P) and realized what a huge productivity booster it was to me.
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.
Umm what? Yes they do and that is a pretty terrible analogy even if they didn't. Why do you feel the need to pollute a release thread with your VIM elitism?
The original code for vi was written by Bill Joy in 1976. So, if we applied Gott's Principle and estimated the maximum upside of how long we'll be using Vi or Vi-like editors:
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.
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.
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.
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.
my experience was that once you get used to keeping everything important in either svn or in a backup snapshot, you simply become annoyed by all of the tilde files lying around.
I'll bet you don't spend any time editing multiple languages with conflicting notions of whitespace. I split my time between C and Python, and tabs in C (per Linux kernel coding style) and spaces for Python (per PEP-8), and having that be correct is important for my sanity (as well as for the other people I work with - especially those who aren't multi-linugual).
Vim has the ftplugin (filetype plugin), which makes this easy as pie,
and extremely configurable, too.
You 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.
From colors to text objects, most of my vim config/plugins is not about speed but about reducing strain (which has the positive side effect of enhancing speed)
While partly true, the secondary issue is that your editor is inferior to the current state of the art (on all platforms).
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.
But so do Vim's t text object (one of the few text objects that Sublime's Vintage mode doesn't implement) and dot command, along with Vim's C-o and C-i cursor history commands.
Using macvim is surprisingly like using a normal editor; even more so after you press "i" and start typing. All the normal copy, paste, highlight, tabs, and other os basics that you would want are there with the power of vim in the background if you want to explore.
That's an issue for the first month or few, but then it goes intuitive.
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.
Serendipitous, as I'm planning on doing a lightning talk on ST2 tonight.
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.
>>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.
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."
What prevents me from using cmd-P is that I usually just open my entire project folder in Sublime. When I do cmd-P to open for example "foo.py", it doesn't understand that I mean the foo.py which is in the same directory with the file I have currently open. Instead it lists all the foo.pys I have in any project I have ever created.
look forward to your talk tonight. I blew half my morning in vim playing with different plugins for a better file search experience, and finally caved and installed ST2.
I'm happy so far, but hope they add multi-window support and terminal integration (unless they already have).
My vim setup has typically been two vertical split buffers,
one with whatever code I'm looking at, the other running either another piece of code, or ConqueTerm (bash console within vim).
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.
I don't know of any full fledged terminals that you can embed in st2 at this time. There's a plugin called Shell-Turtlestein that allows you to run a single command. \
Can I just say I love the pricing model. It's paid software, with an unenforced 'trial period'. Relying on coders who use a text editor all day and appreciate good software and want to compensate someone for their good software. +1 humans.
I agree. It would be great to see some revenue numbers, if it's really successful (which I think it is), it would be a nice model for other developers or software companies.
Well, it's infinite trialware, but it pops a few nag screens here and there, especially when saving files. And this, when you are working and have a habit of mashing Cmd+S regularly, gets in the way often enough.
I think the nag dial is just about right between casual use/unlimited evaluation and I'm using this editor for real shit.
I'm not sure about that. Developers tend to be more sensible about paying for software. Regular people will just download it without reading the "yada yada" stuff about paying.
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.
An article on the demise of winamp suggested that the winamp people were receiving over $100,000 a month in checks sent by mail. I would suppose if you had an easier way to pay then checks by mail, even more "regular" people would be willing to pay.
I point out winamp because it is similar in that no new features are unlocked after paying.
I'm fairly sure he's made really quite a large chunk of dollar out of it already. Especially after he started forcing people to pay up if they wanted the very latest builds. That was a stroke of genius.
I saw it as more that he didn't want the masses trying to use potentially buggy builds as their 9-5 editor, which is what happened with "dev" beforehand.
Interestingly, I think this model works best for 'software for developers'. Developers naturally empathize with the author of their software much more so than a 'typical user' would.
Developers are typically very bad software customers. As much as they could empathize, more often than not, they think they could do it themselves in a couple of weekends.
I have wasted so many months of my life in this trap, spending a few days coding an app myself rather than paying usually less than $100 for it (usually because I want some small feature it doesn't have) . I dont think its ever been worth it in the long run.
That's interesting. Back when I was using Windows, I had some tools (like WinRAR, I think) with that sort of license. I hated it. One of the things I really loved when switching to Linux is that I didn't have to deal with that sort of nonsense for an archiving tool, or for any other tool I needed but didn't use often.
Naturally, I use a text editor almost all the time. That doesn't make this licensing model any better though: it's still annoying, and there are still superior alternatives that are free in both senses of the word. For me, that alternative happens to be Emacs, but there are other options that are almost as good :P.
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.
While I agree with almost everything you said, I think you're downplaying the importance of person preference. I used Emacs nearly exclusively for well over a decade, but fell in love with ST2 the moment I tried it. To me, it feels like a well-configured Emacs that's 95% the way I like it right out of the box. The other 5% has been easy to install through the package manager. As a bonus, it's scripted in a language I like working in.
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 really appreciate being able to just use it on whatever machine I am at. I did bought it initially just to support the developer, but since I use both Linux, OSX and Win, it helps great deal to have two good editors, vim and Sublime Text ;)
An absolutely joyful piece of software. I love it so much, I bought it right away. Plus, where else can you experience such a pleasant multiplatform situation? Great Job!
I like it too. The main problem I have with it—and Textmate—is the lack of an emacs-like Follow-mode: http://www.gnu.org/software/emacs/manual/html_node/emacs/Fol... . It's 2012, I'm using a 27" monitor, and yet I can't find this feature, or one like it, in anything other than emacs, which has a learning curve far too steep for my pretty simple needs.
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.
Honestly I've always looked at follow mode as mostly a cute toy. It's too distracting to use while editing, and in my single-screen environment I always want a shell beside my editor anyway. Surely the proper solution to this problem in 2012 is to buy another monitor and flip it on it's side, no?
In Vim, you can bind several windows to scroll together by doing :scrollbind in each. It's a bit more manual than what you do in Emacs, but you could use this and some :vsplit'ing to achieve a result similar to the follow mode described at your link (though I'm not sure if Vim has the learning curve you're after).
I started writing the same thing, and thought I'd just add onto this instead. Tried using Vim because I like the look of how flexible it is to tile windows, but I just cannot move away from Sublime's file search.
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.
Yes, CtrlP is faster and easier to install because it's just a vimscript. It also supports all of Command-T's functionality, so it's pretty much just great.
Hey, what agscala says below is absolutely right. I tried it, but honestly, Sublime Text 2 is far superior. Even my Vim-core colleague to my right agrees. And thats saying something!
Edit: Scrap that, rush-read - CntrlP doesn't beat Sublime's Apple+P. Honestly, try it and you'll see what I mean.
I've found Command-T slows way down on large trees, causing a very noticeable interruption in my "flow" when I use it. Also, it's written in ruby which can be a bit more painful to get started with if your distro doesn't compile ruby support into vim by default.
Do you find that it slows down only the first time you use it within an editing session, or everytime you use it? If only the first time, I've got a fork which caches the files to disk, so that you don't hit that slowdown very often. The downside is that when you add new files, you have to bust that cache.
I've been really tempted to fork and contribute to MacVim and steal some of the nicer visual things ST2 is doing. Namely,
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 think that we are entirely different types of developers (and that is fine, this is in no way meant as as being negative on the way you work), but I couldn't care less about the first 3 points you mention. They don't add anything to my productivity.
I do wonder though, if visual attraction is such an issue to you, why in the first place do you use Vim?
I use Vim because I'm faster in it than anything else, hands down.
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.
one of the things I've found lacking in MacVim recently is smooth scrolling. The rendering engine on OSX doesn't handle large files well at all. It's a shame because otherwise everything work quite well
As an Intellij user (and Emacs way before that) I'm trying to give this a chance, but I see no way to click-navigate through source code. Am I missing something? I tried installing SublimeCodeIntel, and that lets me (occasionally) navigate to symbols in the current file. But I don't seem to be able to click through to symbols defined in other files/classes. Am I missing something fundamental, or is this strictly the domain of the IDEs?
It's language dependent. For instance, I've installed SublimeRope for Python refactoring. When I open a new project, I run the "Rope: New Project" command and give it the source directory of the project and the path to the virtualenv I'm installing it in.
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.
Well, given a sufficiently advanced code parsing module, I'd consider Sublime Text an IDE. It's just that CodeIntel might not be sufficiently advanced enough (for your language of choice or in general). It's a port from the Komodo editor, where it doesn't work perfectly, either.
I don't see anything really fundamental that should stop an improved/better plugin from working, the hooks should be there.
I think that if you're using Java you might as well get some benefit out of the static typing- use an IDE that can put it to good use for source navigation.
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.
I use the mouse all the time while developing software. And oddly enough, it doesn't diminish my productivity, since I generally spend more time thinking than typing, and use an IDE to get any boilerplate out of the way or look up API calls or refactor.
Once you are used to an environment where you can do everything with no mouse, it feels very clunky and inefficient when you are in an IDE and you need to constantly switch between typing and using the mouse.
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.
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.
I don't- but for discoverability purposes, I'm more likely to find success by clicking on a method name than by randomly pawing keyboard shortcuts. Once discovered, I'll happily take the shortcut.
Because you don't always know your code base very well. I almost always use vim but when a new large project comes along I've found no better way to read through it than with a mouse.
Even in Visual Studio that's not true, at least not for me. Just move the cursor to the symbol in question, hit the menu key and select the 'Go to definition' or whatever menu item. Or better yet, map it to something like Ctrl+] which I usually do.
I'm also an IntelliJ user, and this really only works when you are coding in Java or other strongly typed languages. IntelliJ's ability to do this with JavaScript and Ruby is abysmal at best.
It's not necessarily click-through as it is type-and-find. Ctrl+P to find a file, Ctrl+R (usually) to find methods/functions, etc. It's still very fast and productive.
I found that, but it cmd+r (I'm on a Mac) seems to only show you hits in the current file. The thing I'm interested in doing is clicking on a call to foo.bar() and have it bring up Foo.rb, right on the "def bar" method.
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.
What I do in such a situation is cmd+shift+f and do a project wide search (I leave that as the default in the "Where" field. You can tweak case sensitivity, whole word, or even just use a regex.
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 just tried Sublime 2 and I must admit I don't "get it." It seems like a basic editor with several features which Notepad++ already had.
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...
See, I tried to use Visual Studio and I must admit I don't "get it". Actually, I'm not mocking you there. This is the truth. But I don't get many things.
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!
ctrl + tab to switch between open files. ctrl + w, ctrl + s to focus the project explorer, from where you can use the arrow keys to select a file from the current project.
He said "VS does not have a shortcut to switch between files quickly". I'm having trouble thinking of a quicker way to switch files than pressing ctrl + tab.
I'm a long time emacs user and I work in Visual Studio a lot. VS does have pretty good integration with Perforce and other commercial scs, which presumably is what most of it's target audience needs.
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.
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.
Regarding auto-complete, I find it is extremely rare that typing speed is what slows me down, nor that I end up having to chase code around. There are plenty of fast search solutions for terminal based editors, but I don't even use things like ctags because the times I've tried it the speedup was never compelling enough to justify yet another thing to install on all the machines I work on.
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.
Exactly. I avoided IDEs for years thinking they were for lazy typists. Finally a friend convinced me to try one, and it totally changed the way I work. Just hit CTRL-space and see what you can do with it. Who needs to look up documentation when you can just hit CMD+B and jump into that library's source code? Oh the time I wasted...
If I don't remember a method or class name, I sure as hell don't want to auto-complete it into what I'm currently typing without opening up documentation.
* 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.
I use ST2 and have been learning about using multiple cursors, but I wonder what kind of things are you doing where that comes in handy? So far I haven't had a chance to use it, especially since there already is a shortcut for commenting things out.
And why would I want to spend years crafting the perfect .vimrc for myself when tools exist that already do 80% of that better and without any configuration?
I say this with a carefully crafted and organized .vim folder.
Yes, sorry to be unclear. When Emacs 23 was released I took a good look at my config and noticed that a lot of things I had added over the years weren't needed anymore.
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.
>>And why would I want to spend years crafting the perfect .vimrc for myself when tools exist that already do 80% of that better and without any configuration?
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.
For me the biggest reason is speed. I use visual studio at work and love it, but when I am at home writing javascript. All those extra features just make it such a slow experience.
I use both IDEs and ST2. As with most things it comes down to personal preference, but perhaps mine may shed a little light.
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.
My biggest problem with IDEs is that they often don't like when I want to do something nonstandard. I've had trouble using git with Eclipse (it works, but I spend more time than I want fooling with it), for example. It's usually faster and simpler to add support for a new programming language or environment to a programmable text editor than to an IDE. Currently I'd say that the best environment for working with Go, is to use sublimetext2 and the GoSublime extension.
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.
I've reverted back to Vim (not really ST2's fault, just that it doesn't run in a terminal and I've gotten addicted to split-panes in iTerm), but ST2's a solid editor. Definitely worth your $60.
PS: If it got even a basic terminal...
EDIT2: ST2 does have split panes, I just can't run a terminal in them.
A basic terminal is 100% feasible under the plugin API... see http://www.sublimetext.com/docs/2/api_reference.html#sublime... ... although to capture keystrokes, you'd need to bind a keystroke to every single key with every single combination of modifiers.
I'm just curious about why you need to run it in a terminal?
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?
Personally I keep 10+ screen tabs open, many of them with emacs sessions set up to specific projects with split panes and files open to exactly where I left off. I couldn't imagine reopening my editor windows every time I'm due to start something. I do this over ssh to my server from my laptop because even the occasional laptop restart is too annoying for the projects I work on a lot.
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 also switched to vim so that I could run it in a terminal. The reason I did it is that I found Sublime Text 2's file listing cache would sometimes get corrupted or out of date, so suddenly I couldn't using Cmd+p to open things anymore. I couldn't find a way to manually bust that cache, so this was very aggravating. I'd basically be dramatically slowed down until ST2 deigned to update itself. IIRC, this was especially bad when adding new files and whatnot.
It's mainly to keep everything (where everything == files, REPL, docs, etc.) in a single window, which I can then throw full-screen and have absolutely nothing but my work in front of me. I'm sure one could use ST2 (or any other GUI app) on Linux with a tiling WM like xmonad and achieve a similar workflow, but there doesn't seem to be a way to achieve this on OSX that doesn't involve ugly/unstable hacks.
You know, in theory it'd be possible to do that within Sublime but I'm not sure if that's veering towards the emacs approach of ALL THE THINGS. I'd have to try it but I think you can probably use PyQt to grab WebKit and make a package to display HTML docs within Sublime
The "all the things" approach is a large part of what keeps me away from Emacs[1]. I'd much rather use a single-purpose editor (like ST2 or Vim) alongside other similarly-focused tools, or a well-done IDE that's focused on it's environment. Emacs tries too hard to be everything at once (why do I want an editor that's a file manager, IRC client, organizer, and Tetris?).
[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?
> why do I want an editor that's a file manager, IRC client, organizer, and Tetris?
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.
You can init Sublime (and open/edit files) from the command line relatively easily[1] and there's a plugin that will allow you run shell commands from within Sublime Text[2].
I suppose you know that you split the layout of ST just like you can split the pane in iTerm2 ... You can even have the same file open twice in a side by side view.
As a Textmate'r, I have to say using ST for the last few months has been a pleasure.
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.
Keep in mind that updating Sublime will revert this file. Add the bottom two lines to your Preferences > Key Bindings > User file if you want to keep them.
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.
Based on the great reviews of ST2, I switched from vim to ST2 (with vintage mode) a few months ago. It seems good... but it hasn't lived up to the reviews for me.
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)?
For me, at least when I tried the beta, the sore points where:
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.
I learned ST2 from my coworkers, who were all using it. Now I'm learning vim much the same way. I've switched to vim fulltime from ST2, and here are the features of ST2 that I miss:
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.
> I should make a video of me using multiple cursors, because I feel I'm not explaining it well at all.
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.
It doesn't seem like the main issue is age as much as that most people will be coming to VIM from either IDEs or editors that had built-in code-navigation features, so moving to something like vim involves the extra overhead of learning things like tags or rope even.
It's funny, I grew up writing C++, but in an IDE. You're probably right that older people may have started programming before IDEs were commonplace (?). I've actually never liked using IDEs for interpreted languages, but have always used them for compiled languages.
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.
>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",
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?
> 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.
Thanks to that blog post I am convinced that ST2 is a better editor than Eclipse. I'd really like to see a similar list for someone switching from vim though.
I did too but couldn't live with the way search worked in Sublime. Substitutions are also too ingrained for editing. In my opinion Sublime is vastly superior to an IDE but way underpowered to compete with vim or emacs.
There are several problems with sublime especially as an IDE, for 60 bucks I don't see how I can justify not having:
A decent linter.
Auto-complete is really shabby.
Find and search, also sub-par.
No separate console window.
Though it does have some good parts.
Map view
Speed
Multi-select
In fairness -- and I write this as someone who has paid for ST2 and recommends it -- the linting and auto-complete support are weak compared to a good IDE.
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.
I wish those plugins worked on plain Windows (were written in C++ or Python), but they mostly depend on external utilities. (In other words: there aren't things like Emacs' js2-mode that really are native to Emacs and will work everywhere).
As a die-hard Vim'er I like this more every time I look at it.
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?
Maybe take a look at VintageEx: https://github.com/SublimeText/VintageEx I'm not sure if search/replace is included but if not you could open an issue and maybe someone adds it. :)
Thanks man, that does indeed add working search/replace!
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. :)
Yes, in particular the "bulk edit actions" (not sure if they have a proper name) that you can do in Vim in either visual mode.
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!
Maybe I'm not understanding exactly what you're missing, but I do believe sublime can do what you want.
* 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.
I haven't used ST beyond a trivial play, I'd like to use it more but I'm also a "die-hard" vim user, everytime I try to switch I discover some feature of Vim isnt there, like half decent macros (at least stored in a buffer and editable in the editor itself), or text objects, or pathname completion, or sensible shortcuts for switching panes etc ...
Rather than spend a few hours before abandoning, do you think and advanced vim user could successfully make the jump?
The problem with answering this question is what exact subset of Vim features you use and whether you're willing to learn replacement commands or hack your missing features in.
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.
Amazing editor. Switching been OSX and Windows frequently, ST2 became my choice of a universal tool. Especially useful when augmented by plugins for better autocomplete: I use SublimeClang for C++/ObjC coding, and https://github.com/alienhard/SublimeAllAutocomplete for js/html/css to enable ST's autocomplete across all opened files, not just current one. Only wish it would support virtual space, multiple cursors/vertical blocks seem awkward without it.
Yes, please. I am very interested in this. I feel as though I've only scratched the surface of what ST2 can do even though I've been using it for the last year and experimented with writing my own plugins.
I'd also love to see a "cheat-sheet" for shortcut keys.
To be honest, my ebook is on initial stage, but I'm actively working on it. If you want to track its progress, here's its repository on GitHub: https://github.com/elomarns/sublime-coding
Anyway you can find a great cheat sheet on the links below:
ST2 is a fantastic program! I was a die-hard Komodo user for years, but ST2 is much easier (and faster!) to use and extend.
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.
I was an active user of Notepad++, but ever since I started using Sublime text, I never turned back to NP++ (or any other editors). Totally love the Sublime experience.
I've been using Notepad++ as my log-viewing problem for a while and I periodically use it to edit a bit, but when I tried out Sublime I didn't see anything to make me drop Notepad++. It did the same things equally well, but not much more from what I noticed.
i really hoped that he would get a fix in for customizable/better matching brackets indicators before release :( those underlines are just impossible to see, and the alternative plugins that do this are not as good as SynWeb component-based editors or NP++ (scintilla)
For me, for "serious" programming, I use a full-fledged IDE which has stuff like code linking, quick project search (with ST2 I have to switch to the terminal), built-in documentation, refactoring support... So paying $60 for a text editor, when there are many good free options out there (even outside of Linux) is too much.
I don't know how to use ST2, but the people I know who use it do project search from within the editor. It looks pretty snappy, about on par with the analogous feature in IntelliJ.
Pretty season's Vim user here. This editor looks awesome, and I would love to give it a whirl, but I feel like I can't switch without these plugins. I'm sure they exist, if someone could point me to one that would be excellent.
The animated screen shots in this blog post and on the front page are quite nicely done. Looks like a series of images being moved and swapped through a canvas area.
Anyone know of libraries that can automate the creation of these kind of animations?
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.
This is great news. Truly staggering amount of effort for a small gap in build numbers (if you were using the last beta). Love the release and the editor. Worth every penny.
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.
Interesting, but no preference panels for OS X? How is one supposed to change settings if they're in a language the user doesn't know well?
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.
I think I'd change editors before I changed to a different OS. These days, pretty much everything can be done from one machine.
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.
Do what you must. But just in general, I would recommend you to try stuff. Especially if it seems foreign or strange to you but many people seem to like it.
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.
You clearly have a different focus than the author of the software, and its fans. ST2's proponents are more concerned with awesome editing power than having a preferences pane.
That being said, this is not the first time I've heard this line of criticism.
True. Even while I love ST2, have purchased a license, and swayed my boss on the subject, it remains, if nothing else, surprising that there isn't a Preferences / Control Panel / Options style option, even as a plugin / package.
For those interested, here's a way to get a block cursor when in Vi(ntage) mode. It can now be installed via package control (instructions have recommended that way to install for awhile, but I could never find it).
Sublime Text is really awesome! It's remarkable work, especially since there is just one developer working on it: ST2 works very well on all 3 platforms, it's very fast and has a lot of cool features. :)
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.
Yeah, I've been using that one for some days already. It's really nice but not what I really want. :)
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!
Am I missing something or is this essentially a donation based model? Are there missing features in the "evaluation version"? I don't mean to sound like a troll or anything but why would I pay for this if I have the option to use the full product for free? (besides possibly feeling guilty)
If the product is good, as in this case, a very sizable percentage of users will pay. The idea that people will only pay for software/music/movies if there are adequate technical restrictions placed on its distribution is what got us into the DRM mess in the first place.
I believe licensing restrictions require its purchase for commercial purposes.
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.
I would use Vim for one reason than anything else. It is for the commands vit, vat, cat, cit and the like that can select matching tags. In HTML editing this has been my best friend and no other editor comes even close to this feature.
Personally, the only thing that prevents me from using Sublime Text is the lack of proper Xdebug support. There is a plugin, but it felt clunky. Being on Windows, it's a relief to use something as nice as this editor.
I think I'll finally switch from Emacs to ST2. I have this massive .emacs config just to make it behave like ST2 does by default. Not to mention turing complete settings can get crazy. Well done ST!
Updating from within sublime text, I get a 500 Internal Server Error in the release note window (being served up by a pretty old version of nginx). Still able to update though.
I've been super impressed by the steady pace shown by the developer in improving and tweaking the many beta releases. Top quality product and I was glad to buy it.
I tried it, on my Ubuntu 64 bit. Everything is fine, except that sometimes it's really slow expanding a directory on the left sidebar. This drives me crazy.
I tried it out, and didn't see anything really compelling.
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]
It is great! It really is! Give it a shot just to see what we Emacsens are missing.
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.
Nothings changed regarding to evaluation "Sublime Text 2 may be downloaded and evaluated for free, however a license must be purchased for continued use. There is currently no enforced time limit for the evaluation.".
I'd be really interested to hear about how well this model works for them. I know that I, for one, am a paying customer because being able to use it for a month or so for free really got me hooked.
Funny, I bought it more or less right away and ended up using Emacs instead. I still don't feel bad about it though. It is a worthy tool in my belt and I love to support it.
I'll most likely end up being the same way. I'm slow to switch editors, but every time I hear news about SublimeText I'll launch it and get closer to just making the switch - and by extension, paying.
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.
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.