Discussion:
VI* on VMS
(too old to reply)
David Meyer
2024-10-16 13:57:38 UTC
Permalink
I'm helping operate an OpenVMS V7.3 system running on a VAXstation
4000-60. We have Vim 7.4 installed, but it appears to cause a big spike
in CPU usage and DIOCNT whenever it's run. The person who installed it
is no longer with us, and we are considering deleting Vim.

We also have VILE installed, which limited experimentation has not shown
to cause the same kind of performance problems. Does anyone know if VILE
is indeed well-behaved on VMS?
--
David Meyer
Takarazuka, Japan
***@sdf.org
Arne Vajhøj
2024-10-16 19:32:14 UTC
Permalink
Post by David Meyer
I'm helping operate an OpenVMS V7.3 system running on a VAXstation
4000-60. We have Vim 7.4 installed, but it appears to cause a big spike
in CPU usage and DIOCNT whenever it's run. The person who installed it
is no longer with us, and we are considering deleting Vim.
We also have VILE installed, which limited experimentation has not shown
to cause the same kind of performance problems. Does anyone know if VILE
is indeed well-behaved on VMS?
No idea about vile.

But http://www.polarhome.com/vim/ shows vim 9.1-11 being available
for VMS.

Before distching vim, then maybe check if an upgrade helps. From 7.4
to 9.1 is a pretty big jump.

Arne
Dan Cross
2024-10-16 19:45:40 UTC
Permalink
Post by Arne Vajhøj
Post by David Meyer
I'm helping operate an OpenVMS V7.3 system running on a VAXstation
4000-60. We have Vim 7.4 installed, but it appears to cause a big spike
in CPU usage and DIOCNT whenever it's run. The person who installed it
is no longer with us, and we are considering deleting Vim.
We also have VILE installed, which limited experimentation has not shown
to cause the same kind of performance problems. Does anyone know if VILE
is indeed well-behaved on VMS?
No idea about vile.
But http://www.polarhome.com/vim/ shows vim 9.1-11 being available
for VMS.
Before distching vim, then maybe check if an upgrade helps. From 7.4
to 9.1 is a pretty big jump.
You can't run 9.1 on a VAX. I assume that the VAXstation
4000-60 David mention is the hardware at the SDF museum.

- Dan C.
Arne Vajhøj
2024-10-16 19:53:09 UTC
Permalink
Post by Dan Cross
Post by Arne Vajhøj
Post by David Meyer
I'm helping operate an OpenVMS V7.3 system running on a VAXstation
4000-60. We have Vim 7.4 installed, but it appears to cause a big spike
in CPU usage and DIOCNT whenever it's run. The person who installed it
is no longer with us, and we are considering deleting Vim.
We also have VILE installed, which limited experimentation has not shown
to cause the same kind of performance problems. Does anyone know if VILE
is indeed well-behaved on VMS?
No idea about vile.
But http://www.polarhome.com/vim/ shows vim 9.1-11 being available
for VMS.
Before distching vim, then maybe check if an upgrade helps. From 7.4
to 9.1 is a pretty big jump.
You can't run 9.1 on a VAX. I assume that the VAXstation
4000-60 David mention is the hardware at the SDF museum.
The above link has links to a bunch of vim-91*vax.zip files -
that is not version 9.1 for VAX??

Arne
Dan Cross
2024-10-16 19:54:43 UTC
Permalink
Post by Arne Vajhøj
Post by Dan Cross
Post by Arne Vajhøj
Post by David Meyer
I'm helping operate an OpenVMS V7.3 system running on a VAXstation
4000-60. We have Vim 7.4 installed, but it appears to cause a big spike
in CPU usage and DIOCNT whenever it's run. The person who installed it
is no longer with us, and we are considering deleting Vim.
We also have VILE installed, which limited experimentation has not shown
to cause the same kind of performance problems. Does anyone know if VILE
is indeed well-behaved on VMS?
No idea about vile.
But http://www.polarhome.com/vim/ shows vim 9.1-11 being available
for VMS.
Before distching vim, then maybe check if an upgrade helps. From 7.4
to 9.1 is a pretty big jump.
You can't run 9.1 on a VAX. I assume that the VAXstation
4000-60 David mention is the hardware at the SDF museum.
The above link has links to a bunch of vim-91*vax.zip files -
that is not version 9.1 for VAX??
Ah, I see now; I mixed up VMS and VIM versions there.

- Dan C.
Arne Vajhøj
2024-10-16 20:05:10 UTC
Permalink
Post by Dan Cross
Post by Arne Vajhøj
Post by Dan Cross
Post by Arne Vajhøj
Post by David Meyer
I'm helping operate an OpenVMS V7.3 system running on a VAXstation
4000-60. We have Vim 7.4 installed, but it appears to cause a big spike
in CPU usage and DIOCNT whenever it's run. The person who installed it
is no longer with us, and we are considering deleting Vim.
We also have VILE installed, which limited experimentation has not shown
to cause the same kind of performance problems. Does anyone know if VILE
is indeed well-behaved on VMS?
No idea about vile.
But http://www.polarhome.com/vim/ shows vim 9.1-11 being available
for VMS.
Before distching vim, then maybe check if an upgrade helps. From 7.4
to 9.1 is a pretty big jump.
You can't run 9.1 on a VAX. I assume that the VAXstation
4000-60 David mention is the hardware at the SDF museum.
The above link has links to a bunch of vim-91*vax.zip files -
that is not version 9.1 for VAX??
Ah, I see now; I mixed up VMS and VIM versions there.
Upgrading from the non-existing VMS VAX 7.4 to the
non-existing VMS VAX 9.1 would certainly be a problem.

Arne
Chris Townley
2024-10-16 22:26:58 UTC
Permalink
Post by Arne Vajhøj
Post by Dan Cross
Post by Arne Vajhøj
Post by Arne Vajhøj
Post by David Meyer
I'm helping operate an OpenVMS V7.3 system running on a VAXstation
4000-60. We have Vim 7.4 installed, but it appears to cause a big spike
in CPU usage and DIOCNT whenever it's run. The person who
installed it
is no longer with us, and we are considering deleting Vim.
We also have VILE installed, which limited experimentation has not shown
to cause the same kind of performance problems. Does anyone know if VILE
is indeed well-behaved on VMS?
No idea about vile.
But http://www.polarhome.com/vim/ shows vim 9.1-11 being available
for VMS.
Before distching vim, then maybe check if an upgrade helps. From 7.4
to 9.1 is a pretty big jump.
You can't run 9.1 on a VAX.  I assume that the VAXstation
4000-60 David mention is the hardware at the SDF museum.
The above link has links to a bunch of vim-91*vax.zip files -
that is not version 9.1 for VAX??
Ah, I see now; I mixed up VMS and VIM versions there.
Upgrading from the non-existing VMS VAX 7.4 to the
non-existing VMS VAX 9.1 would certainly be a problem.
Arne
Why would anyone want use vi, or vim on VMS?

