Re: GtkTextView overtype mode
- From: Bill Haneman <bill haneman sun com>
- To: Owen Taylor <otaylor redhat com>
- Cc: Joel Brobecker <brobecker act-europe fr>, Havoc Pennington <hp redhat com>, Calum Benson <calum benson sun com>, gnome-accessibility-list gnome org, gtk-devel-list gnome org
- Subject: Re: GtkTextView overtype mode
- Date: Thu, 27 Sep 2001 16:21:23 +0100
Owen Taylor wrote:
> Bill Haneman <bill haneman sun com> writes:
> > Joel Brobecker wrote:
> > > > Yes, and no. Good point on the cursor thing; hrm, now to find time to
> > > > implement it...
> > >
> > > Coming from Emacs and vi, I've always used the block cursor. I find the
> > > I-beam cursor hard to see and follow when moving it. Would it be
> > > possible to allow the usage of the block-cursor even in non-override
> > > mode?
> > This sounds like something that could be themed to good effect.
> > Unfortunately the text-drawing routines themselves don't seem
> > installable via theme engines, so this would need to be a global
> > parameter.
> > There is an upcoming theme patch that addresses some text cursor
> > needs, I can have a look.
> I don't think a block cursor makes any sense for insertion mode -
> Emacs just does it because you can't draw a line on a terminal.
That is probably true for most users, but for someone who has difficulty
seeing the I-beam cursor then we should be able to do whatever is
most visible for them.
Perhaps the line-weight themability for the text cursor which
we've discussed before will do the job, but I think a
block cursor could be useful for some users.
> - The line indicates the position (or positions for split cursor!)
> where text will be inserted.
> - The overtype block indicates the text that will be replaced by
> a new keystroke.
> Trying to customize cursor drawing this radically via theming will
> cause problems for handling of bidirectional text and for input method
> "preedit" strings.
> (I'm not even sure how overtype should work with "preedit" on.)
] [Thread Prev