IDE

[nullify]

The problem I see with console-based editors is that text selections and cut/copy/paste/delete of large chunks of code is much easier and usually quicker with a mouse rather than any keyboard way of doing it, if the console editor supports selections at all. In addition, console editors usually jump by half-page increments every time, which is in contrast to the smooth mouse wheel scrolling I can attain through graphical editors (this may be configurable, but I have not spent enough time with console editors to figure it out). Not all console editors have a scrollbar, either (mostly useful for determine your location within a file).

Usually, the people using console editors also navigate through their source from the shell prompt. For me its just faster to keep multiple file manager windows open (usually one in the include/ directory and one in the directory with all the .c files), and double-click on the icon of the file to edit. If I want to quickly get to a file I know the name of, I can just start typing its name and Konqueror will automatically select the first file that matches the first few letters I typed.

Anyway, back to the editor part of the development environment. I use KWrite. Although GUI editors are slightly less responsive than their console counterparts and they take a bit longer to load, since they are better at handling bigger chunks of code its more useful in my opinion.

This is mostly a preference and habit kind of thing; whatever you are used to from the past will fit you best and allow you to work more efficiently.

[VE3MTM]

I always keep all my source files open in emacs in different buffers. Autocompletion works across all of them that way (which is very nice). As for the half-page scrolling, that has never bothered me. I usually never scroll by one line at a time anyways, usually enough to bring the next chunk of code into view

As for the scrollbar issue, if you want to figure out your position in a file, vi(m) has it at the bottom-right corner of the screen, and Emacs has it as on the bar at the bottom of each buffer, both in percentages

For simple cutting/copying in vim, use the dd command to cut one line, or dxd (where x is some number) to cut that many lines, then p to paste. To cut until the end of the line, use d$, etc.

[nullify]

As for the scrollbar issue, if you want to figure out your position in a file, vi(m) has it at the bottom-right corner of the screen, and Emacs has it as on the bar at the bottom of each buffer, both in percentages

For simple cutting/copying in vim, use the dd command to cut one line, or dxd (where x is some number) to cut that many lines, then p to paste. To cut until the end of the line, use d$, etc.

Thanks for the tips. I'll try them out.

[Solar]

For simple cutting/copying in vim, use the dd command...

That's what I meant. I am aware that vi can do all those things, but unless you have a reference sheet (or the famous reference coffee cup) in front of you, it can be awfully hard to find out about that stuff.

Call me lazy but I need the GUI. My memory is already used up by other stuff.

Thanks for the hint on pasting, I was missing that one.

[Pype.Clicker]

i've never made the effort of learning VI, but it's not more complicated that learning any other kind of shortcuts. MS said "let CTRL+C CTRL+V copy and paste data system-wide" and they saw it was good.
Because many programs under Unix come from miscellaneous sources without a coordinator entity, you'll have "F5" for copy in midnight commander, "ALT+W, CTRL+Y" under emacs and some unknown command under VIm

What is nice, however, is that later programs like tcsh, bash and other shells support command sets for every "famous" editors. Most unix editors also allow better customability than windows ones (hum. did you said that's because MS doesn't need it ? B) ) Just look at the bindkeys features of terminals or at M-x feature of emacs. there's a single interface that allow you to access *everything* and tell you how you could have get it shorter. Do you know an MS-equivalent to Describe-key and Describe-function in MS-Word ?

[beyond infinity lazy]

st gnucius.... stallman 'd be astonished 'bout this.

anyway, for quick and dirty editing of scripts or source files, I always use vi. it's fast and does what one want's it to do.

For emacs... well, it is an editor. I can use it to some extent, but I rather use vi.

for regular development work, I use a graphical editor like kde's kate (file browsing, open files, editor AND a shell all in one... that's what I call development environment).

Something for the COBOL fans among us: ever tried microfocus netexpress 3.1?

[mystran]

Vim, GCC, GNU as and GNU ld glue'd together with make.
Oh, and RCS. CVS would be an overkill but without some kind of version control I would have commited suicide a long time ago..

[Solar]

Version control, now there's something...

<shameless advertising>

To everyone using CVS, you should have a look at Subversion, http://subversion.tigris.org. After reading the CVS manual repeatedly front-to-back trying to figure out how to administrate a large project with it, Subversion came along and made my day...

It's free, it's using almost 100% the same commands as CVS, but it's *dead easy* to keep your stuff really organised...

You get support for copy, move, and rename. Tags aren't some meta-information but a copy of the code. Branches aren't some meta-information but a copy of the code.

Subversion gets 10 out of 10 from me. It's even supported by ViewCVS...

[DevL]

I'm pretty much like Solar (wow, what a surprise) in the sense that I much prefer a text editor such as TextPad than Emacs, having Cygwin around the GNU toolchain, and lastly complementing it all with the odd REBOL script when needed be.
I'll vouch for Subversion over CVS any day.

I also got a RH9 installation around just in case.

[gedeon]

I have try many platform to develop my os and i think that linux is the best for that.
gcc and nasm within kdevelop on Red hat 9 is good platform. And if you have vmware it's perfect.
WinXP + vwmvare(RH9) + vmware(myOs)
no dual boot , no reboot to test, and speed

[Solar]

OK, "update" on my dev env... the cygwin-to-elf cross-compiler is up and running, same goes for Bochs. That's three reboot cycles less per test run cycle...

Previous:
* edit source under Windows, test-compile (couldn't link since Cygwin creates PE...)
* reboot into Knoppix, compile, install
* reboot into test kernel, check results
* reboot into Windows.

Now:

* edit source under Windows
* compile with Cygwin-to-ELF cross-compiler, install to image
* start Bochs, check results
* no reboot.

Life is great. ;D