Slashdot Mirror

Vimacs, I merged them to piss off both sides.

Shit, the Interwebs beat me at my game: https://www.vim.org/scripts/sc...

You DO realize this isn't a binary choice, right?

* Indent with tabs; align with spaces * Elastic Tabstops * Smart Tabs

= Smart Tabs =

Emacs: * https://github.com/jcsalomon/s...

Vim: * https://www.vim.org/scripts/sc... * http://vim.wikia.com/wiki/Inde...

So, you're telling me that, insead of simply using spaces and getting it all correct, I should use tabs, and where tabs break down *then* use spaces?

You DO realize this isn't a binary choice, right?

* Indent with tabs; align with spaces
* Elastic Tabstops
* Smart Tabs

= Smart Tabs =

Emacs:
* https://github.com/jcsalomon/s...

Vim:
* https://www.vim.org/scripts/sc...
* http://vim.wikia.com/wiki/Inde...

Off-topic (sort of):

Let me know if you ever try FreeBSD ports and do "make fetch" in /usr/ports/editors/vim-lite (or editors/vim). If you think apt-get takes ages, or Windows Update takes ages, enjoy what the aforementioned does -- fetch(1) on FreeBSD does not support parallelism.

Bram Mooleenar needs to stop fucking around with drills and start releasing minor releases (or even patch roll-ups) than he currently does. The saddest part is that he he even admitted the excessive patch problem in 7.3 -- I'll quote it here since it's the last news item and he's likely to delete it:

[2013-05-17] 7.3 has more than 950 patches, that's too many! Time for a new (minor) release. The plan is to (1) improve Python support, (2) include a faster regexp engine and (3) include pending patches and fix bugs. A test version should be available end of May. The release happens when it appears to work well. (Bram Moolenaar)

For 7.3, we hit 1314 patches. For 7.2, it was 446 patches.

But back to his news post: note the date, over 2 years ago. So he still hasn't learned. We're currently at 963 patches and counting for 7.4. Despite being open-source, I'm really baffled at the amount of laziness involved in making a release. Seriously -- it cannot take him more than 5 or 10 minutes of effort to roll out an official release. Aggregate, it's less effort than maintaining all these damn patches.

Off-topic (sort of):

Let me know if you ever try FreeBSD ports and do "make fetch" in /usr/ports/editors/vim-lite (or editors/vim). If you think apt-get takes ages, or Windows Update takes ages, enjoy what the aforementioned does -- fetch(1) on FreeBSD does not support parallelism.

Bram Mooleenar needs to stop fucking around with drills and start releasing minor releases (or even patch roll-ups) than he currently does. The saddest part is that he he even admitted the excessive patch problem in 7.3 -- I'll quote it here since it's the last news item and he's likely to delete it:

[2013-05-17] 7.3 has more than 950 patches, that's too many! Time for a new (minor) release. The plan is to (1) improve Python support, (2) include a faster regexp engine and (3) include pending patches and fix bugs. A test version should be available end of May. The release happens when it appears to work well. (Bram Moolenaar)

For 7.3, we hit 1314 patches. For 7.2, it was 446 patches.

But back to his news post: note the date, over 2 years ago. So he still hasn't learned. We're currently at 963 patches and counting for 7.4. Despite being open-source, I'm really baffled at the amount of laziness involved in making a release. Seriously -- it cannot take him more than 5 or 10 minutes of effort to roll out an official release. Aggregate, it's less effort than maintaining all these damn patches.

Off-topic (sort of):

Let me know if you ever try FreeBSD ports and do "make fetch" in /usr/ports/editors/vim-lite (or editors/vim). If you think apt-get takes ages, or Windows Update takes ages, enjoy what the aforementioned does -- fetch(1) on FreeBSD does not support parallelism.

Bram Mooleenar needs to stop fucking around with drills and start releasing minor releases (or even patch roll-ups) than he currently does. The saddest part is that he he even admitted the excessive patch problem in 7.3 -- I'll quote it here since it's the last news item and he's likely to delete it:

[2013-05-17] 7.3 has more than 950 patches, that's too many! Time for a new (minor) release. The plan is to (1) improve Python support, (2) include a faster regexp engine and (3) include pending patches and fix bugs. A test version should be available end of May. The release happens when it appears to work well. (Bram Moolenaar)

For 7.3, we hit 1314 patches. For 7.2, it was 446 patches.

But back to his news post: note the date, over 2 years ago. So he still hasn't learned. We're currently at 963 patches and counting for 7.4. Despite being open-source, I'm really baffled at the amount of laziness involved in making a release. Seriously -- it cannot take him more than 5 or 10 minutes of effort to roll out an official release. Aggregate, it's less effort than maintaining all these damn patches.

Off-topic (sort of):

Let me know if you ever try FreeBSD ports and do "make fetch" in /usr/ports/editors/vim-lite (or editors/vim). If you think apt-get takes ages, or Windows Update takes ages, enjoy what the aforementioned does -- fetch(1) on FreeBSD does not support parallelism.

Bram Mooleenar needs to stop fucking around with drills and start releasing minor releases (or even patch roll-ups) than he currently does. The saddest part is that he he even admitted the excessive patch problem in 7.3 -- I'll quote it here since it's the last news item and he's likely to delete it:

[2013-05-17] 7.3 has more than 950 patches, that's too many! Time for a new (minor) release. The plan is to (1) improve Python support, (2) include a faster regexp engine and (3) include pending patches and fix bugs. A test version should be available end of May. The release happens when it appears to work well. (Bram Moolenaar)

For 7.3, we hit 1314 patches. For 7.2, it was 446 patches.

But back to his news post: note the date, over 2 years ago. So he still hasn't learned. We're currently at 963 patches and counting for 7.4. Despite being open-source, I'm really baffled at the amount of laziness involved in making a release. Seriously -- it cannot take him more than 5 or 10 minutes of effort to roll out an official release. Aggregate, it's less effort than maintaining all these damn patches.

> Now only if it had a decent text editor for ...

You could always use Vim ...

/me ducks ;-)

Or if you are really evil ... Vim mode for Emacs

If you really want to go straight to hell ... Emacs mode for Vim

Pick you religion / devil :-)

Are you mentally retarded? Honestly, I'm curious.

> Now only if it had a decent text editor for ...

You could always use Vim ...

/me ducks ;-)

Or if you are really evil ... Vim mode for Emacs

If you really want to go straight to hell ... Emacs mode for Vim

Pick you religion / devil :-)

Notepad++ is pretty nice, but it does not hold a candle to several of the Linux based text editors.
For instance:
kate http://kate-editor.org/
gedit https://wiki.gnome.org/Apps/Ge...
vim http://www.vim.org/
emacs https://www.gnu.org/software/e...

Like I said, Notepad++ is a good editor, and I use it myself when forced to use Windows, but it does not compare to what is offered in Linux. Also, most things in Linux are well documented. Sadly there are some things that are not, but practically nothing I have ever needed documentation for in Windows has had decent documentation.

As a physician who was dragged screaming and kicking into having to use EPIC, I have to agree.

I never knew I could hate a company more than Microsoft. Their client is a bloated horror that nevertheless acts like the thinnest client in the world: "Oh, look, the doctor pressed the Shift key ... I guess I'll send that over the network, and wait for a response ... oh look, s/he released the Shift key now -- I guess I'll send that over the network, too..." Apparently it's based on the Internet Explorer library, so there is no Mac version (at least not when I was using it)...

The interface was so bad that I learned how to program in AutoHotkey and probably spent in excess of 200 hours over a year to automate things. AutoHotkey was a lifesaver: open source and powerful. (In fact, the pitiful xdotool we have for Linux doesn't even come close to AutoHotkey for windows, and even if I weren't forced to use Windows for my work, I might have ended up choosing it over Linux just because of AutoHotkey and its ecosystem of experienced developers.)