What is wrong with eve/tpu? or even LSE?
--
Chris
Arne Vajhøj
2024-10-16 22:33:37 UTC
Permalink
Post by Chris Townley
Post by Arne Vajhøj
Post by David Meyer
I'm helping operate an OpenVMS V7.3 system running on a VAXstation
4000-60. We have Vim 7.4 installed, but it appears to cause a big spike
in CPU usage and DIOCNT whenever it's run. The person who installed it
is no longer with us, and we are considering deleting Vim.
We also have VILE installed, which limited experimentation has not shown
to cause the same kind of performance problems. Does anyone know if VILE
is indeed well-behaved on VMS?
No idea about vile.
But http://www.polarhome.com/vim/ shows vim 9.1-11 being available
for VMS.
Before distching vim, then maybe check if an upgrade helps. From 7.4
to 9.1 is a pretty big jump.
Why would anyone want use vi, or vim on VMS?
What is wrong with eve/tpu? or even LSE?
EDT, EVE and LSE are the VMS way to edit.

I always use a heavily customized EVE.

But if somebody is doing 98% *nix work and
2% VMS work, then vi(m) may make sense.

OP asked. I am sure he knows about the VMS
editors.

Arne
Lawrence D'Oliveiro
2024-10-16 23:01:08 UTC
Permalink
But if somebody is doing 98% *nix work and 2% VMS work, then vi(m) may
make sense.
Or you could do all your editing on *nix and set up an automated system
for copying files across to VMS. Treat it as an embedded system, in other
words.
David Meyer
2024-10-16 23:40:32 UTC
Permalink
Post by Chris Townley
... I assume that the VAXstation
4000-60 David mention is the hardware at the SDF museum.
Correct.
Post by Chris Townley
Why would anyone want use vi, or vim on VMS?
What is wrong with eve/tpu? or even LSE?
I have become a fan of EVE, and recommend EDT for new VMS users whose
terminals don't have a keypad.

But some people like to try a new OS without having to learn a new
editor. And since a previous administrator thought it was worthwhile to
install VIM and VILE, I don't feel like deleting them unless they cause
unfixable problems. Will give Vim 9.1 a try.
--
David Meyer
Takarazuka, Japan
***@sdf.org
Dave Froble
2024-10-17 00:26:10 UTC
Permalink
Post by Chris Townley
Post by Arne Vajhøj
Post by Dan Cross
Post by Arne Vajhøj
Post by Dan Cross
Post by Arne Vajhøj
Post by David Meyer
I'm helping operate an OpenVMS V7.3 system running on a VAXstation
4000-60. We have Vim 7.4 installed, but it appears to cause a big spike
in CPU usage and DIOCNT whenever it's run. The person who installed it
is no longer with us, and we are considering deleting Vim.
We also have VILE installed, which limited experimentation has not shown
to cause the same kind of performance problems. Does anyone know if VILE
is indeed well-behaved on VMS?
No idea about vile.
But http://www.polarhome.com/vim/ shows vim 9.1-11 being available
for VMS.
Before distching vim, then maybe check if an upgrade helps. From 7.4
to 9.1 is a pretty big jump.
You can't run 9.1 on a VAX. I assume that the VAXstation
4000-60 David mention is the hardware at the SDF museum.
The above link has links to a bunch of vim-91*vax.zip files -
that is not version 9.1 for VAX??
Ah, I see now; I mixed up VMS and VIM versions there.
Upgrading from the non-existing VMS VAX 7.4 to the
non-existing VMS VAX 9.1 would certainly be a problem.
Arne
Why would anyone want use vi, or vim on VMS?
What is wrong with eve/tpu? or even LSE?
Could be what the user is used to using ...
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
John H. Reinhardt
2024-10-17 12:23:38 UTC
Permalink
Post by Dave Froble
Post by Chris Townley
Why would anyone want use vi, or vim on VMS?
What is wrong with eve/tpu? or even LSE?
Could be what the user is used to using ...
What I was going to say, muscle (finger) memory...

After roughly 40 years of EDT/EVE/TPU (and TECO) and around 30 years of VI my fingers remember both, just sometimes not at the correct time. I've thought about adding EMACS but I'm not sure how much memory space my fingers have left.
--
John H. Reinhardt
Lawrence D'Oliveiro
2024-10-17 21:16:07 UTC
Permalink
Post by John H. Reinhardt
After roughly 40 years of EDT/EVE/TPU (and TECO) and around 30 years of
VI my fingers remember both, just sometimes not at the correct time.
I've thought about adding EMACS but I'm not sure how much memory space
my fingers have left.
In my case, I put up with vi because that was the only thing you could be
sure of having on all the proprietary Unix® systems.

Once Unix® went defunct and Linux took over, I switched to Emacs, and
(almost) never looked back.
Arne Vajhøj
2024-10-18 01:06:56 UTC
Permalink
Post by Lawrence D'Oliveiro
Post by John H. Reinhardt
After roughly 40 years of EDT/EVE/TPU (and TECO) and around 30 years of
VI my fingers remember both, just sometimes not at the correct time.
I've thought about adding EMACS but I'm not sure how much memory space
my fingers have left.
In my case, I put up with vi because that was the only thing you could be
sure of having on all the proprietary Unix® systems.
Once Unix® went defunct and Linux took over, I switched to Emacs, and
(almost) never looked back.
No guarantee that emacs is installed on a Linux system. I am not even
sure that it is common to have it installed on servers.

Arne
Lawrence D'Oliveiro
2024-10-18 03:17:08 UTC
Permalink
Post by Arne Vajhøj
No guarantee that emacs is installed on a Linux system.
It’s in the standard repos for all the common distros.
Arne Vajhøj
2024-10-18 10:57:06 UTC
Permalink
Post by Lawrence D'Oliveiro
Post by Arne Vajhøj
No guarantee that emacs is installed on a Linux system.
It’s in the standard repos for all the common distros.
It exist yes.

And for ones own system then no problem installing it.
But if one is working on somebody elses system, then
it may be more complicated.

Arne
Lawrence D'Oliveiro
2024-10-18 21:05:40 UTC
Permalink
But if one is working on somebody elses system, then it may be more
complicated.
If I am expected to be primarily responsible for a customer’s servers,
then I expect to be given reasonably free rein to set them up as I see
fit.
Dave Froble
2024-10-19 02:18:44 UTC
Permalink
Post by Lawrence D'Oliveiro
But if one is working on somebody elses system, then it may be more
complicated.
If I am expected to be primarily responsible for a customer’s servers,
then I expect to be given reasonably free rein to set them up as I see
fit.
That was always my attitude.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2024-10-21 12:21:03 UTC
Permalink
Post by Dave Froble
But if one is working on somebody elses system, then it may be more
complicated.
If I am expected to be primarily responsible for a customer?s servers,
then I expect to be given reasonably free rein to set them up as I see
fit.
That was always my attitude.
I once said at a job interview that I would need emacs on all the
systems I would be interacting with as vi was not something I was
comfortable using. And yes, I was offered the job afterwards... :-)

