Editor recommendation

Probably in the 1970's on the PDP-10.

Well I have page up and page down as well of course, and I also use these extensively. But moving say 25-30 lines up within a 50 line page is incomparably faster/easier to do using the *4 cursor up (it takes having used both to know how useful both are). So the world has only partially caught up, as it turns out :-).

Dimiter

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

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

Joe's Own Editor:

-- /* snipped-for-privacy@world.std.com AB1GO */ /* Joseph H. Allen */ int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)

+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p158?-79:0,q?!a[p+q*2 ]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

Hey Don,

Well my first keyboard did have cursor keys and they have always been functioning :-). But to have shift multiply the effect of up/down keys (among others) by 4 (or whatever one feels is OK) was not - I introduced it in my first editor, don't know who if anyone has done it before on which platform. It is very convenient to have it.

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

In my editor I do this by edit/copying a column which I want to multiply, then I "paste" it (usually in replace mode) where I want it. Usually I start with a 4 line column, once I duplicate it another two keystrokes double it etc., can get as fast as needed.

Hah, she would not mind that I am sure :D. She is pretty far from doing that sort of thing (but she is quite good at learning to use new gadgets).

Dimiter

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

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

Hi Dimiter,

[I sent you a msg a week or two ago... perhaps wr>> Basically, you defined the direction in which the cursor would

I think the "cursor direction" feature is more intuitive -- once you get used to it.

E.g., to number consecutive lines, you simply point down and type "012345678901234567890...". Then, move left a column and invoke "repeat 10 X" (where X is 0, then 1, then 2, etc.)

Applies equally well to "numbering" lines with letters. Or, in different radix: 0123456701234567...

At the time (coming from more "conventional" editors -- qedx, teco, etc.) it was a delightful feature (on a 6MHz 8b "workstation"!)

My best friend was very fond of writing macros -- for all sorts of little things. Of course, that meant he then had to keep track of all of these and how to invoke each, what they did, etc. I much prefer a behavior that I can observe and intuitively apply in different scenarios. Much like the "copy two lines; then four; then eight; etc."

Isn't that a prerequisite, when living with an engineer? :>

C complains each time I make some change in "how things work". Of course, I've only done so to *fix* something that wasn't working properly at the time or to add some functionality -- often that

*she* requested! :-/

("Why can't I get the DVD player to work?" "Because you asked me to hook up a VCR last night so you could watch that video of your family!" "Oh. So, how do I get the DVD to play, now?")

(sigh) Can't win...

--don

P.S. I will assume it is *finally* above 0C there? :> (we're *dropping* to the very high 30's)

A second video card and a 24 inch monitor in portrait mode will set you back, what, $200?

I already have six 21" monitors in the office -- two on each workstation. Rotate one to have the aspect ratio of a "sheet of paper" when working on documents -- the other can remain "as is" to interact with the associated applications.

The problem with larger monitors is you need them further away in order to see the page as a whole. Then, the added detail gets lost (vision degrades with age).

I've found it much more productive to *print* the pages of interest and examine them in my hands. Your eyes are very capable of resolving fine detail WHEN CALLED UPON (they are also very good at *ignoring* fine detail when necessary!). Print a page at 1200dpi (even 600dpi for proofs) and you can get a much better feel for the "product" than a 21 (or 24!) inch monitor operating at a resolution of 7000 pels or greater, vertically!

[There's a reason folks typeset documents at "magnified scale"... you just can't see that sort of fine detail on commercial monitors at 1:1! *I* "cheat" a lot! altering the colors associated with certain tags so that I can rely on color cues in lieu of being able to have a high degree of visual acuity. E.g., perhaps arranging for "emphasis" text (possibly italic?) to be displayed in green -- as well as in the required typeface -- so that the color cue frees me from having to question whether a particular glyph has some slant/skew/boldness to it or not]

ITYM, "The person who bought the TV (or receiver) didn't get one with enough A/V inputs".

Never got one. It is possible if you have sent it to the address I use to post here (dp@... ) that I have just overlooked it, I get a few hundred messages/day on it, almost all spam. Use some of the others if that's the case or please just retry it, me not seeing it is very low chance even at this address.

It is more intuitive indeed, but once you get used to the "mark and duplicate" method I have you get much faster when it comes to larger quantities. Imagine you want to do it on 200 or 2000 lines; chances are you will just look for an alternative method rather than moving the cursor over each line. The way it works for me is to mark the top of the duplicated column(s) and once I duplicate I mark the entire column again, so each time I "paste" I have it duplicated and can also duplicate what I have to paste. So if I start with 4 lines after repeating alt-m F3 alt-i 6 times I will have done 256 lines (unless I miscalculate, give or take 1 repetition). Then the column I insert/replace can contain anything and be of any width/height.

Well it is a way of doing it of course. My way is to make the first ten lines manually, then copy it as many times as it takes, perhaps multiplied. I suppose your method would be a bit faster for 10-20 lines, mine would probably be faster above that.

But these are things we rarely do anyway. It is important to have them easily available so editor inconveniences do not make us avoid doing what we really want to though. I suppose the little things are the great time savers though, like that move(scroll) 4 lines instead of one if shift is down, move to next/previous word, delete from cursor back to word start (that would be alt-left for me), delete from cursor until next word (alt-right), erase to EOL (ctrl-right) etc. etc., things we do hundreds if not thousands of times a day.

I did my first text editor for my 2 MHz 6809 machine I had made. Two 6809-s, actually; a "system" board and a "text/graphics terminal" board, an 8 bit wide 1k FIFO between the two. I replicated the keys on the second which is still the DPS system text editor I use all the time (now running on a 400 MHz power, actually can run multiple instances also of an emulation I did of the 6809 machine under DPS. Obviously I added some new features then; time for yet another overhaul now that we are at it :D.

Hmm, I am not sure which I would prefer :D . This way when a gadget (her laptop or the smartphone) is messed up in some way guess who has to be available to fix things. Come to think of it I am so used to being that guy that I don't even question if I have to do it, whoever it is I have to rescue :D .

Well that sort of thing is similar here of course. Add to that that Lucy often has to cope with system popup messages in English which she more often than not does not understand... :D .

Most of the time when I make that sort of changes Lucy is alert and watching me,

Tell me about it. Summer is going to an end, we had only 6-7 weeks of real summer (should have had 3-4 months). But it is still summerish, hopefully for some time more.

Dimiter

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

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

More like "I thought we were throwing this thing *away*?? Wasn't that the reason I transferred all those tapes onto DVD in the first place??!"

As I said, "can't win...". Next month she'll be asking why it

*didn't* get thrown away! :->

I forwarded a copy just now. Nothing important. Just FYI...

Yes. As I said, I tend to just rely on using existing mechanisms instead of having to "think" about how to approach it. E.g., should I write a piece of code to go through a file and substitute references of with or, should I do this with a keystroke macro inside a text editor?

I find myself often hammering away on "up, left" (or down, etc.) with my right hand while pecking at some other key with my left. E.g., "$ up left" to insert a bunch of '$' in front a column of monetary figures, etc.

You can actually get pretty good setting up a cadence if you do it often!

Yes. And, the expectation of *instant* service!

"Gee, how did you deal with these sorts of problems AT WORK when you had to wait hours or days for someone to come and have a look at your machine? Did you find OTHER THINGS TO DO while waiting? Or, did you sit and grumble about how long it was taking?" :>

She now complains a lot less about all the kit I have stashed around the house: "Don, my monitor just went black!" "OK, here's a new one. I'll fix yours later..."

Ah. You must learn to translate all of these into:

"Total system failure. Please turn the system off and wait at least 72 hours before attempting further use. Error 788WQ3."

I usually do maintenance type things in the wee hours of the morning. More convenient for my schedule. And, I don't have to worry about the "is it done, yet?" attitude.

It seems like Summer started in February, here. But, we have only had ~50 days above 100F (average is 60 or so... 99 of them one year!). Of course, we'll probably *also* have a brutally cold winter (for this area). I'll have to take extra good care of the new citrus plantings...

I can see how some folks like to have two "homes". Though that seems like it would be ripe for "Oh, crap! The item I've spent the past three days searching for must be at the *other* house!" :-/

--don

Neither. You should have an editor that supports search-and-replace via regular expressions, and use that. E.g., and just because this particular editor hasn't been mentioned yet: in plain old vi, that would be

:1,$s///g

(all in one line, not really tested)

And you really shouldn't be. Any programmer's editor really worth having has some sort of "rectangle fill" feature. E.g. in Notepad++, you would just -mark the column (i.e. drag the mouse while holding , or move the cursor from one end to the other while holding Alt+Shift), then type a single $. Done. For more complicated cases, it can even fill in a sequence of numbers

In Emacs one would drop the mark (Ctrl-Space), move to the other end, then Ctrl-x r t $ .

Well, yes, in the context of readily available quality free editors in the early nineties, there really wasn't much choice. Coming to unix from a dec background, it was quite disappointing to be presented with thing like vi, when dec systems had full screen keypad editors for 10 years or more.

Don't know if you have bothered to look at nedit, but it has a lot of other features, like tabbed editing, multi language sensitivity, macros and loads more. All I really need from an editor is a flexible set of core features, not a load of eye candy and obscure "features" that no one ever uses. It also needs to be easy to get started without looking at the manual, which often is a key indicator of how intuitive and user friendly a product is.

NEdit evelopment stopped around 2001, but this page gives gives a little history:

"To the best of my knowledge, NEdit was begun in 1991 as a short project to explore the Motif text widget and provide a simple editor for programmers to use at Fermilab. At that time Fermilab was beginning its migration from VAX/VMS systems to Unix systems, and one of the first stumbling blocks that physicists, and some programmers there, came up against was editing. Most VMS users used EDT or EVE, and the Unix editors were very different from these...."

For me, there are 2 main editor requirements: The first for quick fixes on short files, for which I use vi on unix, pfe on windows (ancient, but still useful) and for serious work, nedit on unix, windows / cygwin, notepad++ on windows. Nedit also has the advantage that there are binaries for just about every flavour of unix and Linux.

You were obviously well ahead of the curve at the time, but if you don't publish or make your work available to others, who will ever know about it ?.

Well, that's the problem with being a genius ahead of the curve; No one understands you .

(Sorry, couldn't resist :-)...

Chris

for-real

Most versions of Codewright will not run on Win 7 or 8 [if that matters]. However, I haven't tried v7.

George

Which is still too big, slow and clumsy for what it does. Eclipse's major asset is being [relatively] cross platform.

However - for my taste anyway - there still are too many annoying differences between the Windows and Linux versions: same functions found in different places, dialogs laid out differently, etc. [never mind the issues of setting up external tool locations and command lines]. It's more difficult than I think it should be to go back and forth between them.

YMMV, George

Not all do. And, using RE's isn't a panacea -- see below.

When I'm working under Inferno, I can either live with Acme's notion of "what a programmer needs". Or, access the file in question from *outside* Inferno (assuming I am working in a hosted environment), manipulate it with a generic tool under the host OS, write it back to disk and *then* access the resulting file from within Inferno.

This is true of lots of applications that maintain their documents in some sort of "coded" ASCII. The "native" tools are often only designed with limited "text manipulation" capabilities. If you want to do something clever, you are forced to:

- understand the encoding being used

- use or develop an external tool to massage the file as desired

For example, I defined most of my gestures using Photoshop. Very easy to create complex Bezier curves and tweek them to form a consistent representation -- that you can visually evaluate.

But, you have very limited precision! E.g., "draw" a 'C' and a 'G' and, ideally, the (obvious) shared portions of each figure (gesture) should be identical. Yet, you can't do this with the tools available

*in* Photoshop. You simply can't position the mouse that accurately.

OTOH, Photoshop creates an ASCII representation of the document containing those "drawings". So, it's a relatively simple matter to massage that ASCII text (in an editor or with a "tool") to ensure the common portions of the two figures are *identical*. Then, verify this by reexamining the document in Photoshop.

And, once these have been visually verified, the same ASCII document provides the data that will reside in the source code to process those gestures.

Similarly, I "proof" AutoCAD documents (esp templates) in "DXF format" (department of redundancy department). This lets me verify that certain intended invariants do, in fact, exist in the document/model which otherwise would have been tedious to examine using the "conventional" user interface.

The example I was alluding to in my previous post came from a lengthy document that I had prepared some time ago (10MB of "text"). Much easier to write a piece of code to walk through it and mechanically rewrite the portions of the files that needed modification than to *hope* I came up with the right RE to fix it all in one shot ("Ooops! Minor error, there. Do I have a backup that I can try that on, again?")

And *that* is the problem ^^^^^^^^^^^^! Unless you want to invest lots of time learning to be an RE guru (and then complaining when some tool doesn't support them!), you're never quite sure you've got it right when you hit ENTER.

Write a piece of code to perform the same sort of thing and you can easily (i.e., with a high degree of success) change a stub that emits "found at file offset ; replacing with " (i.e., used to let you preview the actions that the code will ultimately take) with one that writes directly to the desired output file (without fear of overwriting the original input!).

So, when you view that document in it's *intended* application, you don't have to manually proofread hundreds of pages to discover instances of: Illustratin XX < caused by writing "

Well my purpose back then was just to have a useful tool for myself, not to publish it. Since it worked on my hardware only which would have no chance on the market as a general platform I did not even consider expanding this way. But people who have had such devices in their hands (the oldest of nukemans) would have seen it (and would be uninterested, they would be using a spectrometer as a spectrometer :-) ). Come to think of it, nowadays things haven't changed much, netmca users have a lot more available than what old nukeman users used to have but are still using their spectrometers as spectrometers.... :-) .

Well, nowadays I am kinda used to it. (sorry, that was hard to resist, too :D ).

Dimiter

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

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

It does tend towards the bloatware end of the spectrum, looks like it was designed by committee, all things to all men etc and is complex to set up, so I don't use it here. I like lightweight tools, ideally separate functionality and find that editors that come with ide's usually only do half a job. All I really expect to find is a good editor, compiler and debug link to hardware. Anything over that is luxury, but really don't want a load of features and "options" that just add to the noise and never get used.

Have been having a look at the Insight gui wrapper for gdb in the past year or so. Slightly unstable in the environment here (Solaris Sparc, but definately usable. That and ocd provide a complete lightweight toolchain end to end...

Chris

It very nearly is ... and it's pretty much guaranteed to be faster than even you can write a filter program to do exactly the same job. If only because it's fewer key presses end-to-end.

Looks like you haven't had enough exposure to Emacs ;-) Emacs will happily edit files at the remote end of just about any type of remote file transfer connection.

Thus the notion of a programmer's editor, which just so happens to be the actual topic of this thread. That's exactly the one tool you use in all those cases where simple editors (including those found inside other programs) just don't cut it.

And the reason it's called a programmer's editor these days is that most other users have almost forgotten what a text file even is, to the point that you have to start C textbooks with a full-page warning message that, no, you're not supposed to use MS Word to edit source code.

Or, for crying out loud, just copy the common portion before you make two separate versions.

Sorry, but I'll have to call BS on that one.

And your "piece of code to walk through ...", which is probably an order of magnitude longer than the RE, never has oopses. Sure. Oh, and if you're so worried about the editor corrupting the original, you can always do it outside. 'sed' is wonderful for such jobs.

Usable editors have undo, and better ones have interactive RE-replace that lets you watch the change made step by step. And a history of the RE-strings you tried before. And parenthesis highlighting of the RE while you type it.

No. But if an editing job gets hairy, at some point it simply doesn't make sense any more to fight yet another inferior editor's peculiarities.

I don't know (yet), because that hasn't come up often enough to bother looking it up. If that ever really matters, I'll probably just move the editing job to the proper tool instead.

So I don't follow the Unix principle of "One task One tool" really strictly, but I'll return to it eventually. In the case at hand, that translates into: _one_ full-blown text editor is, ultimately, all you need. If only because it's a waste of brain capacity to memorize a dozen editors' key combinations and specialties.

Happens often enough. But if that's going to be worth it, that code has to be in the real editor, too, either before or after the transmission. So it's just a question of making the sequence edit-copy-paste-send instead of copy-paste-edit-send-copy-paste.

If the editor in whatever application doesn't hack it, that's one option. Another is to get whatever application to use emacs-client as its editor.