I sugest vim, but it may not fall under simple-to-use, just because you need to setup a few plugins to make it worthwile, but I love it.
IDEs
For debugging, there's also zerobugs, which supposedly is quite nice. Haven't used it myself though.
Quote:Original post by Sander
Personally I prefer no IDE. I use (g)vim with a bunch of plugins like netrw, tagexplorer and a debugger plugin.
QFE.
I would also point out that at my place of employment, which is predominantly a Linux development house, this by far and large the preferred MO. Many people come from the Windows side and are used to IDEs but eventually convert. IDEs can get beginners going faster but end up limiting the advanced user (the old 80-20 rule). Also, a vim-based work habit works just the same on Mac OS X and Windows as on Linux and other Unixes to if you're targetting multiple platforms, it's da bomb.
We also have a few hardened emacs people. Interestingly, none of the Windows converts choose that path when they're ready to move up.
I'm currently doing the exact same. I also highly suggest developing inside VIM. Is the switch difficult? Of course. Yet I'm already enjoying the fruits of my labour.
On that note, I highly suggest you learn to type with 10 fingers properly - It'll help unlock VIMs potential.
On that note, I highly suggest you learn to type with 10 fingers properly - It'll help unlock VIMs potential.
Quote:Original post by SanderCan you (or anyone else, for that matter) expand upon your use of plugins? To debug in vim, do you use vimGdb, clewn, pyclewn, or some other plugin? Right now I'm just using virgin gVim, but I'm thinking clewn plus some of these plugins might come in handy:
Give Anjuta a try. It's nice. Personally I prefer no IDE. I use (g)vim with a bunch of plugins like netrw, tagexplorer and a debugger plugin.
taglist (source browser)
c.vim (C/C++ IDE)
OmniCppComplete (intellisense-like functionality)
bufexplorer (Buffer Explorer)
SuperTab (Terminal-like tab completion)
Quote:Original post by foundTo add to this, you don't need arrow keys, you don't need page up or page down, and you don't even need escape (even though that's how most tutorials tell you to exit insert mode). Learn to move around with h, j, k, l, ctrl-u, ctrl-d, ctrl-f, ctrl-b, (and various other movement keys) and use ctrl-[ instead of escape. When you've mastered it, you shouldn't need to move your hands from normal typing position, which greatly enhances productivity.
On that note, I highly suggest you learn to type with 10 fingers properly - It'll help unlock VIMs potential.
The last thing I wanted to mention is that a good .vimrc is essential. Mine is hacked together from various sources and includes my own additions and variations:
" always have syntax highlightingsyntax on" always number linesset number" don't wrap long linesset nowrap" change tabs into 4 spacesset shiftwidth=4set expandtabset shiftround" autoindent new linesset smartindent" be quietset noerrorbells" show matching bracesset showmatch" normally don't automatically format 'text' (code) as it is typed, IE only do" this with comments, at 79 characters:set formatoptions-=tset textwidth=79" get rid of the default style of C comments, and define a style with two stars" at the start of `middle' rows which (looks nicer and) avoids asterisks used" for bullet lists being treated like C comments; then define a bullet list" style for single stars (like already is for hyphens):set comments-=s1:/*,mb:*,ex:*/set comments+=s:/*,mb:**,ex:*/set comments+=fb:*" enable filetype detection:filetype on" let gvim know all of those *.cc* files are C++ filesau BufNewFile,BufRead *.cc* :set ft=cpp" let gvim know all of those *.m* files are Matlab filesau BufNewFile,BufRead *.m* :set ft=matlab" for C-like programming, have better automatic indentation and if starting a" newline in the middle of a comment automatically insert the comment leader" characters:autocmd FileType c,cpp set cindent formatoptions+=ro" in makefiles, don't expand tabs to spaces, since actual tab characters are" needed, and have indentation at 8 chars to be sure that all indents are tabs:autocmd FileType make set noexpandtab shiftwidth=8
I've written an article about two months ago that details all the plugins that I use. See Quote:Is the switch difficult? Of course.
For people new to Vim I highly recommend running the `vimtutor` command. It provides a pretty good and easy to follow Vim tutorial right inside Vim. You can also start it as `vimtutor -g` to run it with Gvim instead. I do recommend that you stick with the default 80x25 screen size when running vimtutor. The tutorial was designed for that, so it makes following it a lot easier.
For people new to Vim I highly recommend running the `vimtutor` command. It provides a pretty good and easy to follow Vim tutorial right inside Vim. You can also start it as `vimtutor -g` to run it with Gvim instead. I do recommend that you stick with the default 80x25 screen size when running vimtutor. The tutorial was designed for that, so it makes following it a lot easier.
Quote:Yann LQuote:Sander
Give Anjuta a try. It's nice.
Anjuta ?! You have to be kidding me...
I partially agree with Sander. I prefer a minimalistic setup for my spare time coding (though at work we use MSVC).
Partially, because when the Anjuta devs changed the GUI so that all elements are freely placeable, it also became slower (w.r.t. latency while typing), plus all elements are bigger now, yielding a smaller editor window. Also, using the builtin terminal emulator is too slow for my taste, and afair, you have to close it to get back to the editor, instead of just switching back to it and keeping the term-emu open.
I am a big fan of code::blocks, but recently the editor has become somewhat slow, especially I couldn't find out how to deactivate that auto-search when marking text. And blazing fast editors are a killer feature for me, like When You Type Is When You Get.
So, after being a long time user of code::blocks, then Anjuta, then code::blocks again, my current coding cycle goes like this:
* scite/notepad++ as the editor, then alt-tab
* terminal emulator for testing, arrow-up then return
* make / gcc, then alt-tab
Best thing is that the first two are independently tabbed.
Btw, if I have to make a GUI, I use wxFormBuilder.
Of course, from to time I check out Anjuta and code::blocks how they evolved, and nothing would prevent me from switching back if saturating.
Sander's post got mangled (forgot a quotation mark), so here it is:
I agree with going through vimtutor as well. I've done so every few months or so, picking up some new tricks each time.
Regarding the OP's requirements, I think everything is pretty well covered by Anjuta, Eclipse, Kdevelop, and Netbeans. Well, "simple to use" is a bit subjective. And excepting code refactoring, that is; Eclipse and Netbeans can do it for Java, but it doesn't look like any Linux IDE's have that feature for C++ until Kdev4, supposedly. For project-wide renaming (which Kdevelop can actually already do) you could always just become a sed expert. [wink]
Quote:Original post by SanderI never could get into the light text on dark background that everybody besides me seems to prefer, but wow, I love the wombat color scheme so far. I've even changed my Konsole color scheme to be closer to it. Usually there's a bright yellow or bright green that's just too jarring (I'd rather have a lot of brightness then just a few obnoxiously bright keywords), but I haven't come across one this eye-friendly. Thanks for that!
I've written an article about two months ago that details all the plugins that I use. See http://www.jejik.com/articles/2008/10/my_list_of_must-have_vim_scripts/. Note that I mostly do web development, so my preferred plugin list is somewhat different than yours.
My most important plugin is netrw. I build vim from source instead of using the one shipped with Debian, just so that I can use the latest netrw. Aside from the plugins listed in the article I also use debugger.vim plus the XDebug PHP module to do remote PHP debugging on servers.Quote:Is the switch difficult? Of course.For people new to Vim I highly recommend running the `vimtutor` command. It provides a pretty good and easy to follow Vim tutorial right inside Vim. You can also start it as `vimtutor -g` to run it with Gvim instead. I do recommend that you stick with the default 80x25 screen size when running vimtutor. The tutorial was designed for that, so it makes following it a lot easier.
I agree with going through vimtutor as well. I've done so every few months or so, picking up some new tricks each time.
Quote:Original post by phresnelVery useful info. I wish it was easier to find opinions like this, because comparing feature lists on wikipedia just doesn't cut it. The Matlab GUI at work is like this as well - the built in editor has some great features but it's just unusable for me for this exact reason. It's one of the main reasons I use gVim exclusively now. Someone just recently added some of those features to vim, so I'm not switching even if they do make it faster. :)
Partially, because when the Anjuta devs changed the GUI so that all elements are freely placeable, it also became slower (w.r.t. latency while typing), plus all elements are bigger now, yielding a smaller editor window. Also, using the builtin terminal emulator is too slow for my taste, and afair, you have to close it to get back to the editor, instead of just switching back to it and keeping the term-emu open.
I am a big fan of code::blocks, but recently the editor has become somewhat slow, especially I couldn't find out how to deactivate that auto-search when marking text. And blazing fast editors are a killer feature for me, like When You Type Is When You Get.
Regarding the OP's requirements, I think everything is pretty well covered by Anjuta, Eclipse, Kdevelop, and Netbeans. Well, "simple to use" is a bit subjective. And excepting code refactoring, that is; Eclipse and Netbeans can do it for Java, but it doesn't look like any Linux IDE's have that feature for C++ until Kdev4, supposedly. For project-wide renaming (which Kdevelop can actually already do) you could always just become a sed expert. [wink]
Or use a dash of perl:
Or, recursively and skipping Subversion directories:
perl -pi -w -e 's/search/replace/g;' *.cppOr, recursively and skipping Subversion directories:
find . -name '*.cpp' | grep -v '.svn' | xargs perl -pi -w -e 's/search/replace/g;'Quote:Original post by Sander
Or use a dash of perl:perl -pi -w -e 's/search/replace/g;' *.cpp
Ok, but the sed equivalent
sed -e 's/search/replace/g' *.cppIf you're going to adopt vi because it's more powerful than and IDE, you might consider also adopting the other 40-year-old tools. Once you've climbed the steep mountain of a learning curve you can see much, much farther.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
