Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #63468 > unrolled thread

Merging .h and .c source files

Back to article view | Back to comp.lang.c

Contents

  Merging .h and .c source files David Kleinecke <dkleinecke@gmail.com> - 2015-06-17 16:27 -0700
    Re: Merging .h and .c source files Richard Heathfield <rjh@cpax.org.uk> - 2015-06-18 00:35 +0100
      Re: Merging .h and .c source files Reinhardt Behm <rbehm@hushmail.com> - 2015-06-18 12:51 +0800
        Re: Merging .h and .c source files Michael Sorn <invalid@example.com> - 2015-06-18 13:27 +0000
          Re: Merging .h and .c source files David Brown <david.brown@hesbynett.no> - 2015-06-18 15:38 +0200
          Re: Merging .h and .c source files gazelle@shell.xmission.com (Kenny McCormack) - 2015-06-18 13:42 +0000
          Re: Merging .h and .c source files Reinhardt Behm <rbehm@hushmail.com> - 2015-06-18 22:47 +0800
      Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-18 06:21 -0700
      Re: Merging .h and .c source files "Morten W. Petersen" <morphex@gmail.com> - 2015-06-18 16:07 +0200
        Re: Merging .h and .c source files Richard Heathfield <rjh@cpax.org.uk> - 2015-06-18 15:29 +0100
          Re: Merging .h and .c source files "Morten W. Petersen" <morphex@gmail.com> - 2015-06-18 16:48 +0200
            Re: Merging .h and .c source files raltbos@xs4all.nl (Richard Bos) - 2015-06-18 21:52 +0000
              Re: Merging .h and .c source files "Morten W. Petersen" <morphex@gmail.com> - 2015-06-19 03:57 +0200
                Re: Merging .h and .c source files raltbos@xs4all.nl (Richard Bos) - 2015-06-19 10:02 +0000
                  Re: Merging .h and .c source files Richard Heathfield <rjh@cpax.org.uk> - 2015-06-19 11:24 +0100
                    Re: Merging .h and .c source files Bartc <bc@freeuk.com> - 2015-06-19 12:10 +0100
                      Re: Merging .h and .c source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-19 13:24 +0100
                        Re: Merging .h and .c source files Bartc <bc@freeuk.com> - 2015-06-19 14:09 +0100
                          Re: Merging .h and .c source files "Morten W. Petersen" <morphex@gmail.com> - 2015-06-19 15:30 +0200
                            Re: Merging .h and .c source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-19 17:34 +0100
                          Re: Merging .h and .c source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-19 17:06 +0100
                            Re: Merging .h and .c source files David Kleinecke <dkleinecke@gmail.com> - 2015-06-19 09:40 -0700
                              Re: Merging .h and .c source files Bartc <bc@freeuk.com> - 2015-06-19 18:12 +0100
                              Re: Merging .h and .c source files Keith Thompson <kst-u@mib.org> - 2015-06-19 11:25 -0700
                                Re: Merging .h and .c source files David Kleinecke <dkleinecke@gmail.com> - 2015-06-20 07:31 -0700
                                  Re: Merging .h and .c source files glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-20 17:07 +0000
                                    Re: Merging .h and .c source files "Charles Richmond" <numerist@aquaporin4.com> - 2015-06-23 17:44 -0500
                                      Re: Merging .h and .c source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-24 01:48 +0100
                                  Re: Merging .h and .c source files Keith Thompson <kst-u@mib.org> - 2015-06-20 12:37 -0700
                              Re: Merging .h and .c source files Robert Wessel <robertwessel2@yahoo.com> - 2015-06-19 22:04 -0500
                                Re: Merging .h and .c source files Les Cargill <lcargill99@comcast.com> - 2015-06-19 22:36 -0500
                                  Re: Merging .h and .c source files Robert Wessel <robertwessel2@yahoo.com> - 2015-06-20 01:23 -0500
                            Re: Merging .h and .c source files Bartc <bc@freeuk.com> - 2015-06-19 17:54 +0100
                              Re: Merging .h and .c source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-19 19:45 +0100
                            Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-21 07:19 -0700
                    Re: Merging .h and .c source files Ian Collins <ian-news@hotmail.com> - 2015-06-20 08:52 +1200
                    Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 18:44 -0700
          Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-18 08:26 -0700
            Re: Merging .h and .c source files Richard Heathfield <rjh@cpax.org.uk> - 2015-06-18 16:41 +0100
              Re: Merging .h and .c source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-18 17:13 +0100
                Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-18 09:26 -0700
                  Re: Merging .h and .c source files Richard Heathfield <rjh@cpax.org.uk> - 2015-06-18 18:03 +0100
                    Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 18:33 -0700
                  Re: Merging .h and .c source files Keith Thompson <kst-u@mib.org> - 2015-06-18 10:28 -0700
                  Re: Merging .h and .c source files gazelle@shell.xmission.com (Kenny McCormack) - 2015-06-18 17:28 +0000
                  Re: Merging .h and .c source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-18 21:07 +0100
                    Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-18 15:04 -0700
                      Re: Merging .h and .c source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-19 00:38 +0100
                        Re: Merging .h and .c source files Bartc <bc@freeuk.com> - 2015-06-19 01:00 +0100
                          Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-19 00:10 -0700
                          Re: Merging .h and .c source files mark.bluemel@gmail.com - 2015-06-19 00:56 -0700
                            Re: Merging .h and .c source files Richard Heathfield <rjh@cpax.org.uk> - 2015-06-19 09:18 +0100
                  Re: Merging .h and .c source files John Bode <jfbode1029@gmail.com> - 2015-06-24 08:43 -0700
                    Re: Merging .h and .c source files Keith Thompson <kst-u@mib.org> - 2015-06-24 11:15 -0700
                    Re: Merging .h and .c source files Richard Heathfield <rjh@cpax.org.uk> - 2015-06-24 19:23 +0100
                      Re: Merging .h and .c source files James Kuyper <jameskuyper@verizon.net> - 2015-06-24 14:40 -0400
                        Re: Merging .h and .c source files Richard Heathfield <rjh@cpax.org.uk> - 2015-06-24 19:45 +0100
                Re: Merging .h and .c source files Keith Thompson <kst-u@mib.org> - 2015-06-18 10:19 -0700
                  Re: Merging .h and .c source files gwowen <gwowen@gmail.com> - 2015-06-19 05:29 -0700
                    Re: Merging .h and .c source files Keith Thompson <kst-u@mib.org> - 2015-06-19 08:26 -0700
              Re: Merging .h and .c source files "Morten W. Petersen" <morphex@gmail.com> - 2015-06-19 04:08 +0200
              Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 17:53 -0700
                Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-10 18:40 -0700
                  Re: Merging .h and .c source files Udyant Wig <udyantw@gmail.com> - 2015-07-11 10:19 +0530
                    Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 15:59 -0700
                      Re: Merging .h and .c source files raltbos@xs4all.nl (Richard Bos) - 2015-07-13 18:50 +0000
                        Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 08:37 -0700
                          Re: Merging .h and .c source files raltbos@xs4all.nl (Richard Bos) - 2015-07-19 21:30 +0000
                            Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 09:46 -0700
                    Re: Merging .h and .c source files Richard Damon <Richard@Damon-Family.org> - 2015-07-11 20:08 -0400
                      Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 18:26 -0700
                      Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 08:38 -0700
                  Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 15:57 -0700
                    Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 16:30 -0700
                      Re: Merging .h and .c source files Ian Collins <ian-news@hotmail.com> - 2015-07-12 15:51 +1200
                        Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-12 06:03 -0700
                          Re: Merging .h and .c source files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 21:36 +0100
                            Re: Merging .h and .c source files gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-12 21:27 +0000
                          Re: Merging .h and .c source files Ian Collins <ian-news@hotmail.com> - 2015-07-13 10:00 +1200
                            Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-13 04:16 -0700
                              Re: Merging .h and .c source files Bartc <bc@freeuk.com> - 2015-07-13 12:47 +0100
                              Re: Merging .h and .c source files Ian Collins <ian-news@hotmail.com> - 2015-07-14 08:32 +1200
                              Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 11:33 -0700
                      Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 11:24 -0700
                        Re: Merging .h and .c source files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-15 12:29 -0700
                          Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 09:50 -0700
                    Re: Merging .h and .c source files raltbos@xs4all.nl (Richard Bos) - 2015-07-13 18:52 +0000
                      Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 08:52 -0700
                        Re: Merging .h and .c source files David Kleinecke <dkleinecke@gmail.com> - 2015-07-15 20:33 -0700
                          Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 09:53 -0700
          Re: Merging .h and .c source files Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 17:47 -0700
      Re: Merging .h and .c source files David Kleinecke <dkleinecke@gmail.com> - 2015-06-18 11:18 -0700
        Re: Merging .h and .c source files David Kleinecke <dkleinecke@gmail.com> - 2015-06-18 11:34 -0700
          Re: Merging .h and .c source files Morris Dovey <mrdovey@iedu.com> - 2015-06-18 15:59 -0500
        Re: Merging .h and .c source files Philipp Klaus Krause <pkk@spth.de> - 2015-06-19 12:46 +0200
      Re: Merging .h and .c source files Bartc <bc@freeuk.com> - 2015-06-18 19:23 +0100
    Re: Merging .h and .c source files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-06-18 07:48 -0600
    Re: Merging .h and .c source files Bartc <bc@freeuk.com> - 2015-06-18 18:27 +0100

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#63531

