Adopt Zap

What should go in an ‘Adopt Zap’ bounty?

Here’s some ideas to start off with.

The main goals are that users suffer less data loss, and that ROOL can include
core Zap and key modes in RISCOSpi, with sources available under appropriate
license(s).

Overview

• Permission from historic and recent authors to release under appropriate license(s).
• Merge more recent work into last official source, ready for new development.
• Fix most egregious corruption: wrong characters in title bar, wrong characters
  in window display, wrong colours in window display, “Not a heap block” errors.

Technical details

Debugging versions of the internal heap functions that can detect errors such as
overruns may be helpful.

A ‘ZapBash’ tool could be devised to check for corruption.

Deliverables

• Git repository incorporating post-2008 changes into the source.

Permission from historic and recent authors to release under appropriate license(s).

Don’t bother asking me, I’m more than happy to see my favourite editor (sorry Fred ;) ) continue. Use my little tweaks and patches in whatever way is useful.

What might be harder is tracking down everybody from the past.

Merge more recent work into last official source, ready for new development.

I think this is the most recent of mine. http://heyrick.eu/random/zapsrc20200620.zip

I’m a little vague on this…because I’m sitting out in the sunshine. ;)

Fix most egregious corruption: wrong characters in title bar, wrong characters
in window display, wrong colours in window display, “Not a heap block” errors.

I wouldn’t worry too much about wrong characters here and there. They may be side effects of other issues.

To me, the major things are:

• Not a heap block
• Zap seemingly randomly just failing badly (abort), can’t save files and can’t load new ones, you can only quit and restart.
• Possibly related – often trying to change file type in the Save dialogue causes an abort.
• Block selection problems, triple click.
• Futzing with entities/characters in HTML mode aborts.

• Zap really needs an optional autosave facility. ;)

Deliverables

Given that we aren’t using 8MHz processors any more, would there be any mileage in a collaborative project to write something that behaves in a manner similar to Zap, but written in a high level language, fully documented, etc?

For me, the things I like about Zap are:

• Decent colouring of BASIC, assembler, C, and disassembly.
• Ability to view the same file in various modes (I can see BASIC as a hex byte dump, for instance).
• Ability to choose from a range of good looking display styles, and set up custom colours.
• Useful and helpful additions to the disassembly, like annotating function entries, string pointers, CLib calls… (just a shame it doesn’t seem able to handle ADRL)
• Ability to pull modules, workspace, and applications out of memory for examination.
• Integrated into the DDE so pressing Sh^C will save the current file and begin compiling (if C) or load the file into NetSurf (if HTML), etc.
• No annoying toolbars. Some modes offer them, they’re optional.
• Other stuff ;) Sorry, I’m debating. Sit in the sun a little longer, or go put the kettle on? Decisions, decisions…

From long ago, Status of Zap

would there be any mileage in a collaborative project to write something that behaves in a manner similar to Zap

StrongED, since the correct configuration will make it behave pretty much any way you want.

At which point the question would be – how open to a committee development model is Fred?

Two households, both alike in dignity,
In fair RISC OS, where we lay our scene…

StrongED

Isn’t that written in assembler? The idea was to wean ourselves off the joy of LDMFD. ;)

since the correct configuration will make it behave pretty much any way you want.

I’d start with an HTML colourisation that actually works…

In case Fred is thinking “huh?”, go to HTML mode in both editors and type in $>%*&"! and note the colours. Zap is highlighting the ones that have significance in HTML.

Note also the behaviour as you enter the text € or whatever other entity you might choose, how it appears on both.

