Subject: Re: spelling images and fields
From: Paul Rohr (paul@abisource.com)
Date: Sat Mar 24 2001 - 17:18:19 CST
At 05:09 PM 3/24/01 +0100, jskov@zoftcorp.adsl.dk wrote:
>>>>>> "Tomas" == Tomas Frydrych <tomas@frydrych.uklinux.net> writes:
>
>>> Basically, as was pointed out later in the thread, the problem is
>>> that we need the current ABI_UCS_OBJECT to be treated both as a
>>> whitespace and as a word. Former is needed for images, latter for
>>> fields.
>
>Tomas> I fail to see the need to spellcheck fields, we are not going
>Tomas> to allow spelling errors into the output of our fields, or are
>Tomas> we?
>
>I didn't say that :) The problem is caused by the fact that Images
>and Fields are identified as "objects" in the backend.
>
>When spellchecking, that needs to be translated to a valid unicode of
>some sort. Presently both types get translated to ABI_UCS_OBJECT which
>makes the spelling code break, but the selection code work. If we
>change ABI_UCS_OBJECT to a space, spelling code will work and
>selection code will not.
>
>So my suggestion was to translate these to two different unicodes.
>See 'case pf_Frag::PFT_Object:' in pt_PieceTable::getBlockBuf. That
>needs to check the sub-types of the PFT_Object and translate
>accordingly.
I'm probably missing something here, but wouldn't the only way to
spell-check field contents (if such a thing is desirable) be to *not* treat
them as a single meta-character at all? Wouldn't you want to expand out the
current contents instead, or is that a situation-specific fix?
Ditto for selections and cursor-level navigation. I'd think a field was as
wide as its referenced contents, not a single metacharacter.
But hey, I'm the guy who considered fields to always be containers, but
never had the time to implement the complexities that'd create. ;-(
Paul
This archive was generated by hypermail 2b25 : Sat Mar 24 2001 - 17:10:58 CST