EDT patch.

[Jan-Erik Söderholm]

Hi.

Just received an mail notification about patch VMS842L2A_EDT-V0100.
I do not remember when I last time saw an EDT patch released...

From the description of the patch I can just quote this part:

“The screen is no longer treated as a hard-coded 24 line terminal
window. The actual terminal page size is used and large format
virtual terminals now use the full page size for editing.”

[Bill Gunshannon]

Wow... can I apply that patch to the EDT I have been
using on RSTS/E lately? :-)

bill

[Phillip Helbig (undress to reply)]

In article <r743jp$nqi$1...@dont-email.me>,
Jan-Erik_Söderholm?= <jan-erik....@telia.com>
writes:

> Just received an mail notification about patch VMS842L2A_EDT-V0100.
> I do not remember when I last time saw an EDT patch released...

Some things are so good that they almost never have to be fixed. :-)

> From the description of the patch I can just quote this part:
>
> `The screen is no longer treated as a hard-coded 24 line terminal
> window. The actual terminal page size is used and large format

> virtual terminals now use the full page size for editing.'

While I tend to use 24-line terminals even with DECwindows when more are
available, this is a nice feature.

What about two other nice features: lines longer than 255 characters and
more than 65,535 actions in one command?

[Jan-Erik Söderholm]

Check the rel.notes. I do not know if they are public...

[Simon Clubley]

That was discussed here last year by the person who did the work.

It is interesting however that VSI turned it into an actual patch
instead of just releasing it in the next version of VSI VMS.

Now, I wonder how they are doing with their replacement for TECO ? :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

[Robert A. Brooks]

On 4/14/2020 8:16 AM, Simon Clubley wrote:

> It is interesting however that VSI turned it into an actual patch instead of
> just releasing it in the next version of VSI VMS.

There was an actual bug fixed, having to do with the display of certain 8-bit
characters.

--
-- Rob

[Robert A. Brooks]

On 4/14/2020 7:40 AM, Phillip Helbig (undress to reply) wrote:

> What about two other nice features: lines longer than 255 characters and
> more than 65,535 actions in one command?

No, those shortcomings were not addressed.

--
-- Rob

[Robert A. Brooks]

On 4/14/2020 7:33 AM, Bill Gunshannon wrote:

> Wow...  can I apply that patch to the EDT I have been
> using on RSTS/E lately?  :-)

Given that it was common source between the 11's and VMS, the fix would
work on the 11's.

--
-- Rob

[Dave Froble]

On 4/14/2020 7:40 AM, Phillip Helbig (undress to reply) wrote:

Ya know, I doubt this was on VSI's roadmap.

I believe it was Michael a while back that mentioned this modification.
Could be wrong. But it was mentioned some months ago. Some thanks are
due to whoever took the time and effort to get it into the official
distribution.

But no good deed ever seems to go unpunished. Give some people an inch,
and they want your entire arm. On their terms. For free.

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

[Bill Gunshannon]

I was joking. :-)

I find it hard to believe that the version I am using is
anything more than a distant ancestor to what is running
on VMS today.

I do have to admit that I find EDT to be an outstanding
editor under RSTS/E using Putty as a terminal. All the
keypad stuff works and it even does the 132 Character Mode.

bill

[Phillip Helbig (undress to reply)]

In article <r74dh6$33h$1...@dont-email.me>, "Robert A. Brooks"

I often use the compose character go generate 8-bit characters, which is
similar to ISO-8859-1 and ISO-8859-15. So, I type € and expect the
other (non-VMS) end to see the Euro sign. Works most of the time, and
only a few characters are different.

Are any changes planned here? Perhaps a logical name to specify the
character set?

And why do some 8-bit characters display sometimes as a HEX number and
sometimes as the corresponding symbol?

[Phillip Helbig (undress to reply)]

In article <r74dib$33h$2...@dont-email.me>, "Robert A. Brooks"

In general, if I have to edit a file with long lines, if there are just
a few edits I'll use TPU and if there are many (which can't be easily
automated), I'll use TPU to wrap it then edit with EDT. So this is not
really a big deal. Lines longer than 255 probably shouldn't be read in
an editor anyway.

The 65,535 is a bigger problem.

[Robert A. Brooks]

On 4/14/2020 12:21 PM, Phillip Helbig (undress to reply) wrote:
> Are any changes planned here? Perhaps a logical name to specify the
> character set?
>
> And why do some 8-bit characters display sometimes as a HEX number and
> sometimes as the corresponding symbol?

There is a translation table that was not completely filled in.

This was an accidental fallout from the work done to deal with the
screen size issue.

Mike Moroney noticed that the translation table was not complete, and
filled it in.

As it turns out, that change solved a subsequent customer-reported problem
regarding 8-bit character display, which is why it's being distributed
now as a patch, rather than waiting for the next release of VMS.

--

-- Rob

[John Reagan]

And EDT has been a good stress for BLISS for x86. It uses a number of BLISS constructs (GLOBAL BIND to static data for those of you scoring at home). The model for describing these things is quite different between GEM and LLVM so the GEM-to-LLVM converter has to carefully pick it apart.

[Phillip Helbig (undress to reply)]

In article <r74ojb$let$1...@dont-email.me>, "Robert A. Brooks"

<FIRST...@vmssoftware.com> writes:

> > And why do some 8-bit characters display sometimes as a HEX number and
> > sometimes as the corresponding symbol?
>
> There is a translation table that was not completely filled in.
>
> This was an accidental fallout from the work done to deal with the
> screen size issue.

I'm referring to something which has been around for a long time.

Some values are will appear as the hex value in EDT but TYPE shows them
properly, eg the r-in-a-circle registered sign. If entered with cut and
paste or compose it shows up as ® (8-b-t character) but as soon as
the screen is refreshed it appears a <XAE> (5 7-bit characters to show
what one 8-bit character in hex display looks lie. If entered with PF1
number PF1 KP3 then it is the hex value from the beginning.

[Phillip Helbig (undress to reply)]

In article <7074790a-797f-489e...@googlegroups.com>, John

I've spent years of my life in EDT. Good that I can spend the rest of
my life there.

I guess that most people who have used it know only the very basic stuff
about it. But it is powerful, has few bugs, and is fast.

That BLISS is working on x86 bodes well for the Rdb port. :-)

[Robert A. Brooks]

On 4/14/2020 1:11 PM, Phillip Helbig (undress to reply) wrote:
> In article <r74ojb$let$1...@dont-email.me>, "Robert A. Brooks"
> <FIRST...@vmssoftware.com> writes:
>
>>> And why do some 8-bit characters display sometimes as a HEX number and
>>> sometimes as the corresponding symbol?
>>
>> There is a translation table that was not completely filled in.
>>
>> This was an accidental fallout from the work done to deal with the
>> screen size issue.
>
> I'm referring to something which has been around for a long time.

Yeah, my response was not clear.

I meant to state that whilst Mike was fixing the screen size issue, he
noticed the incomplete translation table, so he fully populated it.

I did not mean to imply that he inadvertently broke, then fixed, the
translation table.


--
-- Rob

[Arne Vajhøj]

On 4/14/2020 1:13 PM, Phillip Helbig (undress to reply) wrote:
> I've spent years of my life in EDT. Good that I can spend the rest of
> my life there.
>
> I guess that most people who have used it know only the very basic stuff
> about it. But it is powerful, has few bugs, and is fast.

Fast is not difficult.

Fast with few resources is difficult.

And EDT delivers that.

Arne

[Michael Moroney]

hel...@asclothestro.multivax.de (Phillip Helbig (undress to reply)) writes:

>In article <r74dh6$33h$1...@dont-email.me>, "Robert A. Brooks"
><FIRST...@vmssoftware.com> writes:

>> On 4/14/2020 8:16 AM, Simon Clubley wrote:
>>
>> > It is interesting however that VSI turned it into an actual patch instead of
>> > just releasing it in the next version of VSI VMS.
>>
>> There was an actual bug fixed, having to do with the display of certain 8-bit
>> characters.

>I often use the compose character go generate 8-bit characters, which is

>similar to ISO-8859-1 and ISO-8859-15. So, I type ? and expect the

>other (non-VMS) end to see the Euro sign. Works most of the time, and
>only a few characters are different.

>Are any changes planned here? Perhaps a logical name to specify the
>character set?

>And why do some 8-bit characters display sometimes as a HEX number and
>sometimes as the corresponding symbol?

That was the "bug" Rob mentioned. What happens its that EDT had a built-in
assumption that the DEC-MCS character set was what is in use. DEC-MCS is what
VT220 etc. terminals have built in. The problem is, DEC-MCS never defined
many of the 8 bit characters. EDT would display them as <XAB> (where AB is
the hex representation of the digit) I don't know what a "real" VTxxx would
display if presented with one of these undefined characters.

ISO-8859-1 is similar to DEC-MCS (it was actually based on DEC-MCS) except
all 8 bit characters were defined. (ISO-8859-15 is similar to ISO-8859-1
except it changed a few things, including changing a "generic currency symbol"
to the Euro symbol)

Anyway, a customer was trying to use EDT with a file with at least some 8 bit
characters and hit one of the undefined DEC-MCS ones. I changed EDT so that
none of the printing 8 bit characters (hex A0-FF) would display as <XAB> but
instead the actual code is sent to the screen. Up to the windowing software/
font to display it as you want but I tried to make things like ISO-8859-15.

This was in addition to something I did a few years back which made EDT respect
the line-column setting of a terminal window rather than assuming that
all CRTs were 24 lines (hardcoded). That code is a bear to work with.

Changing EDT to allow more than 255 characters/line is problematic since
it assumes everywhere (hardcoded) that the column counter is an unsigned byte.
I didn't look at the 65535 actions thing but that stinks of a similar
word-sized field.

So you'll want the EDT patch.

[Phillip Helbig (undress to reply)]

In article <r750hl$hrt$1...@pcls7.std.com>, mor...@world.std.spaamtrap.com

(Michael Moroney) writes:

> That was the "bug" Rob mentioned. What happens its that EDT had a built-in
> assumption that the DEC-MCS character set was what is in use. DEC-MCS is what
> VT220 etc. terminals have built in. The problem is, DEC-MCS never defined
> many of the 8 bit characters. EDT would display them as <XAB> (where AB is
> the hex representation of the digit)

> Anyway, a customer was trying to use EDT with a file with at least some 8 bit
> characters and hit one of the undefined DEC-MCS ones. I changed EDT so that
> none of the printing 8 bit characters (hex A0-FF) would display as <XAB> but
> instead the actual code is sent to the screen.

OK.

> I don't know what a "real" VTxxx would
> display if presented with one of these undefined characters.

> Up to the windowing software/
> font to display it as you want but I tried to make things like ISO-8859-15.

So what did you test it with---apparently not a real VTXXX. With a
DECterm? With something else?

> So you'll want the EDT patch.

Presumably I'll have to upgrade my VMS first. :-|

I plan to; I'm just holding out until vms on x86 is available, the
necessary hardware is cheap enough, and the upgrade path clear. None of
these is clear now, at least not to me.

[Michael Moroney]

Dave Froble <da...@tsoft-inc.com> writes:

>On 4/14/2020 7:40 AM, Phillip Helbig (undress to reply) wrote:
>> In article <r743jp$nqi$1...@dont-email.me>,
>> Jan-Erik_Söderholm?= <jan-erik....@telia.com>
>> writes:
>>
>>> Just received an mail notification about patch VMS842L2A_EDT-V0100.
>>> I do not remember when I last time saw an EDT patch released...
>>
>> Some things are so good that they almost never have to be fixed. :-)
>>
>>> From the description of the patch I can just quote this part:
>>>
>>> `The screen is no longer treated as a hard-coded 24 line terminal
>>> window. The actual terminal page size is used and large format
>>> virtual terminals now use the full page size for editing.'
>>
>> While I tend to use 24-line terminals even with DECwindows when more are
>> available, this is a nice feature.
>>
>> What about two other nice features: lines longer than 255 characters and
>> more than 65,535 actions in one command?
>>

