Managing code

[BigDumbDinosaur]

scotws wrote:

By blind luck, I started off with vi (now vim http://www.vim.org/) on my very first Unix-y machines decades ago.

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.

[Tor]

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.

[banedon]

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.

[nyef]

banedon wrote:

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

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.

Quote:

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.

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

Quote:

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.

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.

[BigEd]

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

[GARTHWILSON]

What does "folding" mean? I don't know if this is the same or not, but the two major editors I've used, Norton and MultiEdit, both allow condensing the display, making it so you only see the lines that have something in column 1. This is why I don't like local labels to start in column 1. In condensed mode, you see the global labels and any comments you want visible in condensed mode. Go to a line you want, press Enter, and it goes back to the normal display starting at that line.

[BigEd]

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.

[nyef]

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.

[Factory]

BigDumbDinosaur wrote:

scotws wrote:

By blind luck, I started off with vi (now vim http://www.vim.org/) on my very first Unix-y machines decades ago.

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.

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.

[BigEd]

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

[GARTHWILSON]

Factory wrote:

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.  You motivated me to look up Emacs, something I should have done earlier.  The MultiEdit [1] I use and like a lot does allow editor macros and apparently has a very capable editor macro language; but I must confess I've never used that part of it.  Can you elaborate further from your experience?  How would you compare various parts of it to other editors, and how do you use the macros?

[1] Edit, 8/9/25:  I just found out, from the Wikipedia article that MultiEdit is defunct, due to the heart-attack death of the man who really made it go, and that even the website has been gone since Aug 2022.

[BigDumbDinosaur]

Factory wrote:

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.

I'm a silver-back "knuckle-dragger" when it comes to UNIX and its editors. I still recall how to use ed, which is about as primitive as an editor can get. emacs, on the other hand, is a prime example of what "creeping featurism" means. If I didn't know any better, I'd be convinced the code jockeys who developed it work for a certain convicted monopolist in Redmond, Washington (US).

Unfortunately, some of that emacs stench has rubbed off on vim, which isn't all that surprising.

[unclouded]

BigEd wrote:

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

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

[Martin_H]

unclouded wrote:

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.

[BigDumbDinosaur]

Martin_H wrote:

unclouded wrote:

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.