Re: Editor survival [Was: Recommended editor for novice programmers?]

2017-09-09 Thread Zenaan Harkness
On Fri, Sep 08, 2017 at 04:17:50PM -0500, David Wright wrote:
> On Fri 08 Sep 2017 at 03:19:49 (+0100), Nick Boyce wrote:
> > You're absolutely right.  I have sat next to seasoned vi users watching in 
> > awe as their fingers flew entering weird totally non-intuitive commands (to 
> > me) and achieving great edits in next to no time.  Other colleagues lived 
> > inside emacs all day long, using it as a sort of OS with an editor 
> > attached.  I used other editors to achieve the same goals, quite possibly 
> > taking more real time than the vi guys.  Each to their own.
> 
> > Agreed .. or whatever terminal (emulation) you're actually using - in my 
> > case very often a real VT220/320/420, attached to a VMS, then TELNETed to a 
> > Un*x, where the available /etc/termcap|terminfo may or may not have been 
> > well crafted back at the factory.  Sometimes an ICL mainframe VDU connected 
> > via an obscure 3rd-party emulation converter box to a DEC machine.  
> > Latterly it would be some 3rd-party terminal emulator on Windows 3.1/95. I 
> > still say ugh, though it may well not be vi's fault.  The fact is that 
> > miraculously 'joe' seemed to be much more resilient and usable in these 
> > circumstances.  As did emacs .. if you could afford to wait.  I like an 
> > editor to appear within 1 second of me calling it (which rules out most GUI 
> > editors).
> 
> Just to point out there's a connection between these two paragraphs.
> You shouldn't have to wait even a second for emacs to start if you
> "live" in it, ie use the server-start command and keep a running
> instance open. Then, instead of emacs, invoking emacsclient from the
> shell and applications will be virtually instant.

Java has the same "sort of" thing in Nailgun - "insanely fast Java" -
the same concept, but for Java, where the ng client just sends a
message to a running Java instance (running ng server), to make it
easy to launch or do whatever you want in Java - I assume (but don't
know) that Eclipse has something like this built in (just like
Firefox).

Cheers,



Re: Editor survival [Was: Recommended editor for novice programmers?]

2017-09-08 Thread David Wright
On Fri 08 Sep 2017 at 03:19:49 (+0100), Nick Boyce wrote:
> You're absolutely right.  I have sat next to seasoned vi users watching in 
> awe as their fingers flew entering weird totally non-intuitive commands (to 
> me) and achieving great edits in next to no time.  Other colleagues lived 
> inside emacs all day long, using it as a sort of OS with an editor attached.  
> I used other editors to achieve the same goals, quite possibly taking more 
> real time than the vi guys.  Each to their own.

> Agreed .. or whatever terminal (emulation) you're actually using - in my case 
> very often a real VT220/320/420, attached to a VMS, then TELNETed to a Un*x, 
> where the available /etc/termcap|terminfo may or may not have been well 
> crafted back at the factory.  Sometimes an ICL mainframe VDU connected via an 
> obscure 3rd-party emulation converter box to a DEC machine.  Latterly it 
> would be some 3rd-party terminal emulator on Windows 3.1/95. I still say ugh, 
> though it may well not be vi's fault.  The fact is that miraculously 'joe' 
> seemed to be much more resilient and usable in these circumstances.  As did 
> emacs .. if you could afford to wait.  I like an editor to appear within 1 
> second of me calling it (which rules out most GUI editors).

Just to point out there's a connection between these two paragraphs.
You shouldn't have to wait even a second for emacs to start if you
"live" in it, ie use the server-start command and keep a running
instance open. Then, instead of emacs, invoking emacsclient from the
shell and applications will be virtually instant.

Cheers,
David.



Re: Editor survival [Was: Recommended editor for novice programmers?]

2017-09-08 Thread Jude DaShiell
If you are torn between emacs and vi, it's probably because you haven't 
run eval-mode inside emacs.


On Fri, 8 Sep 2017, Nick Boyce wrote:


Date: Thu, 7 Sep 2017 22:19:49
From: Nick Boyce <n...@steelyglint.org>
To: debian-user@lists.debian.org
Subject: Re: Editor survival [Was: Recommended editor for novice programmers?]
Resent-Date: Fri,  8 Sep 2017 02:18:59 + (UTC)
Resent-From: debian-user@lists.debian.org

On Wed, 6 Sep 2017 16:08:15 +1000
Erik Christiansen <dva...@internode.on.net> wrote:


On 06.09.17 05:31, Nick Boyce wrote:

[...]

[Joe is] one of the first things I install on any Linux
or *BSD system.