>Ya know, I doubt this was on VSI's roadmap.

It wasn't. I did it on the spur of the moment.

>I believe it was Michael a while back that mentioned this modification.
>Could be wrong. But it was mentioned some months ago. Some thanks are
>due to whoever took the time and effort to get it into the official
>distribution.

The 24 line restriction was something that bothered me for 20+ years.
A few times I pulled the sources for a look and decided I didn't want to mess
with that. Then something put a bug in my ear to look at it and I did, with
the intent to see how much work was really needed. The window (terminal) height
was hardcoded as 24 and I changed the relevant values to something like 40.
I decided to try and build it and after a few dumb mistakes I tried it and
it worked as a 40 line window. I made a few more changes to make it changeable
and set it to the terminal's actual height (and width) and in a half day it was
mostly working.

Not perfect, a last minute issue when a tester noticed upon exiting EDT changes
the screen width to 132 (or 80), regardless of your original screen width.
I didn't notice because my terminal emulator ignored the relevant escape
sequence, and this didn't get fixed. It's also something else EDT always did
since EDT assumed your terminal could be any width you wanted, as long as you
wanted either an 80 or 132 column width.

>But no good deed ever seems to go unpunished. Give some people an inch,
>and they want your entire arm. On their terms. For free.

No punishment yet other than comments from Hoff regarding ancient software.
But a few from within VSI thanked me.

