Updated 2012-10-11 22:22:27 by dkf ▲

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) [1]
  • man ntextBindings (bindings) [2]
  • man ntextWordBreak (rules for word-boundary detection) [3]
  • man ntextIndent (indentation of word-wrapped display lines) [4]

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 [5] on 2007-06-25 and can be obtained by fetching the tklib module from CVS [6]. Alternatively a snapshot of CVS dated 2007-06-28 can be downloaded from [7]. 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 <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.

Category DiscussionCategory GUICategory Widget