On Monday, November 8, 2021 at 1:25:50 PM UTC-5, Simon Clubley wrote:
> On 2021-11-08, Phillip Helbig (undress to reply) <hel...@asclothestro.multivax.de> wrote:
> > In article <b6c4a416-0ccf-4518...@googlegroups.com>,
> >=?UTF-8?Q?Lawrence_D=E2=80=99Oliveiro?= <lawren...@gmail.com> writes:
> >
> >> On Monday, November 8, 2021 at 6:27:48 PM UTC+13, Phillip Helbig (undress to reply) wrote:
> >> > It is the most efficient, not the most powerful. :-)
> >>
> >> As in helping you to be the most productive?
> >
> > Exactly.
> >
> How exactly ?
>
> By today's standards, EDT's limited functionality makes it the
> assembly language version of editors when compared to other editors
> which are fully featured editors.
>
> EDT can't even show more than one window on the screen at the same
> time. How does that make EDT the most productive editor ?
>
> Even EVE can do that, which makes even EVE much more productive than EDT.

Not when you are compiling and it aborts at line 1. Not when you need SET NOTRUNCATE.

Features and capabilities? On net, EVE wins. More productive? Depends what you want to do.

> Simon.

AEF

On Thursday, November 18, 2021 at 1:39:07 PM UTC-5, Simon Clubley wrote:
> On 2021-11-17, alanfe...@gmail.com <alanfe...@gmail.com> wrote:
> >
> > Can your favorite editor let you define keys without compiling a huge
> > section file? Can you easily look up what any given key combo does? Esp..
> > when done by learn mode? Just asking.
> >
> I have already answered your first question (answer is yes) and posted
> EVE examples for you to try.

I just scanned this entire thread for your posts and do not see either of the above.
Please re-post.

>
> Someone else has already answered your second question. I don't know if
> that includes learn sequences, but I have _never_ needed to see the learn
> sequence that I have just entered as I don't care about it after the end
> of the current session.

I couldn't find this one, either. Please post the answer. But the answer appears to be "no".

>
> BTW, EVE isn't my favourite editor. It's just that its a lot more powerful
> and productive to use on VMS than trying to use EDT.

Depends on your tasks and whether you keep getting "Compile aborted on line 1" when you make a change dozens of lines down. I had to struggle to get EVE to work at all every time I wanted to use it at a remote lab. That is not what I would call productive! But EDT always worked no matter where I was.. It's like Stereo Review (or some other stereo mag) once said: you can always tell the difference between the sound quality of a working amp vs. that of a broken one! EVE was always a pain at remote labs just to get it to run at all. THAT IS NOT WHAT I WOULD CALL PRODUCTIVE!!! And we weren't writing applications, though I did write a FORTRAN program to analyze logical combinations of hits on our detectors. And it's the only non-trivial program I wrote that worked on first compile! Unfortunately I don't have a copy of it. I think the key was to repeatedly scan two lists: the wait (?) list and the done list. Or something like that. I do remember that there were two lists that were key to the program.

Yes, some people use editors for purposes other than writing sophisticated apps. Please take note.

Hey! vi is more productive on many Unix systems (and Linux?), as it is the only one guaranteed to actually be on the box. You can't be productive with an editor that isn't there!!! (~_^)

Emacs is an even more
> powerful editor however.

Lovely. You are welcome to use emacs. I'm not stopping you. I'm not forcing you to use EDT either. \relax

I'm beginning to get the impression you don't think much of EDT. (!) (~_^)

> Simon.
> [...]

AEF

On 11/19/2021 7:11 AM, alanfe...@gmail.com wrote:
> Depends on your tasks and whether you keep getting "Compile aborted
> on line 1" when you make a change dozens of lines down. I had to
> struggle to get EVE to work at all every time I wanted to use it at a
> remote lab. That is not what I would call productive! But EDT always
> worked no matter where I was. It's like Stereo Review (or some other
> stereo mag) once said: you can always tell the difference between the
> sound quality of a working amp vs. that of a broken one! EVE was
> always a pain at remote labs just to get it to run at all. THAT IS
> NOT WHAT I WOULD CALL PRODUCTIVE!!!

I am little confused by this.

First compilation of TPU code is not part of normal editing. It is
part of developing TPU code. I don't consider TPU development
difficult, but obviously other may have a different experience.

Second EVE has been the default editor on VMS for a couple of decades
and I suspect that over 50% of VMS editing is done using EVE
And we have not been swamped with reports of EVE not working or being
difficult to get working. So I will assume that in most contexts then
EVE just work out of the box.

Arne

On 11/18/2021 5:44 PM, alanfe...@gmail.com wrote:
> On Monday, November 8, 2021 at 1:25:50 PM UTC-5, Simon Clubley wrote:
>> By today's standards, EDT's limited functionality makes it the
>> assembly language version of editors when compared to other editors
>> which are fully featured editors.
>>
>> EDT can't even show more than one window on the screen at the same
>> time. How does that make EDT the most productive editor ?
>>
>> Even EVE can do that, which makes even EVE much more productive than EDT.
>
> Depends on the task. Use the right tool for the job. Don't hire a robot to open a jar.

Right tool for the job is always good.

But EVE and EDT are very close in what types of task they are designed
to do.

I can only think of a few technical reasons to prefer EDT over EVE for
an editing task: ability to run in very little memory and ability to
run line mode. Neither is very likely to be relevant today.

The main reason for EDT use is that a significant portion of VMS people
know EDT better than EVE. EDT works and even though EVE could do
the work as well, then they do not have a need for any of the extra
capabilities offered by EVE so it does not make sense for them to
switch.

Arne

On Friday, November 19, 2021 at 9:56:41 AM UTC-5, Arne Vajhøj wrote:
> On 11/19/2021 7:11 AM, alanfe...@gmail.com wrote:
> > Depends on your tasks and whether you keep getting "Compile aborted
> > on line 1" when you make a change dozens of lines down. I had to
> > struggle to get EVE to work at all every time I wanted to use it at a
> > remote lab. That is not what I would call productive! But EDT always
> > worked no matter where I was. It's like Stereo Review (or some other
> > stereo mag) once said: you can always tell the difference between the
> > sound quality of a working amp vs. that of a broken one! EVE was
> > always a pain at remote labs just to get it to run at all. THAT IS
> > NOT WHAT I WOULD CALL PRODUCTIVE!!!
> I am little confused by this.
>
> First compilation of TPU code is not part of normal editing. It is
> part of developing TPU code. I don't consider TPU development
> difficult, but obviously other may have a different experience.

