20 ms·

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

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.

tylermenezes 14y ago
It's certainly possible to write code without a good editor, but a good editor simplifies a lot of tasks which get in the way of writing good code.
- falcolas 14y ago
  That makes the erroneous assumption that vim, without heavy customization, is not a good editor. Vim is capable, out of the box, of everything a more heavyweight editor can do. The only thing really missing is library aware code completion.
mdonahoe 14y ago
Now I'm curious. What 15 lines do you use?
- lordlarm 14y ago
  Something like this: https://gist.github.com/2996793 https://gist.github.com/2996793 (16 lines, but you get the point).
  - drbawb 14y ago
    Can I ask why you disable the swap file? 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.
    - bsg75 14y ago
      Possibly to speed up opening large files. There is a plugin that does this for files above a configured size.
    - riffic 14y ago
      it can be a security risk, for example, .php config files on a web server.
    - cellularmitosis 14y ago
      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.
      - jlogsdon 14y ago
        You can change where the swap files are saved too with `set directory=path`
  - akincisor 14y ago
    I prefer to use set directory=~/tmp instead of turning off swap files. All the fun for none of the junk.
richbradshaw 14y ago
You'd think that :) It's not about writing code though in my case, but marking things up as HTML. Multiple cursors help a lot here.
- dsrguru 14y ago
  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.
  - richbradshaw 14y ago
    I guess it's what you are used to – I've never really got into Vim, whereas Sublime looks like a normal text editor until you need more from it.
    - weaksauce 14y ago
      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.
leif 14y ago
Not everyone has the privilege of working on interesting things. Consider yourself lucky.
lloeki 14y ago
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)
guns 14y ago
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.
- cabalamat 14y ago
  > 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.
  - michael_fine 14y ago
    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.
- bergie 14y ago
  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.
exim 14y ago
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. These are just _very_ basic things.
- rapind 14y ago
  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.
  - jules 14y ago
    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 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).
    - rapind 14y ago
      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.
no_more_death 14y ago
Same here. Editors are vastly more complex than necessary. I want an editor like google.com. It's simple "sentence" model totally wins. Of course, creation instead of consumption requires additional abstractions. Three dimensions build an entire universe. An editor built with three choice abstractions could outstrip every other editor conceived. Ever. Somebody do it.
- fusiongyro 14y ago
  Acme is close: 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.
  - luriel 14y ago
    When I read the grand parent post, I immediately thought of acme. And of sam and how some of the best programmers I know use sam[1] a language that provides even less configurability than acme. [1]: http://sam.cat-v.org http://sam.cat-v.org
    - fusiongyro 14y ago
      As I'm sure you already know, there's a fellow who did some impressive things with acme a few years back: http://ipn.caerwyn.com/search/label/acme http://ipn.caerwyn.com/search/label/acme If I understand correctly, these hinge on 9p; instead of Acme worrying about keypresses, it's some 9p client worrying about characters read. A clever solution, and self-evidently powerful, but with the obvious drawback that most of us aren't running Plan 9 or Inferno. And we still have the problem of syntax highlighting.
naner 14y ago
Obviously not. I stumbled across this same sentiment the other day: http://utcc.utoronto.ca/~cks/space/blog/programming/FancyProgrammingEditors http://utcc.utoronto.ca/~cks/space/blog/programming/FancyPro...
fragmede 14y ago
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).
- daviddaviddavid 14y ago
  My .vimrc has the following two lines which expand tabs to spaces by default but make an exception for makefiles: set expandtab au FileType make setlocal noexpandtab
- slowpoke 14y ago
  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.
ubercore 14y ago
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.
- tsm 14y ago
  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.
  - mattacular 14y ago
    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?
    - kamaal 14y ago
      I think his point is right. Market a tool for what it is good at doing. If I want to use vim, I can use vim. Heck there are many things these days that will give you the same GUI candy what GUI based text editors give. Glossy text editors come and go every 2-3 years, Editors like Emacs and vim stay.
      - swah 14y ago
        On the other hand, what are the odds we're still using them in 100 years? Almost none. The next question then must be: when do we start writing the next generation of tools? Now, or should we wait?
        kamaal 14y ago
        >>On the other hand, what are the odds we're still using them in 100 years? Firstly you are not going to live for the coming 100 years. So lets not worry about impossible scenarios. Secondly next generation tools for the next hundred years need to be designed such.
deleted 14y ago
[deleted]
irahul 14y ago
> 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: inoremap \1 <%<Space><Space>%><Esc>2hi inoremap \2 <%=<Space><Space>%><Esc>2hi inoremap \3 {%<Space><Space>%}<Esc>2hi inoremap \4 {{<Space><Space>}}<Esc>2hi No one is contesting you can't type '{{ some_crap }}' repeatedly, but I don't see how doing that is beneficial in any way. Adding simple customization to vimrc is simple. Plugins are even simpler. Committing the shortcuts to muscle memory is not as simple. But if you really need the customization/plugin, that means you will be using it and it will become muscle memory very quickly. Thinking is the major hurdle when it comes to writing good code, but it isn't the only one. The other factors are important.
deedorgreed 14y ago
Um - I have to "think" about what archaic command I have to use with vim.
- jamesgeck0 14y ago
  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.
jabr 14y ago
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. For now, I'll let conciseness win.
mdesantis 14y ago
No, thanks

