From Newsgroup: comp.programming
"vallor" <
vallor@cultnix.org> wrote in message news:
m9i7k5Fj42gU3@mid.individual.net...
On Mon, 26 May 2025 08:40:50 +1000, "Paul Edwards" <mutazilah@gmail.com> wrote in <101069l$1k3nm$1@dont-email.me>:
The idea that you can't do that without a constant defined in your
language standard is just silly.
It may be silly from your perspective, but for me it is crucial.
I've x-posted this to comp.programming, and set followup-to there.
I'm wondering why your control-character-handling wouldn't be better
handled with a curses library. IIRC, back in my DOS days (early 90's),
there was a curses library for DOS.
I don't mind having a curses library.
But in order to write that curses library, at least one that
can cope with ANSI terminals, I need an escape character.
And yes, unless some other solution is found, I will need
the control characters to be defined in C90+ also. Either
for use by the curses library, or directly in microemacs,
whatever.
A quick look around found this: https://pdcurses.org/ ...which
includes DOS support.
If it doesn't handle EBCDIC terminal escapes, consider extending it.
I'm happy to either extend pdcurses, or simply use microemacs
as-is, which already has support for ANSI X3.64.
I don't know anything about microemacs, but if it doesn't use a
curses-like
library to handle different terminal types, I'd be surprised.
Here is what microemacs 3.6 comes with:
D:\devel\memacs>dir *.c
Volume in drive D is PAULDATA
Volume Serial Number is DAB2-6E30
Directory of D:\devel\memacs
2024-05-03 10:18a 4,569 ansi.c
2024-09-18 05:45p 12,236 basic.c
2023-09-02 04:23p 20,687 bind.c
2023-09-02 02:21p 16,280 buffer.c
2024-09-18 05:46p 32,545 display.c
2023-09-02 02:50p 17,178 file.c
2023-09-02 03:21p 3,128 fileio.c
2023-07-08 07:50p 7,209 hp150.c
2023-09-02 03:21p 19,558 line.c
2023-09-02 03:21p 3,786 lock.c
2024-05-03 11:33a 24,221 main.c
2024-09-18 05:39p 18,286 random.c
2023-09-02 04:02p 7,300 region.c
2024-09-18 05:40p 13,820 search.c
2023-09-02 04:17p 7,836 spawn.c
2023-07-08 07:50p 2,920 tcap.c
2023-09-02 04:17p 13,132 termio.c
2023-07-08 07:50p 5,328 vmsvt.c
2023-07-08 07:50p 2,630 vt52.c
2023-09-02 04:17p 12,638 window.c
2023-09-02 04:17p 13,685 word.c
ansi.c is the one that I'm interested in. vt52.c and vmsvt.c
and hp150.c and tcap.c are all for different types of
screen.
This is the bit in ansi.c where I go beyond what C90 says exists:
#if EBCDIC
#define ESC 0x27 /* ESC character. */ #else
#define ESC 0x1B /* ESC character. */ #endif
I don't need to do that for '\n', or the letter 'Q', or the number '5'. Standard C90 has me covered there.
But if I wish to stick purely to what has been standardized by
the ISO C90 committee, this code is not portable.
And thus, if I restrict myself to just what C90 provides, I cannot
write the above code, and I cannot drive an ANSI X3.64
terminal (ASCII or EBCDIC).
I'm not saying anyone else shares my goal, but my goal, which
is (sort of) to "be honest", means that I cannot use microemacs
to drive an ANSI terminal, and I must restrict myself to a line
editor like edlin.
Rather than be a C90 fanatic that insists on using edlin because
that's all that C90 provides, I'd rather extend the C90 standard
to C90+ or whatever.
Just a minimal number of changes to support crucial functionality
that will change my life. Have you ever tried programming using
edlin? Being able to use microemacs instead of edlin "will be" a
life-changing experience.
That's my goal. I'm not asking anyone else to share my goal. I only
asked for technical advice on how best to extend the C90 standard
with the minimal changes I required. Or some other option I
haven't thought of.
BFN. Paul.
--- Synchronet 3.21a-Linux NewsLink 1.2