At the time I was with a large clinic chain that had about 40% of the market in our large sprawling metropolitan supercluster location. They surveyed the doctors, who said that on average they were spending an extra hour per day using Epic. And in the end, it was a lot of *data*-generation and not a lot of *information*. Our specialists complained that everything was being crammed into a template form, and they really couldn't tell what we were thinking, just checklists of what the patient did/did not have.

Having vendor lock-in, they have no incentive to improve. They can do whatever they want... if the clinic/hospital is already stuck using Epic, why would they spend money on fixing their problems instead of recruiting more clients?

Having said all that, even Epic is better than what I'm stuck using right now ... eClinicalWorks. That's even worse than Epic. All the problems of Epic, plus even worse interface. Right now I type my notes in a plain text editor and then use AutoHotkey to cut-n-paste it into eClinicalWorks. What a nightmare.

OpenEMR all the way!

Roc --

There is always this installer: ftp://ftp.vim.org/pub/vim/pc/gvim74.exe on this site: http://www.vim.org/download.php

-- kjh

Roc --

There is always this installer: ftp://ftp.vim.org/pub/vim/pc/gvim74.exe on this site: http://www.vim.org/download.php

-- kjh

I started using gvim on windows and I never looked back. Give it a try:
http://www.vim.org/download.php#pc

Rsync your CherryTree file, or sync with whatever cloud storage solution you use, Google Drive, Microsoft NSAAS, whatever.

It's a bit limited for complex things, but it worked for some students I know tracking the majority of their note-keeping needs. Stopped using 3rd party solutions since I eat my own dogfood, and now have notes integrated into my distributed versioned whiteboard / issue tracker / build & deploy & test product. I have issue/note/image annotation plugins for coding with Netbeans, Eclipse, Visual Studio, Emacs and Vim -- Which reminds me of a Vim plugin I just saw that you might find useful... if you can run a (home) server (and port forward around NAT), then install Wordpress on a LAMP stack (in a VM, because PHP exploits) -- I'm pretty sure Emacs has all that built in by default now: C-x M-c M-microblog.

I jest, it's just Org mode. Save your .org to your Git repo, and away you go.

Visual Studio Express is Microsoft's zero-cash programming environment. Why do you want a high-cost office suite with a lousy macro engine to be discounted to free when they already offer their actual development suite pro bono. It's upgradeable to more complete Visual Studio versions later. This will encourage Microsoft-centric code, but that can be avoided and it's less specific of a tie-in than VBA. C#, C, C++, and more are included.

If you don't want to be tied to Microsoft-specific tools even on Windows there are other options. Those include other office suites and other actual development tools.

LibreOffice/OpenOffice have OOBasic and can be scripted with Python and Java if you really want. These things are zero-cash and open source.

You can use Lazarus and FreePascal (Wikipedia article about FreePascal) or Eclipse and Java/C/C++ if you'd rather. Or you could use Eric and Python. Or Padre and Strawberry Perl, complete with MinGW. Some of the IDEs are more or less general and language agnostic, while others are mainly narrowly targeted.

Don't forget MsysGit (git for Windows) if you're not using Cygwin and haven't already chosen a version control system.

Really, you could be teaching with a good programmer's editor rather than specifically with IDEs too. vim, Emacs, jEdit, Gedit, and others are applicable. Some of them are powerful enough to make that line between editors and IDEs very fuzzy.

What, exactly, would a free copy of Word get you that isn't already available?

There are two elephants in the room when it comes to vim that really need to be addressed:

1. Its pattern or "regular expression" support. I'm talking about things like :%s/// for matching/replacing but it can be used in other places. I'll refer folks to the docs, which they should read (or if you just want to skim, go to the vim wiki link):

http://vimdoc.sourceforge.net/htmldoc/pattern.html
http://vimdoc.sourceforge.net/htmldoc/usr_27.html
http://vim.wikia.com/wiki/Search_patterns

