Adopt Zap

Zap is not good at taskwindows

Not specially TaskWindows. I think what you describe is related to the Ctrl-End method of making a text copy of the current editor view… it tends to muck up long lines if BASIC.

I noticed Edit taskwindow

So something that spews a lot of output (such as *Help .) and you’ll see a vast gulf of difference between (Src)Edit and Zap.

But doesn’t crash or corrupt the text.

It doesn’t crash but it absolutely can risk corruption if the redraw screws up and where you think you’re editing isn’t what is actually being edited.
That’s actually the primary reason I ditched Edit back circa RISC OS 3.

platforms need editor wars.

There’s always the ages old Ovation vs Impression war to rekindle…

It turns out it is the lineeditor module (2.76 or 2.77) that makes the paste key fail.
This can be seen in an Edit taskwindow by entering a few commands and then going up the window select some spaced text, and use ctrl c, v.
It is the Ctrl v part (using the keyboard) that fails.

The lineeditor also doesn’t seem to add to its history lines where I shift-dragged a file (to get the file’s path).

The lineeditor also doesn’t seem to add to its history lines where I shift-dragged a file (to get the file’s path).

In Edit taskwindow that dragged text doesn’t go to the task regardless of lineeditor presence. It wont get read by task or execute until a copy paste is done. I think that issue is more of an Edit taskwindow one. (unless you are experiencing this in other Editors?)

Time to fess up – I end up editing mostly using Visual Studio, just tweaking code on the RISC OS systems. Never got on well with either Zap or StrongEd, so am a 100% SrcEdit (from DDE) person.

Well, time for my confession too then! I use Xcode on my Mac (which itself has a data loss bug, but at least I know how to avoid it since Apple is in no hurry to fix it), and then copy across and use SrcEdit in a pinch. I tried Zap back in the day and it crashed too often for my liking, and initially I was getting errors from StrongEd, which I did resolve, but to be honest I don’t do enough on the RISC OS machine itself to bother with it.

Most – have a favorite Editor.

Back along I was using Zap for large ASM files – like disassembled ‘C’ !RunImage – which were quite large :-)

Most – have a favorite Editor.

Zap. Happily still working on my Pi, RISCOS updated when I got my Pi4, but not since & I won’t for as long as I can get away with it – it’s working.

That’s on RISCOS. On the Mac, I use Atom. Nice that it can render UTF8 nicely, good for editing PERL or HTML, but useless for anything but ASCII or UTF8.

Reasons I like Zap, and tolerate it’s random “quirks”…

• Ease of switching between ASCII, byte, and word mode.

• Competent and fast redraws, very useful if you have something that spews a lot of output to TaskWindow.

• Ability to modify assembler directly in the executable by simply entering the instruction (no need to work it out as hex).

• Assembler annotations. Not perfect (seems unable to handle ADRL), but it’s useful to know that R# is a pointer to this string, and this branch is to CLib’s strncpy, etc.
  Also annotates AIF and module headers.
  Also ability to control (within the capabilities of the disassembler) the style of output, such as ARM vs APCS naming (ExtDisAsm had many more features, but it’s not a part of the 32 bit world).

• Flexible text resizing (even if it’s a bit of a pain to set up). Very useful on my little 7" LCD where I think it’s one of the 24px fonts in use.

• Capable syntax colouring with context.

• Ability to drop a pile of files onto the icon (like the Wimp sources) and then search in all files at once, with the results being listed in a throwback window (double click to go to that line, triple click bring the file to the top and then go to that line).

• Isn’t fazed by any file. If it’s loadable, Zap will show it at least in ASCII mode with control characters in red.
  Slightly marred by its desire to convert CRLF to plain LF when loading a DOS file, which can trick you if you’re not paying attention as byte mode will not show any CRs as they were quietly removed.

• When I’m programming, a single Ctrl-Shift-C will save the current file and invoke Amu to build the project.
  Also works in other modes, doing that with an HTML file will save it and get it opened in the browser.

• Directly handles tokenised BASIC, no need to detokenise/retokenise. This means it can handle some code that everything else fails with, especially the output of BASIC compression utilities that squeeze so much onto a single line…

