DEC Multinational Character Set, DECterm, EDT: rhyme or reason?

[Phillip Helbig (undress to reply)]

HELP FORTRAN CHAR DEC brings up this table:

+------------------------------------------+
| 8 9 A B C D E F |
+---+--------------------------------------+
| 0 | DCS ° À à |
| 1 | PU1 ¡ ± Á Ñ á ñ |
| 2 | PU2 ¢ ² Â Ò â ò |
| 3 | STS £ ³ Ã Ó ã ó |
| 4 | IND CCH Ä Ô ä ô |
| 5 | NEL MW ¥ µ Å Õ å õ |
| 6 | SSA SPA ¶ Æ Ö æ ö |
| 7 | ESA EPA § · Ç × ç ÷ |
| 8 | HTS š È Ø è ø |
| 9 | HTJ © ¹ É Ù é ù |
| A | VTS ª º Ê Ú ê ú |
| B | PLD CSI « » Ë Û ë û |
| C | PLU ST Œ Ì Ü ì ü |
| D | RI OSC œ Í Ý í ý |
| E | SS2 PM Î î |
| F | SS3 APC ¿ Ï ß ï |
+---+--------------------------------------+

Writing this in a DECterm, it looks now, cut and pasted into EDT, just
as when displayed on the screen by the HELP command. Since this post is
in 8859-15, those characters which are different in the MCS and 8859-15
will of course show up differently, presumably as the EURO sign, upper-
and lower- case "S" and "Z" with what looks like a little "v" on top,
upper- and lower case "OE" ligature, and uppercase "ÿ".

I wrote the last character in the above paragraph, y with diaresis,
which is not visible in the table, as "COMPOSE-y-", and it showed up as
the lower-case y with diaresis, but refreshing the screen makes it show
up as "<XFF>" (though this is one character, not the 5 I have typed in
this sentence). Why is this?

One can enter any character in EDT via GOLD-<value in decimal>-GOLD-KP3.
One can also enter most (all?) of them via COMPOSE. Sometimes these
show up as the proper character, such as "€", which remains after a
refresh. (This is %XA4, 164, and hence different in 8859-15, where it
should be the EURO sign.) Why does this character not show up in the
table above?

Others are visible in the table but when entered show up properly then
as the mnemonic after the refresh, such as Ÿ.

TYPE on such a file displays all characters properly.

Here is the table with the missing characters inserted. Writing this to
a file and displaying it with TYPE works as expected.

+------------------------------------------+
| 8 9 A B C D E F |
+---+--------------------------------------+
| 0 | DCS   ° À Ð à ð |
| 1 | PU1 ¡ ± Á Ñ á ñ |
| 2 | PU2 ¢ ² Â Ò â ò |
| 3 | STS £ ³ Ã Ó ã ó |
| 4 | IND CCH € Ž Ä Ô ä ô |
| 5 | NEL MW ¥ µ Å Õ å õ |
| 6 | SSA SPA Š ¶ Æ Ö æ ö |
| 7 | ESA EPA § · Ç × ç ÷ |
| 8 | HTS š ž È Ø è ø |
| 9 | HTJ © ¹ É Ù é ù |
| A | VTS ª º Ê Ú ê ú |
| B | PLD CSI « » Ë Û ë û |
| C | PLU ST ¬ Œ Ì Ü ì ü |
| D | RI OSC ­ œ Í Ý í ý |
| E | SS2 PM ® Ÿ Î Þ î þ |
| F | SS3 APC ¯ ¿ Ï ß ï ÿ |
+---+--------------------------------------+

It also looks fine (all characters displayed properly) in TPU, except
for %XFF. Why is that?

Of course, if for some reason this post is base-64 encoded and not
decoded, then you will have to correct for this as well.

So, to summarize, why are some characters not in the HELP table? Why
do some appear properly when entered, but change to the mnemonic after a
refresh of the screen? Why are some always displayed as the mnemonic in
EDT? Note again that TYPE shows everything directly.

[Phillip Helbig (undress to reply)]

In article <nn26v0$ekp$1...@news.kjsl.com>, hel...@asclothestro.multivax.de