Take a very, very close look at how parenthesis work under the section called Magic. It's completely inverted compared to every other expression/RE, even base system regex.

Any vim user who has been using this functionality knows how painful it is; it can literally take you 20 full minutes to come up with a vim :%s line that does what you need, and most of the time the user ends up just shelling out to the CLI and using sed or perl or whatever else to do the replacement because of vim's awful pattern syntax.

"21st century" (I hate this term) vim should just use PCRE and be done with it. I'm a KISS principle minimalist and don't like the idea of tying vim to another 3rd-party library, but I think this would be acceptable given PCRE's prevalence.

2. Bram's absolutely horrible laziness when it comes to making actual releases. For those who don't follow vim regularly, you probably don't know of this problem, but its existed for years. Basically someone submits a patch to Bram, he approves it, and the patch gets made and dumped as a single patch/diff file in the patches directory:

ftp://ftp.vim.org/pub/vim/patches/

Take 2-3 minutes of your time and go to that directory and look around. For starters, look at the 7.3 directory and how many patches there were between 7.3 and 7.4. The answer? 1314 patches. Yes, over THIRTEEN HUNDRED patches before 7.4 was made. Now look at the 7.4 directory (7.4 is the current release of vim); there are already 211 patches.

The problem is that Bram lets things sit in this condition for ages -- often YEARS -- before making a release. He needs to make releases more often. And in case you think I'm whining, I'm not: even Bram himself has admitted that "there's too many patches between releases":

http://www.vim.org/news/news.php

Quote:

Work on Vim 7.4 has started

[2013-05-17] 7.3 has more than 950 patches, that's too many!

There's hilarity in the fact that he admitted this in May 2013, but didn't do anything about it for another 3 months (vim 7.4 came out August 2013), during which time nearly 400 patches were submit/accepted.

Yet this problem continues on and on (cue Journey's Don't Stop Believing). The only person to blame for it is Bram. He should make an effort to actually roll a new release when he reaches an arbitrary number of patches -- say, 100 or 150. 1300+ is literally insane, because by the time someone upgrades from 7.3 to 7.4, and finds something broken, there are _1300+ patches_ to go through to figure out the regression. It's not manageable, and I'm sure he knows it. So he should step up to the plate and stop playing with drills.

There are two elephants in the room when it comes to vim that really need to be addressed:

1. Its pattern or "regular expression" support. I'm talking about things like :%s/// for matching/replacing but it can be used in other places. I'll refer folks to the docs, which they should read (or if you just want to skim, go to the vim wiki link):

http://vimdoc.sourceforge.net/htmldoc/pattern.html
http://vimdoc.sourceforge.net/htmldoc/usr_27.html
http://vim.wikia.com/wiki/Search_patterns

Take a very, very close look at how parenthesis work under the section called Magic. It's completely inverted compared to every other expression/RE, even base system regex.

Any vim user who has been using this functionality knows how painful it is; it can literally take you 20 full minutes to come up with a vim :%s line that does what you need, and most of the time the user ends up just shelling out to the CLI and using sed or perl or whatever else to do the replacement because of vim's awful pattern syntax.

"21st century" (I hate this term) vim should just use PCRE and be done with it. I'm a KISS principle minimalist and don't like the idea of tying vim to another 3rd-party library, but I think this would be acceptable given PCRE's prevalence.

2. Bram's absolutely horrible laziness when it comes to making actual releases. For those who don't follow vim regularly, you probably don't know of this problem, but its existed for years. Basically someone submits a patch to Bram, he approves it, and the patch gets made and dumped as a single patch/diff file in the patches directory:

ftp://ftp.vim.org/pub/vim/patches/

Take 2-3 minutes of your time and go to that directory and look around. For starters, look at the 7.3 directory and how many patches there were between 7.3 and 7.4. The answer? 1314 patches. Yes, over THIRTEEN HUNDRED patches before 7.4 was made. Now look at the 7.4 directory (7.4 is the current release of vim); there are already 211 patches.