Perhaps not. But isn't customization important?

>
> Second EVE has been the default editor on VMS for a couple of decades
> and I suspect that over 50% of VMS editing is done using EVE
> And we have not been swamped with reports of EVE not working or being
> difficult to get working. So I will assume that in most contexts then
> EVE just work out of the box.

Well, my experience with EVE is mostly from the late 1980s in graduate school. It was a continual PITA. Default or not, EDT worked at remote labs and to get EVE to work AT ALL was a royal PITA. Maybe 30-some years things are better.

>
> Arne

AEF

On 11/19/2021 3:38 PM, alanfe...@gmail.com wrote:
> On Friday, November 19, 2021 at 9:56:41 AM UTC-5, Arne Vajhøj wrote:
>> On 11/19/2021 7:11 AM, alanfe...@gmail.com wrote:
>>> Depends on your tasks and whether you keep getting "Compile aborted
>>> on line 1" when you make a change dozens of lines down. I had to
>>> struggle to get EVE to work at all every time I wanted to use it at a
>>> remote lab. That is not what I would call productive! But EDT always
>>> worked no matter where I was. It's like Stereo Review (or some other
>>> stereo mag) once said: you can always tell the difference between the
>>> sound quality of a working amp vs. that of a broken one! EVE was
>>> always a pain at remote labs just to get it to run at all. THAT IS
>>> NOT WHAT I WOULD CALL PRODUCTIVE!!!
>> I am little confused by this.
>>
>> First compilation of TPU code is not part of normal editing. It is
>> part of developing TPU code. I don't consider TPU development
>> difficult, but obviously other may have a different experience.
>
> Perhaps not. But isn't customization important?

It is.

But note that EVE got 3 levels of customization:
1) EVE init file
2) TPU command file
3) TPU section file

The first is equivalent to EDT init file.

But only the last 2 compiles.

>> Second EVE has been the default editor on VMS for a couple of decades
>> and I suspect that over 50% of VMS editing is done using EVE
>> And we have not been swamped with reports of EVE not working or being
>> difficult to get working. So I will assume that in most contexts then
>> EVE just work out of the box.
>
> Well, my experience with EVE is mostly from the late 1980s in
> graduate school. It was a continual PITA. Default or not, EDT worked
> at remote labs and to get EVE to work AT ALL was a royal PITA. Maybe
> 30-some years things are better.
Weird.

With standard VMS and standard section file and a suitable
VT terminal then it should work. Even a botched init or
command file should just result in it not being run.

Arne

On 11/18/2021 2:41 PM, alanfe...--- via Info-vax wrote:
> On Thursday, November 18, 2021 at 1:39:07 PM UTC-5, Simon Clubley wrote:
>> On 2021-11-17, alanfe...@gmail.com <alanfe...@gmail.com> wrote:
>>>
>>> Can your favorite editor let you define keys without compiling a huge
>>> section file? Can you easily look up what any given key combo does? Esp.
>>> when done by learn mode? Just asking.
>>>
>> I have already answered your first question (answer is yes) and posted
>> EVE examples for you to try.
>
> I didn't see any such post. Also my other problem with compiling things in EVE is that I once got "Compilation aborted on line 1." Line 1!!! How am I supposed to debug something with a msg. like that? (My changed line of code was well past line 1.)
>
> AGAIN: Every time I try EVE there's a problem. At remote labs it didn't work _at all_ without a lot of fuss playing with terminal settings and whatnot. With EDT I don't have such problems. I don't have to wait half a minute to open a huge file just to change the first few lines like I do with EVE. EDT works fine for me. If you need a more powerful editor, fine! I'm not stopping you. I don't need multiple buffers on the screen at the same time in the same session. I don't need all that scripting. I just want to edit some simple DCL. OK? I'm a lowly ex-physicist who wrote a lot of stuff in FORTRAN. I've inspected Pascal code, started learning c, and dabbled a little in existing perl scripts. That's it! I'm not a professional coder! For those who are, use a more powerful editor. I'm okay with that!!!
>
> One time both EDT and EVE failed me! I needed lines longer than 255 chars, but also SET NO TRUNCATE. Neither editor has both. So I had to struggle to get the task done.
>
> The only times I need EVE is for overstrike mode and box editing. The rest of the time I like EDT, esp. now that it is not limited to 22 lines. (Actually, there may be other rare times, like wildcard searches maybe, but it's been a long, long time!)
>

Many times I've used EVE to edit files whose records are 2000+
characters. I never had problems. The system was running at least VMS
V5.5, but maybe V6.2. On what version of VMS did you last use EVE?

<<snip>>

> AEF
> _______________________________________________
> Info-vax mailing list
> Info-vax@rbnsn.com
> http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com
>

On Friday, November 19, 2021 at 7:04:42 PM UTC-5, Arne Vajhøj wrote:
> On 11/19/2021 3:38 PM, alanfe...@gmail.com wrote:
> > On Friday, November 19, 2021 at 9:56:41 AM UTC-5, Arne Vajhøj wrote:
> >> On 11/19/2021 7:11 AM, alanfe...@gmail.com wrote:
[...]
> > Perhaps not. But isn't customization important?
> It is.
>
> But note that EVE got 3 levels of customization:
> 1) EVE init file
> 2) TPU command file
> 3) TPU section file
>
> The first is equivalent to EDT init file.
>
> But only the last 2 compiles.

As I've said before: EVE is a blow torch, but I only need a match.
Also, I'm not so sure I could translate many of my EDT key definitions into EVE. I'd have to check.