Reading this in NEWSRDR, also everything shows up properly except %XFF,
which is blank (in TPU it is the bold reverse question mark).

[roger...@gmail.com]

I suspect the basic problem here is that EDT is really old software
and has no idea about 8859-15; it thinks it's dealing strictly
with the DEC Multinational Character Set, in which character 0xff
is specifically designated as an undefined character. See square
15/15 of http://vt100.net/docs/vt220-rm/table2-3b.html which says
(undef) instead of being blank, like square 10/4 (0xa4, which
you also mention).

Since EDT bloody well knows the character is undefined, it displays
it as a hex code, just like it displays control characters.

Allowing you to enter the character and displaying it until you
refresh is probably a bug; I bet EDT just never expected that you would
be able to enter character code 0xff.

Don't know what TPU's excuse is.
--
roger ivie
roger...@gmail.com

[Phillip Helbig (undress to reply)]

In article <38ce2137-844d-4b8f...@googlegroups.com>,

roger...@gmail.com writes:

> I suspect the basic problem here is that EDT is really old software
> and has no idea about 8859-15; it thinks it's dealing strictly
> with the DEC Multinational Character Set, in which character 0xff
> is specifically designated as an undefined character. See square
> 15/15 of http://vt100.net/docs/vt220-rm/table2-3b.html which says
> (undef) instead of being blank, like square 10/4 (0xa4, which
> you also mention).

Most of my comments deal with characters which ARE in the DEC MCS.

> Since EDT bloody well knows the character is undefined, it displays
> it as a hex code, just like it displays control characters.

Looking at just the characters in the DEC MCS, EDT's behaviour is
different for different characters.

[roger...@gmail.com]

On Sunday, July 24, 2016 at 11:54:25 AM UTC-7, Phillip Helbig (undress to reply) wrote:
>
> Most of my comments deal with characters which ARE in the DEC MCS.

Not really. I see two questions in your post:

- Why does this character (the Euro sign) not show up in the table.

If you look at square 10/4 (0xa4) in the VT220 reference manual, you'll
the square is blank; the glyph was not assigned. If you're making a reference
table for a character set that includes unassigned characters, what do you
put in the unassigned squares? There's nothing you *can* put there, so you
leave it blank. If you did put something there, how would you know it's
right? Since the character is unassigned, you can't proofread it.

- Why does 0xff show up as <XFF> instead of y with diaresis?

0xff is a reserved undefined character in MCS. EDT displays it in the
same way as it displays a control character, as a hex sequence.

- Why does it show up properly in TYPE?

Because TYPE doesn't care. It just dumps what's there.

- Why does TPU not display 0xff properly?

Dunno. I suspect it agrees with EDT that it's a reserved undefined
character.

To summarize:

- The spots are missing in the HELP table because the characters were
unassigned when the HELP table was made; there was nothing to put
in those spots.
- EDT and TPU display 0xff as a hex sequence because that character is
reserved as being undefined in MCS. It isn't an unassigned character, it
is assigned to being undefined.
- TYPE displays 0xff properly because it doesn't care.
- EDT and TPU allow you to enter the characters other than 0xff and display
them properly because an unassigned character might not stay unassigned;
it might become assigned in the future.
- You can't enter 0xff and have EDT and TPU display it properly because 0xff
isn't unassigned; it's reserved as undefined.

I'm not seeing the mystery.
--
roger ivie
roger...@gmail.com

[jirk...@gmail.com]

Exactly, EDT behavior is hard-coded in CHAR_INFO table.
There is the only support for dec-mcs charset.
Two bits of each entry define how the character is displayed on the terminal (normal, ^x, <name>, <Xxx>). For 8bit characters, <name> is used on 7bit terminals only. There are other tables for lowercase/uppercase/diacritical/nodiacritical transformations.
TPU use similar tables, but different charinfo values. There are three sets of tables for dec-mcs, iso-latin1, and general charsets. You can select it using /CHARACTER_SET qualifier or TPU$CHARACTER_SET logical name.
In 1990s we patched EDT and TPU executables to be able to edit iso-latin2 files because this functionality was never on the radar screen. Can we change it now?