In my decades of leading software teams, one thing I did not do is ask
"What editor do you use?", even in employment interviews. In my
experience, a programmer is most productive using the editor with which
he's most proficient.


You're absolutely right.  I have sat next to seasoned vi users watching in awe 
as their fingers flew entering weird totally non-intuitive commands (to me) and 
achieving great edits in next to no time.  Other colleagues lived inside emacs 
all day long, using it as a sort of OS with an editor attached.  I used other 
editors to achieve the same goals, quite possibly taking more real time than 
the vi guys.  Each to their own.

It's interesting how programmers who arrived at Unix via VMS, and programmers 
who came from the mainframe world, often have correspondingly different 
software tastes.


... and vi's power makes light work of many tasks but it's
as user-friendly as a cornered rat


On the three occasions I've had to extract a marsupial possum from our
chimney (they're like a cat on steroids), I've armed myself with thick
leather gloves and grim determination.


:)


For vim, a cheat-sheet suffices,
and :help " or google do explain.


On DEC Ultrix, Digital Unix (OSF/1 .. Tru64) and on HPUX there is no vim, and 
the DEC/HP salesmen have delivered no cheet sheets with the beasts, and in vi 
the F1 key does not summon any help, and from insert mode there is no help 
command, and in 1995 google has not yet been invented.  The unskilled novice 
smokes a cigarette (it's 1995) to calm down, and gravitates to a different 
editor 


... a whole bunch of weird character sequences get entered
instead of cursor control, which you then spend the next 10 minutes
removing again.  Ugh.


That's an xterm error, as the arrows simply produce motion even in
Insert-mode, if that's properly set up.


Agreed .. or whatever terminal (emulation) you're actually using - in my case 
very often a real VT220/320/420, attached to a VMS, then TELNETed to a Un*x, 
where the available /etc/termcap|terminfo may or may not have been well crafted 
back at the factory.  Sometimes an ICL mainframe VDU connected via an obscure 
3rd-party emulation converter box to a DEC machine.  Latterly it would be some 
3rd-party terminal emulator on Windows 3.1/95. I still say ugh, though it may 
well not be vi's fault.  The fact is that miraculously 'joe' seemed to be much 
more resilient and usable in these circumstances.  As did emacs .. if you could 
afford to wait.  I like an editor to appear within 1 second of me calling it 
(which rules out most GUI editors).


... unless you also add something like:

" These days I expect to be out of insert mode, after a vertical move:
inoremap  ^[
inoremap  ^[


That's great to have - thanks for that (seriously), along with the other .vimrc 
tweaks you gave.  I realise much can be improved by tweaking .vimrc, as it can 
be with .muttrc, .bashrc and the like.  This is why power users often carry 
their own personal versions of these rc files with them wherever they roam ... 
and old greybeards sometimes dispense rc nuggets to neophytes at moments of 
crisis.

Cheers
Nick



--



Re: Editor survival [Was: Recommended editor for novice programmers?]

2017-09-07 Thread Nick Boyce
On Wed, 6 Sep 2017 16:08:15 +1000
Erik Christiansen  wrote:

> On 06.09.17 05:31, Nick Boyce wrote:
[...]
> > [Joe is] one of the first things I install on any Linux
> > or *BSD system.
> 
> In my decades of leading software teams, one thing I did not do is ask
> "What editor do you use?", even in employment interviews. In my
> experience, a programmer is most productive using the editor with which
> he's most proficient. 

You're absolutely right.  I have sat next to seasoned vi users watching in awe 
as their fingers flew entering weird totally non-intuitive commands (to me) and 
achieving great edits in next to no time.  Other colleagues lived inside emacs 
all day long, using it as a sort of OS with an editor attached.  I used other 
editors to achieve the same goals, quite possibly taking more real time than 
the vi guys.  Each to their own.

It's interesting how programmers who arrived at Unix via VMS, and programmers 
who came from the mainframe world, often have correspondingly different 
software tastes.

> > ... and vi's power makes light work of many tasks but it's
> > as user-friendly as a cornered rat
> 
> On the three occasions I've had to extract a marsupial possum from our
> chimney (they're like a cat on steroids), I've armed myself with thick
> leather gloves and grim determination. 

:)

> For vim, a cheat-sheet suffices,
> and :help " or google do explain.

On DEC Ultrix, Digital Unix (OSF/1 .. Tru64) and on HPUX there is no vim, and 
the DEC/HP salesmen have delivered no cheet sheets with the beasts, and in vi 
the F1 key does not summon any help, and from insert mode there is no help 
command, and in 1995 google has not yet been invented.  The unskilled novice 
smokes a cigarette (it's 1995) to calm down, and gravitates to a different 
editor 

> > ... a whole bunch of weird character sequences get entered
> > instead of cursor control, which you then spend the next 10 minutes
> > removing again.  Ugh.
> 
> That's an xterm error, as the arrows simply produce motion even in
> Insert-mode, if that's properly set up.

Agreed .. or whatever terminal (emulation) you're actually using - in my case 
very often a real VT220/320/420, attached to a VMS, then TELNETed to a Un*x, 
where the available /etc/termcap|terminfo may or may not have been well crafted 
back at the factory.  Sometimes an ICL mainframe VDU connected via an obscure 
3rd-party emulation converter box to a DEC machine.  Latterly it would be some 
3rd-party terminal emulator on Windows 3.1/95. I still say ugh, though it may 
well not be vi's fault.  The fact is that miraculously 'joe' seemed to be much 
more resilient and usable in these circumstances.  As did emacs .. if you could 
afford to wait.  I like an editor to appear within 1 second of me calling it 
(which rules out most GUI editors).

> ... unless you also add something like:
> 
> " These days I expect to be out of insert mode, after a vertical move:
> inoremap  ^[
> inoremap  ^[

That's great to have - thanks for that (seriously), along with the other .vimrc 
tweaks you gave.  I realise much can be improved by tweaking .vimrc, as it can 
be with .muttrc, .bashrc and the like.  This is why power users often carry 
their own personal versions of these rc files with them wherever they roam ... 
and old greybeards sometimes dispense rc nuggets to neophytes at moments of 
crisis.

Cheers
Nick
-- 
Never FDISK after midnight.



Editor survival [Was: Recommended editor for novice programmers?]

2017-09-06 Thread Erik Christiansen
On 06.09.17 05:31, Nick Boyce wrote:
> I don't like to confess to my august and more sophisticated colleagues
> here how much code I've written using joe - albeit in the simpler
> languages (a variety of Bash scripts, Perl, C, HTML and similar).
> There is some syntax highlighting, but no code-completion or compiler
> integration or the other trinkets that come with proper IDEs.  It is
> however, small, fast and reliable - it hasn't had a new feature in
> *years* because for it's intended use-cases it's *feature-complete* !
> 
> It's one of the first things I install on any Linux or *BSD system.

In my decades of leading software teams, one thing I did not do is ask
"What editor do you use?", even in employment interviews. In my
experience, a programmer is most productive using the editor with which
he's most proficient. End of story.

> ... and vi's power makes light work of many tasks but it's
> as user-friendly as a cornered rat ... novices usually remember their
> first time trying to find out how to exit with a genuine shudder.

On the three occasions I've had to extract a marsupial possum from our
chimney (they're like a cat on steroids), I've armed myself with thick
leather gloves and grim determination. For vim, a cheat-sheet suffices,
and :help " or google do explain.

> A frequent vi moment for those familiar with modeless editors is to
> enter 'insert mode' (when you figure out how), type some text, and
> then try to use the arrow keys to move to a different line without
> remembering to first exit insert mode - depending on vi version,
> terminal emulation, Un*x flavour, phase of the Moon etc., the effect
> of this is that a whole bunch of weird character sequences get entered
> instead of cursor control, which you then spend the next 10 minutes
> removing again.  Ugh.

That's an xterm error, as the arrows simply produce motion even in
Insert-mode, if that's properly set up.

But Vim's Insert-mode/Normal-mode modality still requires user
awareness, either through memory or looking at the status line, with a
"set showmode" in ~/.vimrc - unless you also add something like:

" These days I expect to be out of insert mode, after a vertical move:
inoremap  ^[
inoremap  ^[

(The ^[ is , entered as  in insert mode.)

Now the Insert-mode exit is automated, so long as you use the arrow keys
for moves. (If you use hjkl for speed, then you're not a novice, by
definition.) I've left  and , so I stay in Insert-mode
while on the line. It works for me, but you could remap them too.

To avoid the need to glance to the bottom of the window to check mode, I
also add:

" Cursor Appearance and behaviour:
" (Insert_Mode == Green, Normal_Mode == Red)
if  =~ "xterm"
   let _SI = "\]12;yellow\x7"
   let _EI = "\]12;green\x7"
endif

So the cursor itself is a reminder. (I haven't yet found a way to have
it make coffee though, so that I always have my eyes open.)
(Colours chosen for yellow text on darkslategrey background, set in the
xterm. YTMV)

> (Yes, I do use more sophisticated GUI IDEs for anything serious, but
> that's not what OP asked for.  Also, I do realise vim is much better
> than vi.)

Even without integration in an editor, in *nix you can Control-Z out to
the command line, run make, and fg back in. I too would use whatever
editor my fingers remember.

Erik