> >> Second EVE has been the default editor on VMS for a couple of decades
> >> and I suspect that over 50% of VMS editing is done using EVE
> >> And we have not been swamped with reports of EVE not working or being
> >> difficult to get working. So I will assume that in most contexts then
> >> EVE just work out of the box.
> >
> > Well, my experience with EVE is mostly from the late 1980s in
> > graduate school. It was a continual PITA. Default or not, EDT worked
> > at remote labs and to get EVE to work AT ALL was a royal PITA. Maybe
> > 30-some years things are better.
> Weird.
>
> With standard VMS and standard section file and a suitable
> VT terminal then it should work. Even a botched init or
> command file should just result in it not being run.

Well, I worked on an Alpha from 2015-2018 (maybe 2015-2017). I don't think I tried EVE there. I didn't really need it. Remember: I am a lowly ex-physicist who used to write a lot of DCL and Fortran. I haven't done Fortran since maybe 1993. No original Fortran since 1991. And on that Alpha from 2015 to 2018 I did some DCL and zero Fortran. Mostly I just moved automated file transfer data (company names, file names, addresses, etc. -- oh, metadata, I guess!) from there to a Unix box.

I'm working on EISNER:: now, and EVE comes up fine. I use it only when I need overstrike mode or box cut, copy and paste. I see no point in starting all over again just to update TO.COM and perhaps a few very small DCL command procedures for the Freeware page. I really don't want to redo my several dozen EDT key definitions. For what? OK, might be nice to have split screen, but still not worth converting my EDT command file.

Oh, I have a 13-line Fortran program that writes your current command to a tmp file. Saves re-typing!

>
> Arne

