Is there a Task Window command repeat key

Is there a key, in Task Window, to repeat the last command? Like the up arrow in Linux.

Thanks in advance.

Yes, if you use StrongEd or Zap to open the Task Window. Surprise: it’s the up arrow too.

Nearly!

The up arrow bit is supplied by the LineEditor module within !Zap, !Zap.Code.Extensions.LineEditor. Once RMLoaded the module does indeed work with StrongED, and with the F12 command line. The module can be used as a standalone with StrongED, the rest of Zap is not required.

Yes, if you use StrongEd or Zap to open the Task Window. Surprise: it’s the up arrow too.

To be more explicit, make sure StrongED has been seen by the system so that it claims the Ctrl-F12 and make sure the LineEditor¹ module is loaded to give you editing on the repeated command. The barebones edit is very barebones.

¹ It’s in the Zap archives

Thanks for you responses.

Where are the Zap Archives? Do I type the RMLoad, or do I need to put it in an obey file? Where should I put the obey file?

Sorry for all the questions but I’m still new to Risc OS.

Thanks again.

At this point is it important that I’m running on a Raspberry PI B+? Just mentioning it in case it is.

Just be aware that there is a bug in the latest 32bit version of the LineEditor Module (2.76d) which causes the VDU command that turns the cursor off to not work, as a consequence OFF in BASIC stops working. It doesn’t seem to affect OS_RemoveCursors though.

It also causes register corruption with OS_ReadLine.

I’m not sure if the one bundled with Zap suffers these issues.

Where are the Zap Archives?

http://zap.tartarus.org/

Do I type the RMLoad, or do I need to put it in an obey file? Where should I put the obey file?

Various ways of doing the job, but simply dropping the module into !Boot.Choices.Boot.Predesk will cause it to be loaded during the predesktop portion of the boot sequence.

Just be aware that there is a bug in the latest 32bit version of the LineEditor Module (2.76d) which causes the VDU command that turns the cursor off to not work, as a consequence OFF in BASIC stops working. It doesn’t seem to affect OS_RemoveCursors though.

It also causes register corruption with OS_ReadLine.

I’m not sure if the one bundled with Zap suffers these issues.

I don’t know about your issues but I remember at the time’s ROL released RISC OS 6 that the LineEditor module from the Zap 1.47 distro made a complete mess of the RO 6 desktop and one had to revert to an older version of the module.

The last thing I want is to install buggy code. The up-arrow would be nice, but it’s just not worth the risk. If anyone knows of a bug-free version let me know.

Thanks for your time and responses.

???

I’m using the one supplied with Zap (Tank’s version) on my Pi – can’t say I’ve noticed any particular problems. Granted, I’ve never tried to turn the cursors off, but I don’t think you can in a TaskWindow…
Given that testing and debugging can mean repeating the same commands over and over, especially complicated ones like taking DADebug output and writing it to a file, it has proven itself invaluable.

???

I’m using the one supplied with Zap (Tank’s version) on my Pi – can’t say I’ve noticed any particular problems

I think the problem is that, slightly confusingly, André mentioned that there were problems when used with RISC OS 6 and corruption of the desktop.
Since the filer and desktop were among the items most altered by ROL the fact that something designed to work with a different version had problems shouldn’t really surprise anyone.
Those of us with LineEditor loaded on a currently supported version can state that it works just fine without errors.

Mark should note that it may well have been bugs in the OS rather than LineEditor.

Granted, I’ve never tried to turn the cursors off, but I don’t think you can in a TaskWindow…

Maybe in RO6? Maybe that is/was buggy?

Jon Abbot mentions bugs without referencing RO6. He mentions register corruption with OS_ReadLine.

Is Tank’s version the one at zap.tartarus.org? I assume I want the stable one not the beta version.

Do I just need to copy LineEditor from !Zap.Code.Extensions.LineEditor into !Boot.Choices.Boot.Predesk?

Thanks for everyone trying to help me. I really appreciate it.

Jon Abbot mentions bugs without referencing RO6. He mentions register corruption with OS_ReadLine.

It’s across all OS versions, essentially it corrupts R4 whenever the ReadLineV vector is called and may be why it fails on RO6. It’s easily fixed though, download the source code, find the ReadLineV section and add R4 to the STM/LDM surrounding it.