• Other stuff I’ve forgotten. ;)

To be fair, asides from the contextless colouring (due to implementation differences), and the BASIC tokenisation issue, StrongEd can do most or all of the above (cue Fred…).

I’m just used to the way Zap works, just like I’m used to the way OvationPro works.
I’ll leave others to argue whether Impression or OvationPro is “best”, I think they’re both quite competent and capable.

Just like Zap vs StrongEd. The primary reason that I’d say StrongEd is better than Zap is because somebody is still maintaining it. Which is kind of important, actually…

I’m just used to the way Zap works

Yup. Me too.

I used to be used to the way Impression worked, but I don’t need its capabilities any longer, and I do need compatibility with other platforms. I’ve got used to LibreOffice, but even there compatibility with Migrainesoft Wrod is imperfect, sadly – and not everyone wants PDFs.

StrongEd is better than Zap is because somebody is still maintaining it. Which is kind of important, actually…

In a general sense, yes. From the point of view of a user like me, less so: Zap works on the set-up I’ve got, for the kind of work I use it for. I’m unlikely to upgrade/update this set up – if I can’t keep it going pretty much as is, I’ll probably regretfully retire it and switch to using just Mac. I might conceivably switch to StrongEd if I’m able to keep RISCOS running post Pi4 somehow if Zap ceases to work at that point, but I doubt if that’ll happen.

compatibility with Migrainesoft Wrod is imperfect,

Version to version, it’s been known to be incompatible with itself, so any compatibility with software from elsewhere is a testament to the efforts elsewhere.

Version to version, it’s been known to be incompatible with itself,

Indeed, particularly in the area where I’ve run into problems with stuff saved as .doc or .docx from LibreOffice – page breaks moving, as soon as you have any headers, footers, or footnotes.

Beware users with different printer drivers loaded too.

(cue Fred…).

Did someone call my name? ;-)

Okay, lets have a quick run-down and see which features are in StrongED as well.

Ease of switching between ASCII, byte, and word mode.

Yes. Either using the keyboard or the toolbar.

Competent and fast redraws, very useful if you have something that spews a lot of output to TaskWindow.

Yes.

Ability to modify assembler directly in the executable by simply entering the instruction (no need to work it out as hex).

Yes.

Assembler annotations. Not perfect (seems unable to handle ADRL), but it’s useful to know that R# is a pointer to this string, and this branch is to CLib’s strncpy, etc. Also annotates AIF and module headers.

Yes, but annotations are better as StrongED will also annotate applications/modules grabbed from memory which Zap doesn’t do. ADRL is handled, Utility headers are annotated too as are fast service call tables.

Flexible text resizing

Yes.

Capable syntax colouring with context.

No, syntax colouring is there but doesn’t take context into account.

Ability to drop a pile of files onto the icon (like the Wimp sources) and then search in all files at once,

Yes, including dragging in directories with ability to filter on filetype and/or filename. Searching through all open files but also provides directory search.

Isn’t fazed by any file. If it’s loadable, Zap will show it at least in ASCII mode with control characters in red. Slightly marred by its desire to convert CRLF

Yes, except line endings are left as they are.

When I’m programming, a single Ctrl-Shift-C will save the current file and invoke Amu to build the project.

Yes, doesn’t use cs-C for this but that’s very easy to change.

Directly handles tokenised BASIC, no need to detokenise/retokenise.

No, converts from and to text so has problems with BASIC files that have been crunched. Beyond that it handles BASIC just fine.

Just like Zap vs StrongEd. The primary reason that I’d say StrongEd is better than Zap is because somebody is still maintaining it.

Yep, 22 years on the job and still going (strong?).

Which is kind of important, actually…

You mean like this?

Its been driving me nuts that tripple click to select a line is broken in Ricks Zap updates.

It’s an easy fix though. :-))

BTW SrcRick07 fails to build because the ‘h’ directory has been renamed to ‘hdr’.

Did someone call my name? ;-)

Pretty much the response I expected. ;)

Yes, doesn’t use cs-C for this but that’s very easy to change.

Yes, I believe you already said how.

It’s an easy fix though. :-))