On Thursday, June 18, 2015 at 5:14:00 PM UTC+1, Ben Bacarisse wrote:
>
> I seem to remember there was time when the arrow keys worked (on almost
> all terminals) with vi, let alone vim (or any of the newer variants).
> Did they ever stop working, or is my memory rosy?
> 
vi is designed for situation where it's too much strain on the processor to
update a whole 25 x 80 character screen.
So when it fires up, instead of getting some text you can read, and a nice flashing
cursor you can move up and down with the arrow keys to navigate it, it gives
you what superficially looks like an edit buffer, but is in fact just a read-only
window onto the text. You then type idiosyncratic commands into the line buffer
below to edit it. So to insert a work it's colon i or something like that.
If you hardly ever use it, it's very hard to make it do what you want, and you
hardly ever use it, because most people aren't going to write their novel over
a 100 baud connection. You might have to update a five line config file over
such a connection, however.
 

[toc] | [prev] | [next] | [standalone]

#63532

On 18/06/15 17:26, Malcolm McLean wrote:
> On Thursday, June 18, 2015 at 5:14:00 PM UTC+1, Ben Bacarisse wrote:
>>
>> I seem to remember there was time when the arrow keys worked (on almost
>> all terminals) with vi, let alone vim (or any of the newer variants).
>> Did they ever stop working, or is my memory rosy?
>>
> vi is designed for situation where it's too much strain on the processor to
> update a whole 25 x 80 character screen.

