StrongED 4.69f7 released

Just one suggestion… Since StrongEd is used by default as a taskwindow replacement, would it be a good idea to include the taskwindow mode by default? Without it, some backspaces suppress characters on screen, but not on the command line. Difficult to use :)

I mistakenly believed saving the Mode file was refreshing the colours as well, which will explain why I was seeing no effect.

Sorry, my bad, didn’t explain that too well. In 4.69f7, if you save a ModeFile then all of the mode data including the colours are re-read/re-parsed. If you save a Colours file on its own then it is not re-read.

(StrongED 4.70a8 does not reload the colours when a ModeFile is saved to prevent losing changes to the mode settings which haven’t been saved.)

I’m used to BasASM and use it across both BASIC assembly and ExtASM files – my code base uses both.

Fair enough, I was just checking in case you weren’t aware of extASM mode. When you’re happy with your changes to BasAsm mode I’d appreciate a copy. I always find it interesting to see how people set up modes.

Oh, one last thing. Is it possible to change the way the Undo/Redo button works so you can hold it down instead of repeatedly clicking.

No, there’s no way to make Toolbar buttons auto-repeat. You could use F8 though, but sometimes this fails if there are many undo’s in quick succession.

Since StrongEd is used by default as a taskwindow replacement, would it be a good idea to include the taskwindow mode by default?

Good point! Without the TaskWindow mode keypresses won’t be passed on to the TaskWindow which diminishes its usefulness. Perhaps modes should be downloaded on first use?

Perhaps modes should be downloaded on first use?

Or simply included. It’s not a big file :)

A few suggestions now I’m getting used to having 50+ windows open. Could the LoW have directory separators and show unhidden windows in a different colour? And what’s the grey bar down the right side for? It doesn’t seem to serve any purpose, could it be removed so more of the filename is visible when the window is narrow?

I keep it pinned on the screen edge so I can quickly switch between windows, but am finding it quicker to browse to the file and reopen, instead of hunt through the list for windows I have open in the background.

Perhaps modes should be downloaded on first use?

Or simply included. It’s not a big file :)

That’s what I will do. I was just musing if downloading modes on demand might be a better option. Initially StrongED came with all modes included but some users didn’t like that as they only used a couple of modes.

To address this modes were made available separately from the application, to be downloaded when the user wanted it. But that doesn’t please everyone either, some don’t like the additional work others simply forget.

An on demand system would prompt you when you want to use a mode that hasn’t been downloaded yet and as the mode is installed automatically it would require less work.

A few suggestions now I’m getting used to having 50+ windows open. Could the LoW have directory separators and show unhidden windows in a different colour?

A different colour for open files is no problem – just finished adding it.

Directory separators are more of an issue as the LoW redraw code is used for both the permanent and the transient LoW. The transient LoW is opened in MRU order where directory separators are no use.

And what’s the grey bar down the right side for? It doesn’t seem to serve any purpose, could it be removed so more of the filename is visible when the window is narrow?

It’s used to show if a text has been altered or not and how many views are open on a text. I use the altered status quite regularly to make sure I’ve saved all altered files before rebuilding the code so I would prefer to keep it.

An on demand system would prompt you when you want to use a mode that hasn’t been downloaded yet and as the mode is installed automatically it would require less work.

Could you not include them all and provide an option page to toggle them on/off so they’re not visible in the create menu etc?

A different colour for open files is no problem – just finished adding it.

Just this one addition will make a massive difference, as I can quickly scroll the LoW and immediately spot the one I want; thanks for adding it so quickly.

That’s what I will do. I was just musing if downloading modes on demand might be a better option. Initially StrongED came with all modes included but some users didn’t like that as they only used a couple of modes.

IMHO, the problem is not to have them (disc space is not a big deal today), but to see them. A configuration option to active or not modes one by one would be great/

Could you not include them all and provide an option page to toggle them on/off so they’re not visible in the create menu etc?

Oups :)