On Friday, November 19, 2021 at 11:00:07 PM UTC-5, Tad Winters wrote:
> On 11/18/2021 2:41 PM, alanfe...--- via Info-vax wrote:
> > On Thursday, November 18, 2021 at 1:39:07 PM UTC-5, Simon Clubley wrote:
> >> On 2021-11-17, alanfe...@gmail.com <alanfe...@gmail.com> wrote:
[...]
> > AGAIN: Every time I try EVE there's a problem. At remote labs it didn't work _at all_ without a lot of fuss playing with terminal settings and whatnot. With EDT I don't have such problems. I don't have to wait half a minute to open a huge file just to change the first few lines like I do with EVE. EDT works fine for me. If you need a more powerful editor, fine! I'm not stopping you. I don't need multiple buffers on the screen at the same time in the same session. I don't need all that scripting. I just want to edit some simple DCL. OK? I'm a lowly ex-physicist who wrote a lot of stuff in FORTRAN. I've inspected Pascal code, started learning c, and dabbled a little in existing perl scripts. That's it! I'm not a professional coder! For those who are, use a more powerful editor. I'm okay with that!!!
> >
> > One time both EDT and EVE failed me! I needed lines longer than 255 chars, but also SET NO TRUNCATE. Neither editor has both. So I had to struggle to get the task done.
> >
> > The only times I need EVE is for overstrike mode and box editing. The rest of the time I like EDT, esp. now that it is not limited to 22 lines. (Actually, there may be other rare times, like wildcard searches maybe, but it's been a long, long time!)
> >
> Many times I've used EVE to edit files whose records are 2000+
> characters. I never had problems. The system was running at least VMS
> V5.5, but maybe V6.2. On what version of VMS did you last use EVE?

On EISNER:: just a short wile ago. (OpenVMS V8.4-2L2)

My bad experiences with EVE came from my time as a graduate research assistant. That was in the late 1980s. We had various editions of v4 and v5 VAX/VMS.

EVE was always a pain. Never worked at remote sites without a lot of fuss. Had a lot of trouble with it at "home." I've already described all those misadventures that in this thread. At some point I realized that I never had any of these problems with EDT. So EDT it was.

I last used EVE today to see how hard it would be to convert all my EDT key definitions. At least some of them might not be doable at all. Why should I bother? I'm just working on my TO.COM and maybe a few rather small DCL procedures -- both for the Freeware webpage. Again, I'm a lowly ex-physicist who worked at jobs where I could manage and work with VMS. I am not a professional coder. I don't need super whiz-bang editors. They're overkill.

Earlier in the last month or so I used EVE to update the help page in TO.COM, where overstrike mode and the box bit were quite useful.

And what's with the multi-colored editors I saw at my last job which have god-knows-what other features? There are still too many bugs in software! I think it just means the coders can crank out bugs at a higher rate. (~_^)

BTW, why did it take so long for someone to fix the hard-coded 22-line limit on EDT? How long could it have taken? Well, I'm very happy about it now!

> <<snip>>
>
> > AEF
> > _______________________________________________
> > Info-vax mailing list
> > Info...@rbnsn.com
> > http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com

AEF

On Thursday, November 18, 2021 at 1:39:07 PM UTC-5, Simon Clubley wrote:
> On 2021-11-17, alanfe...@gmail.com <alanfe...@gmail.com> wrote:
> >
> > Can your favorite editor let you define keys without compiling a huge
> > section file? Can you easily look up what any given key combo does? Esp.
> > when done by learn mode? Just asking.
> >
> I have already answered your first question (answer is yes) and posted
> EVE examples for you to try.

I just searched the entire thread again and I do not see any such post. Maybe Google Groups doesn't have it. Can you please re-post?

>
> Someone else has already answered your second question. I don't know if
> that includes learn sequences, but I have _never_ needed to see the learn
> sequence that I have just entered as I don't care about it after the end
> of the current session.

I have.

>
> BTW, EVE isn't my favourite editor. It's just that its a lot more powerful
> and productive to use on VMS than trying to use EDT. Emacs is an even more
> powerful editor however.
> Simon.

Again, I am a lowly ex-physicist who worked at jobs where my knowledge of VMS was of use. I am not a professional coder. I have BBEdit on my Mac at home. Even its free version appears to have a bazillion features I'll never use.

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

AEF

On 11/21/2021 4:32 AM, alanfe...@gmail.com wrote:

> BTW, why did it take so long for someone to fix the hard-coded 22-line limit on EDT? How long could it have taken? Well, I'm very happy about it now!

That "someone" is myself. As to why did it "take so long", EDT was
considered obsolete for decades. Nobody was actively maintaining it. I
just recently posted some comments about fixing it. It was an unofficial
fix, I just did it one day. But EDT fans may be happy to know that EDT
was the first editor to run on x86. I forget why EVE/TPU took longer, it
may have been a compiler bug that affected it but not EDT. A different
problem prevented EDT from working out of the box however.

Yes, EDT was the first VMS supplied editor running on x86, in June 2020.
Micro emacs ran on x86 in October 2019.

FWIW, JED, another also not so popular editor available for VMS, was
ported to x86 in August 2020: yeah, some people find syntax coloring for
DCL procedures useful. And Emacs 21.2, a somehow more popular editor
available for VMS, was just cross-compiled for x86. It seems to work,
but it's not yet ready for use.

On 11/22/21 4:19 AM, Michael Moroney wrote:
> On 11/21/2021 4:32 AM, alanfe...@gmail.com wrote:
>
>> BTW, why did it take so long for someone to fix the hard-coded 22-line
>> limit on EDT? How long could it have taken? Well, I'm very happy about
>> it now!
>
> That "someone" is myself.  As to why did it "take so long", EDT was
> considered obsolete for decades. Nobody was actively maintaining it. I
> just recently posted some comments about fixing it. It was an unofficial
> fix, I just did it one day. But EDT fans may be happy to know that EDT
> was the first editor to run on x86. I forget why EVE/TPU took longer, it
> may have been a compiler bug that affected it but not EDT. A different
> problem prevented EDT from working out of the box however.

On 11/21/2021 10:19 PM, Michael Moroney wrote:
> On 11/21/2021 4:32 AM, alanfe...@gmail.com wrote:
>
>> BTW, why did it take so long for someone to fix the hard-coded 22-line
>> limit on EDT? How long could it have taken? Well, I'm very happy about it
>> now!
>
> That "someone" is myself. As to why did it "take so long", EDT was
> considered obsolete for decades. Nobody was actively maintaining it. I just
> recently posted some comments about fixing it. It was an unofficial fix, I
> just did it one day. But EDT fans may be happy to know that EDT was the first
> editor to run on x86. I forget why EVE/TPU took longer, it may have been a
> compiler bug that affected it but not EDT. A different problem prevented EDT
> from working out of the box however.

Both editors were affected by the change on X86 where code is placed in 64-bit
space by default. This default can be overriden with the LINK qualifier
/SEGMENT_ATTRIBUTE=CODE=P0.

The problem was that in both editors (and other areas of the operating system
and layered products), certain data PSECTS were marked as EXECUTABLE. This
worked on VAX, Alpha, and IA64, and was likely a VAX-era optimization to keep
certain data co-located with the relevant code. This does not work on X86;
Reagan can give the details.

Both editors are written in BLISS, and early BLISS compilers (or perhaps the
GEM-to-LLVM converter) did not deal with the GLOBAL BIND syntax correctly.

I drew the short straw for both editors and had the pleasure of of tracking down
where in the code was failing, coming up with stripped-down reproducers, and
bringing my findings to Reagan so he could puzzle it out.

--
-- Rob

On Monday, November 22, 2021 at 2:41:00 PM UTC, Robert A. Brooks wrote:
> On 11/21/2021 10:19 PM, Michael Moroney wrote:
> > On 11/21/2021 4:32 AM, alanfe...@gmail.com wrote:
> >
> >> BTW, why did it take so long for someone to fix the hard-coded 22-line
> >> limit on EDT? How long could it have taken? Well, I'm very happy about it
> >> now!
> >
> > That "someone" is myself. As to why did it "take so long", EDT was
> > considered obsolete for decades. Nobody was actively maintaining it. I just
> > recently posted some comments about fixing it. It was an unofficial fix, I
> > just did it one day. But EDT fans may be happy to know that EDT was the first
> > editor to run on x86. I forget why EVE/TPU took longer, it may have been a
> > compiler bug that affected it but not EDT. A different problem prevented EDT
> > from working out of the box however.
> Both editors were affected by the change on X86 where code is placed in 64-bit
> space by default. This default can be overriden with the LINK qualifier
> /SEGMENT_ATTRIBUTE=CODE=P0.
>
> The problem was that in both editors (and other areas of the operating system
> and layered products), certain data PSECTS were marked as EXECUTABLE. This
> worked on VAX, Alpha, and IA64, and was likely a VAX-era optimization to keep
> certain data co-located with the relevant code. This does not work on X86;
> Reagan can give the details.
>
> Both editors are written in BLISS, and early BLISS compilers (or perhaps the
> GEM-to-LLVM converter) did not deal with the GLOBAL BIND syntax correctly.
>
> I drew the short straw for both editors and had the pleasure of of tracking down
> where in the code was failing, coming up with stripped-down reproducers, and
> bringing my findings to Reagan so he could puzzle it out.
>
> --
> -- Rob

but does TECO work on x86 yet? :-)

On 11/22/2021 11:52 AM, Ian Miller wrote:

> but does TECO work on x86 yet? :-)

TECO barely works on IA64.

TECO was VEST'ed for Alpha and AEST'ed for IA64.

We'll need a native version for X86, and it may be a freeware version.

--
-- Rob

On 11/22/21 08:52, Ian Miller wrote:
>
> but does TECO work on x86 yet? :-)
>

You beat me to it! :-)

While I don't use TECO daily, there are times when it is the
only suitable tool. One customer has an annual (yes, just once
a year) job that involves extracting data from a vendor's report
file. We considered other approaches, but eventually concluded
that TECO was the right tool for the job, by a long shot.

Documenting it was fun!

Depending on the task at hand, I may use TPU, EDT, vi(m), notepad
or TECO. What matters is which one is most suitable for the job.

Alan

On 2021-11-19, alanfe...@gmail.com <alanfeldman48@gmail.com> wrote:
> On Thursday, November 18, 2021 at 1:39:07 PM UTC-5, Simon Clubley wrote:
>> On 2021-11-17, alanfe...@gmail.com <alanfe...@gmail.com> wrote:
>> >
>> > Can your favorite editor let you define keys without compiling a huge
>> > section file? Can you easily look up what any given key combo does? Esp.
>> > when done by learn mode? Just asking.
>> >
>> I have already answered your first question (answer is yes) and posted
>> EVE examples for you to try.
>
> I just scanned this entire thread for your posts and do not see either of the above.
> Please re-post.
>