Do tell, you’ll make Alan’s day.

BTW SrcRick07 fails to build because the ‘h’ directory has been renamed to ‘hdr’.

Eh? I wasn’t aware I’d changed anything, unless I copied stuff wrongly?

Do tell, you’ll make Alan’s day.

In the mode0 source file find the section:

mode0_linenext
       FNJSR   "R1-R2"
       LDR     R14,[R9,#f_ptr]          ; >>tim, protect against deleted file
       MOVEQ   R0,#0
       CMP     R14,#-1
       FNRTS   EQ

Swap the MOVEQ and CMP lines, then save and rebuild. Job done. :-)

Eh? I wasn’t aware I’d changed anything, unless I copied stuff wrongly?

Don’t know as I can’t find the original zip. Perhaps I renamed it myself in order to run some kind of test. Anyway, problem is solved now.

ETA: I’ve downloaded the source zip again and the directory is called ‘h’ and not ‘hdr’.

Some time ago I tested a new version of a tool for StrongED’s ObjAsm mode. The tool attempts to load a header file when the user double-clicks on an include line.

Tested on a number of sources that use ObjAsm, also checking if ‘hdr’ is handled the same as ‘h’. It looks like Zap was one of those sources and that I forgot to rename ‘hdr’ back to ‘h’. Apologies for the confusion.

Getting back to the LineEditor spoiling Ctrl V pasting in an Edit Taskwindow.
I found today that Ctrl Shift v will do the job (that Ctrl v should)
Edit: While this is difficult to see why, It could have a benefit when running unixlib interactive programs that use Ctrl c to quit as you can use Ctrl Shift c to do the copy as well.

Getting back to the LineEditor spoiling Ctrl V pasting…

I’ve actually started to get used to Ctrl/D (duplicate) instead of Ctrl/C (copy) for objects in Draw!

I’ve actually started to get used to Ctrl/D (duplicate) instead of Ctrl/C (copy) for objects in Draw!

Yup, me too.

It turns out it is the lineeditor module (2.76 or 2.77) that makes the paste key fail.

It seems LineEditor handles every space in the input stream as if it was entered at the keyboard without checking if Space is actually pressed. I think I have found a fix for this but there’s some guesswork involved so treat with care.

At around line 960 there’s this code in the LineEditor source:

MOV     R0,#122
SWI     XOS_Byte          ; /X R1 = intl. key # or &FF
MOVS    R0,R4             ; Extended key code ?
BEQ     extended
CMP     R0,#32
BGT     gt32
TEQEQ   R1,#98            ; <-- add this line
TSTEQ   R3,#%0100
MOVEQ   R0,#0             ; cSpace -> &000
BEQ     doshift           ; scSpace -> &100

Add the indicated line which checks if Space is pressed. Rebuild LineEditor, RMKill current LineEditor (with no TaskWindows open) then run the updated copy.

This seems to make c-V work correctly in Edit, have not tested if this causes problems elsewhere.

Nice one Fred, I should start testing it straight away before time slips away.
Could you email me the test version please, (same Ronald as on StrongEd forum recently) and I should get it.

Edit: Cancel that, I found the github source this morning.
The change certainly looks good in Edit. Early days yet, but the stability of the left right editting seems to be good, maybe improved.
Obviously we lose sight of the text to the right but inserting/deleting etc seems reliable so far.

Obviously we lose sight of the text to the right but inserting/deleting etc seems reliable so far.

I noticed that this improvement in Edit taskwindow editting only happened after Zap had been running.
I narrowed it down to the FlashCar module, but also needs LineEditor RMLoaded.
To release the obey file that calls it, I am doing
Do Wimptask RMRun <Mods$Dir>.FlashCar
Combined with LineEditor this ensures that the left arrow key editting is improved.
There may be an issue with running FlashCar without LineEditor in StrongED taskwindow.

Edit: Well the above ‘method’ didn’t last long. wild goose (or zombie) chase.
It turns out that as long as !Zap has been seen (filer booted) that is enough for
the Edit taskwindow to get its improved editting.
I got in the habit of hiding !Zap so that it would not claim stuff.