Could you not include them all and provide an option page to toggle them on/off so they’re not visible in the create menu etc?

There already is a mechanism to ‘hide’ modes by way of the ‘Extra modes’ submenu. Modes that aren’t used regularly can be moved to this submenu so they are not visible initially but can still be reached if required.

A mode can be moved to/from the Extra modes submenu using Mode Choices > Misc or by editing the ModeLock file (useful for bulk changes, file is re-parsed on saving). The ModeLock file can be opened by Ctrl-Select click on the iconbar icon.

A configuration option to active or not modes one by one would be great

Modes are not active, in the sense of being parsed, until they are needed – with the exception of BaseMode which must be parsed. However modes need to be enumerated so that the mode menus can be created. The ModeWhen files must also be parsed so we know which mode to use for which filetype.

In 4.69f7 and earlier a full mode record is created during enumeration, even though most of it is unused until the mode is parsed. StrongED 4.70a8 only creates a minimum mode header, just enough to hold the bits that must always be present (on start up this saves about 1.5 kB per mode installed).

thanks for adding it so quickly.

No problem, it was easy to add. In fact, getting it saved to the choices file was what took the most effort. :-)

There already is a mechanism to ‘hide’ modes by way of the ‘Extra modes’ submenu.

Doesn’t sound like you need to make any changes then, if the functionality is already here.

No problem, it was easy to add. In fact, getting it saved to the choices file was what took the most effort. :-)

If you’d like some testing done, eMail me a copy (jon at jaspp dot org dot uk). I’m using it 12-20hrs a day at the minute whilst working on the next ADFFS release.

Unrelated, I was trying to get folding working last night but couldn’t figure out how to get it to fold at each Label. I tried all kinds of variations for Fold_End, from looking for a “.” (“\x2E” “<{ }*.” etc) and “Label” to (“LDR*PC,” | “MOV*PC,” | “LDM*PC,”) but couldn’t get them to work consistently. In the end I resorted to “\l\l\l\l” but it’s not ideal.

“Label | EndOfFile” is what’s really required for Fold_End – but how do I specify that?

There already is a mechanism to ‘hide’ modes by way of the ‘Extra modes’ submenu.

So it’s perfect :)

If you’d like some testing done, eMail me a copy

Thanks for the offer, Jon. I’ll send you a copy soon, just need to rollback the LoW redraw code which uses the desktop font now but isn’t finished yet.

Unrelated, I was trying to get folding working last night but couldn’t figure out how to get it to fold at each Label.

Folding assembler is a bit tricky as there are no clear points on which to fold such as, say, DEF PROC / ENDPROC in BASIC.

I tried all kinds of variations for Fold_End, from looking for a “.” (“\x2E” “<{ }*.” etc) and “Label” to (“LDR*PC,” | “MOV*PC,” | “LDM*PC,”) but couldn’t get them to work consistently.

You don’t have to define Fold_End, the main thing is that Fold_Start works correctly. When Fold_End is absent a fold continues until the start of the next fold.

In the end I resorted to “\l\l\l\l” but it’s not ideal.

Using fold markers is the right idea though when the language doesn’t offer something obvious to fold on. In the StrongED sources labels at the start of subroutines look like this: ;:.Label

This has two advantages; it’s easy to list all subroutines without listing all the local labels too and it can be used for folding:

FoldParm1(";:.",,StartOfLine)

The only downside is that the comment block at the start of a subroutine is inside the preceding fold. To counter that another fold marker would have to be set at the end of each subroutine. For example a special label .EndOfSub which Fold_End can match.

You don’t have to define Fold_End, the main thing is that Fold_Start works correctly

Switching to Fold_Parm1(Label) has done the trick, working perfectly now folding wise. I have however noticed a few minor issues that you might want to look at:

1. The final Label doesn’t always end at the end of the file and sometimes leaves the last line out
2. If you Fold the whole code, then scroll it slightly, expand the final Fold and shrink it again you end up with a blank screen and have to unfold the whole file to get it back
3. With folds on, there’s screen corruption when scrolling
4. Turning folds on doesn’t increase the screen width by the 2 chars it needs if you have “Longest line in file” set as the default Wrapping option. You have to manually do a “Longest Line” for the wrapping to be correct.
5. The folds are continually being redrawn as you type

If you fire me an eMail, I’ll reply with the source code and Mode should you wish to take a look.

The final Label doesn’t always end at the end of the file and sometimes leaves the last line out

That anything like the objasm complaining about “no END” if there isn’t a newline after the END?
i.e. sticking an extra newline in fixes the issue?

3. With folds on, there’s screen corruption when scrolling

Folding is a trick performed at redraw, the lines inside a closed fold are skipped. If for some reason the list of folds is incorrect then it will result in redraw errors.

This is most likely to happen when using two fold levels. You say you switched to Fold_Parm1, did you comment out Fold_Parm2? If it’s still live then that may be the cause of issues 1,2 and 3.

4. Turning folds on doesn’t increase the screen width by the 2 chars it needs if you have “Longest line in file” set as the default Wrapping option. You have to manually do a “Longest Line” for the wrapping to be correct.

StrongED was basically designed with 8 pixel wide characters in mind. The wrapwidth was translated to a window width and the window was kept at that width (unless the user changed it).

Adding folds or wrapline marks took space away from the wrapwidth, in later versions line numbers did the same. Increasing the size of an outline font also reduced the wrapwidth.

This has been changed in 4.70, the wrapwidth is now always kept at the number of characters specified. The window’s workarea in now increased to make room for folds, wrapline mark and line numbers.

5. The folds are continually being redrawn as you type

Yes, I see that too but I’m not sure why that is. There is code to work out which area of the window needs updating and a ForceRedraw is generated for that area so why all fold markers are being redrawn I don’t know yet.

If you fire me an eMail, I’ll reply with the source code and Mode should you wish to take a look.

Will do, just need to write some notes on 4.70a8 before I send you a copy.

Question. Is there a way to stop HTML mode changing “é” to “eacute”, etc. I don’t want to remove the feature, but just to shut it off, sometimes…

Is there a way to stop HTML mode changing “é” to “eacute”

It’s defined as a shortcut which means the only way to stop it is to remove this particular shortcut. However you can use F8 to undo the expansion and get “é” back.

Arg. I’ll need to duplicate the mode… just for NetSurf :)
Thanks for the information.

I’ve done a bit more digging and there is an option to turn shortcut expansion off but it’s a global option so it will be turned off for all modes.

The option is:
Global Choices → Edit → Check entered text for shortcuts to expand.

haaaa cool.
StrongEd can do everything :)
(but I’ll try to duplicate HTML mode too, or to comment unneeded things in current one)

The option to turn on/off shortcut expansion has been moved to the Edit section of the Mode Choices. This gives finer control as it can now be set on a per mode basis.

It also makes it possible to enable/disable it as required using a toolbar icon or a key binding.

Fantastic!

I’ve encountered an odd bug with the current version of StrongED when running under an emulator—either Red Squirrel or RPCEmu—on a PC laptop. When a keyboard key—specifically the right ALT key—is mapped to the Acorn middle mouse button, StrongED does not respond to it’s being pressed—but every other application does respond.

When the right mouse button is being mapped to the menu button, however, StrongED does respond.

When there’s a click on the iconbar icon StrongED tests if Ctrl or Shift is down. For some reason when the right Alt key is down the test for Ctrl returns a positive result. As no action is tied to Ctrl-Menu click nothing happens.

This seems to be a RPCEmu issue as right Alt on native RISC OS doesn’t register as Ctrl. The Menu key on the keyboard works as expected so I’d suggest using that if present.

It also happens on Red Squirrel using KeyMapper to map the right ALT key as the middle mouse button—but not if I map the right CTRL key instead—that works correctly and does invoke the menu (surely if your reasoning is correct that wouldn’t happen?)

The laptop doesn’t have a menu key.