[Jan-Erik Söderholm]

Den 2020-04-14 kl. 22:36, skrev Phillip Helbig (undress to reply):
> In article <r750hl$hrt$1...@pcls7.std.com>, mor...@world.std.spaamtrap.com
> (Michael Moroney) writes:
>
>> That was the "bug" Rob mentioned. What happens its that EDT had a built-in
>> assumption that the DEC-MCS character set was what is in use. DEC-MCS is what
>> VT220 etc. terminals have built in. The problem is, DEC-MCS never defined
>> many of the 8 bit characters. EDT would display them as <XAB> (where AB is
>> the hex representation of the digit)
>
>> Anyway, a customer was trying to use EDT with a file with at least some 8 bit
>> characters and hit one of the undefined DEC-MCS ones. I changed EDT so that
>> none of the printing 8 bit characters (hex A0-FF) would display as <XAB> but
>> instead the actual code is sent to the screen.
>
> OK.
>
>> I don't know what a "real" VTxxx would
>> display if presented with one of these undefined characters.
>
>> Up to the windowing software/
>> font to display it as you want but I tried to make things like ISO-8859-15.
>
> So what did you test it with---apparently not a real VTXXX.

I hope not! :-)
Hopefully with some of the common Windows based terminal emulators.

[Phillip Helbig (undress to reply)]

