| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 42 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 01:28:42 |
| Calls: | 220 |
| Calls today: | 1 |
| Files: | 824 |
| Messages: | 121,541 |
| Posted today: | 6 |
> 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.
On 10/21/2024 8:14 AM, Simon Clubley wrote:
On 2024-10-18, Arne Vajh°j <arne@vajhoej.dk> wrote:
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 2024-10-21, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 10/21/2024 8:14 AM, Simon Clubley wrote:
On 2024-10-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
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 Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
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.
On 10/22/2024 8:21 AM, Simon Clubley wrote:
On 2024-10-21, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 10/21/2024 8:14 AM, Simon Clubley wrote:
On 2024-10-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
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. :-)
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
On 22/10/2024 13:25, Arne Vajhøj wrote:
On 10/22/2024 8:21 AM, Simon Clubley wrote:
On 2024-10-21, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 10/21/2024 8:14 AM, Simon Clubley wrote:
On 2024-10-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
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. :-)
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?
On 10/21/2024 10:46 PM, Dennis Boone wrote:
> 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.
On 10/22/2024 8:55 AM, Chris Townley wrote:
MMS still has some relevance (make ports usually misses some VMS
specific functionality, MMK is an MMS clone)
They have another release of DECSET planned, for all platforms
On 10/22/2024 8:29 AM, Chris Townley wrote:
On 22/10/2024 13:25, Arne Vajhøj wrote:
On 10/22/2024 8:21 AM, Simon Clubley wrote:
On 2024-10-21, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 10/21/2024 8:14 AM, Simon Clubley wrote:
On 2024-10-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
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. :-)
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
On 10/22/2024 9:04 AM, Arne Vajhøj wrote:
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.
On 22/10/2024 13:34, Arne Vajhøj wrote:
On 10/22/2024 8:29 AM, Chris Townley wrote:
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
But it does use DESCRIP.MMS files and not MAKEFILE. files.
VMS IDE is not an obvious choice to add a line to SYSTARTUP_VMS.COM.
No, the "right" solution would be to add a:
on_key_press(whatever...)
handler. :-)
True. But only VSI can do that.
On Tue, 22 Oct 2024 08:25:20 -0400, Arne Vajhøj wrote:
No, the "right" solution would be to add a:
on_key_press(whatever...)
handler. :-)
True. But only VSI can do that.
What, no custom key bindings in TPU?
On Tue, 22 Oct 2024 09:30:25 -0400, Arne Vajhøj wrote:
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.
On 10/22/2024 4:41 PM, Lawrence D'Oliveiro wrote:
On Tue, 22 Oct 2024 08:25:20 -0400, Arne Vajhøj wrote:
No, the "right" solution would be to add a:
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.
On 10/22/2024 3:45 PM, Lawrence D'Oliveiro wrote:
On Tue, 22 Oct 2024 08:34:28 -0400, Arne Vajhøj wrote:
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
On Tue, 22 Oct 2024 08:34:28 -0400, Arne Vajhøj wrote:
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.
Adding a file to Startup - http://www.rlgsc.com/blog/openvms-consultant/adding-file-to-startup.html
On Tue, 22 Oct 2024 17:54:32 -0400, Arne Vajhøj wrote:
On 10/22/2024 4:41 PM, Lawrence D'Oliveiro wrote:
On Tue, 22 Oct 2024 08:25:20 -0400, Arne Vajhøj wrote:
No, the "right" solution would be to add a:
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?
On 10/22/2024 6:06 PM, Lawrence D'Oliveiro wrote:
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.
On 10/16/2024 9:57 AM, David Meyer wrote:
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.
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?
In article <vep4bs$2cblv$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 10/16/2024 9:57 AM, David Meyer wrote:
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.
On 10/16/2024 3:45 PM, Dan Cross wrote:
In article <vep4bs$2cblv$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 10/16/2024 9:57 AM, David Meyer wrote:
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??
In article <vep5j4$2cbm0$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 10/16/2024 3:45 PM, Dan Cross wrote:
In article <vep4bs$2cblv$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 10/16/2024 9:57 AM, David Meyer wrote:
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.
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 10/16/2024 9:57 AM, David Meyer wrote:
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?
On 10/16/2024 3:54 PM, Dan Cross wrote:
In article <vep5j4$2cbm0$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 10/16/2024 3:45 PM, Dan Cross wrote:
In article <vep4bs$2cblv$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 10/16/2024 9:57 AM, David Meyer wrote:
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
But if somebody is doing 98% *nix work and 2% VMS work, then vi(m) may
make sense.
On 10/16/2024 3:45 PM, Dan Cross wrote:
... I assume that the VAXstation
4000-60 David mention is the hardware at the SDF museum.
Why would anyone want use vi, or vim on VMS?
What is wrong with eve/tpu? or even LSE?
On 16/10/2024 21:05, Arne Vajhøj wrote:
On 10/16/2024 3:54 PM, Dan Cross wrote:
In article <vep5j4$2cbm0$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 10/16/2024 3:45 PM, Dan Cross wrote:
In article <vep4bs$2cblv$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 10/16/2024 9:57 AM, David Meyer wrote:
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?
On 10/22/2024 4:43 PM, Lawrence D'Oliveiro wrote:
On Tue, 22 Oct 2024 09:30:25 -0400, Arne Vajh°j wrote:
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.
On Tue, 22 Oct 2024 17:42:46 -0500, John H. Reinhardt wrote:
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 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.
On 2024-10-22, Hunter Goatley <goathunter@goatley.com> wrote:
On 10/21/2024 10:46 PM, Dennis Boone wrote:
> 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.
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.
On 10/22/2024 9:04 AM, Arne Vajhøj wrote:
On 10/22/2024 8:55 AM, Chris Townley wrote:
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.
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.
Why would anyone want use vi, or vim on VMS?
What is wrong with eve/tpu? or even LSE?
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.
On 2024-10-16, Chris Townley <news@cct-net.co.uk> wrote:
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.
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.
On 10/16/2024 6:26 PM, Chris Townley wrote:
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 ...
On 10/17/2024 8:37 AM, Simon Clubley wrote:
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).
But then EVE has relative little out of the box.
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.
On Thu, 17 Oct 2024 07:23:38 -0500, John H. Reinhardt wrote:
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.
On Thu, 17 Oct 2024 21:06:56 -0400, Arne Vajhøj wrote:
No guarantee that emacs is installed on a Linux system.
It’s in the standard repos for all the common distros.
On 10/17/2024 8:53 AM, Arne Vajh°j wrote:
On 10/17/2024 8:37 AM, Simon Clubley wrote:
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.
On 2024-10-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 10/17/2024 8:53 AM, Arne Vajhøj wrote:
On 10/17/2024 8:37 AM, Simon Clubley wrote:
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.
On 10/18/2024 8:09 AM, Simon Clubley wrote:
On 2024-10-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 10/17/2024 8:53 AM, Arne Vajhøj wrote:
On 10/17/2024 8:37 AM, Simon Clubley wrote:
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.
On 10/18/2024 8:48 AM, Arne Vajhøj wrote:
On 10/18/2024 8:09 AM, Simon Clubley wrote:
On 2024-10-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 10/17/2024 8:53 AM, Arne Vajhøj wrote:
On 10/17/2024 8:37 AM, Simon Clubley wrote:
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.
But if one is working on somebody elses system, then it may be more complicated.
On 10/18/2024 9:26 AM, Arne Vajhøj wrote:
On 10/18/2024 8:48 AM, Arne Vajhøj wrote:
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.
On Fri, 18 Oct 2024 06:57:06 -0400, Arne Vajhøj wrote:
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.