Despite that, it also does excellent work on modern machines.

> So when it fires up, instead of getting some text you can read, and a nice flashing
> cursor you can move up and down with the arrow keys to navigate it, it gives
> you what superficially looks like an edit buffer, but is in fact just a read-only
> window onto the text.

Well, it's read-only until you go into write mode, yes. That's actually 
quite handy, believe it or not.

> You then type idiosyncratic commands into the line buffer
> below to edit it. So to insert a work it's colon i or something like that.

It's just i (for "insert"), which is one of a number of commands you can 
use to get into edit mode.

> If you hardly ever use it, it's very hard to make it do what you want,

I would have to agree with this, but of course it's true of emacs as 
well. About the only thing I ever require of emacs is to be able to 
submit some Usenet text to its psychiatrist (because there are times 
when the Usenaut in question needs to consult a psychiatrist, and I'm 
always willing to pick up the referral fee). But even this use is so 
rare that I generally take a few seconds to figure where in the menu 
structure the poor dear can be found.

> and you
> hardly ever use it, because most people aren't going to write their novel over
> a 100 baud connection. You might have to update a five line config file over
> such a connection, however.

Like any good editor, if you use it a lot (which I do), you get used to 
it. It is in fact easy to use. It's just hard to learn. Like emacs.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#65215

Richard Heathfield <rjh@cpax.org.uk> writes:

> [.. vi/vim, emacs ..]
>
> Like any good editor, if you use it a lot (which I do), you get used
> to it.  It is in fact easy to use.  It's just hard to learn.  Like emacs.