Simon.

PS: The only place I use vi is on my phone and that is only because you
need a proper keyboard to use emacs.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Rich Alderson
2024-10-21 19:48:46 UTC
Permalink
PS: The only place I use vi is on my phone and that is only because you need
a proper keyboard to use emacs.
Hunh. I frequently use emacs under Mocha Telnet on my iPhone, if I need to
check on something while away from the desk.
--
Rich Alderson ***@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
Simon Clubley
2024-10-22 12:28:16 UTC
Permalink
Post by Rich Alderson
PS: The only place I use vi is on my phone and that is only because you need
a proper keyboard to use emacs.
Hunh. I frequently use emacs under Mocha Telnet on my iPhone, if I need to
check on something while away from the desk.
I'm talking about running an editor on the phone itself, not over
a network connection.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dennis Boone
2024-10-22 02:46:55 UTC
Permalink
Post by Simon Clubley
PS: The only place I use vi is on my phone and that is only because you
need a proper keyboard to use emacs.
On Android, Hackers Keyboard will do what you need. I'd say that it's
not particularly practical to use emacs on the phone, except that (a)
I've done it; and (b) it's really not much worse than using vi on the
phone.

De
Hunter Goatley
2024-10-22 12:02:34 UTC
Permalink
Post by Dennis Boone
Post by Simon Clubley
PS: The only place I use vi is on my phone and that is only because you
need a proper keyboard to use emacs.
On Android, Hackers Keyboard will do what you need.
Unfortunately, I just searched for that on my phone, and Play Store is
telling me, "This app isn't available for your device because it was
made for an older version of Android."

The GitHub site has an old warning of this future possibility.

Hunter
Simon Clubley
2024-10-22 12:45:36 UTC
Permalink
Post by Hunter Goatley
Post by Dennis Boone
Post by Simon Clubley
PS: The only place I use vi is on my phone and that is only because you
need a proper keyboard to use emacs.
On Android, Hackers Keyboard will do what you need.
Hmmm, looks like it's time once again for me to review the versions
of Emacs available for Android. Thanks. (Seriously. :-))

The last time I looked at this a few years ago, the Emacs version
available required a hardware keyboard to work instead of the Hacker's
Keyboard soft keyboard vi is quite happy with.
Post by Hunter Goatley
Unfortunately, I just searched for that on my phone, and Play Store is
telling me, "This app isn't available for your device because it was
made for an older version of Android."
The GitHub site has an old warning of this future possibility.
I hate this kind of arrogant crap from Google. :-(

In my case, I have used the Hacker's Keyboard on every Android device
I own or have ever owned and it continues to work so far. I have the
standalone APK (ie: not installed via Google Play), which I install
after enabling the untrusted install option in Developer Tools on the
device.

I am currently running it on an Android 12 device. I _really_ hope I also
don't have to start looking for a replacement for the Hacker's Keyboard
as well because Google breaks some API it needs in a future Android version.

BTW, from Android 14, Google are also stopping you from outright installing
some perfectly working older APKs unless you install them via adb and they
are also planning to further restrict which older APKs which can be
installed in future Android versions.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Simon Clubley
2024-10-23 17:31:06 UTC
Permalink
Post by Simon Clubley
Post by Hunter Goatley
Post by Dennis Boone
Post by Simon Clubley
PS: The only place I use vi is on my phone and that is only because you
need a proper keyboard to use emacs.
On Android, Hackers Keyboard will do what you need.
Hmmm, looks like it's time once again for me to review the versions
of Emacs available for Android. Thanks. (Seriously. :-))
The last time I looked at this a few years ago, the Emacs version
available required a hardware keyboard to work instead of the Hacker's
Keyboard soft keyboard vi is quite happy with.
I did some exploring last night and found:

https://f-droid.org/en/packages/org.gnu.emacs/

There are reports about this build having some problems, but all the
basic stuff I tried worked OK on Android 12 and it works just fine with
the Hacker's Keyboard.

You have to grant it file access permissions, but you are prompted about
that in the welcome screen. Note that this is on F-Droid, NOT Google
Play (with all the checks Google Play does), so that may or may not be
a concern for you.

