Re: TAB inside draw-text

• To: SWM@stony-brook.scrc.symbolics.com
• Subject: Re: TAB inside draw-text
• From: chyde@BBN.COM
• Date: Tue, 9 Nov 93 13:16:46 EST
• Cc: clim@BBN.COM
• In-Reply-To: <19931109172226.3.SWM@SUMMER.SCRC.Symbolics.COM> (message from Scott McKay on Tue, 9 Nov 1993 12:22 -0500)
• Sender: chyde@BBN.COM

   Date: Tue, 9 Nov 1993 12:22 -0500
   From: Scott McKay <SWM@stony-brook.scrc.symbolics.com>
   cc: clim@BBN.COM

       Date: Mon, 8 Nov 1993 10:09 EST
       From: Jeff Morrill <jmorrill@BBN.COM>

	 Date: Mon, 8 Nov 93 9:27:54 EST
	 From: chyde@BBN.COM

	 I'm drawing some text that has #\TABs in it. but, they don't show up
	 on screen, their width is zero. is there a special extra control one
	 has to provide to get this to have some width?

       Both TAB and RETURN don't seem to be processed correctly.
       They both seem to be treated the same as #\space.

       If you use FORMAT to generate the string in the first place,
       then you might be able to use ~T to work around it.

   If you are using DRAW-TEXT[*] (as opposed to WRITE-STRING), it does
   not handle tabs and newlines.  Handling tabs and newlines requires
   maintaining cursor state, and DRAW-TEXT[*] does not maintain any such
   cursor state.

   This was true as far back as CLIM 1.0.

   (Actually, this was true as far back as (SEND WINDOW :DRAW-STRING ...)
   in Symbolics system 98, circa 1982.  Maybe earlier.)

well, shoot. couldn't we get a default behavior that covers it in a
simplistic way (i.e., substitute N #\space characters for a tab) ?

I don't need anything too fancy. I could of course just use something
besides draw-text, but that really cramps my style in creating a
compound presentation...

 -- clint

• Re: TAB inside draw-text
• From: Scott McKay <SWM@stony-brook.scrc.symbolics.com>

• Prev: Genera 8.1.1 CLIM 1.1
• Next: Re: use of AND and Or in presentation specs
• Index: CLIM Mailing list (1-Jan-93 to 31-May-94)
• Thread: CLIM Mailing list Index (1-Jan-93 to 31-May-94)