«

Hello folks.

According to the 1990 C standard (which is what I wish to code to), there is no "escape" character. So the only way to produce an escape character is to harcode its ASCII or EBCDIC value (x'1b'/x'27' respectively). I don't like doing that. I want to be able to write an editor like micro-emacs without having to have an #ifdef EBCDIC.

My conclusion is that I need to create a new type of terminal. Instead of having an ANSI terminal where ESC [ 2 J causes the screen to be cleared:

http://forum.codecall.net/topic/5914...-any-language/

I instead want to replace the ESC with either a form feed, vertical tab or alert. All of these things are defined in 5.2.2 of the standard. But 5.2.1 of the standard says:

"control characters representing horizontal tab, vertical tab. and form feed."

ie there is no alert defined. So I guess that is ruled out. A reminder thatmy goal is an "ideal terminal from the C programmer's perspective".

I've never seen a vertical tab defined on a US keyboard, so I'm thinking that can be stolen for this purpose. But I would say that form feed is even more meaningless/useless when an escape sequence exists in order to clear the screen.

So would form-feed be the ideal character to steal?

Note that in order to maintain compatability with existing ANSI terminals, my plan is to get the operating system itself to convert form-feed (or whatever) characters into an ASCII/EBCDIC escape character. Note that form-feedis x'0c' in both ASCII and EBCDIC. I don't mind the operating system having some hard-coding in it to convert x'0c' to x'1b'/x'27'. I just don't wantto see that in my application program (in this case my application programwill be somewhat of a clone of micro-emacs).

Any room for conceptual improvement?

Note that the main target for this is PDOS/390, which can be found at http://pdos.sourceforge.net - ie this is intended to run in an EBCDIC environment being emulated on an ASCII machine. I will telnet into Hercules.

The short story is that I am happy that the people who wrote the ANSI terminal specification did a reasonable job, they just didn't quite cater for a portable C program to drive the terminal. So it's just a minor thing I wantto change. Any name for the new ANSI-like terminal? I was thinking of PANSI/PANSY, the P coming from PDOS.

Thanks. Paul.

On Tuesday, October 23, 2012 3:34:57 PM UTC+11, robert...@yahoo.com wrote:
>
> Is this a meaningful problem? Is there actually a terminal
> (presumably emulated) that actually implements *EBCDIC* ANSI escape
> sequences?

My plan was for the EBCDIC operating system to assume
the existence of an EBCDIC ANSI/PANSY terminal. Then
it would be up to Hercules to translate the ASCII
telnet ANSI terminal into the required EBCDIC form, so
that the EBCDIC application has something to drive.

How else would you propose getting micro-emacs (or
similar) to run on the mainframe?

> Most EBCIDIC systems which allow the attachment of ASCII terminals
> provide a considerable (and usually very clumsy) translation layer if
> the application is to use EBCDIC

Yes, this is the route I intend to take.

> or pass through the ASCII unchanged,
> in which case the translation needs to happen in the application.

I do not wish to go this route. I think I have a fundamental
right to write an execution-character-set-neutral editor in C
without deviating from the C90 standard.

Which raises another point. I intend to make stdin/stdout
be IONBF, and leave them as text mode, since I don't think
there is a standard way to switch to binary mode.

> And most EBCDIC terminals are block mode devices, or line mode devices
> with very, very different characteristics than typical ASCII
> terminals.

Right. Which is why micro-emacs hasn't been implemented on
MVS for decades.

> Or am I missing something?

I intend to change decades of micro-emacs-less mainframes.
I have proposed a path to achieve that. I'm not aware of
a better path, but open to comment.

Thanks. Paul.

kerravon <> wrote in
news:90bcf5bb-f8e9-4ea2-9cbe-:

> Hello folks.
>
> According to the 1990 C standard (which is what I wish to code to),
> there is no "escape" character. So the only way to produce an escape
> character is to harcode its ASCII or EBCDIC value (x'1b'/x'27'
> respectively). I don't like doing that. I want to be able to write an
> editor like micro-emacs without having to have an #ifdef EBCDIC.
>
> My conclusion is that I need to create a new type of terminal.
CUT
First you should get a keyboard with an enter key.
Then spend a few hours to learn to use it.

Sjouke Burry <s@b> writes:
> kerravon <> wrote in
> news:90bcf5bb-f8e9-4ea2-9cbe-:
>> According to the 1990 C standard (which is what I wish to code to),
>> there is no "escape" character. So the only way to produce an escape
>> character is to harcode its ASCII or EBCDIC value (x'1b'/x'27'
>> respectively). I don't like doing that. I want to be able to write an
>> editor like micro-emacs without having to have an #ifdef EBCDIC.
>>
>> My conclusion is that I need to create a new type of terminal.
> CUT
> First you should get a keyboard with an enter key.
> Then spend a few hours to learn to use it.

Perhaps a let sarcastic approach would be more productive.

kerravon, the Google Groups interface is not well suited for
posting to Usenet. One of its problems is that it doesn't make
it easy to write text in a suitable manner. For a web interface,
it makes sense to write very long lines and let the web interface,
or your browser, wrap it for you. For Usenet, it's better to post
with lines no longer than 80 columns; 72 or less is even better.
You have to insert explicit line breaks to do this. (My newsreader,
for example, will wrap long lines, but not at word boundaries;
other news software may be even less friendly to very long lines.)

Google Groups has also recently started double-spacing quoted text,
which is *really* annoying.

You can work around this problem if you can compose your article
in a text editor that lets you do this, and then copy-and-paste it
into the Google Groups text window. Or, better yet, get a real
Usenet newsreader (I use Gnus, which you'll like if and only if
you like Emacs) and an account on a free or cheap Usenet server
(I use eternal-september.org).

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Wednesday, October 24, 2012 7:16:57 AM UTC+11, Keith Thompson wrote:
> Sjouke Burry <s@b> writes:
>
> > First you should get a keyboard with an enter key.
> > Then spend a few hours to learn to use it.
>
> Perhaps a let sarcastic approach would be more productive.

Yes, I assumed that the other response was along the
lines of EBCDIC devices always operate in either line
mode or block mode, so stop trying to use character
mode, and learn to press enter to terminate text.

> or your browser, wrap it for you. For Usenet, it's better to post
> with lines no longer than 80 columns; 72 or less is even better.

OK.

So any comment on the C90 not defining an escape
character, while ANSI terminals requiring an
escape character? Which computers did C90 have
in mind when they left out the escape character,
but included a vertical tab?

BFN. Paul.

On Tuesday 23 October 2012 00:19, in comp.lang.c, wrote:

> Hello folks.
>
> According to the 1990 C standard (which is what I wish to code to), there
> is no "escape" character. So the only way to produce an escape character
> is to harcode its ASCII or EBCDIC value (x'1b'/x'27' respectively). I
> don't like doing that. I want to be able to write an editor like
> micro-emacs without having to have an #ifdef EBCDIC.
>
> My conclusion is that I need to create a new type of terminal.

Having written code on EBCDIC-based mainframe systems for many years, and
with both hardcopy and video terminals for even more years, I gotta say,
you /are/ ambitious, aren't you.

Some things to think about (none of them C related)

1) EBCDIC is a "family" of related but slightly-differing charactersets.
While I believe that most of the EBCDIC control characters are common to
all of the EBCDIC charactersets, I don't remember the details. You should,
perhaps, specify /which/ EBCDIC you intend to deal with, and/or research to
determine that the control characters you select are common to the EBCDIC
charactersets you intend to work with.