This doesn't match my experience.  I started using emacs after
what was literally a five minute (or shorter) introduction.  I
never sat down with the intention of learning emacs, just picked
things up as I went along, making a lot of use of the built-in
help (mostly command search).  Getting up to a reasonable command
set did take a while, but it wasn't hard at all, in fact I didn't
even notice it happening - at some point I started listing the
various commands that I knew and used all the time and was
shocked to find that the number was way over 50 (I started with
just 10 or 12).  If there is a single factor that explains the
difference in my reactions to vi/vim and emacs, I would guess
it is having a command reference readily and easily available
within the editor itself (which vi did not have at the time,
and so I am still a novice at vi and its later versions).

[toc] | [prev] | [next] | [standalone]

#63537

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Thursday, June 18, 2015 at 5:14:00 PM UTC+1, Ben Bacarisse wrote:
>> I seem to remember there was time when the arrow keys worked (on almost
>> all terminals) with vi, let alone vim (or any of the newer variants).
>> Did they ever stop working, or is my memory rosy?
>> 
> vi is designed for situation where it's too much strain on the processor to
> update a whole 25 x 80 character screen.
> So when it fires up, instead of getting some text you can read, and a nice flashing
> cursor you can move up and down with the arrow keys to navigate it, it gives
> you what superficially looks like an edit buffer, but is in fact just a read-only
> window onto the text. You then type idiosyncratic commands into the line buffer
> below to edit it. So to insert a work it's colon i or something like that.
> If you hardly ever use it, it's very hard to make it do what you want, and you
> hardly ever use it, because most people aren't going to write their novel over
> a 100 baud connection. You might have to update a five line config file over
> such a connection, however.

It almost sounds like you're describing ex, which is vi's line-oriented
mode.  That's not the default behavior.

Vi, unlike emacs, uses modes.  Well, they both have numerous modes, but
in emacs you can start typing text and it will be inserted, whereas in
vi you have to go into insert mode (by typing "i", not ":i") to be able
to modify anything.

One advantage of vi's approach is that in command mode, all the letter
keys are available for use as commands (e.g., 'w' to move forward one
word), whereas emacs needs to use control sequences (M-w or ESC-w).

I don't think that either vi or emacs is particularly optimized for slow
connections.  vi's ex mode is, but it's rarely used.  Both editors
continuously show you the current state of the buffer.  In both editors,
if you insert characters at the beginning of a line, the rest of the
line is shifted over on each keystroke.

I am *not* saying that you should use one or the other, just correcting
some inaccuracies in your description.

