Having to write some Icelanding words in a DECterm (as one does), I
notice that COMPOSE-T-H and COMPOSE-t-h create upper and lower case
thorn (Þ þ if those characters get through). If entered by c
both create the character, unless it is at the beginning of a line, in
which case one sees <XDE> or <XFE> (one character, displayed as
several). ASCII values are 222 and 254. Refreshing the screen also
causes the mnenonics to appear. Also, they are not displayed via
HELP FORTRAN CHAR DEC.

Any deeper reason or just flaky instrumentation?

I also notice that × (COMPOSE-x-x) works fine in a DECterm but not on a
real VT220 (where most or all other composed characters work). Again,
deeper meaning or just flaky?

On 2021-11-10 09:44:34 +0000, Phillip Helbig (undress to reply said:

> Having to write some Icelanding words in a DECterm (as one does), I
> notice that COMPOSE-T-H and COMPOSE-t-h create upper and lower case
> thorn (Þ þ if those characters get through). If entered by cboth
> create the character, unless it is at the beginning of a line, in which
> case one sees <XDE> or <XFE> (one character, displayed as several).
> ASCII values are 222 and 254. Refreshing the screen also causes the
> mnenonics to appear. Also, they are not displayed via HELP FORTRAN
> CHAR DEC.
>
> Any deeper reason or just flaky instrumentation?
>
> I also notice that × (COMPOSE-x-x) works fine in a DECterm but not on a
> real VT220 (where most or all other composed characters work). Again,
> deeper meaning or just flaky?

You're definitely not looking at ASCII, and AFAIK Þ and þ aren't in DEC
MCS, which likely means you're looking at inconsistent handling of or
inconsistent configuration of ISO 8859-1 among your apps and OS and
hardware; I'd guess some here is MCS, and some 8859-1.

You've asked variations of this question over the years too, usually
involving trying to use EDT past ASCII or maybe past DEC MCS.

https://groups.google.com/g/comp.os.vms/c/QAQAyRo9BPM/m/IrmCw1UJBQAJ
https://groups.google.com/g/comp.os.vms/c/Yji2Tufvv7k/m/mhUy-zKXAAAJ
etc.

This is part of the (lack of) UTF-8 and Unicode support in OpenVMS and
its tooling that I've grumbled. Not that adding UTF-8 and Unicode
support is ever going to be a small overhaul.

--
Pure Personal Opinion | HoffmanLabs LLC

Den 2021-11-10 kl. 19:04, skrev Stephen Hoffman:
> On 2021-11-10 09:44:34 +0000, Phillip Helbig (undress to reply said:
>
>> Having to write some Icelanding words in a DECterm (as one does), I
>> notice that COMPOSE-T-H and COMPOSE-t-h create upper and lower case thorn
>> (Þ þ if those characters get through).  If entered by cboth create the
>> character, unless it is at the beginning of a line, in which case one
>> sees <XDE> or <XFE> (one character, displayed as several). ASCII values
>> are 222 and 254.  Refreshing the screen also causes the mnenonics to
>> appear.  Also, they are not displayed via HELP FORTRAN CHAR DEC.
>>
>> Any deeper reason or just flaky instrumentation?
>>
>> I also notice that × (COMPOSE-x-x) works fine in a DECterm but not on a
>> real VT220 (where most or all other composed characters work).  Again,
>> deeper meaning or just flaky?
>
> You're definitely not looking at ASCII, and AFAIK Þ and þ aren't in DEC
> MCS, which likely means you're looking at inconsistent handling of or
> inconsistent configuration of ISO 8859-1 among your apps and OS and
> hardware; I'd guess some here is MCS, and some 8859-1.
>
> You've asked variations of this question over the years too, usually
> involving trying to use EDT past ASCII or maybe past DEC MCS.
>
> https://groups.google.com/g/comp.os.vms/c/QAQAyRo9BPM/m/IrmCw1UJBQAJ
> https://groups.google.com/g/comp.os.vms/c/Yji2Tufvv7k/m/mhUy-zKXAAAJ
> etc.
>
> This is part of the (lack of) UTF-8 and Unicode support in OpenVMS and its
> tooling that I've grumbled. Not that adding UTF-8 and Unicode support is
> ever going to be a small overhaul.
>

Now, UTF8 is just a "row of bytes", so if you use (as an example) Putty
in its default setup using UTF8, you can type (or copy/paste) any UTF8
character into Putty and it will be stored using whatever editor you
are using. It is just a row of bytes, so there is no specific need for
any "UTF8 support" for doing just that.

Later on, of you send the same text to some UTF8 compatible display (like
another Putty session using the default UTF8 setup, or a web browser using
UTF8 encoding) the Islandic characters would be displayed just fine.

But if you are using some display tool that doesn't support UTF8, you
will get garbled text, of course. But that is not the fault of OpenVMS.

It is unclear if ISO/IEC 646 have/had support for Icelandic characters,
the Wiki page has an entry for "IS" in some tables but no real data.
https://en.wikipedia.org/wiki/ISO/IEC_646

Then of course, it is a totally other matter if you are talkning about
UTF8 support for symbols/variables in compilers or in file/directory
names, but that is a totally differnt area from just storing and
displaying some "data" that happens to include UTF8 sequences.
But that isn't in the scope of the question asked.

I would not expect tools like DECterm or VT220 (really?) to handle
UTF8 or anything else outside the DEC-MCS range of characters. If you
need that, simply use modern tool from the last 20 years or so.

On 2021-11-11 00:21:38 +0000, Jan-Erik Søderholm said:

> Now, UTF8 is just a "row of bytes", so if you use (as an example) Putty
> in its default setup using UTF8, you can type (or copy/paste) any UTF8
> character into Putty and it will be stored using whatever editor you
> are using. It is just a row of bytes, so there is no specific need for
> any "UTF8 support" for doing just that.

You're quite possibly headed for a few surprises within OpenVMS apps,
even if cutting-and-pasting wads of bytes around. Not the least of
which involves counting characters/code points/clusters (one byte is no
longer one character, so is the app looking for the buffer size or the
character/code point/cluster length, and what to do with the zero-width
stuff?), the fun that is directionality (there's a recent CVE related
to this), and identifying the string encoding and the string language
for each string, normalization, and the inherent language-sensitivity
of strings for purposes such as sorting. In aggregate, some baked-in
app and OpenVMS API assumptions—and developers' own assumptions—about
strings can and will break. Sure, UTF-8 is a "row of bytes", with some
caveats. Sort of. Mostly.

There are a few corners of OpenVMS that have some UTF-8 support, one is
the XQP. Another is C including the I18N bits. Java. I'd expect that
pervasive support is at least a decade away.

--
Pure Personal Opinion | HoffmanLabs LLC

On 11/10/2021 7:21 PM, Jan-Erik Söderholm wrote:
> Den 2021-11-10 kl. 19:04, skrev Stephen Hoffman:
>> This is part of the (lack of) UTF-8 and Unicode support in OpenVMS and
>> its tooling that I've grumbled. Not that adding UTF-8 and Unicode
>> support is ever going to be a small overhaul.
>
> Now, UTF8 is just a "row of bytes", so if you use (as an example) Putty
> in its default setup using UTF8, you can type (or copy/paste) any UTF8
> character into Putty and it will be stored using whatever editor you
> are using. It is just a row of bytes, so there is no specific need for
> any "UTF8 support" for doing just that.
>
> Later on, of you send the same text to some UTF8 compatible display (like
> another Putty session using the default UTF8 setup, or a web browser using
> UTF8 encoding) the Islandic characters would be displayed just fine.
>
> But if you are using some display tool that doesn't support UTF8, you
> will get garbled text, of course. But that is not the fault of OpenVMS.

The biggest problems with UTF-8 is that the byte length is not
necessarily the character length and that byte index i is not character
index i (and worse byte index i may not even point to a character at all
if it hits in the middle of a multi-byte sequence).

> It is unclear if ISO/IEC 646 have/had support for Icelandic characters,
> the Wiki page has an entry for "IS" in some tables but no real data.
> https://en.wikipedia.org/wiki/ISO/IEC_646

http://www.kreativekorp.com/charset/encoding/ISO646IS/

https://www.freeutils.net/source/jcharset/ &
https://www.mvndoc.com/c/net.freeutils/jcharset/net/freeutils/charset/iso646/ISO646ISCharset.html

seems to indicate that it exist.

Arne

On Thursday, November 11, 2021 at 3:33:33 PM UTC+13, Arne Vajhøj wrote:
> The biggest problems with UTF-8 is that the byte length is not
> necessarily the character length ...

That would be true of any Unicode encoding, even UCS-4.

In article <smh1k8$ul5$1@dont-email.me>, Stephen Hoffman
<seaohveh@hoffmanlabs.invalid> writes:

> On 2021-11-10 09:44:34 +0000, Phillip Helbig (undress to reply said:
>
> > Having to write some Icelanding words in a DECterm (as one does), I

"Icelandic" of course.

> > notice that COMPOSE-T-H and COMPOSE-t-h create upper and lower case
> > thorn (Þ þ if those characters get through). If entered by cboth
> > create the character, unless it is at the beginning of a line, in which
> > case one sees <XDE> or <XFE> (one character, displayed as several).
> > ASCII values are 222 and 254. Refreshing the screen also causes the
> > mnenonics to appear. Also, they are not displayed via HELP FORTRAN
> > CHAR DEC.
> >
> > Any deeper reason or just flaky instrumentation?
> >
> > I also notice that × (COMPOSE-x-x) works fine in a DECterm but not on a
> > real VT220 (where most or all other composed characters work). Again,
> > deeper meaning or just flaky?
>
> You're definitely not looking at ASCII, and AFAIK Þ and þ aren't
> in DEC
> MCS,

At least HELP FORTRAN CHAR DEC doesn't show them.

> which likely means you're looking at inconsistent handling of or
> inconsistent configuration of ISO 8859-1 among your apps and OS and
> hardware; I'd guess some here is MCS, and some 8859-1.

Only LK411, Alpha hardware and DECterm (under CDE, but that's probably
irrelevant). Maybe they are inconsistent. :-|

> You've asked variations of this question over the years too, usually
> involving trying to use EDT past ASCII or maybe past DEC MCS.

Yes. :-)

In article <smhnmj$2d8$1@dont-email.me>,
=?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik.soderholm@telia.com>
writes:

> Now, UTF8 is just a "row of bytes", so if you use (as an example) Putty
> in its default setup using UTF8, you can type (or copy/paste) any UTF8
> character into Putty and it will be stored using whatever editor you
> are using. It is just a row of bytes, so there is no specific need for
> any "UTF8 support" for doing just that.
>
> Later on, of you send the same text to some UTF8 compatible display (like
> another Putty session using the default UTF8 setup, or a web browser using
> UTF8 encoding) the Islandic characters would be displayed just fine.
>
> But if you are using some display tool that doesn't support UTF8, you
> will get garbled text, of course. But that is not the fault of OpenVMS.
>
> It is unclear if ISO/IEC 646 have/had support for Icelandic characters,
> the Wiki page has an entry for "IS" in some tables but no real data.
> https://en.wikipedia.org/wiki/ISO/IEC_646
>
> Then of course, it is a totally other matter if you are talkning about
> UTF8 support for symbols/variables in compilers or in file/directory
> names, but that is a totally differnt area from just storing and
> displaying some "data" that happens to include UTF8 sequences.
> But that isn't in the scope of the question asked.

Right; just a text file.

> I would not expect tools like DECterm or VT220 (really?)

Sorry, VT320. :-)

> to handle
> UTF8 or anything else outside the DEC-MCS range of characters. If you
> need that, simply use modern tool from the last 20 years or so.

I don't expect anything more than MCS. I'm just wondering why in a
DECterm it is sometimes displayed correctly and sometimes not.

On 11/11/2021 12:42 AM, Phillip Helbig (undress to reply) wrote:
> In article <smh1k8$ul5$1@dont-email.me>, Stephen Hoffman
> <seaohveh@hoffmanlabs.invalid> writes:
>
>> On 2021-11-10 09:44:34 +0000, Phillip Helbig (undress to reply said:
>>
>>> Having to write some Icelanding words in a DECterm (as one does), I
>
> "Icelandic" of course.
>
>>> notice that COMPOSE-T-H and COMPOSE-t-h create upper and lower case
>>> thorn (Þ þ if those characters get through). If entered by cboth
>>> create the character, unless it is at the beginning of a line, in which
>>> case one sees <XDE> or <XFE> (one character, displayed as several).
>>> ASCII values are 222 and 254. Refreshing the screen also causes the
>>> mnenonics to appear. Also, they are not displayed via HELP FORTRAN
>>> CHAR DEC.
>>>
>>> Any deeper reason or just flaky instrumentation?
>>>
>>> I also notice that × (COMPOSE-x-x) works fine in a DECterm but not on a
>>> real VT220 (where most or all other composed characters work). Again,
>>> deeper meaning or just flaky?
>>
>> You're definitely not looking at ASCII, and AFAIK Þ and þ aren't
>> in DEC
>> MCS,
>
> At least HELP FORTRAN CHAR DEC doesn't show them.
>
>> which likely means you're looking at inconsistent handling of or
>> inconsistent configuration of ISO 8859-1 among your apps and OS and
>> hardware; I'd guess some here is MCS, and some 8859-1.
>
> Only LK411, Alpha hardware and DECterm (under CDE, but that's probably
> irrelevant). Maybe they are inconsistent. :-|
>
>> You've asked variations of this question over the years too, usually
>> involving trying to use EDT past ASCII or maybe past DEC MCS.
>
> Yes. :-)
>
The character set ISO-8859-1 is almost the same as DEC-MCS with some of
the undefined DEC-MCS characters being defined in ISO-8859-1. The
exceptions are a few rarely used characters such as Œ and Ÿ.
Specifically, ISO-8859-1 has Icelandic Þ and þ, these positions are
undefined in DEC-MCS. 99% of the time one can use ISO-8859-1 instead of
DEC-MCS and get away with it.

There is an EDT patch which makes it more ISO-8859-1 friendly, actually
prompted by a customer who used EDT for strictly ASCII except for a
character at the 'þ' position (but not þ). EDT fans may want the patch
for its ability to understand terminals with more than 24 lines.

On 11/11/2021 12:45 AM, Phillip Helbig (undress to reply) wrote:
> In article <smhnmj$2d8$1@dont-email.me>,
> =?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik.soderholm@telia.com>
> writes:

>> to handle
>> UTF8 or anything else outside the DEC-MCS range of characters. If you
>> need that, simply use modern tool from the last 20 years or so.
>
> I don't expect anything more than MCS. I'm just wondering why in a
> DECterm it is sometimes displayed correctly and sometimes not.
>

If you're talking about how EDT behaves, it's because EDT was
inconsistent whether that character position was printable or not, if
not printable it treated it much like a control code (displaying it as
<Xnn> ) See my other reply.

In article <smicj8$h9r$1@gioia.aioe.org>, Michael Moroney
<moroney@world.std.spaamtrap.com> writes:

> >>> notice that COMPOSE-T-H and COMPOSE-t-h create upper and lower case
> >>> thorn (Þ þ if those characters get through). If entered by both
> >>> create the character, unless it is at the beginning of a line, in which
> >>> case one sees <XDE> or <XFE> (one character, displayed as several).
> >>> ASCII values are 222 and 254. Refreshing the screen also causes the
> >>> mnenonics to appear. Also, they are not displayed via HELP FORTRAN
> >>> CHAR DEC.
> >>>
> >>> Any deeper reason or just flaky instrumentation?
> >>>
> >>> I also notice that × (COMPOSE-x-x) works fine in a DECterm but not on a
> >>> real VT220 (where most or all other composed characters work). Again,
> >>> deeper meaning or just flaky?
> >>
> >> You're definitely not looking at ASCII, and AFAIK Þ and þ aren't
> >> in DEC
> >> MCS,
> >
> > At least HELP FORTRAN CHAR DEC doesn't show them.
> >
> >> which likely means you're looking at inconsistent handling of or
> >> inconsistent configuration of ISO 8859-1 among your apps and OS and
> >> hardware; I'd guess some here is MCS, and some 8859-1.
> >
> > Only LK411, Alpha hardware and DECterm (under CDE, but that's probably
> > irrelevant). Maybe they are inconsistent. :-|
> >
> >> You've asked variations of this question over the years too, usually
> >> involving trying to use EDT past ASCII or maybe past DEC MCS.
> >
> > Yes. :-)
> >
> The character set ISO-8859-1 is almost the same as DEC-MCS with some of
> the undefined DEC-MCS characters being defined in ISO-8859-1. The
> exceptions are a few rarely used characters such as Œ and Ÿ.
> Specifically, ISO-8859-1 has Icelandic Þ and þ, these positions are
> undefined in DEC-MCS. 99% of the time one can use ISO-8859-1 instead of
> DEC-MCS and get away with it.