2) EBCDIC terminals don't act like ASCII terminals. IBM defined them as
a "block oriented" device, taking a specific set of (already predefined)
commands, that are /nothing/ like the ANSI escape sequences you already
know. On such a terminal, each printing position is paired with a second,
control, octet, which governs the form and function of that position
(readable, writable, colour, intensity, etc.) Terminals are read and
written screen at a time (up to 4000 characters at a time (80x25x2),
including the non-data "status line", depending on those paired control
bytes). The equivalent to the ANSI "clear screen" escape sequence is a
full screen block (80x25) of non-rereadable blanks.

3) On most ASCII-based terminals, the ASCII "form feed" (FF) character will
clear the screen. It does not guarantee the cursor position. Alternatively,
a series of ASCII "line feed" characters will also clear such a screen,
again without guarantee of cursor position. Neither is acceptable on a
hardcopy terminal.

4) I seriously doubt that you will actually "create a new type of terminal".
Is hardware your specialty? And do you have a market? You probably mean
that you want to write some sort of "terminal emulator". This isn't easy,
but it isn't difficult either. You /do/ need a hardware terminal to target
to; you need something to display on, and you have to build your emulator
to interpret input and write or read on the hardware.

5) This seems all to 1990's for me. You are running at least 30 years behind
the times; this has all been done before, many times over. Perhaps you need
to look into prior art.

