I've been pounding on vi for so long I'm not sure when I first used it. Some UNIX knuckle-draggers swear by EMACS, but I never got attuned to that editor. On the Windows side, I use UltraEdit, which works nicely, is pretty fast and doesn't do much in the way of stupid stuff.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Both vi and emacs are fantastic editors, both of course giving you multiple views and windows into the source code (one reason I don't use IDEs is because they usually force you to use their built-in editor, which simply can't compare).
I think the main reason for liking one or the other is the difference between a modal concept (vi) or non-modal (emacs). Personally I've never seen the point of the "editor wars". I happen to prefer emacs for programming, although I use vi for *nix config file editing (it's always available, unlike other editors).
One thing I use emacs for btw is to edit files on some other computer which may not be *nix or support a big editor, and may be low on resources -- if it is networked and can handle ftp, emacs can handle that transparently.

Some very interesting responses - thanks guys. With regard to VI... I'm not a fan, but acknowledge that I don't know enough to say if it's completely rubbish or the best thing since sliced bread. At the moment I much prefer Nano (although it does sort of reminds me of Wordstar if anyone remembers that ).

The reason I aked the question is that I've been busy doing other things and have recently gone back to my 6502 compiler only to find myself somewhat confused about which version did what. I've made sure that the code is commented, but is getting large enough that it's not easy to see differences between versions.
Also, the assembly source code for my 6502 build is looking like one massive confusing list of mnemonics so I need to find a way fo sectioing it off to make it easier to read/edit. I think maybe include files is the way to go on that.

Heh. I remember Wordstar. I do my server configuration in nano if it's available, otherwise in vi. But I find vi to be awkward and largely unfamiliar, which suggests that I need to spend a month or two using it heavily. My main editor is emacs.


This is what source control is for, and meaningful commit messages (something that is too-often skimped on, commit messages are documentation, they provide context for the actual changes being made over time).


Another possibility is a "code-folding" or "outlining" code editor. Make the bodies of functions invisible, but the headers not, until you need to see them. I mostly don't do this for code, but most of my prose life is lived in an outline editor (emacs org-mode, actually). This might be worth a shot. That said, I believe I mentioned my penchant for source files of a few hundred lines at most, right? Either include files or separate assembly/compilation and then a linker phase at the end.

"Folding" is the main reason I ended up in the emacs camp: both visual editors have something of a learning curve, so people are likely to stick closely to the one they know how to use. At Inmos there was a folding version of microemacs, which became the normal way to work on the 25-line VDUs we had. Although microemacs is no true emacs, it shares many key bindings and some facilities. (Inmos' software development system had a folding editor, which became a standard way to work with Occam, their high level language. We used the folding when working in our HDL, whose name I forget.)

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

That does sound like a version of folding. In my case, the editor interprets certain comments as fold markers, so you can choose whether you want to fold at function declarations, or fold up inner loops, or fold up related collections of functions.

Another approach I've seen is to use literal form-feed characters between major sections of code, followed by a description of the next section. If your editor allows easy navigation to the next such break (emacs certainly does, although it's a sufficiently-unique character that simply searching for it would work) then you can move around quite quickly.

emacs users are literally the opposite of "knuckle draggers".

The explanation for why most people don't get "attuned" to it is its murderous learning curve. The more you use it the more you'll think less of other editors.

Welcome, Factory! (That's an unfortunate post to have picked up for your first contribution here: most of us, most of the time, manage to avoid the sort of phrasing which is likely to divide the audience into two opposing camps. Or at least, I like to think so.)

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Nicely said. Next we'll be arguing about tabs versus spaces.

Even worse, those who argue for tabs will have an argument about standard tab indent sizes of 2 vs 4 vs 8.

...which is why I don't use tabs in most of my source code. Tabs inconsistently render because of many editors' ability to define a tab as something other than eight horizontal character positions. I'd use tabs if I could set tab stops in the editor, as can be done in word processing programs.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!