RISC OS 5.30 Task window error

I’ve recently updated to RO 5.30 on a Pi 3B and spotted this error occurring when bringing up the task window on the desktop.
Firstly bring up the task display, then press Ctrl F12 or choose Task window from the menu.
This produces the error – Internal error. Undefined Instruction at &80C0

Is this with Zap? If so see here for a similar report.

Thanks for that link. Zap is on the the machine but not running when this happens. I’ll try the updated version and see if that helps. It’s also strange that the 2nd time I open the task window it works just fine.

What editor is responsible for managing the task window?

I just updated Zap to the latest and that has cured the problem. Good to know. Thanks all.

Just to note – for future readers – Drucks question is very relevant:

What editor is responsible for managing the task window?

Basically the default editor for the system will be managing the task window, be it Edit, Zap, or StrongED, and even when not visible on the taskbar a bug in the editor can cause errors in the task window startup or operation.

I’ve been wondering about this for a while, and this seems a convenient place to ask. When programming on RISC OS, I miss the history feature for command lines that is typical on Linux etc. You know type a command line, find there’s something wrong with it, and all you have to do is press up arrow to have another go, as opposed to typing the whole lot again.

In 1988, someone I knew did a module for the Archimedes OS 1.2 command line (plain F12) that allowed this. I wonder about doing it for task windows – are there hooks somewhere.

I’ve found mentions of ShellC by MartinWurthner – of course the actual software is vanished – so no idea if it is relevant.

Why wouldn’t the F12 version work in a taskwindow?

I wrote one years ago – I’m sure it worked fine both in a task window and not. You’re probably thinking of Olly Betts’ module rather than mine, though, as I’m not even sure I put it anywhere. Maybe Arcade.

This is the magic: https://github.com/philpem/LineEditor

Stick it in PreDesk.

This is the magic: https://github.com/philpem/LineEditor

Thanks. The ReadMe tells that it was based on a line editor written by Richard K Lloyd, which is the one from the past I was thinking of. It is a new implementation by Olly Betts then Darren Salt.

Why wouldn’t the F12 version work in a taskwindow?

I don’t understand how the command line interacts with the text editor, from that point of view why would it work. In the ReadMe for the line editor above there is plenty of discussion about things occasionally not working with task windows.

I should learn how to use Google. My logic was if such a thing exists it will be supplied as standard with RISC OS.

My logic was if such a thing exists it will be supplied as standard with RISC OS.

Seems perfectly logical. Unfortunately, logic doesn’t always seem to apply.

You might also be interested in https://github.com/gerph/linenoise – I ported another line editor which was written in C, because the LineEditor that we know and love is all in BASIC assembler, and that makes it far less useful for maintenance, updates, etc.

LineNoise isn’t as featureful at LineEditor, but it is significantly more manageable, being written in C and more easily testable without having to replace ReadLine. Feel free to have a play with it as well, and PRs are happily received – that’s why it’s open source.

I don’t understand how the command line interacts with the text editor, from that point of view why would it work. In the ReadMe for the line editor above there is plenty of discussion about things occasionally not working with task windows.

TaskWindows only provide you character input and output. They fake (through… stuff) some of the character input and output operations, but because the process model on RISC OS is non-existant, their faking is incomplete. As such, the ‘read position’, ‘read size of screen’, and similar, won’t work the way they are expecting. Similarly, the changing of key input doesn’t always work the right way (function and cursor effects might not be exactly the same) – and of course the controlling system may be using some keys for its own purposes. You can’t (for example) reliably say ‘Is ALT pressed’ by calling INKEY in a taskwindow because the key may have been released, or if the TaskWindow was being driven remotely, there may not be any ‘keys’ pressed.