One nice feature is that it integrates into Android so that in the Files
application you are given an option (in Open with) to open the file with
Emacs.
Post by Simon Clubley
Post by Hunter Goatley
Unfortunately, I just searched for that on my phone, and Play Store is
telling me, "This app isn't available for your device because it was
made for an older version of Android."
The GitHub site has an old warning of this future possibility.
I hate this kind of arrogant crap from Google. :-(
In my case, I have used the Hacker's Keyboard on every Android device
I own or have ever owned and it continues to work so far. I have the
standalone APK (ie: not installed via Google Play), which I install
after enabling the untrusted install option in Developer Tools on the
device.
I am currently running it on an Android 12 device. I _really_ hope I also
don't have to start looking for a replacement for the Hacker's Keyboard
as well because Google breaks some API it needs in a future Android version.
I also did a quick check last night for what other soft keyboards might
be available and I found one called Unexpected Keyboard at:

https://f-droid.org/en/packages/juloo.keyboard2/

This one is also found on Google Play as well. It's better than the
standard Android keyboard, but while it's got some interesting features,
I don't find it overall to be as good or as nice as the Hacker's Keyboard.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Simon Clubley
2024-10-23 17:53:44 UTC
Permalink
Post by Simon Clubley
You have to grant it file access permissions, but you are prompted about
that in the welcome screen. Note that this is on F-Droid, NOT Google
Play (with all the checks Google Play does), so that may or may not be
a concern for you.
That may be a little unclear for you, so I will restate that as: it is on
F-Droid, not Google Play, so the APK will not have the Google Play
specific checks that Google apply before they will list an application
on Google Play.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Hunter Goatley
2024-10-24 00:04:31 UTC
Permalink
Post by Simon Clubley
That may be a little unclear for you, so I will restate that as: it is on
F-Droid, not Google Play, so the APK will not have the Google Play
specific checks that Google apply before they will list an application
on Google Play.
I was going to check F-Droid to see if was there, but haven't had time
yet. Thanks.

Hunter

Simon Clubley
2024-10-17 12:37:08 UTC
Permalink
Post by Chris Townley
Why would anyone want use vi, or vim on VMS?
VI on VMS is just about using what you already know IMHO, in the same
way as I enable EDT keypad mapping in emacs.
Post by Chris Townley
What is wrong with eve/tpu? or even LSE?
However, when it comes to emacs, it does a _lot_ that EVE does not do.
For one simple but very important example, you have brace matching in
emacs so you can easily check the closing brace matches the correct
opening brace.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Chris Townley
2024-10-17 12:43:44 UTC
Permalink
Post by Simon Clubley
Post by Chris Townley
Why would anyone want use vi, or vim on VMS?
VI on VMS is just about using what you already know IMHO, in the same
way as I enable EDT keypad mapping in emacs.
Post by Chris Townley
What is wrong with eve/tpu? or even LSE?
However, when it comes to emacs, it does a _lot_ that EVE does not do.
For one simple but very important example, you have brace matching in
emacs so you can easily check the closing brace matches the correct
opening brace.
Simon.
Eight Meg and Continuously Swapping ISTR
--
Chris
Arne Vajhøj
2024-10-17 12:53:27 UTC
Permalink
Post by Simon Clubley
Post by Chris Townley
What is wrong with eve/tpu? or even LSE?
However, when it comes to emacs, it does a _lot_ that EVE does not do.
For one simple but very important example, you have brace matching in
emacs so you can easily check the closing brace matches the correct
opening brace.
EVE does not have that out of the box.

But then EVE has relative little out of the box.

You can add it.

Either DIY or grab a copy of Kenneth Faitfield's
EVE_MATCH_DELIMITORS.

I am afraid there are no online archive of INFO-TPU, but
the most valuable pieces will have survived somewhere
(I got the above).

Arne
Arne Vajhøj
2024-10-17 12:57:30 UTC
Permalink
Post by Arne Vajhøj
Post by Simon Clubley
Post by Chris Townley
What is wrong with eve/tpu? or even LSE?
However, when it comes to emacs, it does a _lot_ that EVE does not do.
For one simple but very important example, you have brace matching in
emacs so you can easily check the closing brace matches the correct
opening brace.
EVE does not have that out of the box.
But then EVE has relative little out of the box.
You can add it.
Either DIY or grab a copy of Kenneth Faitfield's
EVE_MATCH_DELIMITORS.
I am afraid there are no online archive of INFO-TPU, but
the most valuable pieces will have survived somewhere
(I got the above).
Here it is.

Arne

!++
! This procedure highlights (in BOLD, REVERSE video) matching pairs
! of delimitors, the first of which is taken to be the character at
! the current cursor position. Highlighting is turned off by invoking
! this procedure with the cursor positioned on a non-delimitor character.
! Subsequent invocations turn off the highlighting on previously matched
! pairs, as well.
!
! This procedure uses the global marker variables khf$x_match1_position,
! khf$x_match2_position, khf$x_match3_position, and khf$x_match4_position.
!
! Author/Date: K.H. Fairfield, 16-Jan-1988
!
!--
Procedure Eve_Match_Delimitors
! --------------------
Local saved_mark, ! mark current position
first_char, ! first character of matching pair
last_char, ! second character of matching pair
direction, ! search direction
n; ! character position in khf$kt_left_delims or
! khf$kt_right_delims string.


On_Error
[TPU$_CONTROLC]:
Eve$Learn_Abort;
Eve$$Restore_Position (saved_mark);
[OTHERWISE]:
Eve$$Restore_Position (saved_mark);
Endon_Error;


saved_mark := Mark (NONE);

!+
! Make an early return here if the current position is the same
! position as the last previously marked delimitor.
!-
If khf$x_match1_position <> 0 Then
If saved_mark = khf$x_match1_position Then

khf$x_match1_position:= 0;
khf$x_match2_position:= 0;
khf$x_match3_position:= 0;
khf$x_match4_position:= 0;
Return (TRUE);

Endif;
Endif;

first_char := CURRENT_CHARACTER;

n := Index (khf$kt_left_delims, first_char);

If n > 0 Then
last_char := Substr (khf$kt_right_delims, n, 1);
direction := FORWARD;
Else
n := Index (khf$kt_right_delims, first_char);

If n > 0 Then
last_char := Substr (khf$kt_left_delims, n, 1);
direction := REVERSE;
Else
!+
! Current_Character was not a delimitor. If highlighting is on, turn it
! off, else issue an error message.
!-
If khf$x_match1_position = 0 Then
Eve$message ("The current character, " + first_char +
", is not a valid delimitor to match.");
Endif;
khf$x_match1_position:= 0;
khf$x_match2_position:= 0;
khf$x_match3_position:= 0;
khf$x_match4_position:= 0;
Return (FALSE);
Endif;
Endif;

khf$x_match1_position:= Mark (BOLD);
khf$x_match2_position:= Mark (REVERSE);

If Khf_Find_Match (first_char, last_char, direction) = 1 Then
khf$x_match3_position:= Mark (BOLD);
khf$x_match4_position:= Mark (REVERSE);
Update (CURRENT_WINDOW);
Position (khf$x_match1_position);
Return (TRUE);
Else
Position (khf$x_match1_position);
khf$x_match1_position:= 0;
khf$x_match2_position:= 0;
khf$x_match3_position:= 0;
khf$x_match4_position:= 0;
Eve$message (" Could not find the matching " + last_char +
" character for the current character, " + first_char);
Return (FALSE);
Endif;


EndProcedure; ! Eve_Match_Delimitors


!++
! The following procedure does the actually search for the matching
! delimitor character. A recursive algorithm is used so that intervening
! pairs of matched delimitors are not mistakenly selected as the match.
!
! Input Parameters:
!
! first the delimitor character whose mate is being sought
!
! last the matching delimitor character
!
! direction the direction to search. If first_char is a right-
! delimitor, the search direction is FORWARD,
! otherwise it is REVERSE.
!
! Author/Date: K.H. Fairfield, 16-Jan-1988
!-

Procedure Khf_Find_Match (first, last, direction)
! --------------
Local this_patt, this_range;

this_patt := first + last;
Loop
If direction = FORWARD Then
Move_Horizontal (1);
Else
Move_Horizontal (-1);
Endif;
this_range := Search_Quietly (Any (this_patt), direction);
If this_range <> 0
Then
Position (this_range);
Else
Return (0);
Endif;
If CURRENT_CHARACTER = last Then
Return (1);
Else
If Khf_Find_Match (first, last, direction) = 0 Then
Return (0);
Endif;
Endif;
Endloop;

Endprocedure; ! Khf_Find_Match
Simon Clubley
2024-10-18 12:09:23 UTC
Permalink
Post by Arne Vajhøj
Post by Arne Vajhøj
Post by Simon Clubley
Post by Chris Townley
What is wrong with eve/tpu? or even LSE?
However, when it comes to emacs, it does a _lot_ that EVE does not do.
For one simple but very important example, you have brace matching in
emacs so you can easily check the closing brace matches the correct
opening brace.
EVE does not have that out of the box.
But then EVE has relative little out of the box.
You can add it.
Either DIY or grab a copy of Kenneth Faitfield's
EVE_MATCH_DELIMITORS.
I am afraid there are no online archive of INFO-TPU, but
the most valuable pieces will have survived somewhere
(I got the above).
Here it is.
[snip]

How is this run ? Do you have to manually press a key to do the matching
or does the routine get called automatically as you type (as in emacs) ?

I also don't see what happens if the opening brace is off the top of the
screen. For emacs, it shows the matching source code in the status line
at the bottom of the screen in this case.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2024-10-18 12:48:04 UTC
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
Post by Arne Vajhøj
Post by Simon Clubley
Post by Chris Townley
What is wrong with eve/tpu? or even LSE?
However, when it comes to emacs, it does a _lot_ that EVE does not do.
For one simple but very important example, you have brace matching in
emacs so you can easily check the closing brace matches the correct
opening brace.
EVE does not have that out of the box.
But then EVE has relative little out of the box.
You can add it.
Either DIY or grab a copy of Kenneth Faitfield's
EVE_MATCH_DELIMITORS.
I am afraid there are no online archive of INFO-TPU, but
the most valuable pieces will have survived somewhere
(I got the above).
Here it is.
[snip]
How is this run ? Do you have to manually press a key to do the matching
or does the routine get called automatically as you type (as in emacs) ?
As is it is just a command. You can bind that command to a key of
your choice.

Doing it automatically is an interesting question. I don't know how, but
maybe there is a way in TPU - an "on something changed event". I don't
think anyone wanted to do that back then (late 80's early 90's), but
with todays CPU's then why not.
Post by Simon Clubley
I also don't see what happens if the opening brace is off the top of the
screen. For emacs, it shows the matching source code in the status line
at the bottom of the screen in this case.
It definitely does not use status line. It just highlights and when
you scroll down you can see it as highlighted. That would
obviously not work with the automatic process you envision above
and VT where scrolling change current position.

Arne
Arne Vajhøj
2024-10-18 13:26:11 UTC
Permalink
Post by Arne Vajhøj
Post by Simon Clubley
Post by Arne Vajhøj
Post by Arne Vajhøj
Post by Simon Clubley
For one simple but very important example, you have brace matching in
emacs so you can easily check the closing brace matches the correct
opening brace.
EVE does not have that out of the box.
But then EVE has relative little out of the box.
You can add it.
Either DIY or grab a copy of Kenneth Faitfield's
EVE_MATCH_DELIMITORS.
I am afraid there are no online archive of INFO-TPU, but
the most valuable pieces will have survived somewhere
(I got the above).
Here it is.
[snip]
How is this run ? Do you have to manually press a key to do the matching
or does the routine get called automatically as you type (as in emacs) ?
As is it is just a command. You can bind that command to a key of
your choice.
Doing it automatically is an interesting question. I don't know how, but
maybe there is a way in TPU - an "on something changed event". I don't
think anyone wanted to do that back then (late 80's early 90's), but
with todays CPU's then why not.
I took a look at the TPU manual. It does not look like there
is anything smart for this.

It would of course be possible to do a callout in all
procedures that change current position. But that is a very
intrusive solution.

Seems like CTRL/whatever is the best practical.

Arne
Arne Vajhøj
2024-10-18 17:47:18 UTC
Permalink
Post by Arne Vajhøj
Post by Arne Vajhøj
Post by Simon Clubley
Post by Arne Vajhøj
Post by Arne Vajhøj
Post by Simon Clubley
For one simple but very important example, you have brace matching in
emacs so you can easily check the closing brace matches the correct
opening brace.
EVE does not have that out of the box.
But then EVE has relative little out of the box.
You can add it.
Either DIY or grab a copy of Kenneth Faitfield's
EVE_MATCH_DELIMITORS.
I am afraid there are no online archive of INFO-TPU, but
the most valuable pieces will have survived somewhere
(I got the above).
Here it is.
[snip]
How is this run ? Do you have to manually press a key to do the matching
or does the routine get called automatically as you type (as in emacs) ?
As is it is just a command. You can bind that command to a key of
your choice.
Doing it automatically is an interesting question. I don't know how, but
maybe there is a way in TPU - an "on something changed event". I don't
think anyone wanted to do that back then (late 80's early 90's), but
with todays CPU's then why not.
I took a look at the TPU manual. It does not look like there
is anything smart for this.
It would of course be possible to do a callout in all
procedures that change current position. But that is a very
intrusive solution.
Seems like CTRL/whatever is the best practical.
Nothing in the TPU manual, but something in the TPU$ manual.

This is not pretty, but it seems to work.

procedure eve_auto_match()
if (current_character = "{") or
(current_character = "(") or
(current_character = ")") or
(current_character = "}") then
eve_match_delimitors();
endif
endprocedure;

#include <stdio.h>
#include <stdint.h>

#include <descrip.h>
#include <tpudef.h>
#include <starlet.h>
#include <lib$routines.h>
#include <tpu$routines.h>

static const uint32_t MATCH_DELIM_ACTION = 1;

static void setup_timer();

static void do_match()
{
tpu$trigger_async_action(&MATCH_DELIM_ACTION);
setup_timer();
}

static void setup_timer()
{
uint64_t tmo = 1000000; // 0.1 second
sys$setimr(0, &tmo, do_match, 0, 0);
}

static uint32_t cmd_handler()
{
char cmdlin[1024];
uint16_t cmdlin_len;
$DESCRIPTOR(cmdlin_desc, cmdlin);
uint32_t fileio_desc[2] = { (uint32_t)&tpu$fileio, 0 };
lib$get_foreign(&cmdlin_desc, 0, &cmdlin_len);
cmdlin_desc.dsc$w_length = cmdlin_len;
return tpu$cliparse(&cmdlin_desc, fileio_desc, NULL);
}

int main(int argc, char *argv[])
{
lib$establish(tpu$handler);
uint32_t cmd_handler_desc[2] = { (uint32_t)&cmd_handler, 0 };
tpu$initialize(cmd_handler_desc, 0);
tpu$execute_inifile();
$DESCRIPTOR(matchdelim_desc, "EVE_AUTO_MATCH()");
tpu$specify_async_action(&MATCH_DELIM_ACTION, &matchdelim_desc);
setup_timer();
tpu$control();
uint32_t flags = TPU$M_DELETE_CONTEXT;
tpu$cleanup(&flags);
return 0;
}

Arne
Arne Vajhøj
2024-10-19 00:42:59 UTC
Permalink
Post by Arne Vajhøj
Post by Arne Vajhøj
Post by Arne Vajhøj
Doing it automatically is an interesting question. I don't know how, but
maybe there is a way in TPU - an "on something changed event". I don't
think anyone wanted to do that back then (late 80's early 90's), but
with todays CPU's then why not.
I took a look at the TPU manual. It does not look like there
is anything smart for this.
Nothing in the TPU manual, but something in the TPU$ manual.
This is not pretty, but it seems to work.
Code updated to fix a few issues (not supporting
empty file, having to explicit specify "tpu" as
argument).

procedure eve_auto_match()
if mark (NONE) <> end_of(current_buffer) then
if (current_character = "{") or
(current_character = "(") or
(current_character = ")") or
(current_character = "}") then
eve_match_delimitors();
endif;
endif;
endprocedure;

#include <stdio.h>
#include <string.h>
#include <stdint.h>

#include <descrip.h>
#include <tpudef.h>
#include <starlet.h>
#include <lib$routines.h>
#include <tpu$routines.h>

static const uint32_t MATCH_DELIM_ACTION = 1;

static void setup_timer();

static void do_match()
{
tpu$trigger_async_action(&MATCH_DELIM_ACTION);
setup_timer();
}

static void setup_timer()
{
uint64_t tmo = 1000000; // 0.1 second
sys$setimr(0, &tmo, do_match, 0, 0);
}

static uint32_t cmd_handler()
{
char cmdlin[1024];
$DESCRIPTOR(cmdlin_desc, cmdlin);
uint16_t cmdlin_len;
uint32_t fileio_desc[2] = { (uint32_t)&tpu$fileio, 0 };
strcpy(cmdlin, "tpu ");
cmdlin_desc.dsc$a_pointer += 4;
cmdlin_desc.dsc$w_length -= 4;
lib$get_foreign(&cmdlin_desc, 0, &cmdlin_len);
cmdlin_desc.dsc$a_pointer -= 4;
cmdlin_desc.dsc$w_length = 4 + cmdlin_len;
return tpu$cliparse(&cmdlin_desc, fileio_desc, NULL);
}

int main(int argc, char *argv[])
{
$DESCRIPTOR(matchdelim_desc, "EVE_AUTO_MATCH()");
uint32_t cmd_handler_desc[2] = { (uint32_t)&cmd_handler, 0 };
uint32_t flags = TPU$M_DELETE_CONTEXT;
lib$establish(tpu$handler);
tpu$initialize(cmd_handler_desc, 0);
tpu$execute_inifile();
tpu$specify_async_action(&MATCH_DELIM_ACTION, &matchdelim_desc);
setup_timer();
tpu$control();
tpu$cleanup(&flags);
return 0;
}

Arne
Simon Clubley
2024-10-21 12:14:55 UTC
Permalink
Post by Arne Vajhøj
Code updated to fix a few issues (not supporting
empty file, having to explicit specify "tpu" as
argument).
[snip]

This code is technically a solution in the same way that writing an
accounting system in TECO is also technically possible. :-)