In article <r750hl$hrt$1...@pcls7.std.com>, mor...@world.std.spaamtrap.com
(Michael Moroney) writes:

> That was the "bug" Rob mentioned. What happens its that EDT had a built-in
> assumption that the DEC-MCS character set was what is in use. DEC-MCS is what
> VT220 etc. terminals have built in. The problem is, DEC-MCS never defined
> many of the 8 bit characters. EDT would display them as <XAB> (where AB is
> the hex representation of the digit) I don't know what a "real" VTxxx would
> display if presented with one of these undefined characters.

Yesterday I was at a DECterm. For character 174, ®, the
R-in-a-circle registered symbol, EDT has <XAE> if entered with PF1 174
PF1 KP3 and the R in a circle if entered with cut and paste or with
compose o r, but it goes back to <XAE> as soon as the screen is
refreshed. LYNX shows the r in a circle. Today, on a real VT220, also
<XAE> if entered via PF1 174 PF1 KP3 and NOTHING (not invisible, just
nothing) if entered with compose o r. TYPE and LYNX show a boldface
backward question mark (like TPU shows for some (all?) 8-bit characters.

If you have Fortran installed, HELP FORTRAN CHAR DEC gives a nice table
(with ASCII instead of DEC you get the ASCII table).

[Phillip Helbig (undress to reply)]

In article <r759fv$nqi$3...@dont-email.me>,
=?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik....@telia.com>
writes:

> >> I don't know what a "real" VTxxx would
> >> display if presented with one of these undefined characters.
> >
> >> Up to the windowing software/
> >> font to display it as you want but I tried to make things like ISO-8859-15.
> >
> > So what did you test it with---apparently not a real VTXXX.
>
> I hope not! :-)
> Hopefully with some of the common Windows based terminal emulators.

It should certainly be tested with a real VT, just to see what happens.
Since I doubt that there will be a firmware update for them, we can't
expect it to be fixed, but it at least shouldn't break anything. Of
course, it should be tested with other terminal emulators, especially
DECterm.

Some VT terminals have the possibility to load a character set.
Presumably one could use this feature to get the missing characters to
be displayed properly.

I like ISO-8859-15. While I tend to use the abbreviations or numerical
HTML codes for portability, one can use 8-bit characters and get them to
display correctly by specifying the character set.

Occasionally I need to print something out in Cyrillic characters, but
want to write the text on a VT or in a DECterm. So I wrote a DCL
procedure which translates abbreviations like ZH (the real Z and H never
occur together in the languages in question) to the corresponding 8-bit
Cyrillic characters. It looks like gibberisch on the screen, but in an
HTML page with the appropriate character set specified, it looks
perfect.

[Phillip Helbig (undress to reply)]

In article <r76doq$1878$1...@gioia.aioe.org>,

hel...@asclothestro.multivax.de (Phillip Helbig (undress to reply))
writes:

> Yesterday I was at a DECterm. For character 174, ®, the
> R-in-a-circle registered symbol, EDT has <XAE> if entered with PF1 174
> PF1 KP3 and the R in a circle if entered with cut and paste or with
> compose o r, but it goes back to <XAE> as soon as the screen is
> refreshed. LYNX shows the r in a circle. Today, on a real VT220, also
> <XAE> if entered via PF1 174 PF1 KP3 and NOTHING (not invisible, just
> nothing) if entered with compose o r. TYPE and LYNX show a boldface
> backward question mark (like TPU shows for some (all?) 8-bit characters.

Also the same in NEWSRDR.

Does the latest TPU still show the boldface reversed question mark for
eight-bit characters? Ancient versions of EDT at least show the hex
value so that you know what you are dealing with even if it can't be
displayed correctly.

[Michael Moroney]

hel...@asclothestro.multivax.de (Phillip Helbig (undress to reply)) writes:

>Does the latest TPU still show the boldface reversed question mark for
>eight-bit characters?

That is an effect of the terminal/terminal emulator when presented with unknown
8 bit codes. It sounds like TPU is transmitting the 8 bit characters
unchanged, which is what the EDT patch does. Are you using a real VTxxx?
An emulator set to use UTF-8? (don't use that for VMS even though it's used
everywhere else)

> Ancient versions of EDT at least show the hex
>value so that you know what you are dealing with even if it can't be
>displayed correctly.

With PuTTY you can select the character set. It has DEC-MCS, ISO-8859-1 and
ISO-8859-15 as well as a zillion others so PuTTY users can play around.
The default is UTF-8 which will really mess up all 8 bit characters on VMS.

With a real terminal it would likely be a difficult(?) one time effort to find
or create a VTxxx ISO-8859-1/ISO-8859-15 font. Once created, TYPE on VMS should
be able to load it, stick that in LOGIN.COM.

[Phillip Helbig (undress to reply)]

In article <r77gli$8ha$1...@pcls7.std.com>, mor...@world.std.spaamtrap.com

(Michael Moroney) writes:

> >eight-bit characters?
>
> That is an effect of the terminal/terminal emulator when presented with unknown
> 8 bit codes. It sounds like TPU is transmitting the 8 bit characters
> unchanged, which is what the EDT patch does. Are you using a real VTxxx?
> An emulator set to use UTF-8? (don't use that for VMS even though it's used
> everywhere else)

Either DECterm or real VT (usually 320---probably my favourite model---;
I have several of them and also a few each of 510 and 220. I also have
a 420, a 520, and a 102.

It's not JUST a terminal(-emulator) things because the same character is
displayed differently in TPU and EDT.

> With a real terminal it would likely be a difficult(?) one time effort
> to find or create a VTxxx ISO-8859-1/ISO-8859-15 font. Once created,
> TYPE on VMS should be able to load it, stick that in LOGIN.COM.

You mean the "downloadable font" stuff?

[Michael Moroney]

hel...@asclothestro.multivax.de (Phillip Helbig (undress to reply)) writes:

>In article <r77gli$8ha$1...@pcls7.std.com>, mor...@world.std.spaamtrap.com
>(Michael Moroney) writes:

>> >eight-bit characters?
>>
>> That is an effect of the terminal/terminal emulator when presented with unknown
>> 8 bit codes. It sounds like TPU is transmitting the 8 bit characters
>> unchanged, which is what the EDT patch does. Are you using a real VTxxx?
>> An emulator set to use UTF-8? (don't use that for VMS even though it's used
>> everywhere else)

>Either DECterm or real VT (usually 320---probably my favourite model---;
>I have several of them and also a few each of 510 and 220. I also have
>a 420, a 520, and a 102.

I don't know what character set DECterms use. Or wheter it can be changed.

>It's not JUST a terminal(-emulator) things because the same character is
>displayed differently in TPU and EDT.

EDT assumes (assumed) DEC-MCS is being used and changed undefined characters
before sending them.

>> With a real terminal it would likely be a difficult(?) one time effort
>> to find or create a VTxxx ISO-8859-1/ISO-8859-15 font. Once created,
>> TYPE on VMS should be able to load it, stick that in LOGIN.COM.

>You mean the "downloadable font" stuff?

Yes. I know of no real world examples of that, other than rumors of april fool
jokes where all the characters were backwards or something.

[Arne Vajhøj]

If somebody want to try and have a real VT terminal or a very good
terminal emulator then:
* download https://www.vajhoej.dk/arne/info-vax/fontgen/fontgen.zip
* compile, link and run fontgen.pas
* type font1.fnt or font2.fnt

I think it is for VT320, but it is a long time ago.

And if somebody wonder WTF a Pascal program has to do with
it, then it works like this:
- there is a fontx.dat file with an ASCII picture of letters
- the fontgen program converts that fontx.dat to a fontx.fnt
with the VT escape sequence

That way it is actually easy to design ones font.

If someone think that I had too much time on my hands
25 years ago, then they are probably right.

:-)

Arne

[Henry Crun]

way back in the last century (under RSTS IIRC) I wasted some time building a downloadable Hebrew cursive font.
If I still have it, its on a RSTS Backup TK50 cassette -- so in effect its lost...

--
Mike R.
Home: http://alpha.mike-r.com/
QOTD: http://alpha.mike-r.com/qotd.php
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#before
and: http://alpha.mike-r.com/jargon/T/top-post.html
Missile address: N31.7624/E34.9691

[Phillip Helbig (undress to reply)]

In article <r77r47$gip$1...@pcls7.std.com>, mor...@world.std.spaamtrap.com

(Michael Moroney) writes:

> EDT assumes (assumed) DEC-MCS is being used and changed undefined characters
> before sending them.

OK. Maybe TPU sends just the raw hex. I was thinking that all the
interpretation was done in the emulator or terminal, but apparently not.

> >> With a real terminal it would likely be a difficult(?) one time effort
> >> to find or create a VTxxx ISO-8859-1/ISO-8859-15 font. Once created,
> >> TYPE on VMS should be able to load it, stick that in LOGIN.COM.
>
> >You mean the "downloadable font" stuff?
>
> Yes. I know of no real world examples of that, other than rumors of april fool
> jokes where all the characters were backwards or something.

I've actually seen that. Read about it here, downloaded it, and tried
it out.

[Michael Moroney]

hel...@asclothestro.multivax.de (Phillip Helbig (undress to reply)) writes:

A little googling found some code that claims to be able to display black and
white .GIFs on a VT300 and later. I downloaded it but haven't tried it yet.
I guess those dumb terminals weren't quite so dumb after all.

[Phillip Helbig (undress to reply)]

In article <r78t2d$u34$1...@pcls7.std.com>, mor...@world.std.spaamtrap.com

(Michael Moroney) writes:

> A little googling found some code that claims to be able to display black and
> white .GIFs on a VT300 and later. I downloaded it but haven't tried it yet.
> I guess those dumb terminals weren't quite so dumb after all.

Back in the day, while the terminals were dumb, the programmers were
smart. :-)

[Bill Gunshannon]

On 4/16/20 2:13 AM, Michael Moroney wrote:
>

OK, I have to ask, Michael, are you a ham radio operator?

bill
KB3YV

[Bill Gunshannon]

On 4/16/20 2:13 AM, Michael Moroney wrote:

Didn't those later DEC terminals do REXX or something?
Wouldn't make them smart, but graphics capable.

bill

[John E. Malmberg]

On 4/15/2020 3:34 PM, Michael Moroney wrote:
>
> I don't know what character set DECterms use. Or wheter it can be changed.

The DECterm appears to be able to be configured to use any font that is
known to the X-11 server.

The client needs to also be able to access the font.

The easiest way to do that is to use a Alpha or Itanium running VMS as
an X11 font server.

The x11-servers that I have seen for PCs, except for Excursion did not
have the default font for Decterms installed, so that "monitor system"
would not display correctly.

There also seems to be a set of escape sequences unique to DECterms that
I am not sure there is documentation for all of them.

Things that would be nice to fix in DecTERMS:

1. UTF-8 support. Some unknown to me UTF-8 sequence will lock up a DECTerm.

2. There is a bug in the handling of the escape sequences to route data
to an attached printer or in the case of a DECTerm a file to get the
data. The DECTerm incorrectly sends the escape sequences through that
start the transfer with the transfer.

Just for experimentation, I once wrote print symbiont that would use an
attached printer to a terminal. As I recall I never worked out how to
get it to support disconnectable terminals, but it mostly worked. I
think it is on one of the Decus submissions. Testing it on a DECTerm is
how I found that second bug.

Regards,
-John
wb8...@qsl.net_work

[Arne Vajhøj]

Some models above the standard VTx20 did Regis.

Arne

[Phillip Helbig (undress to reply)]

In article <hfr10i...@mid.individual.net>, Bill Gunshannon

<bill.gu...@gmail.com> writes:

> Didn't those later DEC terminals do REXX or something?

ReGiS or something like that.

Take a look at VT100.net for some interesting terminal stuff.

I normally work in a DECterm (several in several CDE workspaces), but am
typing this at a VT320 which I use as the console. As long as I don't
have to use more than one at once, I actually prefer physical terminals.

[Bill Gunshannon]

That's it, Regis. REXX is IBM, I think.
But I was pretty sure higher end DEC terminals did some graphics.

bill

[Roy Omond]

Just wondering if VSI might be so altruistic as to release the
new EDT version to those who do not have a support contract
with VSI.

I would not imagine that there's anything specific in there to
tie it to VSI VMS, since EDT has never required a PAK or any
other licence.

As yet another who has EDT keys tied to my fingertips, I would
love to get this.

Any chance ?

[Michael Moroney]

I was once WA2VXY but I let it lapse long ago.

[Jan-Erik Söderholm]

This REXX?
https://en.wikipedia.org/wiki/Rexx

[Bill Gunshannon]

Just curious as there was picture of a Michael Moroney in the
latest issue of QST. You must admit, not a really common name.

bill

[Bob Eager]

Yup. I use it quite a bit. On UNIX!

--
My posts are my copyright and if @diy_forums or Home Owners' Hub
wish to copy them they can pay me £1 a message.
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor

[Bill Gunshannon]

yeah, that's the one.

bill

[Jan-Erik Söderholm]

OK. Never heard about a (any) *terminal* that runs IBM REXX...
Are you sure it wasn't REGIS?

[Hans Bachner]

Actually, the VT125 was a ReGIS capable terminal as well, of couse
monochrome. The VT240 had an extra box below the (color) monitor which
held the electronics and was (iirc) the first color ReGIS device. The
VT3x0 series offered a monochrome (VT330) and a color (VT340) ReGIS
terminal. I seem to remember that the VT525 was also a color ReGIS
device, not sure about the VT4xx series.

Graphic on a VT300 probably was in sixel format, not ReGIS.

Hans, contributor to an software analysis and design tool using ReGIS
for diagrams (remember Yourdon? Gane&Sarson?) back in the late 80ies
(for DEC internal use only).

[Bill Gunshannon]

We already determined that was the case. Too many similar
named products and too many multi-bit errors at my age.

bill

[Stephen Hoffman]

On 2020-04-16 13:43:57 +0000, Roy Omond said:

> As yet another who has EDT keys tied to my fingertips, I would love to
> get this.

http://texteditors.org/cgi-bin/wiki.pl?EDT
https://web.archive.org/web/20040805101758/http://www.atl.external.lmco.com/proj/csim/gui/edt/edt.html

http://www.o3one.org/edt.html
etc.

Or learn vim, emacs, pico/nano, or whatever happens to be commonly
around. Which usually isn't EDT.

I'd rather see a few of these other editors arrive on OpenVMS, but then
the "OpenVMS must not be contaminated with heathen tools; why don't
people want to use our favorite OS?" runs deep.

Yes, I already have the vim port for OpenVMS. No, I don't use emacs,
and no I don't know of a current port. Yes, I do use pico when that's
what is available. No, I haven't looked for a port. Yes, I use LSEDIT,
too, when that's the available IDE. Etc...

As for the no-support-contract folks and access, donno. VSI might
surprise here, but they've held patches and open source closely.
They've further held the patch notifications closely, and which always
seemed quite absurd.


--
Pure Personal Opinion | HoffmanLabs LLC

[Phillip Helbig (undress to reply)]

In article <r7a24t$fu3$1...@dont-email.me>, Stephen Hoffman

<seao...@hoffmanlabs.invalid> writes:

> On 2020-04-16 13:43:57 +0000, Roy Omond said:
>

> > As yet another who has EDT keys tied to my fingertips, I would love to
> > get this.
>

> http://texteditors.org/cgi-bin/wiki.pl?EDT
> https://web.archive.org/web/20040805101758/http://www.atl.external.lmco.com/proj/csim/gui/edt/edt.html
>
> http://www.o3one.org/edt.html
> etc.

Will these build on VMS? How close are they to EDT? Will all my macros
work?

> Or learn vim, emacs, pico/nano, or whatever happens to be commonly
> around. Which usually isn't EDT.

I've had experience with all of these and more, but none are as good as
EDT. :-)