From my original posting:

You define them in your EVE initialisation file. Some examples:

define key= gold/d wps gold-|
define key= gold/r wps gold-r
define key=gold-left shift left 16
define key=gold-right shift right 16

>>
>> Someone else has already answered your second question. I don't know if
>> that includes learn sequences, but I have _never_ needed to see the learn
>> sequence that I have just entered as I don't care about it after the end
>> of the current session.
>
> I couldn't find this one, either. Please post the answer. But the answer appears to be "no".
>

I can't remember what they wrote, but Gold-PF2 gives a list of key
definitions for me.

>
> I'm beginning to get the impression you don't think much of EDT. (!) (~_^)
>

By today's standards, no I don't. It was good by 1980s standards,
but not by today's standards.

Even back when I switched from RSTS/E to VAX/VMS, I switched from
EDT to EVE within half a day of first trying EVE because EVE was
immediately obviously so superior to me.

I do like the EDT keypad however and I continue to use that in EVE
and emacs because it's so much easier to work with than
Ctrl-{this, that and the other} for routine navigation tasks.

Simon.

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

On 2021-11-19, alanfe...@gmail.com <alanfeldman48@gmail.com> wrote:
> On Friday, November 19, 2021 at 9:56:41 AM UTC-5, Arne Vajhøj wrote:
>>
>> Second EVE has been the default editor on VMS for a couple of decades
>> and I suspect that over 50% of VMS editing is done using EVE
>> And we have not been swamped with reports of EVE not working or being
>> difficult to get working. So I will assume that in most contexts then
>> EVE just work out of the box.
>
> Well, my experience with EVE is mostly from the late 1980s in graduate school. It was a continual PITA. Default or not, EDT worked at remote labs and to get EVE to work AT ALL was a royal PITA. Maybe 30-some years things are better.
>

So you are judging the editors of today by knowledge obtained
30 years ago ? :-)

That sounds about right for some topics or people around here... :-)

Simon.

PS: $ set response/mode=good_natured :-)

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

On 2021-11-22, Robert A. Brooks <FIRST.LAST@vmssoftware.com> wrote:
> On 11/22/2021 11:52 AM, Ian Miller wrote:
>
>> but does TECO work on x86 yet? :-)
>
> TECO barely works on IA64.
>
> TECO was VEST'ed for Alpha and AEST'ed for IA64.
>
> We'll need a native version for X86, and it may be a freeware version.
>

Do you have any ideas about which freeware version ?

The one I am aware of is tecoc but the last time I looked at it, it did
not have a proper video mode so you couldn't run VTEDIT (for example).

Do you know of any others that do have a proper video mode ?

Simon.

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

In article <sngih5$c9$1@dont-email.me>, "Robert A. Brooks"
<FIRST.LAST@vmssoftware.com> writes:

> On 11/22/2021 11:52 AM, Ian Miller wrote:
>
> > but does TECO work on x86 yet? :-)
>
> TECO barely works on IA64.
>
> TECO was VEST'ed for Alpha and AEST'ed for IA64.
>
> We'll need a native version for X86, and it may be a freeware version.

Is Elliott Roper still around?

On 11/22/2021 2:03 PM, Simon Clubley wrote:
> On 2021-11-19, alanfe...@gmail.com <alanfeldman48@gmail.com> wrote:
>> On Friday, November 19, 2021 at 9:56:41 AM UTC-5, Arne Vajhøj wrote:
>>>
>>> Second EVE has been the default editor on VMS for a couple of decades
>>> and I suspect that over 50% of VMS editing is done using EVE
>>> And we have not been swamped with reports of EVE not working or being
>>> difficult to get working. So I will assume that in most contexts then
>>> EVE just work out of the box.
>>
>> Well, my experience with EVE is mostly from the late 1980s in graduate school. It was a continual PITA. Default or not, EDT worked at remote labs and to get EVE to work AT ALL was a royal PITA. Maybe 30-some years things are better.
>>
>
> So you are judging the editors of today by knowledge obtained
> 30 years ago ? :-)

Perhaps some people feel the need to keep changing editors. That's fine for
them. But other people learn how to do something, and as long as it works for
them, that is what they turn to when needing an editor. No new learning curve.
No wasted time. More productive.

The key is, if it is a good tool for a job, why change?

If more is required, then of course find a better tool.

Now can we drop this really silly subject?

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

In article <P5SdnQcKt_xOTAb8nZ2dnUU7-RfNnZ2d@supernews.com>, Alan
Frisbie <Usenet03_REMOVE@flying-disk.com> writes:

> On 11/22/21 08:52, Ian Miller wrote:
> >
> > but does TECO work on x86 yet? :-)
> >
>
> You beat me to it! :-)
>
> While I don't use TECO daily, there are times when it is the
> only suitable tool. One customer has an annual (yes, just once
> a year) job that involves extracting data from a vendor's report
> file. We considered other approaches, but eventually concluded
> that TECO was the right tool for the job, by a long shot.
>
> Documenting it was fun!
>
> Depending on the task at hand, I may use TPU, EDT, vi(m), notepad
> or TECO. What matters is which one is most suitable for the job.

Time to repost this gem (which I see I've had for a quarter of a
century!). I wonder how many would understand it without the comments.

>Newsgroups: comp.os.vms
>Path: news.rrz.uni-hamburg.de!news.dkrz.de!dscomsa.desy.de!news.belwue.de!scsing.switch.ch!newsstand.cit.cornell.edu!news.kei.com!world!mv!mv.mv.com!morris
>From: morris@mv.mv.com (Skipper W. Morris)
>Subject: Tool to convert U**x mail to VMSMail
>Message-ID: <DK8E95.Dt1@mv.mv.com>
>Organization: MV Communications, Inc.
>Date: Wed, 27 Dec 1995 06:05:28 GMT
>X-Nntp-Posting-Host: mv.mv.com
>Lines: 241