(I mostly use vim myself, but I'm typing this message in emacs.)

(BTW, the very first thing I do when I set up a new system is disable
the "nice" flashing cursor.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#63538

In article <ba1fcec1-7e80-40d3-a9d8-6e8cea465430@googlegroups.com>,
Malcolm McLean  <malcolm.mclean5@btinternet.com> wrote:
>On Thursday, June 18, 2015 at 5:14:00 PM UTC+1, Ben Bacarisse wrote:
>>
>> I seem to remember there was time when the arrow keys worked (on almost
>> all terminals) with vi, let alone vim (or any of the newer variants).
>> Did they ever stop working, or is my memory rosy?
>> 
>vi is designed for situation where it's too much strain on the processor
>to update a whole 25 x 80 character screen.  So when it fires up, instead
>of getting some text you can read, and a nice flashing cursor you can move
>up and down with the arrow keys to navigate it, it gives you what
>superficially looks like an edit buffer, but is in fact just a read-only
>window onto the text. You then type idiosyncratic commands into the line
>buffer below to edit it. So to insert a work it's colon i or something
>like that.  If you hardly ever use it, it's very hard to make it do what
>you want, and you hardly ever use it, because most people aren't going to
>write their novel over a 100 baud connection. You might have to update a
>five line config file over such a connection, however.
> 

You're out of your mind.

Some of what you wrote above was true when I first learned vi (in 1984).
None of it is true today (and by "today", I mean, basically, for at least
the past 20 years).

Also, some of what you wrote is true for some versions of TECO (c. 1980).

You should check out a recent post to comp.editors, which gives a pointer
to the currently maintained version of TECO - which includes that form of
editing (as described above).  Ah, does it bring back memories...

-- 
"If our country is going broke, let it be from 
feeding the poor and caring for the elderly. 
And not from pampering the rich and fighting 
wars for them."

    --Living Blue in a Red State--

[toc] | [prev] | [next] | [standalone]

#63550

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Thursday, June 18, 2015 at 5:14:00 PM UTC+1, Ben Bacarisse wrote:
>>
>> I seem to remember there was time when the arrow keys worked (on almost
>> all terminals) with vi, let alone vim (or any of the newer variants).
>> Did they ever stop working, or is my memory rosy?
>> 
> vi is designed for situation where it's too much strain on the processor to
> update a whole 25 x 80 character screen.

All editors of the period operated under the same restrictions.
Supporting the arrow keys does not require updating the whole screen.

> So when it fires up, instead of getting some text you can read, and a
> nice flashing cursor you can move up and down with the arrow keys to
> navigate it, it gives you what superficially looks like an edit
> buffer, but is in fact just a read-only window onto the text.

As far as I can recall, vi (and friends) have had working arrow keys for
more than a quarter of a century.  What is is about the resource
limitations of the time that make you think arrows are are hard or that
they were not supported?

> You then
> type idiosyncratic commands into the line buffer below to edit it. So
> to insert a work it's colon i or something like that.  If you hardly
> ever use it, it's very hard to make it do what you want, and you
> hardly ever use it, because most people aren't going to write their
> novel over a 100 baud connection. You might have to update a five line
> config file over such a connection, however.

I've use full-screen editors at 110 baud (I've never seen 100 baud) with
working arrow keys.  What's the connection you are making between
resources (processor speed and connection speed) with arrow keys?

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#63561

On Thursday, June 18, 2015 at 9:07:22 PM UTC+1, Ben Bacarisse wrote:
> 
> All editors of the period operated under the same restrictions.
> Supporting the arrow keys does not require updating the whole screen.
> 
A lot of early terminals could send, but not delete. So if you
typed a character and wanted to echo it to the line buffer, that was
no problem. The server, on some massive 64K machine serving twenty
terminals, would send you the ascii character. However if you wanted to
delete, it had no way of doing that, other than sending you a whole
screen. So deleting a line could be painfully slow.
As for arrow keys, they were simply unrealistic. You'd have to send a 
whole screen for every cursor movement, and memory map the lot to
know where the arrow was supposed to go. 

[toc] | [prev] | [next] | [standalone]

#63564

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Thursday, June 18, 2015 at 9:07:22 PM UTC+1, Ben Bacarisse wrote:
>> 
>> All editors of the period operated under the same restrictions.
>> Supporting the arrow keys does not require updating the whole screen.
>> 
> A lot of early terminals could send, but not delete. So if you
> typed a character and wanted to echo it to the line buffer, that was
> no problem. The server, on some massive 64K machine serving twenty
> terminals, would send you the ascii character. However if you wanted to
> delete, it had no way of doing that, other than sending you a whole
> screen. So deleting a line could be painfully slow.
> As for arrow keys, they were simply unrealistic.

vi has always permitted screen movement commands so arrow keys are not
unrealistic -- so much so that vi has supported them since I can
remember (that's almost back to it's very start -- about 1979).  If it
did not support them pre-'79 it is not due to anything about processor
power, baud rate or terminal capabilities.

These historical ramblings can be an explanations of something that
was not the case.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#63565

On 19/06/2015 00:38, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
>> On Thursday, June 18, 2015 at 9:07:22 PM UTC+1, Ben Bacarisse wrote:
>>>
>>> All editors of the period operated under the same restrictions.
>>> Supporting the arrow keys does not require updating the whole screen.
>>>
>> A lot of early terminals could send, but not delete. So if you
>> typed a character and wanted to echo it to the line buffer, that was
>> no problem. The server, on some massive 64K machine serving twenty
>> terminals, would send you the ascii character. However if you wanted to
>> delete, it had no way of doing that, other than sending you a whole
>> screen. So deleting a line could be painfully slow.
>> As for arrow keys, they were simply unrealistic.
>
> vi has always permitted screen movement commands so arrow keys are not
> unrealistic -- so much so that vi has supported them since I can
> remember (that's almost back to it's very start -- about 1979).  If it
> did not support them pre-'79 it is not due to anything about processor
> power, baud rate or terminal capabilities.
>
> These historical ramblings can be an explanations of something that
> was not the case.

There were still some teleprinter terminals being used at the time that 
printed onto a paper roll. Text editors working on such a terminal were 
very restricted in what they could do.

Sometimes a VDU was substituted for the teletype, but if still running 
the same software that thought it was printing onto paper, then that 
wouldn't magically give it the ability to randomly update the screen. 
However you probably got a faster baud rate and you saved paper. And it 
was quieter.

Obviously this 'vi' did take advantage of what a video display could do, 
although even then, it would have to keep track of what was currently 
being displayed, as I'm not sure the contents of the internal display 
memory were accessible via the connection.

Also, unless the terminal had extra display memory that remembered what 
had scrolled off the top of the screen, then if the cursor kept moving 
upwards, preceding lines would have to be resent, at 5-10 lines per 
second, whatever the keyboard repeat rate was. That's not practical at 
110 baud or 10cps.

So maybe you used an advanced terminal, or had a fast connection, as 
well as the right software.


-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#63572

On Friday, June 19, 2015 at 1:01:00 AM UTC+1, Bart wrote:
>
> Obviously this 'vi' did take advantage of what a video display could do, 
> although even then, it would have to keep track of what was currently 
> being displayed, as I'm not sure the contents of the internal display 
> memory were accessible via the connection.
> 
> Also, unless the terminal had extra display memory that remembered what 
> had scrolled off the top of the screen, then if the cursor kept moving 
> upwards, preceding lines would have to be resent, at 5-10 lines per 
> second, whatever the keyboard repeat rate was. That's not practical at 
> 110 baud or 10cps.
> 
> So maybe you used an advanced terminal, or had a fast connection, as 
> well as the right software.
> 
The terminal was an electronic printer. It got ascii characters from
the server, and displayed them on a scrolling screen. So if the
program was producing slow scrolling output from printf(), it was fine.
But there was no way of scrolling down, or moving a cursor about the
screen, except by resending the entire screen. 
The terminals weren't memory mapped, but the server could of course 
keep a memory map of the terminal screen, which it would have to do
if you treated the screen as an addressable raster. But that took
2K of memory.

[toc] | [prev] | [next] | [standalone]

#63575

On Friday, 19 June 2015 01:01:00 UTC+1, Bart  wrote:

> There were still some teleprinter terminals being used at the time that 
> printed onto a paper roll. Text editors working on such a terminal were 
> very restricted in what they could do.

When I started programming in 1978, we had to queue for access to a room of such terminals. I was working on DECSystem-10 machines using the TOPS-10 O/S (writing COBOL-68!).

The choice of editors was TECO - see the first paragraph of <https://en.wikipedia.org/?title=Emacs#History> - or SOS (Son Of Stopgap!) - see <http://texteditors.org/cgi-bin/wiki.pl?STOPGAP>.

My word, how things have improved.

[toc] | [prev] | [next] | [standalone]

#63578

On 19/06/15 08:56, mark.bluemel@gmail.com wrote:
> On Friday, 19 June 2015 01:01:00 UTC+1, Bart  wrote:
>
>> There were still some teleprinter terminals being used at the time that
>> printed onto a paper roll. Text editors working on such a terminal were
>> very restricted in what they could do.
>
> When I started programming in 1978, we had to queue for access
 > to a room of such terminals. I was working on DECSystem-10
 > machines using the TOPS-10 O/S (writing COBOL-68!).

By January 1982, you'll be pleased to hear, the queue had died down a 
bit, and I generally had no problem getting access to Trends 
(toilet-roll typewriters) or DT-22s (30cps, or 120cps if you knew where 
to find them - there were only a few dotted around the place). Editing 
was done via line numbers. You know:
 > LIST
10 PRINT "WHAT IS THE ANGLE?"
20 INPUT THETA
30 PRINT "WHAT IS THE VELOCITY?"
 > 5 PRINT "RICHARD HEATHFIELD 14 JANUARY 1982 ASSIGNMENT 2"
 > LIST
5 PRINT "RICHARD HEATHFIELD 14 JANUARY 1982 ASSIGNMENT 2"
10 PRINT "WHAT IS THE ANGLE?"
20 INPUT THETA
30 PRINT "WHAT IS THE VELOCITY?"
 > RENUM
 > LIST
10 PRINT "RICHARD HEATHFIELD 14 JANUARY 1982 ASSIGNMENT 2"
20 PRINT "WHAT IS THE ANGLE?"
30 INPUT THETA
40 PRINT "WHAT IS THE VELOCITY?"
 > 50 INPUT VELOCITY

and so on.

Such an editor was surprisingly[1] workable, especially when one 
reflects that LIST could show you specific ranges of lines.

Later, I discovered XEDIT, which would let you see a full screen of text 
at a time, but editing was done via a command window at the bottom of 
the screen.

When I finally discovered some full-screen terminals, I was a little 
thrown by them. It wasn't immediately obvious to me how to use them, so 
conditioned had I become to line editors.

XEDIT was a horrible editor, but nevertheless some people loved it so 
much that a PC version, KEDIT, was written to help them settle down in 
Dosland.

[1] Surprisingly *now*. It was no surprise then, because (for a time) it 
was all I knew, so *obviously* it was workable, because it worked.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#64079

On Thursday, June 18, 2015 at 11:26:56 AM UTC-5, Malcolm McLean wrote:
> On Thursday, June 18, 2015 at 5:14:00 PM UTC+1, Ben Bacarisse wrote:
> >
> > I seem to remember there was time when the arrow keys worked (on almost
> > all terminals) with vi, let alone vim (or any of the newer variants).
> > Did they ever stop working, or is my memory rosy?
> > 

I've encountered terminals where the arrow keys don't work* in insert mode,
but I think that's as much to do with terminal configuration as anything 
else.  

And I get odd behavior on different systems (on one system, backspace only 
deletes the text you've written since you went into insert mode, while on 
another it will delete everything up to the beginning of the line, stuff 
like that).  

> vi is designed for situation where it's too much strain on the processor 
> to update a whole 25 x 80 character screen.
> So when it fires up, instead of getting some text you can read, and a nice 
> flashing cursor you can move up and down with the arrow keys to navigate 
> it, it gives you what superficially looks like an edit buffer, but is in 
> fact just a read-only window onto the text. You then type idiosyncratic 
> commands into the line buffer below to edit it. So to insert a work it's 
> colon i or something like that. If you hardly ever use it, it's very hard 
> to make it do what you want, and you hardly ever use it, because most 
> people aren't going to write their novel over a 100 baud connection. You 
> might have to update a five line config file over such a connection, 
> however.

That's the ex editor, which vi uses in command mode.  And yeah, there are
times when you're editing in a terminal session over a slow connection and
you really can't take advantage of a screen-oriented editor.  Those times
should be fairly rare, though.  vi (or vim, or gvim, or whatever) should
be full-screen right out of the box, just need to type "i" to go into insert
mode.

I learned vi first**, so it's what I use (I like my ruts *narrow* and
*deep*).  The only time I use emacs is when I run a sqlplus session, where 
the line recall and editing features are really useful.  As a text editor, 
though, not so much.  Hitting Esc-: is so deeply etched into my DNA that
I wind up getting into a bad state in any other editor.  

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