Right. And ISO-8859-15 is also similar. I routinely write € in EDT to
get the Euro sign when most people read that text.

> There is an EDT patch which makes it more ISO-8859-1 friendly, actually
> prompted by a customer who used EDT for strictly ASCII except for a
> character at the 'þ' position (but not þ).

So the patch causes the wanted characters to be displayed? Of course,
one can enter any value in EDT.

> EDT fans may want the patch
> for its ability to understand terminals with more than 24 lines.

Will the patch become standard? Not that I need a terminal with more
than 24 lines. :-)

On Thursday, November 11, 2021 at 7:18:24 PM UTC+13, Michael Moroney wrote:
> Specifically, ISO-8859-1 has Icelandic Þ and þ ...

Don’t they also use Ð and ð?

On 11/10/2021 11:48 PM, Lawrence D’Oliveiro wrote:
> On Thursday, November 11, 2021 at 3:33:33 PM UTC+13, Arne Vajhøj wrote:
>> The biggest problems with UTF-8 is that the byte length is not
>> necessarily the character length ...
>
> That would be true of any Unicode encoding, even UCS-4.

No.

It is a practical problem in UTF-8 as everything not in ASCII is more
than 1 byte.

It is a theoretical problem in UTF-16 because there are defined unicode
code points that become more than 2 bytes (they are just extremely
rare).

