Editor recommendation

What editor would you recommend for code development? Looking for something that understands C & C++ syntax, can define projects, run external compilations, etc. and has active support. My choice would be CodeWrite, (if it was still supported.) For some reason never got used to Emacs, and Eclipse is too ginormous for my taste.

Alternatives?

Thanks,

--
Roberto Waltman 

[ Please reply to the group, 
 Click to see the full signature
Reply to
Roberto Waltman
Loading thread data ...

I used to find Eclipse too big, slow and clumsy - but it has improved enormously in the last couple of years. If it is a while since you last used it, I recommend trying again with the latest version.

Reply to
David Brown

I've used nedit for years. Development stopped years ago, but it is open source, so you can modify as you wish. Is language sensitive and has loads of setup options. The most useful thing when I started using it was the rectangular cut and paste, which I still use all the time, though the rest of the world has caught up meantime. unix environment required, though it works flawlessly with cygwin on windows. I still prefer a separate editor / makefile system, though ides are getting better.

Notepad++ is pretty good (windows), though there are niggles. Jedit is also worth a look as well. One or both (?) of these has plugin capability and both are in active development.

All quality product, free and open source...

Chris

Reply to
chris

You can still find both SlickEdit and CodeWright. And there is a for-real version of Brief available.

formatting link
Dunno about support; I have never made a support call for a text editor.

formatting link

formatting link

--
Les Cargill
Reply to
Les Cargill

What about VCS support?

I'm guessing you're working under Windows (re: your CodeWright reference)? Is that the *only* place where you develop code? Or, do you also have to develop/maintain in other environments?

Under DOS (and ancient Win's), Brief was my hands-down favorite. But, as machines got faster, Brief became unusable (IIRC, Brief had some keyboard repeat timing loops that didn't hook the system timer; as a result, you could *touch* a key and end up with a screenful of that keystroke...).

CodeWright was good under Windows. But, the GUI doesn't seem to add much to usefullness (IMO) and can be distracting as your hands tend to come off the keyboard too easily.

Emacs is comparable under X. And, *can* be very helpful -- but really only if you are writing mainstream code (i.e., something where someone has already created a *robust* "mode").

Currently, I spend more time in simple text editors (no syntax highlighting, macro support, etc.) because the effort to support a

*single* editor across different development platforms (and tasks!) is just too much work (perhaps if you have "support staff" it is easier?) I rely on plumbing in the window manager to move stuff from "window" (session!) to "window" (session). [It also gets too tedious trying to get fancier tools to coexist with a variety of different vendor tools -- none of which appear to have been created with any of the others in mind! Esp when everyone wants to make your life *easier* -- and ends up doing the exact oppopsite! ("No, I *don't* want all those spaces replaced with tabs, thankyouverymuch!")]
Reply to
Don Y

Do you know if this is based on the original sources (MASM?) or a "work-alike" (like Crisp :< )?

Reply to
Don Y

Brief was written mainly in Brief (macros).

"Brief was written from the ground up in 2006 as a Windows application."

formatting link

--
Les Cargill
Reply to
Les Cargill

Try Netbeans.

formatting link

Reply to
bbhack

I'd have imagined the original Brief was a LISP dialect interpreter. E.g., the macros were C-like functions but with LISP-like syntax.

Ah, that is unfortunate. Not worth the bother exploring, then. :<

Reply to
Don Y

I had the same feeling toward Eclipse, as it felt a monster when running on the computers of yesterday. Now, the CPU speeds and memory capacities are much better, and you can tune Eclipse to your heart's content.

I have run Eclipse on Mac OS X, Linux (several flavors) and Windows, and I'm pretty happy with the results. However, there is a hefty learning step to climb until one feels at home with the myriad of settings.

My old favorites were WordStar, nedit, Codewright, Smultron and kate, but they have all given way to Eclipse with CDT plug-in. With quite modern hardware (MacBook Pro of 2008), it runs well even in a virtual machine with Linux or Windows XP (no idea of newer windozes, however).

The CDT nag-machine is much more than bare syntax coloring, it quite well replaces lint, as well.

--

Tauno Voipio
Reply to
Tauno Voipio

Wasn't that originally a Sun Micro product ?. Anyway, the fact that it's available for Solaris Sparc and X86 means i'll be having a look at that. Thanks for the pointer...

Chris

>
Reply to
chris

Thanks for the replies - my notes in no particular order.

I knew about all the options except Smultron (not a Mac guy,) and the new implementation of Brief, and thought CodeWright was dead. Pity the new Brief doesn't have the original's macro language. (I used it extensively in the DOS days. )

By "still supported", I meant "bugs are fixed"

No CVS integration needed.

Working under windows when at work.

I don't want my spaces replace by tabs either ;)

I used Nedit and recommended it to others, but did not use it under Windows

Will give a try to Eclipse again, although don't like the screen real state it uses in things other than the files edited. Specially when I need to use larger and larger fonts as time goes by. (Not everybody has dual 30" monitors.) And what was that Saturn-like icon for?

--
Roberto Waltman 

[ Please reply to the group, 
 Click to see the full signature
Reply to
Roberto Waltman

What are exactly the reason(s) why you have excluded Emacs ?

I have been using Emacs for 15 years (sometimes extensively) and i always enjoy using it as an editor for C/C++. I think Emacs is one of few tools making you a better programmer.

H
Reply to
Habib Bouaziz-Viallet

Did you notice that there is a box-like icon in the right top corner of the editor frames (and quite many others)? It can be used to maximize the window. There may be several files open in the same window, and they may be used as split screen. I'm usually using the editor window maximized with two tabbed subwindows containing the files currently of interest. This has been sufficient for me (67 yrs) on a MacBook, though I like the 24 inch Cinema display on BigMac more.

Please take the time to wade the workbench and CDT documents. A single pass was not enough for me, but after some frustrating 'Where on Earth is the function I'd find' the terrain starts to feel more familiar.

The globe in Eclipse icon is a darkened Sun in an ... eclipse.

--

-Tauno
Reply to
Tauno Voipio

So the rest of the world slowly catches up I gather :-)? I have had rectangular cut and paste ever since I began using my own editor (around 1990), had no idea who else would have it and since when. I wonder if the world has caught up with some useful key combinations I introduced for myself back then (shift-up or shift-down moves 4 lines, shift right moves to next word etc.). I suppose my editors (two of them, the second one came for DPS around 1996 or 1997) have been a significant part of what has made me as efficient as I am.

Sorry for the OT as I can't recommend any of the PC based editors but sometimes like all of us I also need to talk to people who understand what I am talking about :-).

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

formatting link

------------------------------------------------------

formatting link

Reply to
dp

Emacs has it, but I don't know when Emacs acquired it.

DEC's EVE/TPU editor for VMS has had box select/box cut functionality since at least the early 1990s; I don't know when the functionality was added, but EVE/TPU was created in the middle 1980s.

I've no need for moving up/down in units of 4 lines, but both DEC's editors and Emacs have move by word functionality.

I don't know about others here, but I find DEC's EDT keypad mode, in which common commands are mapped to the numeric keypad (the keypad is placed into application keypad mode which causes escape sequences to be sent instead of numbers) to be very useful indeed.

I find it useful enough that I have emacs setup to use it's built-in emulation of EDT keypad mode. You either need a _good_ terminal emulator to use it (for text mode) or to run a Emacs supplied keypad configuration script (for GUI mode).

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP 
Microsoft: Bringing you 1980s technology to a 21st century world
Reply to
Simon Clubley

How do you move vertically when you have to do it for long distances? To me, shift-cursor up or down is may be the most frequently used combination.

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

formatting link

------------------------------------------------------

formatting link

Reply to
dp

Page up/page down, which is really screen up/screen down as it jumps in units based on the terminal emulator/GUI window length (minus some configurable overlap so you don't lose your place while scrolling through the code).

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP 
Microsoft: Bringing you 1980s technology to a 21st century world
Reply to
Simon Clubley

Brief had rectangular cut & paste in the early 80's (my v2.1 manual is copyright 1984 and I'm pretty sure the feature was present on earlier versions -- I'll have to chase down a floppy .IMZ from my archives...)

In school (late 70's), forward/backward word/line/etc. was a common feature on the (numeric) keypad on one of the DEC? systems I used (I recall "red" and "gold"? keys as command introducers)

[Of course, back then, each class had it's own INCOMPATIBLE system... :< ]

One of the most enjoyable features I have found is being able to set the "cursor direction". I first saw this feature on The Electric Blackboard (under CP/M).

Basically, you defined the direction in which the cursor would move after each keystroke. One of the more common uses was to move over to some column where on-line comments began (e.g., ~40) set the cursor direction to *down* and then lean on, for example, ';' (to introduce comments).

This would have the effect of inserting (or replacing, depending on which mode you were in) a semicolon in column 40 of each line that you passed *through*.

It was also great for "ruling" tables, etc.

One of my common gripes with, e.g., emacs, vi, etc. is that I can't just move to a random point ON THE SCREEN and start typing AS IF the screen was filled with virtual whitespace (which would automatically be inserted *iff* I actually needed it inserted on a particular line in order to pad out to something I've chosen to add "in column 72")

Hope Lucy isn't reading over your shoulder!! :>

--don

Reply to
Don Y

I found the ease of creating a "keystroke macro" to be the most useful tool!

Typically, I would create two windows into the same file (most often one above the other -- but depends on the actual nature of the task I was trying to perform).

The top window would usually be what I considered the "source" window and the bottom, the "destination".

I would *carefully* position the cursors in each window where I wanted them to be -- "initial source" and "initial destination". Then, in the source window, "begin" the keystroke macro and carefully execute some set of cursor positioning, mark, search, etc. keystrokes. Switching to the "window below" and taking advantage of whatever I had "cut" or copied in the window above to paste, overwrite/insert into the lower window. Then, return to the "window above" for any additional steps that needed to be performed there. Back to the lower window, etc.

Once done, "end" the macro (taking care to make sure the cursors in the source and destination windows are positioned appropriately so this stored set of keystrokes could be applied to the *next* source instance (line, field, etc.).

Then, lean on the "play keystroke macro" command and watch the two windows scroll along as the cursor frenetically jumps around applying the stored actions.

I found this *so* easy to do that it was the *first* technique I would often apply -- even if there might have been some more clever way of doing what I wanted. Esp as it would let me *see* the changes being applied ("Ooops! I guess I don't really want to apply this for the entire extent of the file! Best stop here and undo back to where I *should* have stopped!")

It's interesting to see the different attitudes tools take towards their "associates"! I.e., does the editor invoke the VCS toolkit? Or, does the VCS toolkit invoke the *editor*?? Everyone always wants to drive the bus...

I've been setting up a Perforce server for one of the projects, here. Needless to say, they want to think the world revolves around *them*!

And *only* dealing with "source code"? E.g., I find it tedious having to bounce around between different toolchains where different capabilities are present -- or, invoked/implemented in slightly incompatible ways (hence liking the ability to be able to resort to something as banal as vi(1) as needed).

That's one advantage to using, e.g., vi(1) in separate xterm(1)s under X. Very little "wasted" real estate for "button bars", status fields, etc. Likewise, a no-frills window manager so you don't have lots of decorated window frames!

[I have xterm(1) configured so I can easily change font sizes in individual sessions -- though that currently also changes the window geometry]

Be thankful you're just writing code! When preparing publications, you want to see a good fraction of the page (to get a feel for how it lays out, etc.) which drives text size down. Yet, you still want to be able to resolve different typefaces/styles conveniently ("is that italics? or, just excessive jaggies from the lowered relative resolution??")

There comes a point where you just can't get a monitor *big* enough!! :-/

Reply to
Don Y

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.