I am trying to fix the bug in changeing fonts with yellowMouseBotton.
The problem is that font settings made with the yellowMouseButton do
not affect the selected text, while the same changes made with CTRL-K
work as expected. Another thing I noticed is that when the change font
dialog box opens with CTRL-K it displays to correct font. With
yellowMouseButton / set font, it does not.

I have a ScrollableField morph which contains the phrase "note text
goes here." The word text has had its font changed to
BitstreamVeraSerif 24 Roman; it displays much larger and in a serif
font compared to the rest of the line. This is good.

Added the lines below marked * to TextEditor>>changeTextFont

changeTextFont
	"Present a dialog which allows the user to select a font, and if one
is chosen, apply it to the current selection.	If there is no
selection, or the selection is empty, apply it to the whole morph."
	| curFont startIndex |
	
	startIndex := self startIndex.
	curFont := (paragraph text fontAt: startIndex withStyle: paragraph textStyle).

*	Transcript show: paragraph text; cr.
*	Transcript show: curFont; cr.
*	self halt.

	morph openModal: (
...

When I double-click the word text in my phrase, then press CTRL-K, the
transcript displays

    note text goes here.

    TTCFont(BitstreamVeraSerif 24 Roman)

which is correct.

When I double-click the word, perform a yellowMouseButton (for me that
is a right-click) and select "set font", the transcript displays

    This is a note.
    Can we set font attributes for portions of text?

    How does it look now? Too bold.

    This looks good but I want the right-click menu to show attributes.
    TTCFont(BitstreamVeraSans 9 Bold)

This text is not displayed anywhere. It is from an earlier session,
long-since deleted. Ghostly. And the font is wrong. In this method,
the paragraph var is pointing to the wrong text. I have seen something
similar in other cases, where trying to copy and paste produced
similarly bizarre results (pasted text appears in a different morph).

When I look at the back-trace for the CTRL-K process the event
sequence leads quickly and cleanly to the SmallTalkEditor and
offerFontMenu method followed by changeTextFont, where this break
occurs. The yellowMouseButton back-trace is much longer, in part
because it takes a while for squeak to figure out which menu item I
selected.

The problem as I see it is that the yellowMouseButton only digs down
to the ScrollableField morph and stops there. By the time we get to
TextMorphForEditView we have the wrong object, because the value of
text in the debugger at that point, four lines from the top of the
back-trace, is the incorrect, ghostly text. I still have not found
exactly where the trip up occurs. Around the time things go bad I see
a BlockClosure>>ensure: method. Could this be somthing broken by the
addition of block closures?

Any suggestions on how to proceed?

-- 
Gary Dunn
Honolulu