The problem is that Bram lets things sit in this condition for ages -- often YEARS -- before making a release. He needs to make releases more often. And in case you think I'm whining, I'm not: even Bram himself has admitted that "there's too many patches between releases":

http://www.vim.org/news/news.php

Quote:

Work on Vim 7.4 has started

[2013-05-17] 7.3 has more than 950 patches, that's too many!

There's hilarity in the fact that he admitted this in May 2013, but didn't do anything about it for another 3 months (vim 7.4 came out August 2013), during which time nearly 400 patches were submit/accepted.

Yet this problem continues on and on (cue Journey's Don't Stop Believing). The only person to blame for it is Bram. He should make an effort to actually roll a new release when he reaches an arbitrary number of patches -- say, 100 or 150. 1300+ is literally insane, because by the time someone upgrades from 7.3 to 7.4, and finds something broken, there are _1300+ patches_ to go through to figure out the regression. It's not manageable, and I'm sure he knows it. So he should step up to the plate and stop playing with drills.

I like the emacs org mode (also available for vim, and even your mobile), though primarily for structured outlines/note-taking, its markup allows document formatting and it can export to a range of formats including PDF.

Notes, documents, TODOs, all in one format.

Accepting donations here?

I remember reading somewhere that Bram Moolenaar is willing to sell you a special licence for his program if you insist that you want to buy it.
Vim is absolutely magnificent Free Software project - a very powerfull reincarnation of the vi editor. And the left-over money will be used for kids in Uganda.

See this page: http://www.vim.org/sponsor/index.php
Registered Vim user You can become a registered Vim user by sending at least 10 euro. This works similar to sponsoring Vim (see above). Registration was made possible for the situation where your boss or bookkeeper may be willing to register software, but does not like the terms "sponsoring" and "donation".

I'll chip in for Vim and vimoutliner+VOoM. Much better in my opinion than Emacs and its twisted C-chords.

voom: http://www.vim.org/scripts/script.php?script_id=2657
vimoutliner: http://www.vim.org/scripts/script.php?script_id=3515

I'll chip in for Vim and vimoutliner+VOoM. Much better in my opinion than Emacs and its twisted C-chords.

voom: http://www.vim.org/scripts/script.php?script_id=2657
vimoutliner: http://www.vim.org/scripts/script.php?script_id=3515

At worst - create a hex editor and enter the binary from hand-assembled code. But then it must be desperate times.

VIM rules b.t.w. :p

Oh really? :)

VIM has it's own scripting language. If UI can be represented as a text, it can be coded in VIM.

nano implements some features that Pico lacks, including colored text, regular expression search and replace, smooth scrolling, multiple buffers, rebindable key support, and (experimental) undoing and redoing of edit changes.

I poked around nano's website and it seems pretty capable.
It sounds like nano does everything you need, so there is no reason to learn about other editors.
I have fond memories of pine and pico; maybe I will look at nano one of these days.