Jiri Kaspar

[jirk...@gmail.com]

(reformated)

[David Froble]

Just don't break it. EDT works just fine for me ....

:-)

[Phillip Helbig (undress to reply)]

In article <c5d5155b-8451-44ae...@googlegroups.com>,

roger...@gmail.com writes:

> On Sunday, July 24, 2016 at 11:54:25 AM UTC-7, Phillip Helbig (undress to reply) wrote:
> >
> > Most of my comments deal with characters which ARE in the DEC MCS.
>
> Not really. I see two questions in your post:
>
> - Why does this character (the Euro sign) not show up in the table.

THIS was not about the MCS, obviously.

> - The spots are missing in the HELP table because the characters were
> unassigned when the HELP table was made; there was nothing to put
> in those spots.

OK.

> - EDT and TPU display 0xff as a hex sequence because that character is
> reserved as being undefined in MCS. It isn't an unassigned character, it
> is assigned to being undefined.

OK.

> - TYPE displays 0xff properly because it doesn't care.

OK.

> - EDT and TPU allow you to enter the characters other than 0xff and display
> them properly because an unassigned character might not stay unassigned;
> it might become assigned in the future.

OK.

> - You can't enter 0xff and have EDT and TPU display it properly because 0xff
> isn't unassigned; it's reserved as undefined.

OK.

There is still the question why some characters are displayed properly
before a refresh, and as a hex code after that.

[Michael Moroney]

jirk...@gmail.com writes:

>Can we change it now?

I just rebuilt EDT with all the printing 8 bit CHAR_INFO entries changed to
print normally. Works fine on 8 bit terminals. If set /NOEIGHTBIT
it accvios upon encountering one of the new characters because there is no
<name> defined for them.

Will tinker more later.

[Phillip Helbig (undress to reply)]

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

> I just rebuilt EDT

You have the source?

Wasn't EDT VESTed for Alpha?

[hb]

No. TECO was/is VESTed/AESTed, as the file names indicate:
TECO32_TV/TECO32_TV_AV. If you use analyze/image you can see more
translation foot prints. EDT shows none of them.

[Robert A. Brooks]

On 7/26/2016 1:07 AM, Phillip Helbig (undress to reply) wrote:
> In article <nn66t6$grv$1...@pcls7.std.com>, mor...@world.std.spaamtrap.com
> (Michael Moroney) writes:
>
>> I just rebuilt EDT
>
> You have the source?

Mike works at VSI.

--

-- Rob

[Michael Moroney]

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

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

>> I just rebuilt EDT

>You have the source?

My employer, VSI, does.

>Wasn't EDT VESTed for Alpha?

You're probably thinking of TECO. EDT is in Bliss.

[Michael Moroney]

I added some dummy names for all the entries in the CHAR_NAMES
table and it no longer ACCVIOs. It may be foolish to check
something like this in as EDT is ancient and as Hoff points
out there are better alternatives. I'd have to come up with
decent 2 or 3 character names for everything plus fix the
CHAR_INFO table for the types of character.
I would have to assume ISO-8859-1/ISO-8859-15 for this as
these are close to DEC-MCS.

[jirk...@gmail.com]

It is enough for DEC-MCS and ISO-8859-1, but other charsets map
letters in range a0..bf. Changecase, lowercase, and uppercase conversions
do not work for these letters, there are no conversion tables for it.
TPU has such tables, but it does not use them. You can find "xor 20h",
"or 20h", and "and dfh" there as so as in EDT sources.

I also rebuild EDT from sources (actually from source listings), there are
several limitations I'd like to enhance and some new features to add.
VSI definitely has some EDT test-suite to be able to check if EDT still
works as expected. Can I use it to check my EDT build ?
I do not want to brake EDT as David wrote...

[Phillip Helbig (undress to reply)]

In article <nn862o$pbm$1...@pcls7.std.com>, mor...@world.std.spaamtrap.com

(Michael Moroney) writes:

> I added some dummy names for all the entries in the CHAR_NAMES
> table and it no longer ACCVIOs. It may be foolish to check
> something like this in as EDT is ancient and as Hoff points
> out there are better alternatives.

My wild guess is that more than half of the people using VMS use EDT at
least occasionally, and about a third use it almost exclusively.
Multiply that with the time spent using it, and it is a huge fraction of
the time.

> I'd have to come up with
> decent 2 or 3 character names for everything plus fix the
> CHAR_INFO table for the types of character.
> I would have to assume ISO-8859-1/ISO-8859-15 for this as
> these are close to DEC-MCS.

I would go with ISO-8859-15.

[Michael Moroney]

jirk...@gmail.com writes:

>I also rebuild EDT from sources (actually from source listings), there are
>several limitations I'd like to enhance and some new features to add.
>VSI definitely has some EDT test-suite to be able to check if EDT still
>works as expected. Can I use it to check my EDT build ?
>I do not want to brake EDT as David wrote...

I suppose you could send me changes that you have coded and can be added
without breaking anything. I don't want to spend an awful lot of time on
this. But we at VSI wear many hats and I have been encouraged to check in
what I already did. Unfortunately, the annoying 24 line limit appears to
be hardcoded and a real bear to tackle.

I don't think it would be a good idea to give out any test script, also it
may depend on many levels of test SW running it. But any changes will get
tested automagically if any EDT scripts are still enabled by the test
people.

send to first...@vmssoftware.com
Mike Moroney

[Michael Moroney]

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

>I would go with ISO-8859-15.

I guess with the Euro it is pretty obvious this should be the target.

[Simon Clubley]

On 2016-07-25, David Froble <da...@tsoft-inc.com> wrote:
>
> Just don't break it. EDT works just fine for me ....
>
>:-)

Provided you restrict yourself to using a 24 line terminal and provided
you don't want more than one buffer on the screen at the same time.

On the plus side, at least you can use EDT (in line mode at least)
on an ASR 33. That _is_ something which EVE _can't_ do. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Michael Moroney]

mor...@world.std.spaamtrap.com (Michael Moroney) writes:

>Unfortunately, the annoying 24 line limit appears to be hardcoded and a
>real bear to tackle.

I was wrong!

[Robert A. Brooks]

That's Mike's cryptic way of saying that he's figured out how to fix it, and he's provided
VSI folks with a test EDTSHR that checks the terminal page size and uses that to size the
screen.

--

-- Rob

[Simon Clubley]

Actually, I realised what he meant and good for him for fixing it
(I mean that).

Now all Mike needs to do with all this new found screen space is to add
the ability to display multiple windows on the screen at the same time...

Simon.

PS: $ set response/mode=good_natured just in case it isn't obvious. :-)

[Hans Vlems]

I'm not sure that I'd like to see multiple buffers in EDT. I do nearly all my editing in EDT and lots of functions I do by means of a reflex. I cannot tell beforehand which keys to hit, I just know what to do. Changing defaults or the functionality of keys would break a 35 year habit...
Hans

[David Froble]

Hans Vlems wrote:
> I'm not sure that I'd like to see multiple buffers in EDT. I do nearly all my editing in EDT and lots of functions I do by means of a reflex. I cannot tell beforehand which keys to hit, I just know what to do. Changing defaults or the functionality of keys would break a 35 year habit...
> Hans

Ayep ... I'm the same. Hand runs on auto-pilot ...

Except, EDT already has multiple buffers. It's the keypad stuff I'd not want to
see changed. Would have to re-learn all over.

[Jan-Erik Soderholm]

Whas my thought also, EDT already has multiple buffers, just not
visible at the same time. I have never used them, as far as
I can remember.

Anyway, if I need to see multiple files at the same time, I open
multiple emulator windows. Cut-n-paste works just fine between
windows also. The "cut" is automatic in PyTTY when anything is marked
and "paste" is just right-click in another window (and paste works
just as fine in an email with ctrl-V or in anything else).

Finaly, having more lines then 24 (or 23?) in EDT would not hurt...

Jan-Erik.

[David Froble]

