is the cursor always one character wide?
jsparkes at gmail.com
Fri Jun 4 13:35:37 EDT 2010
"Stephen J. Turnbull" <stephen at xemacs.org> writes:
> Jeff Sparkes writes:
> > It would simplify things to know that a cursor only over overlays a single
> > display character.
> It mostly does. But it's not implemented that way, it's implemented
> more generally. For example, from Lisp you can set bar-cursor to a
> non-nil variable and it won't cover a character. Also, in GUI
> displays, the cursor becomes half-width at line-end.
> > I checked the obvious case of TAB, where the cursor is displayed
> > over a single space sized area at the beginning. Are there any
> > unicode cases where a cursor is wider than a space?
> Do you really mean "space"? The block cursor is generally as wide as
> the character after point, and overlays that character. This is true
> for proportional fonts (which typically have extremely narrow spaces),
> as well as for Asian "full-width" (ie, as wide as they are tall)
The cursor only overlays a single space width of a tab. That might
mean that wider unicode characters aren't completely overlaid by the cursor.
> Why not just use the XLIKE functions for display? Even if in the end
> you want to port to Pango, I expect that to be non-trivial, precisely
> because of issues like cursor treatment, where XEmacs does some subtle
> things (e.g., the change in shape at EOL is a nice touch).
It appears that the XLIKE code is correct, but the supposed cursor GC.
is exactly the same the text GC. When the same GC to draw the
outline cursor, the foreground is a red, a different colour than the
text GC. I suspected that the GC cache was causing me problems, but
avoiding it didn't fix the problem. It's truly odd.
Using the outline cursor is workable for now. I want to get the menubar
(and toolbar) working before I tackle using pango to draw the text.
More information about the XEmacs-Beta