The purpose of the ntext package is to make the text widget behave more like other text-editing applications. It makes the text widget more useful for implementing a text editor, and makes it behave in a way that will be more familiar to most users.
Package ntext's functions and variables are contained entirely in the ::ntext namespace; its other code is contained in the binding tag Ntext. ntext has no exports to the global or other namespaces, and no new widget commands. It uses modified copies of the Tk code, leaving the original code, and the Text binding tag, unchanged.
The differences between the Ntext binding tag and the default Text binding tag are in three categories:
Bug reports, feature requests, and discussion are most welcome, either to this page or to comp.lang.tcl (on c.l.t. please put ntext in the subject line). Tests on the following hardware are particularly welcome:
An earlier version named newText was posted on this Wiki; an even earlier version was posted as Modern Bindings for the Text Widget.
What are sensible defaults for the text widget? The possibility of changing some of the default bindings was discussed on that page. Examination of the code for text shows that some of the apparent anachronisms of the text bindings are in fact deliberate choices - e.g. pasting with <Control-v> when a selection exists - on other platforms the selection is deleted, on X11 this is not the case, but this is not because of any limitation of X11: the code specifically checks whether it is using X11 so that it can behave differently on that windowing system.
Recent X11 desktops such as KDE and GNOME behave more like Windows or OS X than like Motif or CDE, so the question arises of whether Tk should follow the same trend. What would users prefer? As Vince suggested, a TIP would be the right way to propose any change, but it would be useful to have some feedback first on what users would prefer as the default. Opinions please, on this page or on c.l.t. (as above please put ntext in the subject line).
MG I think having the same default bindings for the text widget on all platforms would be desirable, possibly with alternative sets of bindings (possibly attained via a text-widget option, or by editing the bindtags for a particular text widget) to get something more specific/suitable for a particular platform/OS. As it is, if you write a "cross-platform" app using the text widget, I believe the bindings are different for that app on each platform you deploy it on, which makes it difficult to use or to support.
KD I agree that it would be better to have the same behaviour on all platforms. While different keybindings still make some sense, interpreting end-of-word differently doesn't. Note that the text widget also has the "index wordend/wordstart" commands, which do behave identical on all platforms. In fact, in my applications I also use some bindings comparable to ntext, and I used the wordend/wordstart commands to implement them.
LV 2007 July 14 It would be useful to see how the community responds to these bindings, and then to consider submitting a TIP to have them implemented as text widget defaults if these bindings are preferred over the existing default bindings.
KD The "overwrite" mode is nice, but it doesn't work well in the presence of tabs. When overwriting a tab, the text jumps to the left. (I know it is difficult to get this right, just wanted to note it.)
KJN: Thanks for your comments. I agree that the text jumping to the left does look a bit strange, but when a tab is replaced by a non-tab character it would seem that, unless the tab spacing is 1, the text to the right of the removed tab must move to the left. Can you suggest a better way to do it?
KD In most editors tabs are not overwritten, unless they are at a position where inserting a character would cause the text to jump to the right (this is when the tab character is just to the left of a tab position). A user who's overwriting free space in a text can't see whether it consists of spaces or tabs, so it's preferable that the behaviour is the same in both cases.
KJN: I hadn't thought of doing it that way - I mainly use the KDE editor kate, which does the jumping to the left. I'll try to implement your suggestion for the next release.