Jan-Erik Soderholm wrote:
> Den 2016-07-29 kl. 20:12, skrev David Froble:
>> Hans Vlems wrote:
>>> I'm not sure that I'd like to see multiple buffers in EDT. I do nearly
>>> all my editing in EDT and lots of functions I do by means of a reflex. I
>>> cannot tell beforehand which keys to hit, I just know what to do.
>>> Changing defaults or the functionality of keys would break a 35 year
>>> habit...
>>> Hans
>>
>> Ayep ... I'm the same. Hand runs on auto-pilot ...
>>
>> Except, EDT already has multiple buffers. It's the keypad stuff I'd not
>> want to see changed. Would have to re-learn all over.
>
> Whas my thought also, EDT already has multiple buffers, just not
> visible at the same time. I have never used them, as far as
> I can remember.

Unless I'm doing something trivial, I often use multiple buffers. Lots of
reasons. Perhaps you want to cut or copy something to a buffer, perhaps to
write it out. Or you use a buffer to pull in some code that you want to extract
some pieces for the main buffer. Very useful.

[Hans Vlems]

I use multiple buffers in EDT all the time. However I prefer too see just one of them.
Hans

[Jan-Erik Soderholm]

Den 2016-07-30 kl. 04:57, skrev David Froble:
> Jan-Erik Soderholm wrote:
>> Den 2016-07-29 kl. 20:12, skrev David Froble:
>>> Hans Vlems wrote:
>>>> I'm not sure that I'd like to see multiple buffers in EDT. I do nearly
>>>> all my editing in EDT and lots of functions I do by means of a reflex. I
>>>> cannot tell beforehand which keys to hit, I just know what to do.
>>>> Changing defaults or the functionality of keys would break a 35 year
>>>> habit...
>>>> Hans
>>>
>>> Ayep ... I'm the same. Hand runs on auto-pilot ...
>>>
>>> Except, EDT already has multiple buffers. It's the keypad stuff I'd not
>>> want to see changed. Would have to re-learn all over.
>>
>> Whas my thought also, EDT already has multiple buffers, just not
>> visible at the same time. I have never used them, as far as
>> I can remember.
>
> Unless I'm doing something trivial, I often use multiple buffers. Lots of
> reasons. Perhaps you want to cut or copy something to a buffer, perhaps to
> write it out. Or you use a buffer to pull in some code that you want to
> extract some pieces for the main buffer. Very useful.
>

Of course, I do the same, just with multiple windows. More lines
visible in each file. Can easily be on different systems. For small
files I usualy just TYPE the file in the other window, no reason to
even start EDT. Just scroll the window to copy the relevant part.

The cut-n-paste using the mouse is far faster then SELecting in
EDT using the keyboard, at least for the usual <20 lines copies.

[Paul Sture]

copy-n-paste using the mouse converts tabs to spaces, and the number of
spaces will represent the tab stops of the source window. In many cases
this won't matter, but for source files which specifically use tabs, EDT
(or EVE) copy-n-paste will transfer the information correctly, also
stuff like embedded <ff>, <cr>, <lf> etc.

As an aside I've just looked at what happens on OS X here. The first
thing to note is that mouse copy-n-paste only works across windows
within an application, not across separate applications. e.g. you
can't mouse-paste from xterm to Terminal or vice versa.

* - unsurprisingly, xterm does the same thing as a DECterm on VMS;
tabs are converted to spaces during display, so mouse copy-n-paste
transfers spaces
* - OS X Terminal does remember where tabs are in the source, even
where you have used 'cat' (the *nix equivalent of TYPE).
* - iTerm2 (beta V3.0.5) faithfully copies tabs instead of spaces in
the same fashion as Terminal, but has the added functionality of
popping up a dialogue when tabs are detected in the source, asking
whether to convert to spaces, if so how many spaces per tab, with a
"don't ask again" option.
iTerm2 also pops up a warning dialogue when mouse pasting multiple
lines, again with a "don't ask again" option.

--
A software-enabled, network connected, crowd funded, smart toaster is,
when all is said and done, still just a toaster. -- Elad Gil