Then there are the effects of the output which might not be supported by the output application. For example, you might assume that would take you to the start of the line, but that depends on a) the output application interpreting that, and b) the ‘line’ being the same length you thought it was (consider a window that’s 3 characters wide – but you did a OS_ReadVduVariables to find the WindowWidth (var 256?) and it said that the screen was 160 characters across). Or you try VDU 7 to get a beep. That’s probably supported… maybe. Or defining a window. Or position the cursor. Or move left and right characters, or up and down lines. Or reprogram the character set and output a character. Or changing colour – if you use VDU 17 (I think that’s the one) you’ll be fine if the output application supports, but still that assumes you know what the colours are. If your output application doesn’t support that, then it obviously won’t work. And if you use ColourTrans_SetTextColour you’re going to be disappointed in the TaskWindow.

There’s many reasons why TaskWindows causes problems because of how it has to operate, and LineEditor (and their ilk) hit these for some cases.

My !GraphTask graphic task windows addresses some of the problems by emulating the VDU system in numbered modes to a certain extent. But it doesn’t get around the problem that when the task window task is running most SWIs will read attributes of the desktop screen as explained above. It does translate mouse position for the task though.

You might also be interested in https://github.com/gerph/linenoise

Interesting. TBH, I failed to get it to build

…module.Makefile (around line 49)
AMU: mal-formed suffix rule

(not worth anyone worrying about my problems with the Acorn C tools, me included).

Note that LineEditor comes with Zap (and is loaded automatically IIRC). This combination works well as Zap handles the cursor movement stuff and cut/paste very well, plus it intercepts the screen width calls so that programs think the screen is the width of the window and hence format their output correctly. (If Fred is listening, this would be a great feature to add to StrongEd!)

Note that LineEditor comes with Zap … and is loaded automatically

In my defence I admit to being a StrongED user and though LineEditor does work with StrongED it is not something I have not made much use of. However a simple way of correcting all my spelling mistakes at the command line has its attractions.

My copy of Zap, rick-07, has an old LineEditor.

*help lineeditor
==> Help on keyword LineEditor
Module is: Line Editor     2.76d (03 Mar 2003) [test version - don't distribute without
permission] Olly Betts

The LineEditor module is here, !Zap.Code.Extensions.LineEditor.LineEditor and is loaded by this file !Zap.Code.Extensions.BootLineEd which includes some setup.

|
| Line Editor boot file
|
RMEnsure LineEditor 0.00 X RMLoad ZapExtensions:LineEditor.LineEditor 16 2_0000011 2 0 &1000
Set CLI$Prompt <17><1>*
Set LineEditor$Edit <17><2>
Set LineEditor$List <17><3>
Set LineEditor$Type <17><4>
Set LineEditor$Output <17><5>

For use with StrongED a user automatic load can be included in !StrED_cfg.UserPrefs.StartUp.UserInit eg:-

| User specific initialisation
| Here you can add commands to perform additional initialisation

RMEnsure LineEditor 2.78 RMload SCSI::SSD120.$.Progm.Editors2.LineEditor

Currently the module is in an arbitrary location in my disc image, as a shared resource !System might be more appropriate.

There is no StrongED setup as there was with Zap, though it could easily be added if necessary.

Interesting. TBH, I failed to get it to build

Ah, that’ll be because it uses my build system, so you won’t have a bunch of things defined, or the makefile headers. I do keep meaning to do a release of the build environment, but it’s not been that much of a priority.

I’ll set up an automated build for it later so that there’s an external build. I thought I’d already done that, to be honest. Oh, I did… they’re in the Releases section – https://github.com/gerph/linenoise/releases

(If Fred is listening, this would be a great feature to add to StrongEd!)

Already done that. It’s present in the latest test release (StrongED 4.70a15).

they’re in the Releases section

Thank you. I learnt something new. I had not taken in there is a releases section.

I’ve tried release 0.02, and the history bit seems to work, but it always executes some other command to the one typed last.

I’ve tried release 0.02, and the history bit seems to work, but it always executes some other command to the one typed last.

That definitely sounds like I’m failing to return the thing that I actually had entered. Will look into that!