In StrongEd, it seems that there is a core colouriser with some extra “group” colour values bolted on. So numbers are numbers, punctuation is punctuation, and that’s it.
Meaning that ☺ is not treated as an entity, but as a number surrounded by punctuation (though the ‘#’ is considered as a number?). It looks… weird. Makes sense for coding but not for markup.

Even worse, the colourisation isn’t too bad when entering <img src="path" width=123 border=0 but note the subtle change in option colour in Zap as the things like “src” and “width” are recognised…

But add that final > and StrongEd changes everything to a solid colour. In my case, red. As I’m trying to set up a black background, I had to fiddle around setting the colours haphazardly until I discovered it was “Group 6” or something.

So… yeah. Applying code colourisation to HTML really doesn’t work; and that behaviour with the > is just weird. Why not keep the markup coloured?

There’s other stuff (like some love for the disassembly mode), but that’ll do for now.

Given that we aren’t using 8MHz processors any more, would there be any mileage in a collaborative project to write something that behaves in a manner similar to Zap, but written in a high level language, fully documented, etc?

Having some idea of what’s needed in creating a text editor, might it be better to first see if there something that could be ported to RISC OS with relative ease?

In StrongEd, it seems that there is a core colouriser with some extra “group” colour values bolted on.

That’s correct, if put a little harshly.

Even worse, the colourisation isn’t too bad when entering <img src=“path” width=123 border=0 but note the subtle change in option colour in Zap as the things like “src” and “width” are recognised…

Because of the core colouriser StrongED does not notice contexts specific to the language it’s colouring. You can add colourisation of HTML attributes but then they’ll always be coloured, not inside tags only.

But add that final > and StrongEd changes everything to a solid colour. In my case, red.

I did not create the HTML mode so don’t know why it was done this way. It can be changed by replacing the ‘EndOfTag’ to ‘EndAlways’ in the HTML ModeFile.

I had to fiddle around setting the colours haphazardly until I discovered it was “Group 6” or something.

Open the Global Choices (eg from the iconbar menu), go to the ‘Misc’ section and tick the ‘Colours section in mode choices follows cursor’ option. After that the ‘Colours’ section of the Mode Choices will automatically select the element that the cursor is in.

There’s other stuff (like some love for the disassembly mode),

What more love does Dump mode need? StrongED 4.70a14 is largely on par with what Zap’s Code mode offers.

Please start a bounty and I’ll contribute to it. Zap is available from !Store in any case but it would be nice to have Zap included as part of the ROOL distro.

might it be better to first see if there something that could be ported to RISC OS with relative ease?

Obviously part of the planning stage would be to see if there’s something that exists that could be used, though I fear that RISC OS might be a little…alien. ;)

if put a little harshly

Sorry. Tact and subtlety are…attributes other people have to allow them to avoid saying what they mean.

does not notice contexts specific to the language it’s colouring

Ah, that’s what I thought. It’s StrongEd doing the colouring, rather than the individual modes.
As such, it cannot match Zap because it lacks context. Or, as you say:

You can add colourisation of HTML attributes but then they’ll always be coloured, not inside tags only.

go to the ‘Misc’ section and tick the ‘Colours section in mode choices follows cursor’ option.

Alternatively, maybe permit the modes to alter the colour options text so it says what it is, rather than a number of anonymous groups?

What more love does Dump mode need?

I’ll look sometime soon, comparing with the latest StrongEd, and get back to you.

Alternatively, maybe permit the modes to alter the colour options text so it says what it is, rather than a number of anonymous groups?

I am sure Fred will be along in due course, but SE already offers two ways apart from the anonymous groups.

First, turn on Interactive Help and hover over a Group entry in the Colour menu and you will see the first few items in the SyntaxGroup definition.

Second, the writer of a mode can add to or create a Messages file with Group tokens. The corresponding messages will be used as the Colour menu entries.

SE is a very complex piece of software with many, many options that may not be fully exploited. Designing SyntaxGroup colouring may need a lot of work, but you can do it for all sorts of files, not just those the author(s) have thought of, which is how Zap works, doesn’t it?

might it be better to first see if there something that could be ported to RISC OS with relative ease?

The editor is such a crucial component, I doubt if there is anything that could be ported as is. It to be 100% RISC OS UI, and have lots of RISC OS specific features such as various file modes. That’s not to say that components such as 3rd party syntax highlighting libraries couldn’t be used, but there would be no relative ease.

Having some idea of what’s needed in creating a text editor, might it be better to first see if there something that could be ported to RISC OS with relative ease?

Start with Scintilla and see how far you get. https://www.scintilla.org/

It needs a very new C++ compiler (the dev branch uses C++17), so no, Norcroft won’t cut it…

The editor is such a crucial component, I doubt if there is anything that could be ported as is. It to be 100% RISC OS UI, and have lots of RISC OS specific features such as various file modes.

I’m not so pessimistic – the majority of the work for an editor is outside the UI. Apart from filemodes BASIC (which is nearly trivially supportable via available Tokenizers and Detokenizers) and ARM Disassembly, I see very little RISC OS specific stuff to do. A bit of specific encoding support possibly.

But still…adding a RISC OS backend to Scintilla is of course not exactly trivial. But it likely needs a lot less work than e.g. adding support for all the programming languages and encodings nowadays taken for granted on other platforms to StrongEd and/or Zap.

An Adopt Zap bounty would get my support; go for it.

;) The main goal is to enable the ROOL hosting of Zap, enabling them to distribute the core Zap and key modes in RISCOSpi, with sources available under appropriate
license(s).

Would there be any mileage in initially using the auto-builder environment for the source code, then on the release of a git client, GitLab or GitHub?