HTH
--
Lew Pitcher
"In Skills, We Trust"

On 10/23/2012 6:46 PM, kerravon wrote:
> [...] Which computers did C90 have
> in mind when they left out the escape character,
> but included a vertical tab?

I don't know "which computers," specifically, the Committee
was concerned about. According to the Rationale, though:

"Proposals to add '\e' for ASCII ESC ('\033') were not
adopted because other popular character sets have no obvious
equivalent (see §6.4.4.4.)"

and

"The C89 Committee considered proposals to add the character
constant '\e' to represent the ASCII ESC ('\033') character.
This proposal was based upon the use of ESC as the initial
character of most control sequences in common terminal driving
disciplines such as ANSI X3.64. However, this usage has no
obvious counterpart in other popular character codes such as
EBCDIC."

At least some versions of EBCDIC feature a control character
named ESC, and I think you can safely assume the Committee was aware
of this. I do not know their reasons for declaring that EBCDIC/ESC
was not an "obvious counterpart" for ASCII/ESC -- but then, I'm not
a character-set expert. On the evidence at hand, neither are you.

--
Eric Sosman
d

On Tuesday 23 October 2012 20:29, in comp.lang.c,
d wrote:
[snip]
>
> At least some versions of EBCDIC feature a control character
> named ESC, and I think you can safely assume the Committee was aware
> of this. I do not know their reasons for declaring that EBCDIC/ESC
> was not an "obvious counterpart" for ASCII/ESC -- but then, I'm not
> a character-set expert.

And neither am I. But, long ago, I dealt with characterset issues as part of
my job.

ISTM that, in ASCII, the use of the ESC character has mutated from the
original "characterset selector" (as in ISO 2022) used to select which
glyphs would activate following an SO or SI control character to a more
generic purpose that includes format effectors (like display controls and
cursor positioning controls) and vendor-specific extensions.

OTOH, IBM control characters have never strayed very far from their BSC and
3270 roots, and didn't seem to have any use for ESCape as a characterset
selector (using their "GE" Graphic Escape for that purpose - see the "3270
Data Stream Programmer's Reference" and others for details). AFAIK, there
was no teleterminal use for the EBCDIC ESCape character at all.

--
Lew Pitcher
"In Skills, We Trust"

Lew Pitcher <> writes:
[...]
> 3) On most ASCII-based terminals, the ASCII "form feed" (FF) character will
> clear the screen.
[...]

That doesn't seem to be the case.

I haven't used an ASCII-based *terminal*, as opposed to a terminal
emulator, in years. But most terminal emulators, and probably
most actual terminals, are VT-100 compatible -- and a form feed
character, as far as I can tell, doesn't clear the screen. In the
several emulators I've tried, it either does nothing or moves the
cursor down one line.

A working clear-screen sequence is "^[[H^[[2J", where "^[" denotes the
ASCII Escape character.

The comp.lang.c FAQ <http://www.c-faq.com/>, in question 19.4, says that
form-feed "will cause some displays to clear".

(Incidentally, a commonly suggested portable solution is to print enough
newlines to scroll everything of the top of the display. Drawbacks of
this approach are: (1) it's hard to tell how many newlines are needed;
(2) the cursor is left at the bottom of the screen, and (3) text can
still be seen by scrolling up, which is a problem if you want to erase
sensitive information.)

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Wednesday, October 24, 2012 11:29:28 AM UTC+11, Eric Sosman wrote:

A truly great response - thanks Eric!

> "The C89 Committee considered proposals to add the character
> constant '\e' to represent the ASCII ESC ('\033') character.
> This proposal was based upon the use of ESC as the initial
> character of most control sequences in common terminal driving
> disciplines such as ANSI X3.64. However, this usage has no

The exact situation I face.

> obvious counterpart in other popular character codes such as
> EBCDIC."

> of this. I do not know their reasons for declaring that EBCDIC/ESC
> was not an "obvious counterpart" for ASCII/ESC -- but then, I'm not
> a character-set expert. On the evidence at hand, neither are you.

I am using as reference the IBM S/370 reference summary
4th edition dated November 1976 (ie more than a decade
before C90).

It has an ESC at position x'27'.

I have never seen an EBCDIC ESC used for anything though.

I wonder what it all means?

BFN. Paul.