Options Embedded in texts

When StrongED loads a file, it scans through the first kilobyte to see if it can find any embedded configuration options, and to determine the Mode to use. The options it currently recognises are:

StrongED$Mode      = modename
StrongED$FoldParm1 = (same parameters as the FoldText function)
StrongED$FoldParm2 = same
StrongED$Tabstops  = String defining Tabstops
StrongED$WrapWidth = Auto, sets wrapwidth to automatic
StrongED$WrapWidth = Line, sets wrapwidth to length of longest line
StrongED$WrapWidth = nnnn, sets wrapwidth to nnnn characters

See note on StrongED$WrapWidth below

Note that, although the syntax of the first four option's argument is the same as that for a ModeFile, these embedded options require an equals sign ( = ) rather than a Tab.

An embedded option should, and does, override all other options so that it's absolutely clear what you're going to get. The settings in the Mode choices have nothing to do with it.

An example here in a C source file:

/* This is an example C source, with embedded StrongED options
     StrongED$Mode = C
     StrongED$WrapWidth = 132
     StrongED$FoldParm1 = ( "/*\<", "/*\>", startspace )
*/

StrongED$WrapWidth

This note is derived from a posting by Fred Graute to the mailing list.

With proportional fonts the width of a character is not fixed, so the StrongED$WrapWidth option only works predictably with fixed width fonts.

For bitmaps and monospaced outline fonts, working out how many pixels (or OS-units) to use for the window width is easy: NNxWW (where NN is desired wrapwidth in characters and WW is width of a character).

For proportional outline fonts it's more complicated as characters here have different widths, so some guesses must be made. Currently StrongED uses the width of the widest character in the proportional font to calculate the window wrapwidth in pixels. This means that the window is quite wide, usually a lot more than the actual text.

If you use a small wrapwidth (say 20) then you'll see that adding "StrongED$Wrapwidth = 20" does work, so some experiment is required to obtain the desired result.

4.69f11 probably still uses the width of 8 pixel wide bitmap fonts. In 4.70, bitmap fonts can have widths other than 8 and so the way the wrapwidth is calculated had to be changed.