It is not a problem for UTF-32 as everything is 4 bytes.

Arne

On 11/11/2021 3:16 AM, Lawrence D’Oliveiro wrote:
> On Thursday, November 11, 2021 at 7:18:24 PM UTC+13, Michael Moroney wrote:
>> Specifically, ISO-8859-1 has Icelandic Þ and þ ...
>
> Don’t they also use Ð and ð?
>

Yes. ISO-8859-1 has many defined characters which are not defined in
DEC-MCS, including Ð and ð. I only mentioned þ because of the original
post and the EDT patch background.

On 11/11/2021 3:10 AM, Phillip Helbig (undress to reply) wrote:
> In article <smicj8$h9r$1@gioia.aioe.org>, Michael Moroney
> <moroney@world.std.spaamtrap.com> writes:
>
>>>>> notice that COMPOSE-T-H and COMPOSE-t-h create upper and lower case
>>>>> thorn (Þ þ if those characters get through). If entered by both
>>>>> create the character, unless it is at the beginning of a line, in which
>>>>> case one sees <XDE> or <XFE> (one character, displayed as several).
>>>>> ASCII values are 222 and 254. Refreshing the screen also causes the
>>>>> mnenonics to appear. Also, they are not displayed via HELP FORTRAN
>>>>> CHAR DEC.
>>>>>
>>>>> Any deeper reason or just flaky instrumentation?
>>>>>
>>>>> I also notice that × (COMPOSE-x-x) works fine in a DECterm but not on a
>>>>> real VT220 (where most or all other composed characters work). Again,
>>>>> deeper meaning or just flaky?
>>>>
>>>> You're definitely not looking at ASCII, and AFAIK Þ and þ aren't
>>>> in DEC
>>>> MCS,
>>>
>>> At least HELP FORTRAN CHAR DEC doesn't show them.
>>>
>>>> which likely means you're looking at inconsistent handling of or
>>>> inconsistent configuration of ISO 8859-1 among your apps and OS and
>>>> hardware; I'd guess some here is MCS, and some 8859-1.
>>>
>>> Only LK411, Alpha hardware and DECterm (under CDE, but that's probably
>>> irrelevant). Maybe they are inconsistent. :-|
>>>
>>>> You've asked variations of this question over the years too, usually
>>>> involving trying to use EDT past ASCII or maybe past DEC MCS.
>>>
>>> Yes. :-)
>>>
>> The character set ISO-8859-1 is almost the same as DEC-MCS with some of
>> the undefined DEC-MCS characters being defined in ISO-8859-1. The
>> exceptions are a few rarely used characters such as Œ and Ÿ.
>> Specifically, ISO-8859-1 has Icelandic Þ and þ, these positions are
>> undefined in DEC-MCS. 99% of the time one can use ISO-8859-1 instead of
>> DEC-MCS and get away with it.
>
> Right. And ISO-8859-15 is also similar. I routinely write € in EDT to
> get the Euro sign when most people read that text.
>
>> There is an EDT patch which makes it more ISO-8859-1 friendly, actually
>> prompted by a customer who used EDT for strictly ASCII except for a
>> character at the 'þ' position (but not þ).
>
> So the patch causes the wanted characters to be displayed? Of course,
> one can enter any value in EDT.