Simon.

PS: $ set response/mode=good_natured
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2024-10-21 19:16:02 UTC
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
Code updated to fix a few issues (not supporting
empty file, having to explicit specify "tpu" as
argument).
[snip]
This code is technically a solution in the same way that writing an
accounting system in TECO is also technically possible. :-)
It actually works reasonable nice on a fast x86-86 system. I would
not want to run it on an old VAX with a lot of users.

The right solution to automate would be to modify every position
changing procedure to do a check. But that would mean hacking a lot
of code.

The pragmatic solution is to just bind the procedure to a key and
manually activate the procedure.

Arne
Simon Clubley
2024-10-22 12:21:18 UTC
Permalink
Post by Arne Vajhøj
Post by Simon Clubley
Post by Arne Vajhøj
Code updated to fix a few issues (not supporting
empty file, having to explicit specify "tpu" as
argument).
[snip]
This code is technically a solution in the same way that writing an
accounting system in TECO is also technically possible. :-)
It actually works reasonable nice on a fast x86-86 system. I would
not want to run it on an old VAX with a lot of users.
The right solution to automate would be to modify every position
changing procedure to do a check. But that would mean hacking a lot
of code.
No, the "right" solution would be to add a:

on_key_press(whatever...)

handler. :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2024-10-22 12:25:20 UTC
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
Post by Simon Clubley
Post by Arne Vajhøj
Code updated to fix a few issues (not supporting
empty file, having to explicit specify "tpu" as
argument).
[snip]
This code is technically a solution in the same way that writing an
accounting system in TECO is also technically possible. :-)
It actually works reasonable nice on a fast x86-86 system. I would
not want to run it on an old VAX with a lot of users.
The right solution to automate would be to modify every position
changing procedure to do a check. But that would mean hacking a lot
of code.
on_key_press(whatever...)
handler. :-)
True. But only VSI can do that.

