Hi Gary,

Gary Dunn wrote:
> 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).
>   

I redesigned this mess in Cuis. Please check the TextModel hierarchy and 
the 'model' instance variable in TextModelMorph, BareTextMorph, 
Paragraph, TextEditor. There is a single model object, shared by all 
them. Only the model has the actual text being edited, and is 
responsible for it. Everything makes sense after this.

> 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?
>   

No, all this stuff has always been broken.

> Any suggestions on how to proceed?

Yes. Study Cuis. Then, if possible, integrate into Squeak... Or better 
yet, try to convince people that Squeak should be rebased on top of Cuis...

Cheers,
Juan Vuletich