Yes since all characters in the range xA0-xFF are defined and printable.
In theory it's compatible with any ISO-8859-x character set since EDT
doesn't care what the actual 8 bit characters are. It's up to the user
and their program to interpret things correctly.
>
>> EDT fans may want the patch
>> for its ability to understand terminals with more than 24 lines.
>
> Will the patch become standard? Not that I need a terminal with more
> than 24 lines. :-)
>
It's a regular patch for VSI V8.4-2x and is already part of 9.X.

On 11/11/21 10:21 AM, Arne Vajhøj wrote:
> On 11/10/2021 11:48 PM, Lawrence D’Oliveiro wrote:
>> On Thursday, November 11, 2021 at 3:33:33 PM UTC+13, Arne Vajhøj wrote:
>>> The biggest problems with UTF-8 is that the byte length is not
>>> necessarily the character length ...
>>
>> That would be true of any Unicode encoding, even UCS-4.
>
> No.
>
> It is a practical problem in UTF-8 as everything not in ASCII is more
> than 1 byte.
>
> It is a theoretical problem in UTF-16 because there are defined unicode
> code points that become more than 2 bytes (they are just extremely
> rare).
>
> It is not a problem for UTF-32 as everything is 4 bytes.

Back when it was called UCS-4, I think that was true. But as far as I
know, all the ones with UTF in the name are varying width. I think
there are a couple of emojis that take more than 4 bytes and would need
two UTF-32 chunks to represent a single character. But even if the
encoding is not varying width, the number of characters displayed might
not match the number of code points because of things like combining
characters.