And I believe there has been no changes to TPU since VMS 5.0.

And VSI seems to push VMS IDE (VS Code) on PC for advanced
development.

So I would not hold my breath waiting for that.

Arne
Chris Townley
2024-10-22 12:29:45 UTC
Permalink
Post by Arne Vajhøj
Post by Arne Vajhøj
Post by Simon Clubley
Post by Arne Vajhøj
Code updated to fix a few issues (not supporting
empty file, having to explicit specify "tpu" as
argument).
[snip]
This code is technically a solution in the same way that writing an
accounting system in TECO is also technically possible. :-)
It actually works reasonable nice on a fast x86-86 system. I would
not want to run it on an old VAX with a lot of users.
The right solution to automate would be to modify every position
changing procedure to do a check. But that would mean hacking a lot
of code.
    on_key_press(whatever...)
handler. :-)
True. But only VSI can do that.
And I believe there has been no changes to TPU since VMS 5.0.
And VSI seems to push VMS IDE (VS Code) on PC for advanced
development.
So I would not hold my breath waiting for that.
Arne
I wonder if they might put it in LSE?
--
Chris
Arne Vajhøj
2024-10-22 12:34:28 UTC
Permalink
Post by Chris Townley
Post by Arne Vajhøj
Post by Arne Vajhøj
Post by Simon Clubley
Post by Arne Vajhøj
Code updated to fix a few issues (not supporting
empty file, having to explicit specify "tpu" as
argument).
[snip]
This code is technically a solution in the same way that writing an
accounting system in TECO is also technically possible. :-)
It actually works reasonable nice on a fast x86-86 system. I would
not want to run it on an old VAX with a lot of users.
The right solution to automate would be to modify every position
changing procedure to do a check. But that would mean hacking a lot
of code.
    on_key_press(whatever...)
handler. :-)
True. But only VSI can do that.
And I believe there has been no changes to TPU since VMS 5.0.
And VSI seems to push VMS IDE (VS Code) on PC for advanced
development.
So I would not hold my breath waiting for that.
I wonder if they might put it in LSE?
It would be more natural to add it there.

But I think LSE is a total dead end. VSI will port
LSE to x86-64 as is and that will be it.

VMS IDE is intended to replace all LSE usage.

EVE will still be needed for let us call it "causual
editing". VMS IDE is not an obvious choice to add a line
to SYSTARTUP_VMS.COM.

Arne
Chris Townley
2024-10-22 12:55:06 UTC
Permalink
Post by Arne Vajhøj
Post by Chris Townley
Post by Arne Vajhøj
Post by Arne Vajhøj
Post by Simon Clubley
Post by Arne Vajhøj
Code updated to fix a few issues (not supporting
empty file, having to explicit specify "tpu" as
argument).
[snip]
This code is technically a solution in the same way that writing an
accounting system in TECO is also technically possible. :-)
It actually works reasonable nice on a fast x86-86 system. I would
not want to run it on an old VAX with a lot of users.
The right solution to automate would be to modify every position
changing procedure to do a check. But that would mean hacking a lot
of code.
    on_key_press(whatever...)