[Steven Schweda]

> As an aside I've just looked at what happens on OS X here.
> The first thing to note is that mouse copy-n-paste only works
> across windows within an application, not across separate
> applications. e.g. you can't mouse-paste from xterm to
> Terminal or vice versa.

Perhaps _you_ can't. I do it all the time. XQuartz
Preferences has a bunch of Pasteboard options, of which I've
checked all but the last ("Update Pasteboard immediately when
new text is selected.", because it says "Due to limitations
in the X11 protocol, this option may not always work in some
applications.").

X11 and OS X ("MacOS"?) maintain separate copy+paste
buffers, but Cmd-C seems to synchronize them. So, for
example, I selected the quoted text above in Firefox (showing
Google Groups), hit Cmd-C (OS X copy), and then pasted it
into an Xterm (SSH to VMS, EDIT /TPU) using Mouse-2 (X11
paste). Then, I selected this whole message in the Xterm
using Mouse-1, hit Cmd-C, and used Cmd-V to paste it into the
"Post reply" box in the Firefox (Google Groups) text box.

It took a while, but these sequences have gotten habitual,
and now I seldom try to use Cmd-V to paste into an Xterm
(which gives "ö"), or Mouse-2 to paste into anything else
(which could do almost anything).

[Simon Clubley]

On 2016-07-29, Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
> Den 2016-07-29 kl. 20:12, skrev David Froble:
>> Hans Vlems wrote:
>>> I'm not sure that I'd like to see multiple buffers in EDT. I do nearly
>>> all my editing in EDT and lots of functions I do by means of a reflex. I
>>> cannot tell beforehand which keys to hit, I just know what to do.
>>> Changing defaults or the functionality of keys would break a 35 year
>>> habit...
>>> Hans
>>
>> Ayep ... I'm the same. Hand runs on auto-pilot ...
>>
>> Except, EDT already has multiple buffers. It's the keypad stuff I'd not
>> want to see changed. Would have to re-learn all over.

In EVE, these are dedicated commands; nothing to do with changing
the keypad. In Emacs (with tpu-edt active) it's either a EVE style
command or a dedicated main keyboard Ctrl sequence. Either way,
having multiple windows on the screen has nothing to do with
changing the existing EDT keypad emulation.

>
> Whas my thought also, EDT already has multiple buffers, just not
> visible at the same time. I have never used them, as far as
> I can remember.
>

Which is why Simon talked about multiple windows on the screen at
the same time and didn't talk about multiple buffers within the editor.

Simon.

[Simon Clubley]

On 2016-07-30, Paul Sture <nos...@sture.ch> wrote:
> On 2016-07-30, Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
>>
>> Of course, I do the same, just with multiple windows. More lines
>> visible in each file. Can easily be on different systems. For small
>> files I usualy just TYPE the file in the other window, no reason to
>> even start EDT. Just scroll the window to copy the relevant part.
>>
>> The cut-n-paste using the mouse is far faster then SELecting in
>> EDT using the keyboard, at least for the usual <20 lines copies.
>>
>
> copy-n-paste using the mouse converts tabs to spaces, and the number of
> spaces will represent the tab stops of the source window. In many cases
> this won't matter, but for source files which specifically use tabs, EDT
> (or EVE) copy-n-paste will transfer the information correctly, also
> stuff like embedded <ff>, <cr>, <lf> etc.
>

Perhaps Jan-Erik is one of those heretics who uses space indentation
instead of tab indentation in his source code. :-)

On a more serious node, the tabify command is available within emacs
to convert spaces to tabs so sometimes it's just quicker to copy
and paste some code into emacs and then run it past tabify especially
when the source code to be copied is being viewed in another terminal
window.

Most of the time however, I use the select keystrokes available within
the editor to move things around in files open within an editing session.

Simon.

[Simon Clubley]

On 2016-07-30, Paul Sture <nos...@sture.ch> wrote:
>

> As an aside I've just looked at what happens on OS X here. The first
> thing to note is that mouse copy-n-paste only works across windows
> within an application, not across separate applications. e.g. you
> can't mouse-paste from xterm to Terminal or vice versa.
>

