Revised Tk Text Widget

Additional Widget Options '-startindex/-endindex'

Command-Line Name: -startindex
Database Name: startIndex
Database Class: StartIndex: Specifies an index representing the start of the underlying textual data store that should be contained in the widget. This allows a text widget to reflect only a portion of a larger piece of text. Instead of an index, the empty string can be provided to this configuration option, which will configure the widget to the start index in the textual data store. Instead of an empty string the special index specifier begin can be used.

Command-Line Name: -endindex
Database Name: endIndex
Database Class: EndIndex: Specifies an index representing the end of the underlying textual data store that should be contained in the widget. This allows a text widget to reflect only a portion of a larger piece of text. Instead of an index, the empty string can be provided to this configuration option, which will configure the widget to the end index in the textual data store. Instead of an empty string the special index specifier end can be used.

Command-Line Name: -startline

Database Name: startLine

Database Class: StartLine

Note that this option is deprecated, option -startindex should be used instead. For compatibility reasons this option still will be supported, but may be removed in a future version.

Specifies an integer line index representing the first line of the underlying textual data store that should be contained in the widget. This allows a text widget to reflect only a portion of a larger piece of text. Instead of an integer, the empty string can be provided to this configuration option, which will configure the widget to start at the very first line in the textual data store.

Command-Line Name: -endline

Database Name: endLine

Database Class: EndLine

Note that this option is deprecated, option -endindex should be used instead. For compatibility reasons this option still will be supported, but may be removed in a future version.

Specifies an integer line index representing the line of the underlying textual data store that should be just after the last line contained in the widget. This allows a text widget to reflect only a portion of a larger piece of text. Instead of an integer, the empty string can be provided to this configuration option, which will configure the widget to end at the very last line in the textual data store.

I've replaced options -startline/-endline with -startindex/-endindex:

The new options -startindex/-endindex are more flexible, not restricted to full lines anymore.
Using indices (in -startindex/-endindex) instead of line numbers (needed in -startline/-endline) fits better with the design of the text widget.
The implementation of -startindex/-endindex, when inserting/deleting text, is easier than the implementation with -startline/-endline, the latter needs special handling, but the former is realized with marks, and don't need any special handling when inserting/deleting text.
But with -startindex/-endindex the operations on indices are a bit more complex, because if -endindex is not set at start of a line, then the text between end index and trailing newline has to be skipped (this only affects the internal implementation).

The old options -startline/-endline still will be supported, but marked as deprecated. In any future Tk release the support of these old options shall be removed.

Note that the new feature -startindex/-endindex is not fully compatible to -startline/-endline. Test the following example:

This is the result:

-startline	-startindex

It's very unlikely that an application is deleting partial lines, like in our example, when having a peer which shows full lines. But if the original behavior of -startline is required, then this can be accomplished with the use of the watch command, see following example:

This script is emulating the behavior of -start/endline. The behavior of -start/endline is a bit unnatural, so the emulation is a bit complex.

Another incompatibility, see next example:

With wish8.6 the result is an empty string, because this widget does not contain any line, so it does not show an insertion cursor. Note that the revised version behaves a bit different, here the widget is not dead (like in this example), because this behavior does not fit with the requirement that the text widget always ensures a final newline at end of text. So dump shows the special marks insert and current with revised version. This minor incompatibility should not cause problems, nothing bad is happening here. The behavior of original implementation is obscure, because it does not coincide with the behavior of unrestricted widgets. (And emulating the original behavior would require some hacks in implementation of the revised version. The new behavior is the result of a sound implementation.)

But if the start index is after last line, then we will also have a dead widget like in the original implementation, test the following example:

This special behavior with dead peers cannot be avoided, this will become clear when doing tests with deletion of text.

Due to the fact that the behavior of restricted widgets have changed a bit, the chapter PEER WIDGETS needs some changes:

PEER WIDGETS

…

Finally any single peer need not contain the whole content from the underlying data store. When creating a peer, a contiguous range (e.g. only range "52.begin" through "125.end") may be specified. This allows a peer to contain just a small portion of the overall text. The range will expand and contract as text is inserted or deleted. If the peer's contents contracts to nothing (i.e. the start of the content is after last newline, as a result of a deletion from another widget), then it is impossible for new content to be inserted. The peer will simply become an empty shell (dead peer) on which the background can be configured, but which will never show any content (without manual reconfiguration of the start and end range). Note that a peer which does not contain all of the underlying data store still has indices numbered from “1.0” to “end”. It is simply that those indices reflect a subset of the total data, and data outside the contained range is not accessible to the peer. This means that the command peerName index end may return quite different values in different peers. Similarly, commands like peerName tag ranges will not return index ranges outside that which is meaningful to the peer. The configuration options -startindex and -endindex may be used to control how much of the underlying data is contained in any given text widget.

…

Here is an example for our new options, try it out: