Re: [StrongED] Display of Tabs and Ctrls

[Martin Bazley <martin.bazley@xxxxxxxxxxxxxxxx>]

The following bytes were arranged on 12 Sep 2012 by Fred Graute :

> In message <e9778acc52.martin@xxxxxxxxxxxxxxxx>
>           Martin Bazley <martin.bazley@xxxxxxxxxxxxxxxx> wrote:

[snip]

> If CtrlTab stops being a style then the only way to retain more than two
> representations is to extend the number of options in Mode Choices. That
> does however mean changing the key/value pairs stored in the Options,
> making upgrading more difficult.

In my Choices file, I have a line saying "Tabs_DisplayAs:Dotted".  It
can't be that difficult to extend that field to allow, say,
"Tabs_DisplayAs:Hyphens".  (The Tabs panel of the Mode Choices window
would probably need a rethink though.)

As for Ctrl, exactly the same as present - either the non-ASCII
representation (using CtrlTab) is on, or it's off.  And if it's an
outline or system font, it's forced off.

> > This would also remove the conflict in the four glyphs used to draw
> > dotted lines needing to be remapped to the two glyphs used to draw
> > '--->', and hence the requirement for a mapping file.
>
> You'd still need to map Tabs and Ctrls. Tab is only one char so needs
> mapping to be able to use 4 glyphs, Ctrls need mapping cause outline
> fonts can't display chars 0-31,127.

I think in the case of outline fonts it would be simplest to force the
Ctrl option to [hex] and the Tab option to '--->'.  (See below.)

> The mapping you propose for bitmap fonts differs from that for outline
> fonts meaning syntax colouring needs to know which font type is in use.
> Something I'd just managed to get rid off with the new, more universal
> mapping.

Ah, but that's the clever bit - it *doesn't*.  Everything I propose can
be implemented by a few improvements to the user interface to the
Choices file without the redraw engine being any the wiser.

It works like this: if the user has the 'dotted line' Tab representation
chosen, and changes the font from bitmap to outline, then when they
click 'OK' StrongED validates the choices and forces the tab style to
change to '--->'.  The same goes for Ctrls.  There's no need to change
either on the fly while redrawing - you can just change the option
itself to make sure it doesn't conflict.

This does open up a security hole where one could theoretically edit the
Choices file by hand to create an illegal combination, but performing
the same validation when loading that file should solve that problem.

Of course, it would be more user-friendly for the Tab style to change
back to dotted lines if the user subsequently changes the font style
back to bitmap (which is what would happen if the syntax colouring knew
which font type was in use), but I think you could get around that by
adding a new boolean key/value along the lines of "Tabs_WasDotted",
which is set to True if StrongED's been automatically fiddling with the
choices.

Hopefully all of these changes can be accommodated strictly within the
boundaries of the mode choices, making sure that valid parameters are
passed to the redraw engine in the first place, rather than expecting
the redraw engine to validate them itself.

-- 
  __<^>__   "Start off every day with a smile and get it over with."
 / _   _ \  - W.C. Fields
( ( |_| ) )
 \_>   <_/  ======================= Martin Bazley ==========================

-- 
To unsubscribe send a mail to StrongED+unsubscribe@xxxxxxxxxxxxxx