Forgot to mention that you should check which paste buffer xterm is
using here. I couldn't paste text from a xterm running on Linux within
a VM into a PuTTY session running on the host machine until I told
the xterm running within the VM to use the X-Windows clipboard.

For xterm, it's a X-Windows resource setting; look at the xterm man
page for details. I don't generally have this problem when doing
inter-application copy and pastes involving xterm between applications
running on the same Linux machine however.

Simon.

[David Froble]

I seem to remember, from way far back, that spaces are used in Cobol, and from
not so far back that that you use a lot of Cobol.

Ok, I've just run into too many things, including "cut-n-paste" on weendoze,
that converts tabs to spaces. I use tabs for indentation in Basic programs, and
definitely don't want them converted to spaces. It can really play havoc with
formatting.

Staying in EDT, there is none of the "I know better than this user" from the
utility. Not always true outside of EDT. I've ust gotten into some habits that
work for me, and don't see much reason to deviate without a darn good reason.

[David Froble]

Simon Clubley wrote:
> On 2016-07-30, Paul Sture <nos...@sture.ch> wrote:
>> On 2016-07-30, Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
>>> Of course, I do the same, just with multiple windows. More lines
>>> visible in each file. Can easily be on different systems. For small
>>> files I usualy just TYPE the file in the other window, no reason to
>>> even start EDT. Just scroll the window to copy the relevant part.
>>>
>>> The cut-n-paste using the mouse is far faster then SELecting in
>>> EDT using the keyboard, at least for the usual <20 lines copies.
>>>
>> copy-n-paste using the mouse converts tabs to spaces, and the number of
>> spaces will represent the tab stops of the source window. In many cases
>> this won't matter, but for source files which specifically use tabs, EDT
>> (or EVE) copy-n-paste will transfer the information correctly, also
>> stuff like embedded <ff>, <cr>, <lf> etc.
>>
>
> Perhaps Jan-Erik is one of those heretics who uses space indentation
> instead of tab indentation in his source code. :-)

Not saying I'm correct, or know what I'm talking about, but I seem to recall
from the dim past that some Cobol required spaces instead of Tabs. I don't
think the Cobol on VMS did so, but, I tend to avoid Cobol ....

[Jan-Erik Soderholm]

"ANSI Formatting" (which is the old "IBM" style Cobol) might not like
tabs since it has som e fixed positions. The "Terminal Formatting" is
more free form and can easily be tab'ed if one want. The latter is
what is used for all new regular code, but the ANSI formatting has
to be used for any code that uses MQ calls since the include files
supplied from IBM are in ANSI format.

/Jan-Erik.

$ help cobol /ANSI_FORMAT

COBOL

/ANSI_FORMAT

/ANSI_FORMAT
/NOANSI_FORMAT (D)

Indicates that the source program is in conventional ANSI format.
The compiler then expects 80-character card image records with
optional sequence numbers in character positions 1 through 6,
indicators in position 7, Area A beginning in position 8, Area B
beginning in position 12, and the identification area in positions
73 through 80.

The default, /NOANSI_FORMAT, indicates that the source program is
in Compaq COBOL terminal format, where Area A begins in position 1,
Area B begins in position 5, and the source program records do not
have line numbers.

Topic?

[IanD]

On Sunday, July 31, 2016 at 5:43:27 AM UTC+10, David Froble wrote:
> Jan-Erik Soderholm wrote:

<snip>

>
> I seem to remember, from way far back, that spaces are used in Cobol, and from
> not so far back that that you use a lot of Cobol.
>
> Ok, I've just run into too many things, including "cut-n-paste" on weendoze,
> that converts tabs to spaces. I use tabs for indentation in Basic programs, and
> definitely don't want them converted to spaces. It can really play havoc with
> formatting.
>
> Staying in EDT, there is none of the "I know better than this user" from the
> utility. Not always true outside of EDT. I've ust gotten into some habits that
> work for me, and don't see much reason to deviate without a darn good reason.