Fixing OFF however isn’t so straightforward as this behaviour is down to the OS providing no means to determine the current cursor state, so the code ends up resetting the cursor on exit. I believe this is also why OS_SpriteOp 3 (*ScreenLoad) doesn’t preserve the cursor state when it forces a mode change for no reason – this was a “feature” introduced with RO3.5 and continues to this day.

It’s easily fixed though, download the source code, find the ReadLineV section and add R4 to the STM/LDM surrounding it.

I could make that kind of source change, but rebuilding the module is beyond me at this point. Thanks for the information.

It’s easily fixed though, download the source code, find the ReadLineV section and add R4 to the STM/LDM surrounding it.

I think it may be even easier than than that and also avoid the necessity of finding the source code.

StrongED in Dump Mode can edit assembler instructions. I have done that here and added R4. As I have so far not worked out how to replicate the bug Jon referred to the change has not at this point been tested but the module still works and the Pi hasn’t exploded.

Double click on the Module to load it into StrongED’s Dump Mode then select click on the ‘i’ leftmost icon in the top toolbar for the instructions.

Zap can do something similar, see “Editing in binary modes” in the Help.

Edit Have now found the original report which includes a test.

Have now found the original report which includes a test.

That original report contains the specific words:

EDIT: This turned out to an issue with the LineEditor module, which corrupts R4 on 26bit non-SA OS’s.

RO5 is most definitely not 26 bit. End of problem or is it hiding better?

Fascinating. I followed the link in the original report for LineEditor and downloaded it. I’ve opened it in StrongED in dump mode. What I can’t find is any labels to tell me where ReadLineV is. How do I find the lines that need editing?

EDIT: I missed the post before this as I was posting. Does this mean that version of LineEditor is no good for RO5?

Does this mean that version of LineEditor is no good for RO5?

No, it means it has problems in certain circumstances on 26 bit OS versions.
Jon found a specific error circumstance which we don’t have as RO5 is not 26 bit

It doesn’t guarantee things, just eliminates that specific error circumstance and we don’t know of any others.

What I can’t find is any labels to tell me where ReadLineV is.

ReadLineV is a vector called by number, &0E in this case, with OS_Claim. See Vectors and OS_Claim

Does this mean that version of LineEditor is no good for RO5?

Not at all, there is a potential issue, as far as I could see with the OS_ReadLine test LineEditor 2.76d did not corrupt R4, but that does mean it never will.

It’s across all OS versions, essentially it corrupts R4 whenever the ReadLineV vector is called and may be why it fails on RO6.

R4 may appear not to be corrupted on OS5 but it isn’t preserved over the call either, so better safe etc.

Hope this helps, otherwise just ask away.

For completeness this is Jon’s test as used here :-

PRINT  "Now type something followed by RETURN"
DIM Z% 256
SYS "OS_ReadLine", Z%, 128, 32, 128, &1234 TO ,,,,E%
PRINT  ~E%
END

With an unmodified 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

*R4test
Now type something followed by RETURN
something
      1234
*

To add to any pre-existing confusion :-

I believe the PRMs state that any registers not listed in the “On exit” section will be preserved, unless explicitly stated otherwise (PRM1-29).

R4 is not in the Exit list for OS_Claim so should be preserved, and R4 is listed as preserved over OS_ReadLine.

One question:
Why edit the compiled code?
Isn’t it somewhat easier to go here and download the source (in BASIC) then edit line 4352 of lesrc276

plus the matching edit of line 4391 to pull back the same number of registers

Or am I missing something?

Though I regard my answer to modify the stacking around the OS_Claim call to be a truly elegant solution to a problem that might not actually exist on OS5, there is just one small caveat, it didn’t work on OS4.39, R4 was still corrupted. It is the merest trifle but R4 actually, or possibly not on OS5, needs to be preserved around the code inserted at the vector, the address of which is given in the OS_Claim code, &3800, and it corresponding exit at &3888. All good on OS4.39 now!

As I understand it the actual bug is in OS4.39, the ‘fix’ to LineEditor is a work around.

All done in StrongED and done in seconds too, no searching for the source, no downloading the source and no recompiling. This method is obviously only good for simple over-writes, if it were required to add anything then that would alter the addressing and necessitating compiling from source.

I put the LineEditor module into !Boot.Choices.Boot.Predesk, rebooted, and now the up arrow works in the StrongED CLI.

I have no idea if R4 is being corrupted. I’m not sure I understand the basic test code given. Shouldn’t E% be set before the call to OS_ReadLine? I’ll try writing some assembler to test it when I get around to it.

Thanks everyone for the depth and breadth of your replies.