> I'd rather see a few of these other editors arrive on OpenVMS, but then
> the "OpenVMS must not be contaminated with heathen tools; why don't
> people want to use our favorite OS?" runs deep.

As we have seen with many other things, something ported from VMS is
usually a fork, and subsequent developments aren't incorporated into
VMS. I'd rather see the effort go into improving VMS. The only extra
stuff needed is stuff needed for communication with non-VMS systems,
such as ZIP.

[Stephen Hoffman]

On 2020-04-16 17:15:54 +0000, Phillip Helbig (undress to reply said:

> As we have seen with many other things, something ported from VMS is

> usually a fork...

VMS is a fork of RSX-11, too.

[Michael Moroney]

Bill Gunshannon <bill.gu...@gmail.com> writes:

>On 4/16/20 9:46 AM, Michael Moroney wrote:
>> Bill Gunshannon <bill.gu...@gmail.com> writes:
>>
>>> On 4/16/20 2:13 AM, Michael Moroney wrote:
>>>>
>>
>>> OK, I have to ask, Michael, are you a ham radio operator?
>>
>>> bill
>>> KB3YV
>>
>> I was once WA2VXY but I let it lapse long ago.
>>

>Just curious as there was picture of a Michael Moroney in the
>latest issue of QST. You must admit, not a really common name.

Not me, I'm certain. You are right, Moroney is scarce enough that we Moroneys
notice when encountering another. Michael, on the other hand, was the most
common male first name for the year I was born.

[Phillip Helbig (undress to reply)]

In article <r7a4dj$ug$1...@dont-email.me>, Stephen Hoffman

<seao...@hoffmanlabs.invalid> writes:

> On 2020-04-16 17:15:54 +0000, Phillip Helbig (undress to reply said:
>

> > As we have seen with many other things, something ported from VMS is

> > usually a fork...
>
> VMS is a fork of RSX-11, too.

OK, but there the similarity ends.

[jirk...@gmail.com]

Congratulations Michael !
Best Regards, Jiri

On Tuesday, April 14, 2020 at 8:48:24 PM UTC+2, Michael Moroney wrote:
> hel...@asclothestro.multivax.de (Phillip Helbig (undress to reply)) writes:
>

> >In article <r74dh6$33h$1...@dont-email.me>, "Robert A. Brooks"
> ><FIRST...@vmssoftware.com> writes:
>
> >> On 4/14/2020 8:16 AM, Simon Clubley wrote:
> >>
> >> > It is interesting however that VSI turned it into an actual patch instead of
> >> > just releasing it in the next version of VSI VMS.
> >>
> >> There was an actual bug fixed, having to do with the display of certain 8-bit
> >> characters.
>
> >I often use the compose character go generate 8-bit characters, which is
> >similar to ISO-8859-1 and ISO-8859-15. So, I type ? and expect the
> >other (non-VMS) end to see the Euro sign. Works most of the time, and
> >only a few characters are different.
>
> >Are any changes planned here? Perhaps a logical name to specify the
> >character set?
>
> >And why do some 8-bit characters display sometimes as a HEX number and
> >sometimes as the corresponding symbol?
>
> That was the "bug" Rob mentioned. What happens its that EDT had a built-in
> assumption that the DEC-MCS character set was what is in use. DEC-MCS is what
> VT220 etc. terminals have built in. The problem is, DEC-MCS never defined
> many of the 8 bit characters. EDT would display them as <XAB> (where AB is
> the hex representation of the digit) I don't know what a "real" VTxxx would
> display if presented with one of these undefined characters.
>
> ISO-8859-1 is similar to DEC-MCS (it was actually based on DEC-MCS) except
> all 8 bit characters were defined. (ISO-8859-15 is similar to ISO-8859-1
> except it changed a few things, including changing a "generic currency symbol"
> to the Euro symbol)
>
> Anyway, a customer was trying to use EDT with a file with at least some 8 bit
> characters and hit one of the undefined DEC-MCS ones. I changed EDT so that
> none of the printing 8 bit characters (hex A0-FF) would display as <XAB> but
> instead the actual code is sent to the screen. Up to the windowing software/
> font to display it as you want but I tried to make things like ISO-8859-15.
>
> This was in addition to something I did a few years back which made EDT respect
> the line-column setting of a terminal window rather than assuming that
> all CRTs were 24 lines (hardcoded). That code is a bear to work with.
>
> Changing EDT to allow more than 255 characters/line is problematic since
> it assumes everywhere (hardcoded) that the column counter is an unsigned byte.
> I didn't look at the 65535 actions thing but that stinks of a similar
> word-sized field.
>
> So you'll want the EDT patch.

[Ross Combs]

On Thursday, April 16, 2020 at 4:04:57 PM UTC+2, Hans Bachner wrote:
> [...]

>
> Actually, the VT125 was a ReGIS capable terminal as well, of couse
> monochrome. The VT240 had an extra box below the (color) monitor which
> held the electronics and was (iirc) the first color ReGIS device. The
> VT3x0 series offered a monochrome (VT330) and a color (VT340) ReGIS
> terminal. I seem to remember that the VT525 was also a color ReGIS
> device, not sure about the VT4xx series.

I think the first color ReGIS device was the GIGI. In fact, wasn't that the terminal that ReGIS was designed for?

My understanding is that the VT525 didn't do Sixel or ReGIS, but I'd be very interested to learn that I'm wrong about that.

-Ross