fwiw, I find some powertools worth learning to use well even if they have a non-easy learning curve (sed comes to mind). This also applies to text editors; they're just tools.
As for "1975 wants vi back", I actually get a lot of mileage from vim which is a bit closer to nano's era.
nano: born 1999 as TIP, inspired by pico.
(btw, the last item on the nano news page is from 2009: "Now on Twitter and Facebook and Happy 10th Birthday nano". Is nano under active development these days?)
vim:born 1988, released 1991 (initially for amiga, much more widespread now), inspired by vi (note I do feel sorry for anyone stuck using "classic vi" in the same way I'd feel sorry for anyone stuck with edlin).
(side note: vi-style learning curve sucks. My first two weeks were Painful, but now that I have some skill (muscle memory) with the keys I find it very effective. Kind of like how touch-typing is harder to learn than "hunt & peck" but it is still well worthwhile to learn how to touch-type; it pays dividends. Most of vi-style power (for me) comes from the fast navigation+editing commands that are tied to a rather terse (and admittedly cryptic) "shorthand" language of key combinations... I remember actually being surprised at how clunky arrow key + mouse navigation felt when I first used conventional editors after driving vi-style for a while.)
One of the things I like about having learned Vim is it will be available pretty much wherever I might need to work: here are some of the targets from from wikipedia's vim page (* indicates ports I have used):

AmigaOS (the initial target platform), DOS, Microsoft Windows 95/*98/Me/*NT/*2000/*XP/*Server 2003/*Vista/*Server 2008/*7, IBM OS/2 and OS/390, OpenVMS, QNX, *Unix, *Linux, BSD, and Mac OS. Also, Vim is shipped with every copy of Apple Mac OS X. Independent ports of Vim are available both for Android and iOS.

(I've also found vim for aix; useful if one needs to spend time there.) Note that vim seems pretty consistently fully featured on the various platforms I've used it on (*'s above).
By comparison, nano seems pretty content to excel in linux distributions (redhat & debian).
And maybe, possibly, kind of sort of windows: from the nano faq, 3.9 How about in Win32

We're still working on documentation for enabling synax highlighting on Win32; please bear with us. Note that the nano.rc file must remain Unix formatted in order for nano to understand it. In other words, you should use probably only use nano to edit its config file. Other programs like Wordpad and Notepad will either convert the file to DOS format when saving, and the latter does not even properly read Unix-formatted files to begin with.

*shrug* I'm glad nano is working for you in the land of the modern linux desktop.

As for emacs: I sincerely believe that emacs users enjoy the capabilities they find; I may find a need for something emacs does well these days. I've never heard anyone say "Yeah,

After writing emacs, what else was there for him to need to write? :D

A decent editor would be a good start. But he was late to that party. ~

Actually VIM is supported on Windows now too. http://www.vim.org/download.php#pc

For those like me who don't need a feature packed application like org-mode and who prefer Vim to Emacs, there's VimOutliner. It's basic but very usable, and it comes with nice plugins (e.g. checklists) and scripts to export to various formats.

http://www.vim.org/scripts/script.php?script_id=2012

Unlike and better than the majority of the password-saferizers out
there, this keeps your passwords in a file which is both decryptable
with standardized tools and in a human readable format (assuming
you typed human readable usernames/passwords in the first place!)

Ten years from now you'll still be able to decrypt your files, and you
can share them with people who don't have the editor plugin.

As a matter of fact, yes. PlantUML and this plugin. Not that I would wish UML upon my worst enemy.

I suggest this.

Find me a good Vim plugin for Eclipse and I'm set for life. Until then, vim+brain.

Worrying about how long your IDE takes to start up makes about as much sense as worrying about how long your computer takes to start. Who cares? It's not like a file manager or notepad. When I open my IDE, I plan on it being open all day. As far as snappiness, I work in VS2010 for web development and Eclipse for Android development (don't ask) and guess what? They're both slow. It's the nature of the beast. Want speed? I suggest this.

We use gnupg+vim to share passwords and other secrets among my team. http://www.vim.org/scripts/script.php?script_id=661

To create a new encrypted secrets file, 'vim secrets.gpg'. Vim prompts you to specify recipients from your gpg keyring. Then vim opens a buffer; you write your secrets in the world's greatest text editor.* On write or close, vim prompts for your passphrase and encrypts the file to the recipient keys you specified, saving it as ascii-armored gpg.

Open an existing file with a .gpg extension, and vim prompts for your passphrase, decrypts the file, and opens it in a new buffer. On write or close, it re-encrypts the file to its configured recipients.

For easy sharing and revisioning, we keep these gpg files in a mercurial repository. This gives us a distributed, free, scalable, and reasonably secure solution.

*There's a similar gnupg plugin for emacs, if you're of that heretical religion.

... fail.

Supposedly, the operating system that "we" made was supposed to have full keyboard support, so we won't have to leave our beloved home row, right?

Wrong. I had a mouse go bad one time, and found out just how wrong.

For starters, just to log off or turn the computer off, you have to click a button in the top panel (in Ubuntu/Gnome), but, although there's a shortcut for the top menu (Alt+F1), you can't get to the panel buttons from there.

Plenty of other annoyances as well, including being not able (or hardly able) to switch among different sections of a program (such as file browser or web browser) with the keyboard.

Protip: I think Gnome's supposed to have support for MouseKeys. I used to use it all the time in Windows, but haven't in Ubunutu. In Windows, there's a handy keyboard combo for turning it on and off. Without that, you've disabled your numpad.

CTRL+ALT+DEL brings up a shut-down menu on my Ubuntu. I didn't have to set it that way, either... it's default. From there, the arrow keys (or tab) and ENTER is all I've ever used to shut down my PC. Mouse, schmouse. Out of habit (and learning with no mouse) I avoid using the mouse unless it's necessary. It's not impossible, just takes a little getting used to.

... fail.

Supposedly, the operating system that "we" made was supposed to have full keyboard support, so we won't have to leave our beloved home row, right?

Wrong. I had a mouse go bad one time, and found out just how wrong.

For starters, just to log off or turn the computer off, you have to click a button in the top panel (in Ubuntu/Gnome), but, although there's a shortcut for the top menu (Alt+F1), you can't get to the panel buttons from there.

Plenty of other annoyances as well, including being not able (or hardly able) to switch among different sections of a program (such as file browser or web browser) with the keyboard.

Protip: I think Gnome's supposed to have support for MouseKeys. I used to use it all the time in Windows, but haven't in Ubunutu. In Windows, there's a handy keyboard combo for turning it on and off. Without that, you've disabled your numpad.

ctags,cscope + super tab above command done in 7-8 keystrokes , including the tab. You haven't use vim that much so don't act like you have.
Finally I used VS for 8 years, use to be my favorite, along with being a windows fan. Sorry but I grew out of it and it got in the way more than helped.
VS is really designed to dumb down programming well for stupid programmers, bad thing is they make bad programs that just don't work or fucking stupid.
GUI everywhere when there shouldn't be, incredibly slow.
Oh yeah I might have eclipse, intellij , vim , slickedit open at the same time for the same code base depending on what I am doing.
The only thing that is really nice in VS is the C++ debugger , and C++ intellisense (sometimes).
You install cygwin just for vim? http://www.vim.org/download.php#pc there is a windows edition.

* Vim,
* Vimperator and
* ViEmu

...but am I the only one who is very hesitant about storing my precious passwords "in the cloud"? I use this gvim gpg plugin to encrypt my passwords, on my own terms, and I make them accessible to myself by any number of ways that I control.

Is this so incredibly difficult to do for most people that they must depend upon others to maintain their personal data?

I use Lastpass but not for "precious passwords". I could care less if they steal all my web forum logins etc. The important ones like online retailers who have personal info, banks, etc. I store in my head.

Most people I know use 123456 or password as their password everywhere then wonder how sh*t happens. If I ever get compromised at a sensitive site it's not because *I* didn't try, it's because I have no control over what happens to my 'net packets after they leave the router. Many sites really make me wonder if they are protecting their data as I would like.

...but am I the only one who is very hesitant about storing my precious passwords "in the cloud"? I use this gvim gpg plugin to encrypt my passwords, on my own terms, and I make them accessible to myself by any number of ways that I control.

Is this so incredibly difficult to do for most people that they must depend upon others to maintain their personal data?

• Open binary file
• Load into some internal metadata format for processing, ie image editor, text editor shit almost anything.
• Transform back to original format

Code folds would be another example.

Damn skippy.

You should be using vi (1), with cscope (1).

Stick with a cross-platform text editor. Both vi and emacs are avaiable for Windows.

http://ftp.gnu.org/gnu/emacs/windows/

http://www.vim.org/download.php#pc

No problem.

This is the first thing I thought of. How long has VIM been doing this?

At least since 1998 (version 5.3), perhaps even earlier. Go here and download vim-5.3-src.tar.gz. Then grep -Rn "hlsearch". It was there.

For all the things Apple has done right and does well, clinging on to Objective-C is not one of them.

It'd be nice if you pointed out, you know, actual reasons rather than just make snide comments. I'm sure some knee-jerk Apple haters will vote you up though.

My issues with iOS development lie not with Objective-C, but with Apple's frameworks and libraries. It's frustrating to only have header files and not be able to check out what a method actually does when debugging. Fortunately, the documentation for their classes is top-notch. The objc runtime is also a pretty wild ride, but once you know your way around you can poke at it and find out where your messages are going at least. Can check out the source for the runtime here http://opensource.apple.com/source/objc4/

Another issue of course, is XCode. I've switched to writing most of my iOS code in vim, building my code with the xcodebuild command. I still rely on XCode to do things like add files to the xcodeproj and manage the build configurations. XCode has a mind of its own, wacky completions, a completely fucked up undo buffer, strange locations for settings, and more frustrating joys. Would love to do away with that.

Check out the cocoa.vim plugin, and also, while I'm at it, you can get your vim for your local environment pimped out in minutes with Vimlander 2: The quickening. Test driving my apps with Pivotal's Cedar framework.

Why people use vim, in 2 minutes:

The popular vi clones (like vim) allow users to perform advanced editing (not just tapping arrow keys to move around), and it does it with the keyboard alone -- and mostly keys that are easy to press (like :w to save, instead of Alt+F, S). This means you do not waste time moving one hand back and forth from the mouse -- it *removes* this overhead. If you try to use something like Word with the keyboard only, you'll be using some very awkward key combinations. Not so with vim.

That covers the "advanced" GUI editors. Now: ed, MS edit, Notepad, etc., don't even try to implement the vast number of features you get with vim that let you quickly edit through the command line. As Bram Moolenaar likes to say, once the commands are "in your fingers" -- so that it's second nature -- your editing speed improves immensely. Particularly for writing code, but it is true for any other use as well.

If you are not interested in quick, efficient editing, then there is no reason to use vim. Ed or Notepad or Word will yield the same result as vim, it will just take you longer to do it (assuming you know how to use both editors efficiently). Most users get hung up because vim is a modal editor, so they ditch it and go back to gedit. For the rest of us who put the time in to learn how to use it effectively, it pays off in a big way.

See also:

Bram's Seven habits of effective text editing: http://www.moolenaar.net/habits.html (this is in presentation form somewhere on youtube, too)
Vim's about page: http://www.vim.org/about.php

I would say that whatever method that works for you is fine.

The important thing is not really the engine to do it but that it works. And DOS batch files - they do work, but can be a bitch to read for someone not familiar with them. One nice help is using an editor like Vim that color-codes the BAT file code.

But for testing - scripts are actually good since it means that you can correct any defects in the testing procedure fast. If the script language is DCL, BAT files, Bourne shell scripts, Perl or Python doesn't matter, just use what's suitable.

That computer takes 8 AAs. I have a camera that takes 8 AAs and I've learned the hard way - that many batteries weighs a lot. I use lithiums just because they're lighter.

No, what I want is a TRS 80 Model 100 with 8 gigs of internal flash, legacy ports replaced by 2 or 3 USB ports, and a text-based Linux distro like INX.

An ethernet port would be required; 802.11x would be optional but nice. Since the only thing I used my M100 for was writing, it's incredibly important that this fantasy machine have exactly the wonderful mechanical feel of the old M100. That thing was an unalloyed joy to type on. And since this is a writer's tool, exclusively, I could even forgo INX as long as I have a file system and VIM.

Seriously, if there were someone out there modding old M100s to these specs by ripping out and replacing the guts while maintaining the form factor and wonderful keyboard mechanicals, I'd buy it in a heartbeat for USD$500. I'd consider paying USD$1000.

Actually, the official page does mention it, under "Unofficial implementations":

Vim (crossplatform) - Sparkup, Zen Coding for Vim