In article <smji9o$4vb$1@gioia.aioe.org>, Michael Moroney
<moroney@world.std.spaamtrap.com> writes:

> >> EDT fans may want the patch
> >> for its ability to understand terminals with more than 24 lines.
> >
> > Will the patch become standard? Not that I need a terminal with more
> > than 24 lines. :-)
> >
> It's a regular patch for VSI V8.4-2x and is already part of 9.X.

Nice to see that EDT is still under active maintenance and even
development at VSI. :-D

On 11/11/2021 1:33 PM, Phillip Helbig (undress to reply) wrote:
> In article <smji9o$4vb$1@gioia.aioe.org>, Michael Moroney
> <moroney@world.std.spaamtrap.com> writes:
>
>>>> EDT fans may want the patch
>>>> for its ability to understand terminals with more than 24 lines.
>>>
>>> Will the patch become standard? Not that I need a terminal with more
>>> than 24 lines. :-)
>>>
>> It's a regular patch for VSI V8.4-2x and is already part of 9.X.
>
> Nice to see that EDT is still under active maintenance and even
> development at VSI. :-D
>

Don't be too sure about that. I believe Michael mentioned in the past
that he did the mod on his own, ie; not assigned work. I could mis-remember.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On Thursday, November 11, 2021 at 1:18:24 AM UTC-5, Michael Moroney wrote:
> There is an EDT patch which makes it more ISO-8859-1 friendly, actually
> prompted by a customer who used EDT for strictly ASCII except for a
> character at the 'þ' position (but not þ). EDT fans may want the patch
> for its ability to understand terminals with more than 24 lines.

