The story of TextMate, VIM and SublimeText(progfu.com)
progfu.com
The story of TextMate, VIM and SublimeText
http://progfu.com/post/16407410728/the-story-of-textmate-vim-and-sublimetext
18 comments
maybe http://thisdeveloperslife.com/ can do a show about it.
Vim has the keyboard entry conquered. Emacs may come close enough, but if we are talking photo finishes to races, then I think Vim always edges out emacs by a hair or more (but still misses a lot which Emacs provides.) We will have to get a totally different interface for entering text before Vim is knocked off its perch.
Emacs has a much better Vim mode for me than SublimeText 2, but neither can really give you Vim. The deeper you are in the Vim rabbit hole, the less likely you will be to return to try anything else.
Emacs wins out against everyone for scripting.
There is one other reason that I knew would always keep me in the Vim and Emacs world. At first I couldn't figure out what it was that bothered me about SublimeText 2. Vim and Emacs is open source! I don't see this point mentioned in arguments for or against but this is important to me.
Emacs has a much better Vim mode for me than SublimeText 2, but neither can really give you Vim. The deeper you are in the Vim rabbit hole, the less likely you will be to return to try anything else.
Emacs wins out against everyone for scripting.
There is one other reason that I knew would always keep me in the Vim and Emacs world. At first I couldn't figure out what it was that bothered me about SublimeText 2. Vim and Emacs is open source! I don't see this point mentioned in arguments for or against but this is important to me.
The thing about Emacs is really its extensibility. There is simply no other text editor out there that can open a single C/C++ source file and automatically infer all tags (even of included headers) without any kind of project set up. That is simply awesome and to my knowledge only available with semantic-mode in Emacs.
Vim can use ctags or cscope or clang, but that is not the same thing. These are great tools, but they need to be set up with the correct include paths and they need to be run regularly to be useful.
To my mind, that is what makes Emacs so unique and powerful and that is something that really, no other program can hope to accomplish in a short time frame (sorry, Sublime Text).
That said, Vim hands down beats Emacs when it comes to pure text editing speed. It's keybindings are just a lot more powerful and flexible than Emacs's. And of course, that is what evil-mode is for. It emulates a subset of Vim in Emacs. It is by far the best simulation of Vim I have ever seen (judging from ViEmu, Viper, Vintage, Vico and Vimpulse), but it is not the real thing. Plus, there are lots of great Vim plugins that do not work in evil-mode.
I, for one, use Emacs and Evil and I am happy with it.
And I hope that Sublime Text will provide a potent entry-level drug for the next generation. But really, without open sourcing it at some point, I can't see it catching up to The Big Two.
Vim can use ctags or cscope or clang, but that is not the same thing. These are great tools, but they need to be set up with the correct include paths and they need to be run regularly to be useful.
To my mind, that is what makes Emacs so unique and powerful and that is something that really, no other program can hope to accomplish in a short time frame (sorry, Sublime Text).
That said, Vim hands down beats Emacs when it comes to pure text editing speed. It's keybindings are just a lot more powerful and flexible than Emacs's. And of course, that is what evil-mode is for. It emulates a subset of Vim in Emacs. It is by far the best simulation of Vim I have ever seen (judging from ViEmu, Viper, Vintage, Vico and Vimpulse), but it is not the real thing. Plus, there are lots of great Vim plugins that do not work in evil-mode.
I, for one, use Emacs and Evil and I am happy with it.
And I hope that Sublime Text will provide a potent entry-level drug for the next generation. But really, without open sourcing it at some point, I can't see it catching up to The Big Two.
> There is simply no other text editor out there that can open a single C/C++ source file and automatically infer all tags (even of included headers) without any kind of project set up.
The SublimeClang plugin for Sublime will do this, pretty much. You may have to add a few paths to its global or per-project config file, but that's pretty obvious considering that it needs them to parse referenced files. It works extremely well, giving you autocompletion of any C/C++ symbol as well as automatic compilation error indicators.
The SublimeClang plugin for Sublime will do this, pretty much. You may have to add a few paths to its global or per-project config file, but that's pretty obvious considering that it needs them to parse referenced files. It works extremely well, giving you autocompletion of any C/C++ symbol as well as automatic compilation error indicators.
That is precisely what I am saying: Other editors interface with some tools, you configure them, they call some external process, they have to be run regularly...
Well, Emacs has that stuff built-in, and better. That is precisely the way in which Emacs is more powerful than Sublime or Vim.
Well, Emacs has that stuff built-in, and better. That is precisely the way in which Emacs is more powerful than Sublime or Vim.
I would rather have just the plugin.
The modularity means that the core application itself is small and simple, with fewer moving parts than something huge like Emacs. It also means that I have the freedom not to install something that would otherwise come bundled with/tangled with the app. Everybody wins.
SublimeClang requires a minimal amount of config, is dead easy to install, and it relies on external toolset by design, because building everything in would be insane. I very much prefer that Sublime does not come with this functionality.
(I don't know what you mean by "have to be run regularly", btw. SublimeClang can run continuously and transparently.)
The modularity means that the core application itself is small and simple, with fewer moving parts than something huge like Emacs. It also means that I have the freedom not to install something that would otherwise come bundled with/tangled with the app. Everybody wins.
SublimeClang requires a minimal amount of config, is dead easy to install, and it relies on external toolset by design, because building everything in would be insane. I very much prefer that Sublime does not come with this functionality.
(I don't know what you mean by "have to be run regularly", btw. SublimeClang can run continuously and transparently.)
You misunderstood the parent post.
Emacs doesn't come with everything built-in. But when you extend Emacs, you usually do it entirely in Emacs with Elisp. Emacs libraries rarely call external tools - they usually implement the tools inside Emacs.
Emacs doesn't come with everything built-in. But when you extend Emacs, you usually do it entirely in Emacs with Elisp. Emacs libraries rarely call external tools - they usually implement the tools inside Emacs.
I don't think I misunderstood the parent. The parent heavily implies that Emacs' semantic mode simply works out of the box.
I have no idea if that's the case, but if it's not, there is no functional difference between that and any other editor, where you need to install a separate plugin.
Sublime itself can be extended with Python. To me, that's a better solution than a proprietary (albeit Lisp-based) language.
Whether those plugins "call external tools" or not is of little importance, although relying, in a modular fashion, on pre-existing software is more Unixy.
I'm sure Emacs' tag system is powerful, but personally, I would rather have something like SublimeClang, which is built on a high-quality, highly maintained C/C++ compiler toolchain that retain type information and so on, than some kind of tag system based on a superficial parser designed purely for code inference.
I have no idea if that's the case, but if it's not, there is no functional difference between that and any other editor, where you need to install a separate plugin.
Sublime itself can be extended with Python. To me, that's a better solution than a proprietary (albeit Lisp-based) language.
Whether those plugins "call external tools" or not is of little importance, although relying, in a modular fashion, on pre-existing software is more Unixy.
I'm sure Emacs' tag system is powerful, but personally, I would rather have something like SublimeClang, which is built on a high-quality, highly maintained C/C++ compiler toolchain that retain type information and so on, than some kind of tag system based on a superficial parser designed purely for code inference.
You did indeed misunderstand my post. I was not arguing about the relative merits of clang vs some-other-tool.
I was simply saying that Emacs can open a C++ file and have all tags and completions right there, no setup required. No external application required either. That is the power of Emacs and that is a power not available to Sublime Text (unless you write your own C++ parser in Python).
You see, clang is an awesome tool and I'm sure its integration in Sublime Text is very good. But by its design it can not look for headers in appropriate locations without someone explicitly telling it to do so. Also it can not parse partially erroneous code. Both these actions are just not sensible actions for a compiler.
And that is why no external tool can ever provide the integration and practicability of a tool purposely built just for parsing code for Emacs in the same way cscope can not match the integration of Visual Studio's C# parser in Visual Studio.
I was simply saying that Emacs can open a C++ file and have all tags and completions right there, no setup required. No external application required either. That is the power of Emacs and that is a power not available to Sublime Text (unless you write your own C++ parser in Python).
You see, clang is an awesome tool and I'm sure its integration in Sublime Text is very good. But by its design it can not look for headers in appropriate locations without someone explicitly telling it to do so. Also it can not parse partially erroneous code. Both these actions are just not sensible actions for a compiler.
And that is why no external tool can ever provide the integration and practicability of a tool purposely built just for parsing code for Emacs in the same way cscope can not match the integration of Visual Studio's C# parser in Visual Studio.
I am not arguing the merits of Clang versus some other tool, either.
I am arguing against the claim that a monolithic app like Emacs that bundles a specific tool is somehow qualitatively superior to any other tool which does not bundle a specific tool.
> But by its design it can not look for headers in appropriate locations
I think that's a perfectly valid design. I would rather want to spend 10 seconds adding a path to my project's config file than spend an eternity with just ctags. :-)
> Also it can not parse partially erroneous code.
Of course it can. Clang recovers from partially invalid code just fine.
For example, if I do something like "typedef enum { a, b, 3 } foo bar;" (constituting two syntax errors), it will still correctly autocomplete "foo" as well as its values, even though the type is strictly incomplete.
I am arguing against the claim that a monolithic app like Emacs that bundles a specific tool is somehow qualitatively superior to any other tool which does not bundle a specific tool.
> But by its design it can not look for headers in appropriate locations
I think that's a perfectly valid design. I would rather want to spend 10 seconds adding a path to my project's config file than spend an eternity with just ctags. :-)
> Also it can not parse partially erroneous code.
Of course it can. Clang recovers from partially invalid code just fine.
For example, if I do something like "typedef enum { a, b, 3 } foo bar;" (constituting two syntax errors), it will still correctly autocomplete "foo" as well as its values, even though the type is strictly incomplete.
Emacs is anything but monolothic. I think that is what our argument boils down to.
Emacs is a Lisp virtual machine and someone happens to have implemented da rather splendid text editor in it. Claiming that Emacs is monolithic is about as meaningful as calling the assorted programs that make up a Unix environment monolithic.
Emacs is a Lisp virtual machine and someone happens to have implemented da rather splendid text editor in it. Claiming that Emacs is monolithic is about as meaningful as calling the assorted programs that make up a Unix environment monolithic.
There is one other reason that I knew would always keep me in the Vim and Emacs world. At first I couldn't figure out what it was that bothered me about SublimeText 2. Vim and Emacs is open source! I don't see this point mentioned in arguments for or against but this is important to me.
I agree, especially after witnessing TextMate go stale and TextMate2 start to follow the Duke Nukem Forever release schedule. When I see a project like IntelliJ, I'm confident they will be around awhile. Looking at TextMate and SublimeText... I'm a little hesitant. The development muscle doesn't appear very robust. If a lead developer (or the only developer) gets hit by a bus is the project going to disappear?
I agree, especially after witnessing TextMate go stale and TextMate2 start to follow the Duke Nukem Forever release schedule. When I see a project like IntelliJ, I'm confident they will be around awhile. Looking at TextMate and SublimeText... I'm a little hesitant. The development muscle doesn't appear very robust. If a lead developer (or the only developer) gets hit by a bus is the project going to disappear?
Being open source doesn't change that. Lots of open source project have gone stale or abandoned after one or more key developers lost interest.
Unless people are going to step up and take the lead, being open source means nothing. If you want some assurance in this area it should be:
1) project is open source AND 2) project has a HUGE community AND 3) there are > 2-3 key developers
(I added (2) because even hugely successful open source projects where abandoned and left in the cold when most members of the core team decided to try something different. Like, how, D (the language) was abandoned for D2 (the second, different implementation).
Unless people are going to step up and take the lead, being open source means nothing. If you want some assurance in this area it should be:
1) project is open source AND 2) project has a HUGE community AND 3) there are > 2-3 key developers
(I added (2) because even hugely successful open source projects where abandoned and left in the cold when most members of the core team decided to try something different. Like, how, D (the language) was abandoned for D2 (the second, different implementation).
I recently switched from Emacs to Vim, because Emacs is pretty much unusable on an iPhone or iPad. Vim seems pretty good on a touchscreen. There are things I miss but as a former Emacs snob I'm pleasantly surprised at how powerful and extensible Vim is.
I switched from emacs to vim because I was tired of typing `git commit` and waiting 3-5 seconds for emacs to finish launching and setting up. Since switching to vim I've installed more vim plugins than I ever had in emacs, and yet I can still launch gvim (not just vim, but the GUI version!) in a fraction of a second.
I just always have an emacs running, and use emacsclient to open files in it. Anyway, if you're typing "git commit" you may not be using the capabilities of your editor to the fullest.
I've never found an in-editor git interface that I like better than the command-line (although I am aware that Fugitive is considered to be extremely good). Besides, I do a lot of work outside of Vim. In fact, most of my work is outside of Vim, because most of my work is done inside of Xcode.
I am a former user of both TextMate and Sublime Text.
The TextMate story everybody knows, it was good at first but got stale with no updates. I feel Sublime Text is fantastic, but after reading some article on Janus (https://github.com/carlhuda/janus) I switched over to MacVim.
After fiddling around with Vim for a while I can honestly say I'll need some serious convincing to switch to another editor. I've always stayed away from Vim except through occasional need for text editing through SSH or something, because out of the box it doesn't feel quite right. But after Janus sets up some sane defaults it feels great, and after putting a few hours in to learn all the shortcuts and study plugins I have never felt as productive.
I feel like Janus is sort of training wheels though cause it has a lot of plugins I don't use etc, but it's great to start and as I use Vim more I reckon I will start to manage my own .vimrc.
P.S., bcvi is so awesome.
The TextMate story everybody knows, it was good at first but got stale with no updates. I feel Sublime Text is fantastic, but after reading some article on Janus (https://github.com/carlhuda/janus) I switched over to MacVim.
After fiddling around with Vim for a while I can honestly say I'll need some serious convincing to switch to another editor. I've always stayed away from Vim except through occasional need for text editing through SSH or something, because out of the box it doesn't feel quite right. But after Janus sets up some sane defaults it feels great, and after putting a few hours in to learn all the shortcuts and study plugins I have never felt as productive.
I feel like Janus is sort of training wheels though cause it has a lot of plugins I don't use etc, but it's great to start and as I use Vim more I reckon I will start to manage my own .vimrc.
P.S., bcvi is so awesome.
The good thing about janus is that it also provides a simple framework for customizing your plugins, even if you change all of the original settings.
I've made my own fork (https://github.com/darthdeus/janus) and basically removed 90% of the default plugins and settings and repalced them with my own, but I still use it for the Rake task and nice directory structure.
I've made my own fork (https://github.com/darthdeus/janus) and basically removed 90% of the default plugins and settings and repalced them with my own, but I still use it for the Rake task and nice directory structure.
This could be my story, even though in the end (after Textmate, then Vim), Emacs tempted me more than Sublime Text and I eventually switched back to it from Sublime Text 2.
There is too much accredited awesomeness in Emacs (and to a somewhat lesser extent, Vim), to be overthrown by a newcomer. That said, Sublime Text is very worthy competition and given a few years, it might actually live up to those two dinosaurs.
There is too much accredited awesomeness in Emacs (and to a somewhat lesser extent, Vim), to be overthrown by a newcomer. That said, Sublime Text is very worthy competition and given a few years, it might actually live up to those two dinosaurs.
Fast fuzzy search across your entire project is called grep. Why do we keep rediscovering tools that have existed for such a long time?
Edit: I suppose people keep rediscovering these tools because even if they use vim, they often times insist on running it as a stand-alone GUI application, rather than in a terminal emulatir where the built-in task switching/multitasking makes it very easy to run complex shell commands, move files around, use your VCS and switch back to your editor. Another benefit is that now you can have the exact same work environment over ssh as locally.
Edit: I suppose people keep rediscovering these tools because even if they use vim, they often times insist on running it as a stand-alone GUI application, rather than in a terminal emulatir where the built-in task switching/multitasking makes it very easy to run complex shell commands, move files around, use your VCS and switch back to your editor. Another benefit is that now you can have the exact same work environment over ssh as locally.
First, grep requires specify intermediate characters. For instance, to match SublimeText, you need the regular expression 'S.*B', while in Sublime you could just type 'SB'. (Neither is better, they just serve different purposes.)
Second, grep is not comparable, it's a different tool. For instance, if you would want to open the openCorpus function in the file MainWindow.cpp, in Sublime you'd just type "MWcp@opC", and you are there. While typing the pane and window dynamically update, allowing you to narrow down the 'search space' quickly.
Grep is for searching for text strings in files in the shell or shell scripts. Sublime's Goto Anything is for searching files and symbols in a text editor.
Edit: I like and use both vim and ST2, but neither grep, ctags, nor Peepopen provide the smooth experience of 'Goto Anything'. Of course, conversely vim also has many things to like over ST2 (such as modeful editing that is definitely better than ST2's Vintage).
Second, grep is not comparable, it's a different tool. For instance, if you would want to open the openCorpus function in the file MainWindow.cpp, in Sublime you'd just type "MWcp@opC", and you are there. While typing the pane and window dynamically update, allowing you to narrow down the 'search space' quickly.
Grep is for searching for text strings in files in the shell or shell scripts. Sublime's Goto Anything is for searching files and symbols in a text editor.
Edit: I like and use both vim and ST2, but neither grep, ctags, nor Peepopen provide the smooth experience of 'Goto Anything'. Of course, conversely vim also has many things to like over ST2 (such as modeful editing that is definitely better than ST2's Vintage).
Three key differences: 1) The search occurs as you type, so you don't need to specify more of a query than you need to. 2) ST2 searches delineate between searching file names and searching file contents, (with, e.g. "#") and you can combine both in a single query, if you want, to go to a particular location in a particular file. 3) At the end of the search you can hit "Enter" to go to the found file and edit it, or "Esc" to return to where you were before the search (which is great for just poking into another file to check something).
In fact, thinking about it now, they're quite different. The thing that grep excels at can't even be done easily (that I know of) in ST2: "I'm looking for this function called xyz, but I don't remember which file in this directory it's in."
In fact, thinking about it now, they're quite different. The thing that grep excels at can't even be done easily (that I know of) in ST2: "I'm looking for this function called xyz, but I don't remember which file in this directory it's in."
I think one huge benefit is the "instant"-esque nature of a find as you type fuzzy search in a GUI.
In Bash, you can do incremental (find as you type) history search with Ctrl+R. Something analogous for grep would be fantastic. Displaying more than one result at a time would also be great.
Another thing that grep/find lacks is a index that could make large fuzzy searches faster, but clearly that can be added too.
In Bash, you can do incremental (find as you type) history search with Ctrl+R. Something analogous for grep would be fantastic. Displaying more than one result at a time would also be great.
Another thing that grep/find lacks is a index that could make large fuzzy searches faster, but clearly that can be added too.
Nope, fast fuzzy search is closer to find than grep since it looks for files. But it requires less keystrokes and precision, allow you to be lazier. It's a much more fluid experience.
I still use grep a lot while using ST2, but I use it for other purposes.
I still use grep a lot while using ST2, but I use it for other purposes.
Fast fuzzy search across your entire project is called grep. Why do we keep rediscovering tools that have existed for such a long time?
Yeah. And a car is called a horse carriage. Why do we keep rediscovering tools that have existed for such a long time? (facepalm)
Grep does not:
1) know about the scope of the project, i.e what files to search, without instructed so specifically.
2) have knowledge of code structure (methods, classes, etc). So "fuzzy" here means just using regex.
3) does not know how to present you with the results in a way that you can open quickly in tabs, etc.
Yeah. And a car is called a horse carriage. Why do we keep rediscovering tools that have existed for such a long time? (facepalm)
Grep does not:
1) know about the scope of the project, i.e what files to search, without instructed so specifically.
2) have knowledge of code structure (methods, classes, etc). So "fuzzy" here means just using regex.
3) does not know how to present you with the results in a way that you can open quickly in tabs, etc.
SublimeText is great, but after using it for a few weeks I went back to Komodo Edit. The reason is because I do a lot of PHP work, and Komodo Edit by far has the best PHP autocomplete I've found.
There's a plugin for SublimeText that supposedly imports the same autocomplete engine that Komodo uses. In my experience, however, it was slow, rarely worked right, and was actively broken for CSS autocompletes (which I also need frequently).
So it's back to Komodo Edit for me, at least until SublimeText gets its autocomplete act together. Which is a shame because I really liked ST as an editor.
There's a plugin for SublimeText that supposedly imports the same autocomplete engine that Komodo uses. In my experience, however, it was slow, rarely worked right, and was actively broken for CSS autocompletes (which I also need frequently).
So it's back to Komodo Edit for me, at least until SublimeText gets its autocomplete act together. Which is a shame because I really liked ST as an editor.
If the author could switch that easily to SublimeText, he wasn't properly using Vim.
Care to elaborate on that? I'm fairly entry-level when it comes to vim and I'd be interested to hear some good examples of what it can do over something like sublime.
The level of comfort using vim for a proficient user is very very high, so much so that it becomes difficult to switch out to other editors. I'm quite sure that textmate, sublime and emacs are perfectly good editors, but there's no way I could ever switch full time.
If you're a touch-typist and you become proficient in vim, the friction between thinking about an edit and it materializing on the screen in front of you is reduced. I think 'whoops, need a comma there', my hands move around a little without thinking and the edits done. Contrast this with move hand to mouse, click where you want to edit, hit backspace, type in new character.
IME this is not necessarily faster, just a lot more comfortable once you get used to it.
A lot of comments will say 'you can have vi-mode in <other editor>' but I've yet to see an implementation that covers the entirety of normal mode _and_ supports custom remaps, and even then the mappings would need an interface to its plugins before it approaches a vim-like environment.
If you're a touch-typist and you become proficient in vim, the friction between thinking about an edit and it materializing on the screen in front of you is reduced. I think 'whoops, need a comma there', my hands move around a little without thinking and the edits done. Contrast this with move hand to mouse, click where you want to edit, hit backspace, type in new character.
IME this is not necessarily faster, just a lot more comfortable once you get used to it.
A lot of comments will say 'you can have vi-mode in <other editor>' but I've yet to see an implementation that covers the entirety of normal mode _and_ supports custom remaps, and even then the mappings would need an interface to its plugins before it approaches a vim-like environment.
Why would I constrast it with reaching for a mouse? I've never in my life thought whoops, need a comma there, and reach for the mouse; other editors can be used through the keyboard, this isn't unique to Vim.
Because vim has a lot of commands which are to do with navigation, with standard editing controls you would either press the left arrow a bunch of times while watching the prompt and stop when it's in the correct place. Then you would enter the comma and repeat the process going right.
(I know you can use home/end or ctrl to jump over words, however often these aren't always applicable and often still need visual feedback)
In vim it's significantly easier to jump to the desired point on the line with fewer key strokes and no need for a visual feedback loop.
In short; it's not the fact you can use the keyboard to navigate, rather it's the fact that you can navigate efficiently with the keyboard without having to think about the position of the cursor.
(I know you can use home/end or ctrl to jump over words, however often these aren't always applicable and often still need visual feedback)
In vim it's significantly easier to jump to the desired point on the line with fewer key strokes and no need for a visual feedback loop.
In short; it's not the fact you can use the keyboard to navigate, rather it's the fact that you can navigate efficiently with the keyboard without having to think about the position of the cursor.
> I know you can use home/end or ctrl to jump over words, however often these aren't always applicable and often still need visual feedback
Which makes vim faster, but doesn't mean one needs to reach for a mouse; secondly, what touch typist isn't already watching what he's typing? Requiring visual feedback is hardly slow.
> In vim it's significantly easier to jump to the desired point on the line with fewer key strokes and no need for a visual feedback loop.
I'm aware of that, but that's not the argument you made. You said you didn't have to reach for the mouse, well, neither do any of the other editors.
> In short; it's not the fact you can use the keyboard to navigate, rather it's the fact that you can navigate efficiently with the keyboard without having to think about the position of the cursor.
While true, you overestimate how much other editors make you think about the cursor as well. Our muscle memory works just as well as yours and though vim gives you more options to exploit it, it's not as if other editors don't offer anything other than visual and a mouse.
Which makes vim faster, but doesn't mean one needs to reach for a mouse; secondly, what touch typist isn't already watching what he's typing? Requiring visual feedback is hardly slow.
> In vim it's significantly easier to jump to the desired point on the line with fewer key strokes and no need for a visual feedback loop.
I'm aware of that, but that's not the argument you made. You said you didn't have to reach for the mouse, well, neither do any of the other editors.
> In short; it's not the fact you can use the keyboard to navigate, rather it's the fact that you can navigate efficiently with the keyboard without having to think about the position of the cursor.
While true, you overestimate how much other editors make you think about the cursor as well. Our muscle memory works just as well as yours and though vim gives you more options to exploit it, it's not as if other editors don't offer anything other than visual and a mouse.
> Which makes vim faster, but doesn't mean one needs to reach for a mouse; secondly, what touch typist isn't already watching what he's typing? Requiring visual feedback is hardly slow.
Yes it is. You can go seven or eight keystrokes in vim recording a macro without any feedback whatsoever, and still end up with a wickedly powerful edit.
> I'm aware of that, but that's not the argument you made. You said you didn't have to reach for the mouse, well, neither do any of the other editors.
No I didn't. I simply said contrast that to moving your mouse. You could also contrast it to ctrl+right arrowing to the word on the line but in vim thats just `5w` (where five is the number of words along the line) in normal mode. It still requires less cognitive and physical effort. You could also contrast it to the built-in readline ctrl+ shortcuts and it would still be less keystrokes.
> While true, you overestimate how much other editors make you think about the cursor as well.
No I really don't. I wasn't magically born with vim superpowers. Like everyone else I started with a regular text editor and worked my way to vim proficiency. I became proficient with eclipse, crimson editor and quite a few others before deciding that vim was what I wanted to invest in long term.
> Our muscle memory works just as well as yours and though vim gives you more options to exploit it, it's not as if other editors don't offer anything other than visual and a mouse.
Very well, good luck to you with your other editors. I seriously think you should use whatever you feel most comfortable with.
Yes it is. You can go seven or eight keystrokes in vim recording a macro without any feedback whatsoever, and still end up with a wickedly powerful edit.
> I'm aware of that, but that's not the argument you made. You said you didn't have to reach for the mouse, well, neither do any of the other editors.
No I didn't. I simply said contrast that to moving your mouse. You could also contrast it to ctrl+right arrowing to the word on the line but in vim thats just `5w` (where five is the number of words along the line) in normal mode. It still requires less cognitive and physical effort. You could also contrast it to the built-in readline ctrl+ shortcuts and it would still be less keystrokes.
> While true, you overestimate how much other editors make you think about the cursor as well.
No I really don't. I wasn't magically born with vim superpowers. Like everyone else I started with a regular text editor and worked my way to vim proficiency. I became proficient with eclipse, crimson editor and quite a few others before deciding that vim was what I wanted to invest in long term.
> Our muscle memory works just as well as yours and though vim gives you more options to exploit it, it's not as if other editors don't offer anything other than visual and a mouse.
Very well, good luck to you with your other editors. I seriously think you should use whatever you feel most comfortable with.
Vim isn't only about movement, it gives you some very efficient ways to actually manipulate text.
Take this example line of code:
Take this example line of code:
#define test "Some magical string."
f"ci"
WgUe
lol no
The laziness level that can be achieved with vim's modal editing still surpasses that of most editors. When you're used to vim and you have to use something else, you even become disappointed when you have to reach for the arrow keys. hjkl is far too convenient. Heck, I hardly use backspace anymore even.
Certainly, but then you're spoiled by vim and everything else sucks, or you're trying to find vim-bindings for it. I'd much rather be accustomed to standard bindings that work in most programs and move between them without all the frustration of overly opinionated programs that think their bindings are the best.
Or you can can just appreciate that you get to use one of the best input models only while you're coding, and settle for regular inputs the rest of the time. It's not like you'll forget how to use the arrow keys after learning Vim.
I don't know if I'd call Vim overly-opinionated. It's a legitimately incredible way to work with text.
I don't know if I'd call Vim overly-opinionated. It's a legitimately incredible way to work with text.
OK, I'm the grandparent post and I'll say it. You can have a vi-mode in Emacs and it is called evil-mode.
Vim plugins obviously don't work, but there is a world of Emacs libraries and you can now extend your editor in lisp.
There are still some inconstancies that bother me (e.g. special buffers that don't respect vim shortcuts), but overall I'm happy.
Vim plugins obviously don't work, but there is a world of Emacs libraries and you can now extend your editor in lisp.
There are still some inconstancies that bother me (e.g. special buffers that don't respect vim shortcuts), but overall I'm happy.
I would describe myself as a pretty proficient and comfortable user of Vim and I have switched to Other Editors for short and long periods of time. Really, switching text editors is like switching languages: Every time you learn a new language, you also learn a new way to think and express yourself.
Vim is absolutely awesome, however it is but one way of editing text. Other methods have their own merits and incorporating their styles in your workflow will make you more proficient in the long run even if you eventually come back to Vim.
Vim is absolutely awesome, however it is but one way of editing text. Other methods have their own merits and incorporating their styles in your workflow will make you more proficient in the long run even if you eventually come back to Vim.
I'm fairly proficient with both Vim and Emacs and I can feel it when I'm not using either editor. For example, I'm using a browser on Windows and I want to jump to a line's end. In Emacs (or on OS X which uses Emacs shortcuts), that's Ctrl-E and in Vim that's $. On Windows, I fumble with the arrow keys or start reaching for the mouse.
When you really know a fundamental text editor, that sensation of helplessness gets worse and worse when you can't use the shortcuts that are burned into your fingers.
If you don't know what I'm talking about, I suggest reading the StackOverflow answer "Your problem with Vim is that you don't grok vi."
http://stackoverflow.com/a/1220118
When you really know a fundamental text editor, that sensation of helplessness gets worse and worse when you can't use the shortcuts that are burned into your fingers.
If you don't know what I'm talking about, I suggest reading the StackOverflow answer "Your problem with Vim is that you don't grok vi."
http://stackoverflow.com/a/1220118
Good God, this.
I spend 95% of each day (not just my 8-5 - 95% of my time on a computer at all) in vim. The rest is in firefox or in a console briefly to tell it to run my tests. I code all day every day, and I quite enjoy it.
Today, I had a 7 hour meeting with a customer to spec out a new project. I had to put together mockups in balsamiq. On a mac (I'm a linux user). My level of discomfort was extremely high, eclipsed only by the fact that since a customer was there I couldn't take to just cursing like a sailor.
When you keep your hands on the home row for an entire day and then all of the sudden you have multitouch swipe gestures and clickie-scrollie touchpads and home keys that don't go home and delete keys that delete the wrong direction and inadequate terminal emulators, HOLY CRAP IS IT LIKE MINI-DYING.
That's all. I just completely feel you.
I spend 95% of each day (not just my 8-5 - 95% of my time on a computer at all) in vim. The rest is in firefox or in a console briefly to tell it to run my tests. I code all day every day, and I quite enjoy it.
Today, I had a 7 hour meeting with a customer to spec out a new project. I had to put together mockups in balsamiq. On a mac (I'm a linux user). My level of discomfort was extremely high, eclipsed only by the fact that since a customer was there I couldn't take to just cursing like a sailor.
When you keep your hands on the home row for an entire day and then all of the sudden you have multitouch swipe gestures and clickie-scrollie touchpads and home keys that don't go home and delete keys that delete the wrong direction and inadequate terminal emulators, HOLY CRAP IS IT LIKE MINI-DYING.
That's all. I just completely feel you.
You may like Pentadactyl.
Am I the only one that uses 'Home' and 'End' on a frequent basis? On standard keyboards, they're right by the arrow keys anyway.
On my laptop, it's just fn+arrow for home, end, and page up/down, and my pinky is usually right there anyway for the control and meta keys.
On my laptop, it's just fn+arrow for home, end, and page up/down, and my pinky is usually right there anyway for the control and meta keys.
The very first thing vim users learn is to avoid the arrow keys. I hate moving my fingers off the home room to navigate. Using hjkl for navigation removes that pesky break between inserting text and navigating.
I think Opera comes with a VIM compatible keyboard setup.
That just means that you don't know the hotkeys, does it? It does not suggest that Emacs or Vim is objectively better.
The conventional end-of-line hotkey for Windows applications is the End key, which on a fairly traditional keyboard like the one I am typing this on requires that my right hand move several inches to the right and find that key on the island; I can't touch type this effectively and it compares poorly to C-e or even $ (itself not especially a convenient operation). Gnome and the Mac don't have this problem because both of them largely retain the simpler Emacs style keystrokes; Firefox does have this problem (at least here) and it pisses me off every time.
No, I think he meant not internalising the proper use of vi's composed count-movement-edit commands and ex commands.
[deleted]
I can't recommend Sublime Text 2 enough to do it justice. Such a fantastic editor.
I would like to try any of these if I am not so addicted to org-mode. I can't live without emacs despite that I hate its slowness very much.
I used to be really addicted to hardcore code completition and refactorings for Java in IntelliJ, it just felt like there is no other way. I had the same feeling when I was considering Sublime while using VIM, I thought there's no other way to edit text than the way VIM does it. And both time it paid off that I gave another editor a try :)
Learning a new tool is learning a new way to think. It always pays off.
I can't vouch for it, but Sublime does have a port of org-mode: https://bitbucket.org/rchl/sublime_orgmode/overview
Might be worth a try.
Might be worth a try.
I tried it. It is good. It supports lists, with checkboxes, and completion ([1/3]). It supports some links.
It does not support tables. You can not reorder entries. It does not support code blocks. You can fold, but you can not narrow (i.e. all headlines stay there, but content is folded away). Your favorite keyboard shortcuts are not there (though you can change that easily).
As much as I like Sublime Text, I am more productive in Emacs.
It does not support tables. You can not reorder entries. It does not support code blocks. You can fold, but you can not narrow (i.e. all headlines stay there, but content is folded away). Your favorite keyboard shortcuts are not there (though you can change that easily).
As much as I like Sublime Text, I am more productive in Emacs.
Also tried it. The editor itself is great and very fast, unfortunately the org-mode clone is much less than the original.
Try Emacs with evil mode for Vim emulation. It doesn't get better than this. It is almost like having a lisp-based Vim.
He talks about the Destroy All Software Screencasts. Are they worth it?
If you're into TDD and Ruby, then they're probably the best ones you can find. But if you don't like testing, then I would suggest saying away :) There's a free one that you can check out here https://www.destroyallsoftware.com/screencasts on the bottom of the page ... and see if you like it.
Has anyone else experienced the slowness the author described with Vim? I think it's possible he may be experiencing slow terminal update time (the OS X terminal is really slow in the scenario he described) instead of Vim being the culprit. MacVim, for example, doesn't have this problem, in my experience.
Did he edit the article? I don't see anything about vim being slow.
Also worth noting that ST2 has a vim emulation mode, called "vintage" mode. IIRC it's just a native ST2 plugin in python.
As a long-time vim user, I found it to be obviously incompatible within moments.
As another long-time vim user, it's more of a vi-compatible mode, and isn't anywhere near perfect, but it's good enough that I get modal editing with the majority of movements and commands that I use in day-to-day editing. Most of the "missing" vi/vim features just don't have appropriate command-mode bindings, so it's simply a matter of getting used to the default ST2 bindings for those, or doing some leg work to make those vintage bindings that you really care about.
I've only been using ST2 for a few weeks on a Python project, but I feel that the end result is better for me than trying to patch together a chain of vim plugins. I gladly give up a few of the more esoteric vim features for the integrated project editing features of ST2.
I've only been using ST2 for a few weeks on a Python project, but I feel that the end result is better for me than trying to patch together a chain of vim plugins. I gladly give up a few of the more esoteric vim features for the integrated project editing features of ST2.
> I gladly give up a few of the more esoteric vim features for the integrated project editing features of ST2.
Right, I just wanted to point out that it's not a very vim-compatible vim mode so people aren't surprised if they try it out.
Right, I just wanted to point out that it's not a very vim-compatible vim mode so people aren't surprised if they try it out.
[deleted]
I must say I am really impressed by the speed and performance of SublimeText 2. If they can get the vintage mode (vim mode) right, I might really consider switching. At the moment it's nowhere near perfect.
All this is fine, but I definitely need a debugger with a gui
PeepOpen supports Vim as well.
This is actually my first post ever on HN. It is in fact not very often that I post anywhere on the interwebs. But I have to speak up.
Can. We. Stop. Posting. About. Fng. Text. Editors.
Please.
Imagine a room where you teleport in computer greats (in no order of importance, and I am probably forgetting tons of worthy people in my pang of internet angst) such as Gates, Torvalds, Ritchie, Thompson, von Neumann, Knuth, Turing, Carmack, ..., Joy, Berners-Lee, Babbage, Stroustrup, Dijkstra, Norvig, Moore, Noyce. I don't think these guys would start talking about text editing, so why should we?
Can. We. Stop. Posting. About. Fng. Text. Editors.
Please.
Imagine a room where you teleport in computer greats (in no order of importance, and I am probably forgetting tons of worthy people in my pang of internet angst) such as Gates, Torvalds, Ritchie, Thompson, von Neumann, Knuth, Turing, Carmack, ..., Joy, Berners-Lee, Babbage, Stroustrup, Dijkstra, Norvig, Moore, Noyce. I don't think these guys would start talking about text editing, so why should we?
Oh yes, I can't imagine a room full of professionals talking about the tools they use to get their job done.
People talk about what's important to them. For some it might be proving that SVN is stupid (Torvalds?) and for others it might be proving that one editor is superior to others (SublimeText 2 obviously </sarcasm>).
"why should we?"
Because we want to, that's why.
If you don't want to, feel free to ignore it.
Because we want to, that's why.
If you don't want to, feel free to ignore it.
[deleted]
This seems kind of grouchy I know, but I am getting a bit tired of these wildly overblown titles attached to very thin blog posts. I knew what I'd see when I clicked the link and was just as disappointed as I'd expected to be. I guess I have a masochistic streak.
The actual stories of those three editors, their authors and how those stories intertwine would probably be pretty interesting. I guess I'll have to wait for This American Life to tackle it.