Re: [gtk-list] Re: vi bindings for text widgets

[Evan Lawrence <evan unix worldpath net>]

I have to say I really don't see what the problem here is - as of yet
noone's actually added vi bindings, and when they do it will be a *good*
thing, because it'll provide more options to the user and the programmer
alike - I personally would like to be able to go into gedit, and click
"Toggle VI mode" and have it behave like vi/vim... When someone *does*
finally add this functionality, it will of course have the option to turn
it off (it should probably be off by default, and let the program call a
gtk_text_set_vi_mode () if they want to change the editting mode)
otherwise it won't be accepted. I don't think anyone's seriously proposing
that the text widget use a vi mode *instead* of the way it currently does
it. Functionality and customizability are good things...


--
Evan Lawrence

On Tue, 7 Jul 1998, James Gardiner wrote:

> I'm reading this thread with some amusement:
> 
> I always thought that key bindings are something the app programmer is
> supposed to be concerned about.  If you want to change a core widget, in this
> case GtkText, to have Vi bindings only I will refuse to use that widget all
> the time...I will have to reimplement a NEW GtkText widget.  If the designers
> of GTK+ want to allow key bindings to be user-definable that's much better,
> but guess what:  Most newbies will *not* change them.  It has taken me quite a
> while to get used to the power of configurable Xresources and .rc files.
> Every app has its own way of defining ways for an app to work.  This is "not a
> bad thing" in itself, but be prepared for users of your app to send you gobs
> of e-mail bemoaning the fact that they accidentally changed "Reformat-text" to
> "Delete-text".
> 
> Instead, I prefer that some apps use Vi-bindings, some apps have fairly simple
> (or not-so-simple) bindings, and that other apps have user-definable bindings.
> This will in all likelihood prevent code bloat from feature creep (and yes,
> disk bloat from number of editors will probably increase).  If we keep asking
> for features from core widgets we will all end up with Vi editors the size of
> Microsoft Word.  Instead, concentrate on developing *extra* widgets for your
> code, or for distribution, that implement your desired functionality.  If you
> doubt the sense in this, look to the market in Windows for components.  Some
> of these components are quite complex, but most apps in Windows use just core
> functions.  This is the reason VB, Delphi, and now JavaBeans are very popular
> development enviroments.  The problem is in maintaining a balance between
> reduction of program size, with shared libraries implementing increased core
> functionality, and reduced complexity of the libraries themselves.
> 
> In short (yeah, right), keep GTK+ fairly simple, add functionality via add-on
> widgets, allow configurability on a programmer-desired basis.  While these
> things may not be programming utopia, we might just prevent GTK+ from becoming
> itself unmaintainable...each new feature can break existing programs.
> 
> Yeah, editor bigotry is a religious issue.  I use vim and gvim only because
> there isn't anything else that gives me the power without a ten-hour learning
> curve.  I don't need an X-only editor.
> 
> James Gardiner
> 
> -- 
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
> 
>