* By which I mean, they spam [[A or whatever the arrow key sequence
is into your source text.

** Actually, I learned EDT on VMS first, but I haven't worked on a VMS
system since 1990.  

[toc] | [prev] | [next] | [standalone]

#64088

John Bode <jfbode1029@gmail.com> writes:
> On Thursday, June 18, 2015 at 11:26:56 AM UTC-5, Malcolm McLean wrote:
>> On Thursday, June 18, 2015 at 5:14:00 PM UTC+1, Ben Bacarisse wrote:
>> >
>> > I seem to remember there was time when the arrow keys worked (on almost
>> > all terminals) with vi, let alone vim (or any of the newer variants).
>> > Did they ever stop working, or is my memory rosy?
>
> I've encountered terminals where the arrow keys don't work* in insert mode,
> but I think that's as much to do with terminal configuration as anything 
> else.  
>
> And I get odd behavior on different systems (on one system, backspace only 
> deletes the text you've written since you went into insert mode, while on 
> another it will delete everything up to the beginning of the line, stuff 
> like that).  

I think that's largely a matter of which version of vi/vim you're using.

The original vi did not support the use of arrow keys in insert mode,
and backspace did not let you erase characters past the beginning of the
current insertion.  I think it was vim that added those features.
"vim -C", which is supposed to be vi-compatible, doesn't seem to turn
them off.

There are several other enhanced vi clones; nvi is the one I've used
most in the past.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#64089

On 24/06/15 16:43, John Bode wrote:
> Hitting Esc-: is so deeply etched into my DNA that
> I wind up getting into a bad state in any other editor.

You can tell a lot about a programmer by putting him in front of an 
unfamiliar editor and examining his plokta.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#64091

On 06/24/2015 02:23 PM, Richard Heathfield wrote:
> On 24/06/15 16:43, John Bode wrote:
>> Hitting Esc-: is so deeply etched into my DNA that
>> I wind up getting into a bad state in any other editor.
> 
> You can tell a lot about a programmer by putting him in front of an 
> unfamiliar editor and examining his plokta.

<https://en.wiktionary.org/wiki/plotka> ?

[toc] | [prev] | [next] | [standalone]

#64092

On 24/06/15 19:40, James Kuyper wrote:
> On 06/24/2015 02:23 PM, Richard Heathfield wrote:
>> On 24/06/15 16:43, John Bode wrote:
>>> Hitting Esc-: is so deeply etched into my DNA that
>>> I wind up getting into a bad state in any other editor.
>>
>> You can tell a lot about a programmer by putting him in front of an
>> unfamiliar editor and examining his plokta.
>
> <https://en.wiktionary.org/wiki/plotka> ?

http://www.catb.org/jargon/html/P/plokta.html

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#63534

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>> On 18/06/15 16:26, Malcolm McLean wrote:
>>> On Thursday, June 18, 2015 at 3:29:55 PM UTC+1, Richard Heathfield wrote:
>>>>
>>>> A few years ago, someone told this group about a company that was
>>>> distributing a "vim reference t-shirt" with lots of handy commands
>>>> printed *upside-down* on the front of the shirt (pull the shirt out and
>>>> forward a bit, and then look down to look up). Ben Pfaff responded by
>>>> asking whether they also did a reference tent, for emacs users.
>>>>
>>> I always run emacs. I hate being chucked into vim or vi, though it happens
>>> occasionally.
>>
>> I can understand that, although of course my view is diametrically
>> opposite to yours.
>>
>>> I like to press the arrow keys and see the cursor move,
>>
>> gvim
>
> I seem to remember there was time when the arrow keys worked (on almost
> all terminals) with vi, let alone vim (or any of the newer variants).
> Did they ever stop working, or is my memory rosy?

Arrow keys do work in vi and vim, though there are ways to configure
it (intentionally or otherwise) so they don't.  In vim, they even
work in insert mode.  Many vi/vim users, particularly touch typists,
prefer to use the j, k, l, and m keys instead because you don't
have to move your right hand off the home row.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#63592

On Thursday, June 18, 2015 at 6:19:57 PM UTC+1, Keith Thompson wrote:

> Arrow keys do work in vi and vim, 

Sometimes ... on a grown up PC linux.  
Over a serial UART onto an embedded busybox system?  Good luck with that.

[toc] | [prev] | [next] | [standalone]

#63608

gwowen <gwowen@gmail.com> writes:
> On Thursday, June 18, 2015 at 6:19:57 PM UTC+1, Keith Thompson wrote:
>> Arrow keys do work in vi and vim, 
>
> Sometimes ... on a grown up PC linux.  
> Over a serial UART onto an embedded busybox system?  Good luck with that.

On modern terminal and emulators, the arrow keys send escape
sequences, not single characters.  For example, typing the up arrow
typically sends a 3-character sequence: Escape [ A.  But the Escape
character by itself is also a valid command.

vi has to distinguish between them by timing.  In old versions,
it would wait one second after seeing an Escape character before
deciding that it was just an Escape character -- which meant
that typing Escape [ A quickly enough would move the cursor up.
Modern vim seems to behave a bit differently; perhaps the timeout
is just shorter, but I just tried "busybox vi", and it does seem
to use a longer timeout that can be faked out.

I can imagine the arrow keys not working reliably over a slow and/or
flaky serial connection.  But then again, I don't usually use the
arrow keys in vi.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web