Editor recommendation

Hi Robert,

On 8/29/2013 3:05 PM, Robert Wessel wrote:
> On Thu, 29 Aug 2013 14:25:10 -0700, Don Y <this@isnotme.com> wrote:

>> 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.  <shamed pause>  So, how do I get the
>> DVD to play, now?")
>>
>> (sigh)  Can't win...
>
> ITYM, "The person who bought the TV (or receiver) didn't get one with
> enough A/V inputs".

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!  :->

Hi Dimiter,

On 8/29/2013 3:44 PM, dp wrote:
> On Friday, August 30, 2013 12:25:10 AM UTC+3, Don Y wrote:

>> [I sent you a msg a week or two ago... perhaps wrong email addr?]
>
> 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.

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

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

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
      <Figure XX: (continued on Page YY)>
with
      <Illustration XX: <italic>(see page YY)<\italic>>
or, should I do this with a keystroke macro inside a text editor?

> 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 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!

>>>> Hope Lucy isn't reading over your shoulder!!  :>
>>>
>>> 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).
>>
>> Isn't that a prerequisite, when living with an engineer?  :>
>
> 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 .

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

>> 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!  :-/
>
> 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 .

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

>> ("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.  <shamed pause>  So, how do I get the
>> DVD to play, now?")
>
> Most of the time when I make that sort of changes Lucy is
> alert and watching me,

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.

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

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

On 30.08.2013 03:02, Don Y wrote:
> 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
>       <Figure XX: (continued on Page YY)>
> with
>       <Illustration XX: <italic>(see page YY)<\italic>>
> or, should I do this with a keystroke macro inside a text editor?

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/<Figure \([^:]*\): continued on Page \([^)]\)>/<Illustration \1: 
<italic>(see page \2)<\italic>>/g

(all in one line, not really tested)

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

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 <Alt>-mark the column (i.e. drag the mouse while holding 
<Alt>, 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 $ <Ret>.

On 08/29/13 16:23, dp wrote:

>
> So the rest of the world slowly catches up I gather :-)?

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:

http://nedit.gmxhome.de/history.html

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

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

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

> 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

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

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

Chris

On Wed, 28 Aug 2013 21:22:59 -0500, Les Cargill
<lcargill99@comcast.com> wrote:

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

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

George

On Wed, 28 Aug 2013 22:46:35 +0200, David Brown
<david.brown@removethis.hesbynett.no> wrote:


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

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

Hi Hans-Bernhard,

On 8/30/2013 4:22 AM, Hans-Bernhard Br�ker wrote:
> On 30.08.2013 03:02, Don Y wrote:
>> 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
>>       <Figure XX: (continued on Page YY)>
>> with
>>       <Illustration XX: <italic>(see page YY)<\italic>>
>> or, should I do this with a keystroke macro inside a text editor?
>
> Neither.  You should have an editor that supports search-and-replace via
> regular expressions, and use that.

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

> E.g., and just because this
> particular editor hasn't been mentioned yet: in plain old vi, that would be
>
> :1,$s/<Figure \([^:]*\): continued on Page \([^)]\)>/<Illustration \1:
> <italic>(see page \2)<\italic>>/g
>
> (all in one line, not really tested)

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 <foo> at file offset <x>; replacing with <bar>"
(i.e., used to let you preview the actions that the code will
ultimately take) with one that writes <bar> 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 "<<italic>" instead of "<italic>" -- or, failed
to double the '>' on the end (i.e., akin to mismatched parens), etc.
Then, find yourself trying to come up with an RE that will find those
superfluous delimiters and fix them, etc.

And, there are problems that just don't lend themselves to an RE
sort of solution (e.g., transposing a matrix is easy to do with
keystroke macros or "a piece of code" -- considerably harder
"out of the gate" with a set of RE's!)

>> 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.
>
> 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 <Alt>-mark the column (i.e. drag the mouse while holding
> <Alt>, 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

Do you *only* deal with "programmer's editors"?  E.g., when I type
code fragments into a FrameMaker document (to formally document
something that I've created), *where* the cursor ends up if I type
<down_arrow> depends on my position in the current line and
the "font" used on that line and the line that follows.  The
idea of a "rectangular fill/copy/delete" simply doesn't apply
(note that this isn't just the proportional/fixed width font
issue but also the *sizes* of the typefaces comes into play!)

What's the keystroke sequence to cut/paste/fill a rectangular region
while composing in Thunderbird?  (or, do you never share code
fragments with colleagues electronically)

Should I keep Emacs open in a second window, type whatever "code"
I want in that window (using the tools emacs makes available to
me) and then *paste* it into whatever application I happen to
be *actively* working in at the time?

Over the years, I've found that the more "features" you rely on,
the more you *need* those features in your normal workflow.

E.g., imagine how you would work if you could only do one or two
builds a day (because the toolchain was slow or some equipment
needed to do it was a scarce resource).  I have colleagues who
have become so accustomed to quick edit/compile/debug cycles
that they don't even NOTICE "foo = bar / 0.0;" but wait, instead,
for the compiler to *tell* them about it!  Then, correct *just*
that problem and wait for the compiler to tell them what else
*might* be wrong...

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

On Friday, August 30, 2013 4:29:59 PM UTC+3, chris wrote:
> On 08/29/13 16:23, dp wrote:
>  ....
> >
> > 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.).
> 
> 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 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.... :-) .

> 
> > 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
> 
> Well, that's the problem with being a genius ahead of the
> curve; No one understands you .
> 
> (Sorry, couldn't resist :-)...
> 
> Chris

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

Dimiter

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

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

On 08/30/13 17:05, George Neuner wrote:

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

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

On 31.08.2013 00:00, Don Y wrote:
> On 8/30/2013 4:22 AM, Hans-Bernhard Br�ker wrote:

>> On 30.08.2013 03:02, Don Y wrote:

>>> 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
>>>       <Figure XX: (continued on Page YY)>
>>> with
>>>       <Illustration XX: <italic>(see page YY)<\italic>>
>>> or, should I do this with a keystroke macro inside a text editor?
>>
>> Neither.  You should have an editor that supports search-and-replace via
>> regular expressions, and use that.

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

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.

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

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.

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

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.

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

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

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

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

>> :1,$s/<Figure \([^:]*\): continued on Page \([^)]\)>/<Illustration \1:
>> <italic>(see page \2)<\italic>>/g

>> (all in one line, not really tested)

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

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.

> Do you *only* deal with "programmer's editors"?

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.

> What's the keystroke sequence to cut/paste/fill a rectangular region
> while composing in Thunderbird?

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.

> (or, do you never share code fragments with colleagues
> electronically)

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.

> Should I keep Emacs open in a second window, type whatever "code"
> I want in that window (using the tools emacs makes available to
> me) and then *paste* it into whatever application I happen to
> be *actively* working in at the time?

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.