highlighting non-breaking-spaces for authors

[naglists]

Hiya,
Some of my authors would like to see the non-breaking-spaces in their
documents more easily.

I'm working through a couple of strategies to help with this.

One is to simply save/display them as character entities using the following
commands/settings:
set charentdisplay=off
set entityoutputconvert=off
set entityinputconvert=off

This is working more or less, but has the drawback that all character
entities are displayed not just the . Further, I'm getting the
following error after issuing the commands and inserting or manipulating the
s:
[A30158] The Java method handleEvent has thrown an exception.

I haven't chased this error yet ... I am hoping someone had seen it/resolved
it while using one or more of the above commands.

My second strategy is to do a find loop through the open content, select
words on either side of the and select them all and wrap them in a
_font PI and color them up and then remove the PIs on close or compose. I
think the authors will find the results of this strategy cleaner
display-wise, but it's a little messier to do and support from my
perspective.

Anyone done anything different? Am I missing an obvious one-click setting
somewhere? Thoughts on the advisability of either of the two listed above?

--
Paul Nagai

[ptc-1908075]

Paul,

If I understand the issue correctly, you could define a text entity such as the following:

'>


Note that you can change the text entity at any time to remove the _Font PI, if desired.

Then define a keymapping for authors to use to insert the text entity when a non-breaking space is desired. The default keymapping for Control+Shift+Space is InsertNbsp. You could re-map that.

A startup file would need to include td _Font -none to hide the _Font PI in the Edit window.

Hope this helps!

Good luck!
Suzanne Napoleon
www.FOSIexpert.com

[naglists]

Hi all,
Thanks, Suzanne for the alternative ideas.

I ended up writing the code to find and wrap all instances and their
neighboring words with a _font PI. I still have a few implementation details
to work out such as how and when the code fires. Currently I have it firing
on startup and "toggling" from a menu pick, meaning you can essentially
show/hide the highlighting. I have not attached it to any hooks or callbacks
... I sort of think that would be over-kill. I can see authors perhaps
wanting the ability to add new "wrapping" without toggling off/on in order
to see "new" s, though. We'll see. Oh, the screen FOSI shows the
surrounding words in darkviolet (for now ... subject to author review). The
print FOSI ignores the PI altogether.

I learned about the discrepancy between length() and goto_oid($oid, $pos)
which is that s count for one character when navigating via $pos but
6 characters in length() and match(). This caused much frothing and steaming
before the final aha moment realization. I learned that Editor gets upset
when you (accidentally) try to nest PIs (and presumably any element) 100
levels deep and that it's nice if you pre-emptively code escapes when
oid_level(oid_root(), oid_caret()) > 25 or something similar before any
insert.

Not sure what the authors will want to see when they have something like
this:
<para></para>

There's nothing for me to highlight in that situation, so for now I've set
td -local -full on that PI. It looks something like this:
<para><_font></para>

I thought the <_font> would color-up, but no luck. Hopefully it's
enough of a visual cue for the authors.

Oh yeah, one last thing, I mapped Control-Alt-a to find('', 0x0530).
It helped me check how well my code was doing. Ironically, it might have
been enough for the authors 😉

Cheers.

On Wed, Aug 6, 2008 at 3:06 PM, Suzanne Napoleon <
SuzanneNapoleon@fosiexpert.com> wrote:

> Paul,
> If I understand the issue correctly, you could define a text entity such as
> the following:
> '>
> Note that you can change the text entity at any time to remove the _Font
> PI, if desired.
> Then define a keymapping for authors to use to insert the text entity when
> a non-breaking space is desired. The default keymapping for Control+Shift+Space
> is InsertNbsp. You could re-map that.
>
> A startup file would need to include td _Font -none to hide the _Font PI
> in the Edit window.
>
> Hope this helps!
>
> Good luck!
> Suzanne Napoleon
> www.FOSIexpert.com
>

[ptc-1908075]

Paul,


Thanks for letting us know 🙂 It's nice to know how it all worked out. And the adepters archives are much more useful when they include the end of the story.

Thanks!
Suzanne
"WYWIWYG is last-century technology!"
www.FOSIexpert.com

[naglists]

On Thu, Nov 6, 2008 at 2:50 PM, Suzanne Napoleon <
SuzanneNapoleon@fosiexpert.com> wrote:

> Paul,
> Thanks for letting us know 🙂 It's nice to know how it all worked out.
> And the adepters archives are much more useful when they include the end of
> the story.
>

I like to pretend it's for the commons, but truthfully it's so I can
remember what I did if I ever have to do it again and can't find my code 😉


Not sure what the authors will want to see when they have something like
> this:
> <para></para>
> There's nothing for me to highlight in that situation, so for now I've set
> td -local -full on that PI. It looks something like this:
> <para><_font></para>
> I thought the <_font> would color-up, but no luck. Hopefully it's
> enough of a visual cue for the authors.
>

Here's an update on this front. I set BackColor (I forget the actual
attribute name, check yourself before using) to darkviolet and left it "td
-none" like the rest. This results in a fairly thick "vbar" that I hope will
be visible enough for the authors.

--
Paul Nagai

[KarlParsons]

hi,

i had a similar issue with thin spaces, so i do a search and replace from instance.acl to replace them with the   character entity

replace(chr(0x2009),' ',0x2070)

and put this in charent.cf to display them as an open box

chars:

thinsp  "Arial Unicode MS" 0x2423 unicode 0x2009 current "\hmode\kern.1666em|"

also arbortext is set to convert character entities back to unicode characters on save.

cheers

karl