tylermenezes 14y ago

It's certainly possible to write code without a good editor, but a good editor simplifies a lot of tasks which get in the way of writing good code.

falcolas 14y ago
That makes the erroneous assumption that vim, without heavy customization, is not a good editor. Vim is capable, out of the box, of everything a more heavyweight editor can do. The only thing really missing is library aware code completion.

mdonahoe 14y ago

Now I'm curious. What 15 lines do you use?

lordlarm 14y ago
Something like this: https://gist.github.com/2996793 https://gist.github.com/2996793 (16 lines, but you get the point).
- drbawb 14y ago
  Can I ask why you disable the swap file? 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.
  - bsg75 14y ago
    Possibly to speed up opening large files. There is a plugin that does this for files above a configured size.
  - riffic 14y ago
    it can be a security risk, for example, .php config files on a web server.
  - cellularmitosis 14y ago
    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.
    - jlogsdon 14y ago
      You can change where the swap files are saved too with `set directory=path`
- akincisor 14y ago
  I prefer to use set directory=~/tmp instead of turning off swap files. All the fun for none of the junk.

richbradshaw 14y ago

You'd think that :) It's not about writing code though in my case, but marking things up as HTML. Multiple cursors help a lot here.

dsrguru 14y ago
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.
- richbradshaw 14y ago
  I guess it's what you are used to – I've never really got into Vim, whereas Sublime looks like a normal text editor until you need more from it.
  - weaksauce 14y ago
    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.

leif 14y ago

Not everyone has the privilege of working on interesting things. Consider yourself lucky.

lloeki 14y ago

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)

guns 14y ago

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.

cabalamat 14y ago
> 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.
- michael_fine 14y ago
  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.
bergie 14y ago
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.

exim 14y ago

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. These are just _very_ basic things.

rapind 14y ago
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.
- jules 14y ago
  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 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).
  - rapind 14y ago
    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.

no_more_death 14y ago

Same here. Editors are vastly more complex than necessary. I want an editor like google.com. It's simple "sentence" model totally wins. Of course, creation instead of consumption requires additional abstractions. Three dimensions build an entire universe. An editor built with three choice abstractions could outstrip every other editor conceived. Ever. Somebody do it.

fusiongyro 14y ago
Acme is close: 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.
- luriel 14y ago
  When I read the grand parent post, I immediately thought of acme. And of sam and how some of the best programmers I know use sam[1] a language that provides even less configurability than acme. [1]: http://sam.cat-v.org http://sam.cat-v.org
  - fusiongyro 14y ago
    As I'm sure you already know, there's a fellow who did some impressive things with acme a few years back: http://ipn.caerwyn.com/search/label/acme http://ipn.caerwyn.com/search/label/acme If I understand correctly, these hinge on 9p; instead of Acme worrying about keypresses, it's some 9p client worrying about characters read. A clever solution, and self-evidently powerful, but with the obvious drawback that most of us aren't running Plan 9 or Inferno. And we still have the problem of syntax highlighting.

naner 14y ago

Obviously not. I stumbled across this same sentiment the other day: http://utcc.utoronto.ca/~cks/space/blog/programming/FancyProgrammingEditors http://utcc.utoronto.ca/~cks/space/blog/programming/FancyPro...

fragmede 14y ago

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

daviddaviddavid 14y ago
My .vimrc has the following two lines which expand tabs to spaces by default but make an exception for makefiles: set expandtab au FileType make setlocal noexpandtab
slowpoke 14y ago
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.

ubercore 14y ago

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.

tsm 14y ago
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.
- mattacular 14y ago
  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?
  - kamaal 14y ago
    I think his point is right. Market a tool for what it is good at doing. If I want to use vim, I can use vim. Heck there are many things these days that will give you the same GUI candy what GUI based text editors give. Glossy text editors come and go every 2-3 years, Editors like Emacs and vim stay.
    - swah 14y ago
      On the other hand, what are the odds we're still using them in 100 years? Almost none. The next question then must be: when do we start writing the next generation of tools? Now, or should we wait?
      - kamaal 14y ago
        >>On the other hand, what are the odds we're still using them in 100 years? Firstly you are not going to live for the coming 100 years. So lets not worry about impossible scenarios. Secondly next generation tools for the next hundred years need to be designed such.

deleted 14y ago

[deleted]

irahul 14y ago

> 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: inoremap \1 <%<Space><Space>%><Esc>2hi inoremap \2 <%=<Space><Space>%><Esc>2hi inoremap \3 {%<Space><Space>%}<Esc>2hi inoremap \4 {{<Space><Space>}}<Esc>2hi No one is contesting you can't type '{{ some_crap }}' repeatedly, but I don't see how doing that is beneficial in any way. Adding simple customization to vimrc is simple. Plugins are even simpler. Committing the shortcuts to muscle memory is not as simple. But if you really need the customization/plugin, that means you will be using it and it will become muscle memory very quickly. Thinking is the major hurdle when it comes to writing good code, but it isn't the only one. The other factors are important.

deedorgreed 14y ago

Um - I have to "think" about what archaic command I have to use with vim.

jamesgeck0 14y ago
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.

jabr 14y ago

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. For now, I'll let conciseness win.

mdesantis 14y ago

No, thanks