The patch breaks some features when used with KEA!420
(I don't have a real DEC terminal to test with).

If you have KEA!420 if you use gold 7 show buf it will not display the buffers

Here is what EDT on Alpha OpenVMS V8.3 looks like.

Command: show buf
=T 1 lines
MAIN No lines
PASTE No lines
Press return to continue

Same on IA64 OpenVMS V8.4-2L1

Command: show buf
Press return to continue

The work around is to use ^Z to drop into command mode
*show buf
=T 1 lines
MAIN No lines
PASTE No lines
* Then use c to return to screen (change?) mode.

Oddly it does work correctly with putty.

I have always found that KEA!420 was a pretty good emulator, but this is a
case that putty works better, and it does support more lines.

If someone has a real VT terminal, it would be interesting to see if it
works correctly. (correctly meaning the way it always has worked before).

On 11/11/2021 1:17 PM, Craig A. Berry wrote:
> On 11/11/21 10:21 AM, Arne Vajhøj wrote:
>> On 11/10/2021 11:48 PM, Lawrence D’Oliveiro wrote:
>>> On Thursday, November 11, 2021 at 3:33:33 PM UTC+13, Arne Vajhøj wrote:
>>>> The biggest problems with UTF-8 is that the byte length is not
>>>> necessarily the character length ...
>>>
>>> That would be true of any Unicode encoding, even UCS-4.
>>
>> No.
>>
>> It is a practical problem in UTF-8 as everything not in ASCII is more
>> than 1 byte.
>>
>> It is a theoretical problem in UTF-16 because there are defined unicode
>> code points that become more than 2 bytes (they are just extremely
>> rare).
>>
>> It is not a problem for UTF-32 as everything is 4 bytes.
>
> Back when it was called UCS-4, I think that was true.  But as far as I
> know, all the ones with UTF in the name are varying width.  I think
> there are a couple of emojis that take more than 4 bytes and would need
> two UTF-32 chunks to represent a single character.

A few quotes from the standard:

<quote>
In the Unicode Standard, the codespace consists of the integers from 0
to 10FFFF16, comprising 1,114,112 code points available for assigning
the repertoire of abstract characters.
</quote>

<quote>
Each Unicode code point is represented directly by a single 32-bit
code unit. Because of this, UTF-32 has a one-to-one relationship
between encoded character and code unit; it is a fixed-width character
encoding form.
</quote>

> But even if the
> encoding is not varying width, the number of characters displayed might
> not match the number of code points because of things like combining
> characters.

Display is another issue - a way more complex issue.

Arne

On Thursday, November 11, 2021 at 1:45:36 PM UTC-5, Jon Pinkley wrote:
> On Thursday, November 11, 2021 at 1:18:24 AM UTC-5, Michael Moroney wrote:
> > There is an EDT patch which makes it more ISO-8859-1 friendly, actually
> > prompted by a customer who used EDT for strictly ASCII except for a
> > character at the 'þ' position (but not þ). EDT fans may want the patch
> > for its ability to understand terminals with more than 24 lines.
> The patch breaks some features when used with KEA!420
> (I don't have a real DEC terminal to test with).
>
> If you have KEA!420 if you use gold 7 show buf it will not display the buffers
>
> Here is what EDT on Alpha OpenVMS V8.3 looks like.
>
>
> Command: show buf
> =T 1 lines
> MAIN No lines
> PASTE No lines
> Press return to continue
>
> Same on IA64 OpenVMS V8.4-2L1
>
>
> Command: show buf
> Press return to continue
>
> The work around is to use ^Z to drop into command mode
> *show buf
> =T 1 lines
> MAIN No lines
> PASTE No lines
> *
> Then use c to return to screen (change?) mode.
>
> Oddly it does work correctly with putty.
>
> I have always found that KEA!420 was a pretty good emulator, but this is a
> case that putty works better, and it does support more lines.
>
> If someone has a real VT terminal, it would be interesting to see if it
> works correctly. (correctly meaning the way it always has worked before).

I should have said

Same on IA64 OpenVMS V8.4-2L1 with EDT patch applied

On 11/11/21 12:53 PM, Arne Vajhøj wrote:
> On 11/11/2021 1:17 PM, Craig A. Berry wrote:
>> On 11/11/21 10:21 AM, Arne Vajhøj wrote:
>>> On 11/10/2021 11:48 PM, Lawrence D’Oliveiro wrote:
>>>> On Thursday, November 11, 2021 at 3:33:33 PM UTC+13, Arne Vajhøj wrote:
>>>>> The biggest problems with UTF-8 is that the byte length is not
>>>>> necessarily the character length ...
>>>>
>>>> That would be true of any Unicode encoding, even UCS-4.
>>>
>>> No.
>>>
>>> It is a practical problem in UTF-8 as everything not in ASCII is more
>>> than 1 byte.
>>>
>>> It is a theoretical problem in UTF-16 because there are defined unicode
>>> code points that become more than 2 bytes (they are just extremely
>>> rare).
>>>
>>> It is not a problem for UTF-32 as everything is 4 bytes.
>>
>> Back when it was called UCS-4, I think that was true.  But as far as I
>> know, all the ones with UTF in the name are varying width.  I think
>> there are a couple of emojis that take more than 4 bytes and would need
>> two UTF-32 chunks to represent a single character.
>
> A few quotes from the standard:
>
> <quote>
> In the Unicode Standard, the codespace consists of the integers from 0
> to 10FFFF16, comprising 1,114,112 code points available for assigning
> the repertoire of abstract characters.
> </quote>
>
> <quote>
> Each  Unicode  code  point  is  represented directly by a single 32-bit
> code unit. Because of this, UTF-32 has a one-to-one relationship
> between encoded character and code unit; it is a fixed-width character
> encoding form.
> </quote>

Hmm. You're right. For some reason I had thought they'd blown the
4-byte limit with emojis, but it doesn't seem UTF-32 has any provision
for surrogate pairs.

>>                                                  But even if the
>> encoding is not varying width, the number of characters displayed might
>> not match the number of code points because of things like combining
>> characters.
>
> Display is another issue - a way more complex issue.
>
> Arne
>

On 11/11/2021 1:40 PM, Dave Froble wrote:
> On 11/11/2021 1:33 PM, Phillip Helbig (undress to reply) wrote:
>> In article <smji9o$4vb$1@gioia.aioe.org>, Michael Moroney
>> <moroney@world.std.spaamtrap.com> writes:
>>
>>>>> EDT fans may want the patch
>>>>> for its ability to understand terminals with more than 24 lines.
>>>>
>>>> Will the patch become standard?  Not that I need a terminal with more
>>>> than 24 lines.  :-)
>>>>
>>> It's a regular patch for VSI V8.4-2x and is already part of 9.X.
>>
>> Nice to see that EDT is still under active maintenance and even
>> development at VSI.  :-D

It really isn't.

> Don't be too sure about that.  I believe Michael mentioned in the past
> that he did the mod on his own, ie; not assigned work.  I could
> mis-remember.
>

You remember correctly. The hardwired '24 line terminal' assumption
pissed me off and a few times I looked at it I said no way I can fix
that spaghetti code. But one day the planets were aligned or something,
and I just did it.

On 11/11/2021 3:57 PM, Michael Moroney wrote:
> On 11/11/2021 1:40 PM, Dave Froble wrote:
>> On 11/11/2021 1:33 PM, Phillip Helbig (undress to reply) wrote:
>>> In article <smji9o$4vb$1@gioia.aioe.org>, Michael Moroney
>>> <moroney@world.std.spaamtrap.com> writes:
>>>
>>>>>> EDT fans may want the patch
>>>>>> for its ability to understand terminals with more than 24 lines.
>>>>>
>>>>> Will the patch become standard?  Not that I need a terminal with more
>>>>> than 24 lines.  :-)
>>>>>
>>>> It's a regular patch for VSI V8.4-2x and is already part of 9.X.
>>>
>>> Nice to see that EDT is still under active maintenance and even
>>> development at VSI.  :-D
>
> It really isn't.
>
>> Don't be too sure about that.  I believe Michael mentioned in the past
>> that he did the mod on his own, ie; not assigned work.  I could
>> mis-remember.
>>
>
> You remember correctly. The hardwired '24 line terminal' assumption
> pissed me off and a few times I looked at it I said no way I can fix
> that spaghetti code. But one day the planets were aligned or something,
> and I just did it.

Macro-32 ?

Arne

On 11/11/2021 4:01 PM, Arne Vajhøj wrote:
> On 11/11/2021 3:57 PM, Michael Moroney wrote:

>> You remember correctly. The hardwired '24 line terminal' assumption pissed me
>> off and a few times I looked at it I said no way I can fix that spaghetti
>> code. But one day the planets were aligned or something, and I just did it.
>
> Macro-32 ?

BLISS-32

--
-- Rob