Subject: FmtMarks (was Re: [PATCH] Fix for bug #863)
From: Paul Rohr (email@example.com)
Date: Thu Apr 26 2001 - 07:36:17 CDT
At 12:04 PM 4/21/01 +0800, Jeremy Teo wrote:
>> I don't understand the code you've patched yet so I don't know why your
>> patch works. In particular, I don't really know what a FmtMark is.
>Here's what i've garnered after some creative use of gdb and reading the
You've done an *excellent* job of detective work here!
Essentially, FmtMarks were Jeff's second catch-all attempt to solve the
kinds of problems you describe below. We did without them for quite a
while, but a bunch of subtle editing behaviours got lost because in certain
situations -- sorry, there never was a complete enumeration -- people wanted
a way to preserve certain formatting information in document states where
there's not any text to hang those character-level properties from.
At the time, he and I thought that the desired behaviors could probably be
implemented without FmtMarks, which never quite lost their hackish feel, but
to date nobody's found a good way to do so.
Originally, we managed to implement behaviors such as the following without
resorting to FmtMarks:
- Move the insertion point to a random spot in the document.
- Toggle the bold button.
- The next character typed will be bold.
In cases like this, we were able to keep track of the "pending format" at
view-level, and either apply or flush it as soon as it wasn't needed. I
still like to think that we could do something similar for other cases where
FmtMarks currently *are* necessary, but I've never thought the problem
through enough to know either way. Without a complete enumeration as
mentioned above, it's pretty hard to tell.
>1. If a line is blank, ie. contains no characters, a FmtMark is inserted
>with the attributes that the user specified. eg. Font name, size, bold, etc
>etc. In other words, it acts as a placeholder for the attributes.
Exactly. This "placeholder effect" is the primary purpose of FmtMarks.
>2. When a line is cleared, ie. by DeleteSpan etc, and it is the end of the
>paragraph (ie. no more characters in the line), FmtMark will be inserted
>with the attributes of the *last* character deleted to acts as said
>3. Bug 863 occurs when you move the cursor, then warpInsPtNextPrevPage/Line
>will remove *any* FmtMark at the present cursor location. Including the one
>DeleteSpan just inserted so that we can remember our attribute settings.
>4. I haven't figured out *why* exactly warpInsPtNextPrevPage/Line needs to
>clear the FmtMark at the current position other than to clear any FmtMark
>inserted if the user changes an attribute in the middle of 2
>characters:that wouldn't make sense.
In principle, FmtMarks are supposed to be temporary -- they allow you to
hang onto character properties so they can be applied to the next character
typed, at which point the FmtMark is removed, since it's no longer needed.
Thus, if the cursor's in the middle of an existing paragraph (ie, no
selection) and you:
- toggle some attributes, and
- move to some other spot in the document (via cursor navigation or a
then that "pending format" should be abandoned.
As you note, the last thing we want is to have "pending bold" FmtMarks lying
in wait at random spots in the text. That way lies madness. [**]
>5. Hence i've left that behaviour untouched, and hope that by *not*
>removing the FmtMark at the beginning of a line, that i will not have
>introduced any other side effects, other than bug #863.
The "other" case where FmtMarks get used is to retain character-level
formatting inside empty paragraphs. (An alternate way to do so would be to
temporarily hang those props off the paragraph, but that can lead to other
weirdness if not done properly.)
In this case, the FmtMark should arguably be preserved until a character is
typed into that paragraph. (Indeed, as Jesper pointed out recently, you may
even want it to persist.)
Thus, I share your intuition that in this particular case, it probably
wouldn't make sense to remove the FmtMark from a totally-empty paragraph
during cursor navigation, because it's probably *not* an "abandoned edit" as
Is that what you were asking?
>Could someone who is familiar with what i've described give me some
>feedback? Thanks. =)
I've done my best here. If you're still stuck, I'll try to track down Jeff
and pass along any further questions you have.
[*] The existing algorithms for determining which adjacent character's
formatting we use for the next character typed are fairly complex and
thoroughly debugged. Thus, I won't even attempt to explain them here.
Anyone interested is encouraged to read the relevant sources.
[**] Where "madness" == "reveal codes". ;-)
This archive was generated by hypermail 2b25 : Thu Apr 26 2001 - 07:28:44 CDT