[KJN]: The '''ntext''' package provides a [bindtags] binding tag named ''Ntext'' for use by Tk 8.5 [text] widgets in place of the default ''Text'' binding tag. '''DOCUMENTATION''' * man ntext (summary) [http://www.kerlin.net/tcl/ntext/ntext.html] * man ntextBindings (bindings) [http://www.kerlin.net/tcl/ntext/ntextBindings.html] * man ntextWordBreak (rules for word-boundary detection) [http://www.kerlin.net/tcl/ntext/ntextWordBreak.html] * man ntextIndent (indentation of word-wrapped display lines) [http://www.kerlin.net/tcl/ntext/ntextIndent.html] '''SUMMARY''' 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: * Some ''Text'' bindings behave differently from most text-editing applications. ''Ntext'' gives these bindings more familiar behaviour. * When a logical line with leading whitespace is word-wrapped onto more than one display line, the wrapped display lines begin further to the left than the first display line, which can make the text layout untidy and difficult to read. '''ntext''' can indent the wrapped lines to match the leading whitespace of the first display line (this facility is switched off by default). * When the user navigates or selects text, Tcl/Tk sometimes needs to detect word boundaries. '''ntext''' provides improved rules for word boundary detection. '''DOWNLOAD''' '''Source''' * '''ntext''' was incorporated into [tklib] [http://tcllib.sourceforge.net/] on 2007-06-25 and can be obtained by fetching the '''tklib''' module from CVS [http://sourceforge.net/cvs/?group_id=12883]. Alternatively a snapshot of CVS dated 2007-06-28 can be downloaded from [http://www.kerlin.net/tcl/ntext/tklib-CVS-2007-06-28.tar.gz]. Tcl licence applies. '''ActiveTcl''' * [ActiveTcl] 8.4.15 includes '''ntext''' with its version of Tklib; however, '''ntext''' requires Tcl/Tk 8.5. * Recent [ActiveTcl] 8.5 (beta) distributions do not include extras such as Tklib; the 8.5 installer advises use of extras from an 8.4 distribution. * Therefore, one way to try '''ntext''' is to install both ActiveTcl 8.4.15 and ActiveTcl 8.5 beta 8 (in different directories), and copy the folders lib/tklib0.4 and demos/Tklib from the 8.4.15 tree to the 8.5 beta 8 tree. '''Teapot''' * '''ntext''' is included in the ActiveState [Teapot] repository, as the entity named ''ntext''. The version of Tklib in the repository is slightly older, and does not include '''ntext'''. It is feasible to install [ActiveTcl] 8.5 beta 8, and then use [Teacup] to install ''ntext''. '''FEEDBACK''' 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: * Apple Mac running OS X * Wheel Mouse (all platforms) * Keyboards with "Meta" key * Anything that uses the tk_strictMotif setting - are any of the '''ntext''' features appropriate for tk_strictMotif? '''HISTORY''' 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 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. ---- [Category Discussion] | [Category GUI] | [Category Widget]