handler. :-)
True. But only VSI can do that.
And I believe there has been no changes to TPU since VMS 5.0.
And VSI seems to push VMS IDE (VS Code) on PC for advanced
development.
So I would not hold my breath waiting for that.
I wonder if they might put it in LSE?
It would be more natural to add it there.
But I think LSE is a total dead end. VSI will port
LSE to x86-64 as is and that will be it.
VMS IDE is intended to replace all LSE usage.
EVE will still be needed for let us call it "causual
editing". VMS IDE is not an obvious choice to add a line
to SYSTARTUP_VMS.COM.
Arne
They have another release of DECSET planned, for all platforms
--
Chris
Arne Vajhøj
2024-10-22 13:04:50 UTC
Permalink
Post by Chris Townley
They have another release of DECSET planned, for all platforms
With new functionality? In what products?

My impression is that:

LSE -> VMS IDE

CMS -> Git/SVN/Hg

MMS still has some relevance (make ports usually misses some VMS
specific functionality, MMK is an MMS clone)

SCA, DTM and PCA I hear very little about today and I suspect very few
are using them (I was very impressed by PCA 30-35 years ago, but long time)

Arne
Hunter Goatley
2024-10-22 13:10:38 UTC
Permalink
Post by Arne Vajhøj
MMS still has some relevance (make ports usually misses some VMS
specific functionality, MMK is an MMS clone)
For anyone who doesn't know, MMK is more than just an MMS clone. It also
adds a lot of functionality that MMS doesn't provide.

Hunter
Arne Vajhøj
2024-10-22 13:30:25 UTC
Permalink
Post by Hunter Goatley
Post by Arne Vajhøj
MMS still has some relevance (make ports usually misses some VMS
specific functionality, MMK is an MMS clone)
For anyone who doesn't know, MMK is more than just an MMS clone. It also
adds a lot of functionality that MMS doesn't provide.
OK.

But it does use DESCRIP.MMS files and not MAKEFILE. files.

Arne
Lawrence D'Oliveiro
2024-10-22 20:43:40 UTC
Permalink
Post by Arne Vajhøj
But it does use DESCRIP.MMS files and not MAKEFILE. files.
Is there a port of CMake to VMS?

That’s not the latest hawtness, but I imagine it would still be a step
forward.
Arne Vajhøj
2024-10-22 21:58:54 UTC
Permalink
Post by Lawrence D'Oliveiro
Post by Arne Vajhøj
But it does use DESCRIP.MMS files and not MAKEFILE. files.
Is there a port of CMake to VMS?
I don't think so.

Even though I believe it has been looked into before.
Post by Lawrence D'Oliveiro
That’s not the latest hawtness, but I imagine it would still be a step
forward.
Feel free to start porting.

Arne
Simon Clubley
2024-10-23 12:11:37 UTC
Permalink
Post by Arne Vajhøj
Post by Lawrence D'Oliveiro
Post by Arne Vajhøj
But it does use DESCRIP.MMS files and not MAKEFILE. files.
Is there a port of CMake to VMS?
I don't think so.
Even though I believe it has been looked into before.
John's working on it as part of the move to a modern LLVM.

I don't know the current status.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Mark Berryman
2024-10-23 20:47:30 UTC
Permalink
Post by Hunter Goatley
Post by Arne Vajhøj
MMS still has some relevance (make ports usually misses some VMS
specific functionality, MMK is an MMS clone)
For anyone who doesn't know, MMK is more than just an MMS clone. It also
adds a lot of functionality that MMS doesn't provide.
Unfortunately, it is also missing some MMS functionality. For example,
it would be really nice if $(wildcard ...) could be fixed.

Mark Berryman
Robert A. Brooks
2024-10-22 13:21:24 UTC
Permalink
Post by Chris Townley
Post by Arne Vajhøj
Post by Chris Townley
I wonder if they might put it in LSE?
It would be more natural to add it there.
But I think LSE is a total dead end. VSI will port
LSE to x86-64 as is and that will be it.
VMS IDE is intended to replace all LSE usage.
EVE will still be needed for let us call it "causual
editing". VMS IDE is not an obvious choice to add a line
to SYSTARTUP_VMS.COM.
Arne
They have another release of DECSET planned, for all platforms
We've been focusing on bug fixes, not ehancements, for the DECset products.
--
-- Rob
Lawrence D'Oliveiro
2024-10-22 20:45:09 UTC
Permalink
VMS IDE is not an obvious choice to add a line to SYSTARTUP_VMS.COM.
Is that an rc.local equivalent?

You’d think by this time VMS would have acquired a more modular service
definition architecture, à la systemd.
John H. Reinhardt
2024-10-22 22:42:46 UTC
Permalink
Post by Lawrence D'Oliveiro
VMS IDE is not an obvious choice to add a line to SYSTARTUP_VMS.COM.
Is that an rc.local equivalent?
You’d think by this time VMS would have acquired a more modular service
definition architecture, à la systemd.
It does, sort of. It's more modular anyway. Virtually nobody uses it. The SYSTARTUP_VMS.COM method is what most people got started with in pre VAX/VMS 5.0 and few have moved on. Check these out for info:

OpenVMS STARTUP - Underappreciated Flexibility - http://www.rlgsc.com/publications/openvmsstartupunderappreciatedflexibility.html
The PDF - http://www.rlgsc.com/publications/openvmsstartupunderappreciatedflexibility.pdf
Adding a file to Startup - http://www.rlgsc.com/blog/openvms-consultant/adding-file-to-startup.html
--
John H. Reinhardt
Arne Vajhøj
2024-10-22 23:06:55 UTC
Permalink
Post by Lawrence D'Oliveiro
VMS IDE is not an obvious choice to add a line to SYSTARTUP_VMS.COM.
Is that an rc.local equivalent?
You’d think by this time VMS would have acquired a more modular service
definition architecture, à la systemd.
It does, sort of. It's more modular anyway.  Virtually nobody uses it.
The SYSTARTUP_VMS.COM method is what most people got started with in pre
OpenVMS STARTUP - Underappreciated Flexibility - http://www.rlgsc.com/
publications/openvmsstartupunderappreciatedflexibility.html
  The PDF - http://www.rlgsc.com/publications/
openvmsstartupunderappreciatedflexibility.pdf
Adding a file to Startup - http://www.rlgsc.com/blog/openvms-consultant/
adding-file-to-startup.html
SYSTARTUP_VMS.COM works fine.

People have 20-30-40 lines in it. After initial installation they add
maybe a few lines per year and in rare cases remove a line.

One does not need a huge advanced system to do that.

Arne
Lawrence D'Oliveiro
2024-10-23 00:09:05 UTC
Permalink
Post by John H. Reinhardt
Adding a file to Startup -
http://www.rlgsc.com/blog/openvms-consultant/adding-file-to-startup.html
I stopped reading at “keyed RMS files”.