VMS Mail lovers,
I worked up the little gem below after another frustrating day of
trying to find a reasonable way to deal with lots of mail. It converts U**X
mail file folders to VMS mail files/folders/messages.
Bug reports/fixes/comments/etc, are appreciated.
enjoy
/Skip Morris

----------------------------------cut here------------------------------------
$ set noon ! 'f$verify(0)'
$!+
$! CONVERT_MAIL.COM V1.0, Skip Morris, "morris@mv.mv.com", 26-Dec-95
$! Input paramters:
$! P1 = The file(s) you want to convert.
$! P2 = Output VMS Mail file.
$! P3 = VMS Mail folder to store mail (defaults to input file name).
$! P4 = if nonnull then only convert to Mail11 V3.
$! Wildcard directory/filename inputs are permitted.
$! Use from batch by:
$! "$ submit convert_mail /param="DISK$FOO:[SOURCE...]*.txt;"
$! Max supported message count per input file is 16,777,215 since
$! that's all that could fit in the available return status fields.
$! Any '"' char's in personal name are blown away as VMSMail barfs on 'em.
$! Any special char's in addresses string cause address to be quoted.
$! Warning!! properly formatted unix mail file assumed. Not much checking.
$!-
$ default = f$envi("procedure")
$ if f$parse(p1,,,"name") + f$parse(p1,,,"type") + f$parse(p1,,,"version") -
.eqs. ".;" then p1 = p1 + "*.*;" ! cause directory input to be wildcard
$ search_file = f$parse(p1)
$ wildcard = f$loca("*",search_file) .ne. f$leng(search_file) .or. -
f$loca("%",search_file) .ne. f$leng(search_file) .or. -
f$loca("...",search_file) .ne. f$leng(search_file)
$ output_file = f$parse(p2,"mail.mai;",p1)
$ temp_file = f$parse("mail_"+f$getjpi("","pid")+".tmp;",output_file,default)
$ v3only = p4 .nes. ""
$main_loop:
$ input_file = f$search(search_file)
$ if input_file .nes. ""
$ then
$ write sys$output "Converting ",input_file," to Maill11V3 format..."
$ folder = f$parse(input_file,,,"name")
$ call convert_unix_mail 'input_file' 'temp_file'
$ ! return status has line count encoded in return status value
$ msg_count = ($status .and. %x07fffff8) / 8
$ if .not. v3only
$ then
$ write sys$output f$fao("Converting to ISAM file !AS folder !AS...", -
output_file,folder)
$ call convert_vms_mail 'temp_file' 'output_file' 'folder'
$ delete 'temp_file'
$ else
$ write sys$output f$fao("New file is !AS.",output_file)
$ rename 'temp_file' 'output_file'
$ endif
$ write sys$output f$fao("...done, !ZL message!%S processed.",msg_count)
$ if wildcard then goto main_loop
$ endif
$ exit
$!
$CONVERT_VMS_MAIL: SUBROUTINE
$ tempcom = f$parse("mail-"+f$getjpi("","pid")+".tmp;",p2,f$envi("procedure"))
$ create 'tempcom'
$ open/append file 'tempcom'
$ write file "$ mail"
$ write file "set file ",p1
$ write file "copy/all ",p3," ",p2,"/noconfirm"
$ write file "exit"
$ close file
$ @'tempcom'
$ delete 'tempcom'
$ exit
$ENDSUBROUTINE
$!
$CONVERT_UNIX_MAIL: SUBROUTINE
$ teco = "$teco32 teco"
$ unix_mail_file = f$search(f$parse(p1))
$ if unix_mail_file .eqs. "" then exit 4
$ temp_file = f$parse(p2)
$ if temp_file .eqs. "" then exit 4
$!
$ if f$trnlnm("tec$memory") .nes. "" then deassign tec$memory
$ assign/user 'unix_mail_file' mail$in
$ assign/user 'temp_file' mail$out
$ assign/user _nla0: sys$output ! comment this line out to vfy teco execution
$ define/user tec$init "96ee"
$ teco
! goto top, case match exact, load <cr><lf> qu, qt tokens illegal Mail-11!
j1^x13^uu`10:^uu`^ut-` ! Add illegal in "From:" after "-" char!
9^uv`32:^uv`13:^uv`:^uv.:%@!^=/[]` ! qv contains sendmail delimiter tokens!

ermail$in`ewmail$out` ! open input, output files!

!main loop for each msg!
<%q ! start loop, increment msg counter!
b,.pb,.ka ! page out previous, get new!
12i` ! insert <ff> at msg start!
.ua ! store msg top in qa!
s^el^equ` ! srch 1 blank lines!
.ub ! store end of headers qb!
qajl2r ! go end of initial "From" line!
.-4,.xm ! get year in qm!
5r.uc ! qc at end of timezone/timeofday!
r-s `::s^ea`"s2r.ucr-s `' ! if alpha timezone then backup!
.,qcxn ! get time in qn!
.-1uc-2s `.,qcxo ! 1-2 digit day-of-month in qo!
3r-s ` ! go to start of month!
.,.+3xp ! get month in qp!
qaj ! search "From: " header!
qb-qa,:s^elFrom: `"s ! if successful!
-d9i` ! then change space to tab!
0l1xlkqajgl-l ! move line to top!
6c.uc ! save start of address qc!
0,0xc0,0xl ! init qc(pers nam), ql(addr)!
0a-34"e ! if 'From: "pp" <aa>' sntx!
c1:fb" `"s ! then if ending '" '!
1:fb<`"s ! then if find starting '<'!
1:fb>`"s ! then if ending '>' found!
qcj ! then go start pers name!
dqb-1ub ! delete leading '"', fixup qb!
s"`-dqb-1ub ! find ending '"', del, fix qb!
qc,.xc ! store pers name qc!
qc,.k ! kill pers name!
dqb-1ub ! delete space end pers name!
s<`-dqb-1ub.ud ! find starting '<' and delete!
s>`-dqb-1ub ! find ending '>' and delete!
qd,.xlqd,.k ! store addr in ql and kill!
|46^t.:=69^t1:=77^tqq=0tt ! else bad msg fmt, out err msg!
' ! endif!
' ! endif!
| 1:fb"`"s ! else if 'From: "aa"aa (pp)' syntax!
1:fb (`"s ! then if ' ('!
1:fb)`"s ! then if ending ')' found!
qcj ! then go start addr!
s (`-2dqb-2ub ! delete ' (', fix qb!
qc,.xlqc,.k ! put addr ql, delete!
s)`-dqb-1ud ! go end pers, del ')', fx qb!
qc,.xcqc,.k ! put pers name qc, delete!
|46^t.:=69^t2:=77^tqq=0tt ! else bad msg fmt, out err msg!
' ! endif!
|qcjl2rqc,.xlqc,.k0,0xc ! else assume 'From: "aa"aa' sntx!
' ! endif!
|46^t.:=69^t3:=77^tqq=0tt ! else bad msg fmt, output err msg!
' ! endif!
' ! endif!
| 1:fb <`"s ! else if 'From: pp <aa>' sntx, if ' <'!
1:fb>`"s ! then if ending '>' found!
qcj ! then go start pers name!
s <`-2dqb-2ub ! find starting ' <' and delete!
qc,.xc ! store pers name qc!
qc,.k ! kill pers name!
s>`-dqb-1ub ! find ending '>' and delete!
qc,.xlqc,.k ! store addr in ql and kill!
|46^t.:=69^t4:=77^tqq=0tt ! else bad msg fmt, output err msg!
' ! endif!
| ! else!
1:fb (`"s ! if 'From: aa (pp) sntx, if ' ('!
1:fb)`"s ! then if ending ')' found!
qcj ! then go start addr!
s (`-2dqb-2ub ! delete ' (', fix qb!
qc,.xlqc,.k ! put addr ql, delete!
s)`-dqb-1ud ! go end pers, del ')', fix qb!
qc,.xcqc,.k ! put pers name qc, delete!
|46^t.:=69^t5:=77^tqq=0tt ! else bad msg fmt, outpt err msg!
' ! endif!
|qcj ! else assume single addr case!
::s<`"s-ds>`-dqb-2ub' ! handle case 'From: <aa>'!
l2rqc,.xlqc,.k0,0xc ! assume 'From: aa' syntax!
' ! endif!
' ! endif!
' ! endif!
qcjgl.ud ! go end "From:", insert addr!
qcj<qd-.,s^egt`; ! loop find illegal chars addr!
-s^egv`i"`s^egt` ! quote previous delimiter token!
s^egv`ri"`qb+2ubqd+2ud ! quote next sendmail delimiter token!
> ! end loop!
:qc"g ! if pers name nonnull!
qdji `qb+1ub ! then insrt space delimiter!
i"`gci"`qb+2ub ! insrt pers nam w/quotes!
' ! endif!
|qajiFrom:`9i` ! else insrt "From:" anyway!
i"<unknown>"`13i`10i`qb+19ub ! create "<unknown>" from, fixup qb!
' ! endif!
qajqb-qa,:s^elTo: `"s ! if 'To:' header found!
-d9i` ! then chg space to tab!
l::s `"s-3dqb-3ub ! if additional 'To:' header lines!
<::s `;-dqb-1ub>i `qb+1ub ! then append & kill leading spaces!
l::fs `To:` ! Add 'To:' hdr if more addressee!
' ! endif!
-l1xlkqajlgl ! move 'To:' line to new loc!
|qajliTo:`9i`i`13i`10i`qb+6ub ! else insert empty 'To:'!
' ! endif!

On Monday, November 22, 2021 at 9:41:00 AM UTC-5, Robert A. Brooks wrote:
> On 11/21/2021 10:19 PM, Michael Moroney wrote:
> > On 11/21/2021 4:32 AM, alanfe...@gmail.com wrote:
> >
> >> BTW, why did it take so long for someone to fix the hard-coded 22-line
> >> limit on EDT? How long could it have taken? Well, I'm very happy about it
> >> now!
> >
> > That "someone" is myself. As to why did it "take so long", EDT was
> > considered obsolete for decades. Nobody was actively maintaining it. I just
> > recently posted some comments about fixing it. It was an unofficial fix, I
> > just did it one day. But EDT fans may be happy to know that EDT was the first
> > editor to run on x86. I forget why EVE/TPU took longer, it may have been a
> > compiler bug that affected it but not EDT. A different problem prevented EDT
> > from working out of the box however.
> Both editors were affected by the change on X86 where code is placed in 64-bit
> space by default. This default can be overriden with the LINK qualifier
> /SEGMENT_ATTRIBUTE=CODE=P0.
>
> The problem was that in both editors (and other areas of the operating system
> and layered products), certain data PSECTS were marked as EXECUTABLE. This
> worked on VAX, Alpha, and IA64, and was likely a VAX-era optimization to keep
> certain data co-located with the relevant code. This does not work on X86;
> Reagan can give the details.
>
> Both editors are written in BLISS, and early BLISS compilers (or perhaps the
> GEM-to-LLVM converter) did not deal with the GLOBAL BIND syntax correctly.
>
> I drew the short straw for both editors and had the pleasure of of tracking down
> where in the code was failing, coming up with stripped-down reproducers, and
> bringing my findings to Reagan so he could puzzle it out.
>
> --
> -- Rob
That's a reasonable summary.

I'm working on (pardon the BLISS for those who don't understand):

GLOBAL BIND A = PLIT(1,2,3);

The BLISS frontend generates two anonymous variables (one for the count and
another for the anonymous data) then one named variable A which is linker visible
for the data, and yet another anonymous variable to represent A's count. Of course
all of these variables occupy the same memory. We incorrectly allocated two count
variables and ended up with:

.long 3
.long 0
A:
.long 1
.long 2
.long 3

Code that used the count to determine how many entries are in the vector would get
zero. Fixing that, I found another case where we over-aligned something and let an
alignment hole get between the count and the data. None of that is goodness.

As I've said before, the single biggest difference between GEM (well, VMS compilers
in general) and LLVM is that GEM is PSECT-oriented. PSECTs have initial values and
variables are simply bound to "PSECT+offset". That's a low-level assembler view of
the world (but very flexible). LLVM is variable-oriented. Variables occupy memory and
can be assigned to sections (aka PSECTs). Variables have initial values. It gets really
twisted with COMMON blocks and is one of the reasons that BASIC MAP statements
are causing my grief (among other things the BASIC frontend does). We essentially
have to skim the PSECT initializers from the frontends, figure out which variables they
apply to, derive a datatype to describe it (LLVM's initializers are "strongly types" and
have to match the size/shape of the variable they are attached to), and stitch it all
together. We had to add extra LLVM magic to get

GLOBAL BIND A = PLIT(1,2,3);
B = A[1];

to work at all. This was one of the EDT issues.

On Monday, November 22, 2021 at 2:03:13 PM UTC-5, Simon Clubley wrote:
> On 2021-11-19, alanfe...@gmail.com <alanfe...@gmail.com> wrote:
> > On Friday, November 19, 2021 at 9:56:41 AM UTC-5, Arne Vajhøj wrote:
> >>
> >> Second EVE has been the default editor on VMS for a couple of decades
> >> and I suspect that over 50% of VMS editing is done using EVE
> >> And we have not been swamped with reports of EVE not working or being
> >> difficult to get working. So I will assume that in most contexts then
> >> EVE just work out of the box.
> >
> > Well, my experience with EVE is mostly from the late 1980s in graduate school. It was a continual PITA. Default or not, EDT worked at remote labs and to get EVE to work AT ALL was a royal PITA. Maybe 30-some years things are better.
> >
> So you are judging the editors of today by knowledge obtained
> 30 years ago ? :-)

I was simply relating why I never caught on to EVE. After all the trouble I had with it in grad school, I had little incentive to try it later. Every time I gave it a shot it would just slap me in the face again and again. EDT never did that. Well, almost never!!!

Come to think of it, I think it was just the Learn-defined keys you couldn't look up. Yes, you can look up the ones you type commands and keys for.

EDT was always there for me. Yes, other editors have more features and so on, but I almost never needed them. So I stuck with EDT. And when I was using DCL to export a database I found neither editor up to the job. I needed both SET NOTRUNCATE mode and long lines at the same time. Neither fit the bill.

I think my emacs experience was mostly limited to a Stratus machine running Stratus VOS. But the Stratus, being huge and expensive, was eventually decommissioned.

I found my self on Unix and Linux. And the only editor guaranteed to be on all of them was vi. So I learened vi.

After a 3- or 4-year near total hiatus from VMS I decided to bring TO.COM back to life. I'm really glad EDT now can have as many lines as you need on the screen. I have all my custom key definitions in a single file, easily readable and modifiable. I had no incentive to move to a new editor that almost always failed me. If I were to get a job doing VMS full time, then maybe I would consider EVE again.

Hey, if EVE is good for you, go for it! I'm not stopping you. Yes, in general, EVE is more capable. So what? It's of little help to me.

Hey, all I asked for was a pointer to some release notes. I didn't mean to start an editor war. And when someone asked how to substitute asdf for zxcv on all lines with poiu using EDT, the answer popped in my head immediately and I had to post it. Then I got sucked in. So be it.

>
> That sounds about right for some topics or people around here... :-)
>
> Simon.
>
> PS: $ set response/mode=good_natured :-)
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.

On Monday, November 22, 2021 at 1:46:21 PM UTC-5, Simon Clubley wrote:
> On 2021-11-19, alanfe...@gmail.com <alanfe...@gmail.com> wrote:
> > On Thursday, November 18, 2021 at 1:39:07 PM UTC-5, Simon Clubley wrote:
> >> On 2021-11-17, alanfe...@gmail.com <alanfe...@gmail.com> wrote:
> >> >
> >> > Can your favorite editor let you define keys without compiling a huge
> >> > section file? Can you easily look up what any given key combo does? Esp.
> >> > when done by learn mode? Just asking.
> >> >
> >> I have already answered your first question (answer is yes) and posted
> >> EVE examples for you to try.
> >
> > I just scanned this entire thread for your posts and do not see either of the above.
> > Please re-post.
> >
> From my original posting:
>
> You define them in your EVE initialisation file. Some examples:
>
> define key= gold/d wps gold-|
> define key= gold/r wps gold-r
> define key=gold-left shift left 16
> define key=gold-right shift right 16

Thanks.

This posting never made it to Google Groups. Did you post it on the SET DEFAULT thread, perhaps?

> >>
> >> Someone else has already answered your second question. I don't know if
> >> that includes learn sequences, but I have _never_ needed to see the learn
> >> sequence that I have just entered as I don't care about it after the end
> >> of the current session.
> >
> > I couldn't find this one, either. Please post the answer. But the answer appears to be "no".
> >
> I can't remember what they wrote, but Gold-PF2 gives a list of key
> definitions for me.

Yep. It certainly does. Got it. I did, however, discover this on my own sometime during this barrage of posts. Sorry I didn't acknowledge it earlier. My bad.

I'm not certain, but I think you can actually do more things with EDT key definitions using the NOKEYPAD commands than you can with the above. I'd check it out, but that is definitely one of the things I wanted to avoid by not trying to switch to EVE!

Perhaps you'll tell me I can script key definitions commands and stuff. Come to think of it, that was probably what I was trying to do when I kept getting the "Compilation aborted on line 1" message again and again.

> >
> > I'm beginning to get the impression you don't think much of EDT. (!) (~_^)
> >
> By today's standards, no I don't. It was good by 1980s standards,
> but not by today's standards.

OK, I'm finally convinced you don't think much of EDT. (^_^) Coffin nailed tight.

>
> Even back when I switched from RSTS/E to VAX/VMS, I switched from
> EDT to EVE within half a day of first trying EVE because EVE was
> immediately obviously so superior to me.
>
> I do like the EDT keypad however and I continue to use that in EVE
> and emacs because it's so much easier to work with than
> Ctrl-{this, that and the other} for routine navigation tasks.

Yes, the EDT keypad is pretty good. I was ecstatic when I finally found out how to set up a bona fide emulation of it on my Mac keyboard. I figured that, as the default EVE layout was pretty lame, and the fact that DEC gave us the SET KEYPAD EDT command was a definite clue that it was a popular bit.

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