My reply might be starting to border on a coding style religious debate but the best reason I've heard for spaces over tabs is that depending on the environment, tabs can represent different numbers of columns, where-as a space is always 1 column wide in no matter what environment but there is no conclusive right or wrong it seems, both camps have their reasons.

IDE editor will usually substitute spaces automatically for tab's anyhow and will word jump too so your not having to painfully skip over each and every space like in basic terminal editors that are not code aware.

I've seen programmers work in a proportional font in an IDE editor and then highlight a block of code and switch to monospace to draw-out certain characters that like to huddle up next to other characters in languages like C (i.e. the '!' character for example). This gives them the best of both worlds, they can write in their proportional font and switch back and forth with ease as an additional visual quality check.

If your using a modern IDE editor and you want those beloved tabs, then maybe elastic tabstops might come to the rescue.

http://nickgravgaard.com/elastic-tabstops/ (warning David, it contains C code!)

The chances of seeing this in something like LSE are, well, zero I would think.

Better to spend the money moving to something like Eclipse longer term but unless the standard widget kit is also ported, development on OpenVMS using modern IDE's is still going to be relegated to a remote compile operation I suspect?

[Bob Koehler]

In article <b50c81c9-7140-41b4...@googlegroups.com>, Hans Vlems <hvl...@freenet.de> writes:
> I'm not sure that I'd like to see multiple buffers in EDT. I do nearly all =
> my editing in EDT and lots of functions I do by means of a reflex. I cannot=
> tell beforehand which keys to hit, I just know what to do. Changing defaul=

> ts or the functionality of keys would break a 35 year habit...
> Hans

EDT already has multiple buffers. I used them for years. What it
doesn't have is the ability to display more than one at a time.

No keys need to be changed just to add a multiple buffer display.
The commands to use a multiple buffer display could be available only
at the command prompt, or previously unused key combinations could be
assigned to them.

[Johnny Billquist]

On 2016-07-26 16:42, Michael Moroney wrote:
> hel...@asclothestro.multivax.de (Phillip Helbig (undress to reply)) writes:
>

>> In article <nn66t6$grv$1...@pcls7.std.com>, mor...@world.std.spaamtrap.com
>> (Michael Moroney) writes:
>
>>> I just rebuilt EDT
>
>> You have the source?
>
> My employer, VSI, does.
>
>> Wasn't EDT VESTed for Alpha?
>
> You're probably thinking of TECO. EDT is in Bliss.

Would the sources still build EDT for PDP-11s as well?

Johnny

[John Reagan]

On Monday, August 22, 2016 at 12:05:35 PM UTC-4, Johnny Billquist wrote:
> On 2016-07-26 16:42, Michael Moroney wrote:
> > (Phillip Helbig (undress to reply)) writes:
> >

> >> In article <>,

> >> (Michael Moroney) writes:
> >
> >>> I just rebuilt EDT
> >
> >> You have the source?
> >
> > My employer, VSI, does.
> >
> >> Wasn't EDT VESTed for Alpha?
> >
> > You're probably thinking of TECO. EDT is in Bliss.
>
> Would the sources still build EDT for PDP-11s as well?
>
> Johnny

I skimmed through the first dozen or so... It feels like the original source could dual-build. There are several %IF %BLISS(BLISS32) constructs which I think are meant to say "BLISS32 means VMS else not-VMS". There are some "%IF %BLISS(BLISS16) as well. The comments talk about PDP-11, DECTAPES, etc. However, I suspect over the years that subsequent bug-fixes, etc. didn't consider any PDP-11 differences and that the current code base might not build or work.

However, the problem is finding a BLISS-16 compiler, right? They were cross compilers that ran on either VAX/VMS and TOPS-20. I guess simh could help.

[Johnny Billquist]

You had both BLISS-11 and BLISS-16. I think BLISS-11 was the PDP-10
cross compiler, while BLISS-16 was the VMS one. I suspect it might
require a VAX as well...

It could/would be interesting to build a new release for the PDP-11
systems, but I suspect it won't happen, as I don't think there would be
much interest from the VSI side.

Not sure, but I think it should be possible to locate BLISS-16.

Johnny