Re: A Proposal (why we should have setBold(true))


Subject: Re: A Proposal (why we should have setBold(true))
From: sam th (sam@bur-jud-118-039.rh.uchicago.edu)
Date: Tue May 30 2000 - 02:45:51 CDT


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 27 May 2000, Eric W. Sink wrote:

>
> I agree that there is much bogosity in passing around properties in
> the form of strings and lists of same.
>
> In fact, I got fed up with this once and tried to fix the situation.
> I did not complete the task, but I did learn just how widespread and
> pervasive this particular implementation tactic is. Lots and lots
> of code will have to be fixed in order to remedy this situation.
> Have a look at the toolbar state management code.
>
> Bottom line: In principle, your proposal is very sensible, and
> it should probably have been done a long time ago. Just try to clear
> your schedule for 2-3 days when you sit down to try and make the
> code change. :-)
>
> --

Eric wasn't kidding. And I haven't even looked at the toolbar stuff. But
I have run into a serious problem. Here goes:

Currently, the ptbl stuff assumes that the only time you need to muck
around with it directly is in the importer(s). All the other fun stuff
goes throught FV_View. This is fortunate for everybody else, because the
ptbl by itself is pretty useless for individual editing. The reason for
this is that FV_View maintains an insertion point (of type
PT_DocPosition). Now, if you have the current insertion point, the ptbl
suddenly becomes lots friendlier. You can find out stuff about the
precise point in the ptbl. However, there's no good way (AFAICT) to
discover where you are in the document from the ptbl code. And when you
are in an importer, you don't have the luxury of a view.

So currently, I'm stuck. I need to use all the nice ptbl functions like
changeSpanFmt() and changeStruxFmt() in order to do the fun stuff I
promised everybody. But all those functions are designed to be accessed
from FV_View, and require a DocPosition as an argument.

The crude way out of this is pretty easy. Insertion point motion doesn't
look that complicated, and I could just chunk it down a level, into the
piece table. Then the ptbl would maintain the insertion point. But that
seems ugly, not least because insertion points don't make any sense in the
context of the raw ptbl. So I'm hoping that someone out there, with a
little more experience with all these fun data structures, can give me a
suggestion. Cause ugly code is no good. :-)

Thanks
           
                                     sam th
                                     sam@uchicago.edu
                                http://sam.rh.uchicago.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5M3Gwt+kM0Mq9M/wRAsWzAKCw58y7+axp5beifNGvo5g7xNV4uACgyfNT
yCjRN/5qf7RizRxubFHCbIw=
=g1FP
-----END PGP SIGNATURE-----



This archive was generated by hypermail 2b25 : Tue May 30 2000 - 02:45:48 CDT