Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Paul Edwards" <mutazilah@gmail.com>
Newsgroups: comp.programming
Subject: Re: encapsulating directory operations
Date: Thu, 29 May 2025 14:31:40 +1000
Organization: A noiseless patient Spider
Lines: 114
Message-ID: <1018nvh$3mvlm$1@dont-email.me>
References: <100h650$23r5l$1@dont-email.me> <20250520065158.709@kylheku.com><100i2la$292le$1@dont-email.me> <87a5770xjw.fsf@nosuchdomain.example.com><100j09o$2f04b$1@dont-email.me> <87tt5ezx9y.fsf@nosuchdomain.example.com><100j4t3$2foah$1@dont-email.me> <87ldqqzfj0.fsf@nosuchdomain.example.com><100kak8$2q0s6$1@dont-email.me> <87a575zvmb.fsf@nosuchdomain.example.com><100o3sc$3ll6t$1@dont-email.me> <87bjrkxonr.fsf@nosuchdomain.example.com><100ob9f$3n9m3$1@dont-email.me> <100ovse$3ubb5$1@dont-email.me><87msb3ucmq.fsf@nosuchdomain.example.com> <100p1u4$3um4p$1@dont-email.me><10103i7$1jdii$1@dont-email.me> <87a570jpe6.fsf@nosuchdomain.example.com><101069l$1k3nm$1@dont-email.me> <m9i7k5Fj42gU3@mid.individual.net>
Injection-Date: Thu, 29 May 2025 06:31:46 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="330b717bae2890f818abff4bf09d7537";
	logging-data="3899062"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/1f0aC6C9g/jm2pvDQdot9nD7ksJEIAks="
Cancel-Lock: sha1:0lauvPzGYM+qjuXmOP62bhI9jq8=
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-Priority: 3
X-MSMail-Priority: Normal

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