@Steve P

At which point the question would be – how open to a committee development model is Fred?

Contributions have always been welcome, especially (suggested) code changes. In my 20+ years as maintainer however there’s only been one person that has actually submitted code.

Zap appears to be in a similar position. Although there have been some valiant efforts to keep it running on modern CPUs, no one has taken on the role of maintainer.

One of the main advantage I see in have other people working on the code would be bouncing off ideas. Most of the easy stuff has been now and incorporating new features is getting more difficult. Looking at things from a different perspective often helps.

@Rick

Ah, that’s what I thought. It’s StrongEd doing the colouring, rather than the individual modes.

Modes in StrongED are essentially elaborate configuration files that control how the central core behaves.

As Steve D points out that makes creating new modes for StrongED easy but at the cost of less flexibility. If the core doesn’t support it then you’re out of luck.

As such, it cannot match Zap because it lacks context.

That’s right. I’m currently considering if (some basic) support for contexts could be added.

Alternatively, maybe permit the modes to alter the colour options text so it says what it is, rather than a number of anonymous groups?

Steve D already answered this so I’ll just add that the author of the HTML mode didn’t use the Messages file to provide names for groups. Possibly because the mode was created before I added support for group names. Easily fixed though.

What more love does Dump mode need?

I’ll look sometime soon, comparing with the latest StrongEd, and get back to you.

Any kind of feedback would certainly be welcome, and should help to improve Dump mode even further (the current version is already a bit further along than the one in 4.70a14).

At the risc of getting flamed down completely, personally I think it would be better to start a SrcEdit bounty. Block cursor and syntax colouring would be off to a good start to replace Zap/pi400 for me which crashes randomly and without notable patterns. Its been driving me nuts that tripple click to select a line is broken in Ricks Zap updates.

syntax colouring would be off to a good start

It’s briefly crossed my mind but I’m not sure whether there are enough SrcEdit users to justify it!

Plus I don’t know how to do it :)

I’m not sure whether there are enough SrcEdit users to justify it!

FTFY. ;)

Plus, being based on the Edit code, SarcEdit will mark control codes like [00][0D][09] etc.
Was the redraw bug ever fixed regarding viewing/editing large binary files?

SrcEdit is so far behind Zap/StrongEd that it might be a better proposition to create something new rather than work out how to paste new features into thirty five year old code…?

Running an editor usually means it will also provide the Taskwindow. Zap is not good at taskwindows, I cured one problem of it throwing an error window whem clicking on the window near the cursor in column 1. It took a bit to work out, but setting the left margin to 2 characters was good, but to save that it is a job and a half. You have to first save ‘this mode’, then a second time just below with defaults. Menus could be a lot better.
I still haven’t found a way to get the missing characters from the right margin.
I noticed Edit taskwindow has changed from a menu driven send selection to task(carat)
It now uses Ctrl c and v, but when using the keyboard, the pasting omits the white spaces.
By way of menu or virtual keyboard and paste works fine.
Has anyone got the upcoming 5.10 Clipboard improvements on a machine to see if this still happens?
It probably should be reported as a bug if there is no improvement.

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. But I wouldn’t put any more features into that, just fix the damn redraw!

Was the redraw bug ever fixed regarding viewing/editing large binary files?

Large binary files? SrcEdit has been screwing up initial redraw of modest text files for me for at least 2014. But doesn’t crash or corrupt the text.

It now uses Ctrl c and v, but when using the keyboard, the pasting omits the white spaces.

Curious – pasting a line using Ctrl-V containing multiple whitespace (leading, internal and trailing) from either (and to either) an Edit document or TaskWindow works fine here. Edit 1.75 / RO 5.29 (01-Feb-2022) [this is a pretty vanilla system, with no extraneous helpers loaded at boot like line editor module, deep keys etc.]

Port Notepad++ ? That’s my Win/Linux (WINE) editor of choice. Linux has a native version – notepadqq – that might be port-able.

TaskWindow works fine here. Edit 1.75 / RO 5.29

Good to hear, I have Edit 1.75 but both my Iyonix and RiscPCEmu are on RO 5.28 and earlier.
Sounds like after the upgrade to 5.30 everything will be fine on Iyonix anyway.
Edit: Mmmm I hope it’s not because youi dont use the LineEditor module.
Just to be clearer, I am talking about a taskwindow (only) copy and paste issue.

Port Notepad++?

Nah, that’s not the correct solution. After all, Notepad++ is based on Scintilla as its main editor core. And we all know that platforms need editor wars. So start with porting Scintilla, and implement AT LEAST two editors based on it.

;-)