systemd conforms to the *nix tradition of using plain-text-based config
files: in this case, the classic .INI file format that was pioneered by
Microsoft (or was it IBM?) before being jettisoned in favour of that
steaming, fetid mess that is the Windows Registry.
Simon Clubley
2024-10-23 12:19:00 UTC
Permalink
Post by John H. Reinhardt
Adding a file to Startup -
http://www.rlgsc.com/blog/openvms-consultant/adding-file-to-startup.html
I stopped reading at ?keyed RMS files?.
systemd conforms to the *nix tradition of using plain-text-based config
files: in this case, the classic .INI file format that was pioneered by
Microsoft (or was it IBM?) before being jettisoned in favour of that
steaming, fetid mess that is the Windows Registry.
You mean the .INI file structure that has no concept of a list of "things"
or a custom data structure so that you have to list the same key more than
once in a systemd config file when you need to build a list structure ?

And before you go into denial about that:

See https://www.freedesktop.org/software/systemd/man/latest/systemd.syntax.html

|Various settings are allowed to be specified more than once, in which case
|the interpretation depends on the setting. Often, multiple settings form a
|list, and setting to an empty value "resets", which means that previous
|assignments are ignored. When this is allowed, it is mentioned in the
|description of the setting. Note that using multiple assignments to the
|same value makes the file incompatible with parsers for the XDG .desktop
|file format.

YUCK!!!

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Lawrence D'Oliveiro
2024-10-22 20:41:52 UTC
Permalink
Post by Arne Vajhøj
Post by Simon Clubley
on_key_press(whatever...)
handler. :-)
True. But only VSI can do that.
What, no custom key bindings in TPU?

Yet another reason to switch to Emacs.
Arne Vajhøj
2024-10-22 21:54:32 UTC
Permalink
Post by Lawrence D'Oliveiro
Post by Arne Vajhøj
Post by Simon Clubley
on_key_press(whatever...)
handler. :-)
True. But only VSI can do that.
What, no custom key bindings in TPU?
It has. But the above is not a key binding.

Arne
Lawrence D'Oliveiro
2024-10-22 22:06:00 UTC
Permalink
Post by Arne Vajhøj
Post by Lawrence D'Oliveiro
Post by Arne Vajhøj
Post by Simon Clubley
on_key_press(whatever...)
handler. :-)
True. But only VSI can do that.
What, no custom key bindings in TPU?
It has. But the above is not a key binding.
You want some kind of additional hook on every keypress?
Arne Vajhøj
2024-10-23 01:06:13 UTC
Permalink
Post by Lawrence D'Oliveiro
Post by Arne Vajhøj
Post by Lawrence D'Oliveiro
Post by Arne Vajhøj
Post by Simon Clubley
on_key_press(whatever...)
handler. :-)
True. But only VSI can do that.
What, no custom key bindings in TPU?
It has. But the above is not a key binding.
You want some kind of additional hook on every keypress?
That was what is needed to do a check every time
position is changed without modifying all the position
moving procedures and without the dirty 0.1 sec AST.

Arne
Lawrence D'Oliveiro
2024-10-23 01:52:13 UTC
Permalink
Post by Lawrence D'Oliveiro
You want some kind of additional hook on every keypress?
That was what is needed to do a check every time position is changed
without modifying all the position moving procedures and without the
dirty 0.1 sec AST.
In Emacs, every key is bound to a command; a key that inserts a
literal character that represents itself is bound to the command
called “self-insert-command”.

So you should be able to hook every action via the command hooks
<https://www.gnu.org/software/emacs/manual/html_node/elisp/Command-Overview.html>.

There is also mention of the special post-self-insert-hook here
<https://www.gnu.org/software/emacs/manual/html_node/elisp/Standard-Hooks.html>.
Lawrence D'Oliveiro
2024-10-17 21:18:14 UTC
Permalink
Post by Arne Vajhøj
But then EVE has relative little out of the box.
Soon as I discovered EVE, I created my own adaptation, which I called
“PEEVE” (“Programmer’s Extension of EVE”, or something like that).

I didn’t have any way of taking a copy with me when I left the University,
and no doubt any backup tapes from that decades-ago time are long gone ...
bill
2024-10-21 16:49:32 UTC
Permalink
Post by Simon Clubley
Post by Chris Townley
Why would anyone want use vi, or vim on VMS?
VI on VMS is just about using what you already know IMHO, in the same
way as I enable EDT keypad mapping in emacs.
Post by Chris Townley
What is wrong with eve/tpu? or even LSE?
However, when it comes to emacs, it does a _lot_ that EVE does not do.
For one simple but very important example, you have brace matching in
emacs so you can easily check the closing brace matches the correct
opening brace.
Which is great if your writing C programs. But of little value for
anything else.

bill
Lawrence D'Oliveiro
2024-10-21 20:48:31 UTC
Permalink
Post by Simon Clubley
For one simple but very important example, you have brace matching in
emacs so you can easily check the closing brace matches the correct
opening brace.
Which is great if [you’re] writing C programs. But of little value for
anything else.
BIND, DHCP and nftables config files also use brace delimiters for
stanzas, just for example.
Dan Cross
2024-10-21 21:45:27 UTC
Permalink
Post by bill
Post by Simon Clubley
Post by Chris Townley
Why would anyone want use vi, or vim on VMS?
VI on VMS is just about using what you already know IMHO, in the same
way as I enable EDT keypad mapping in emacs.
Post by Chris Townley
What is wrong with eve/tpu? or even LSE?
However, when it comes to emacs, it does a _lot_ that EVE does not do.
For one simple but very important example, you have brace matching in
emacs so you can easily check the closing brace matches the correct
opening brace.
Which is great if your writing C programs. But of little value for
anything else.
Brace matching generalizes to parenthesis matching, or any paired
symbols with an "open" character and a "close" character: <>, [],
etc. Parenthesis matching is very useful for e.g. Lisp.

- Dan C.
Arne Vajhøj
2024-10-21 22:57:22 UTC
Permalink
Post by Simon Clubley
However, when it comes to emacs, it does a _lot_ that EVE does not do.
For one simple but very important example, you have brace matching in
emacs so you can easily check the closing brace matches the correct
opening brace.
Which is great if your writing C programs.  But of little value for
anything else.
Curly braces for blocks are used in many languages today.
If we limit ourselves to those available on VMS then: C,
C++, PHP, Java, Kotlin, Scala and Groovy comes to my mind.

Ordinary parenthesis's are used in practically all languages
and there are cases where matching can be relevant - deeply
nested or statement continued over many lines.

Arne
bill
2024-10-21 16:44:45 UTC
Permalink
Post by Chris Townley
Why would anyone want use vi, or vim on VMS?
What is wrong with eve/tpu? or even LSE?
Because they know vi and don't know any of the VMS editors.

bill
Loading...