text(n)

πŸ’– text(n) β€” the Tk Built-In Commands era πŸ’–

okay so bestie, gather round, because this is the manual page for text, tk_textCopy, tk_textCut, and tk_textPaste β€” aka the whole "Create and manipulate 'text' hypertext editing widgets" situation. it lives in the Tk Built-In Commands family, and honestly? it's giving main character energy. πŸŽ€


✨ NAME ✨

text, tk_textCopy, tk_textCut, tk_textPaste β€” Create and manipulate 'text' hypertext editing widgets. that's the whole vibe. πŸ¦‹


🌸 SYNOPSIS 🌸

text pathName ?options?
tk_textCopy pathName
tk_textCut pathName
tk_textPaste pathName

⭐ STANDARD OPTIONS ⭐

so these are the standard options, and every single one of them is invited to the party:

  • -background
  • -borderwidth
  • -cursor
  • -exportselection
  • -font
  • -foreground
  • -highlightbackground
  • -highlightcolor
  • -highlightthickness
  • -insertbackground
  • -insertborderwidth
  • -insertofftime
  • -insertontime
  • -insertwidth
  • -padx
  • -pady
  • -relief
  • -selectbackground
  • -selectborderwidth
  • -selectforeground
  • -setgrid
  • -takefocus
  • -xscrollcommand
  • -yscrollcommand
πŸ’‘ See the options manual entry for details on the standard options. iykyk. ✨

πŸŽ€ WIDGET-SPECIFIC OPTIONS πŸŽ€

these are the ones that make text text and not just some random rectangle. let's get into it, one icon at a time. πŸ’…

πŸ’œ -autoseparators

  • Database Name: autoSeparators
  • Database Class: AutoSeparators

Specifies a boolean that says whether separators are automatically inserted in the undo stack. it's only meaningful when the -undo option is true. no undo, no separators, no drama. πŸ™ˆ

πŸ’œ -blockcursor

  • Database Name: blockCursor
  • Database Class: BlockCursor

Specifies a boolean that says whether the blinking insertion cursor should be drawn as a character-sized rectangular block. if it's false (which is the default), a thin vertical line is used for the insertion cursor. for further discussion, refer to the section THE INSERTION CURSOR below. it's giving choose-your-own-cursor-aesthetic. ✨

πŸ’œ -endline

  • Database Name: endLine
  • Database Class: EndLine

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 is lowkey the "show me just a slice" feature β€” it allows a text widget to reflect only a portion of a larger piece of text. and instead of an integer, you can hand it the empty string, which configures the widget to end at the very last line in the textual data store. slay, flexible. πŸ¦‹

πŸ’œ -height

  • Database Name: height
  • Database Class: Height

Specifies the desired height for the window, in units of characters in the font given by the -font option. it must be at least one. one is the floor, bestie. πŸ’€

πŸ’œ -inactiveselectbackground

  • Database Name: inactiveSelectBackground
  • Database Class: Foreground

Specifies the colour to use for the selection (the sel tag) when the window does not have the input focus. if it's empty β€” {} β€” then no selection is shown when the window doesn't have the focus. ghosted on purpose. πŸ‘»

πŸ’œ -insertunfocussed

  • Database Name: insertUnfocussed
  • Database Class: InsertUnfocussed

Specifies how to display the insertion cursor when the widget does not have the focus. it must be:

  • none β€” the default, which means to not display the cursor
  • hollow β€” which means to display a hollow box
  • solid β€” which means to display a solid box
⚠️ note that hollow and solid will appear very similar when the -blockcursor option is false. yeah. just so you know. 😭

πŸ’œ -maxundo

  • Database Name: maxUndo
  • Database Class: MaxUndo

Specifies the maximum number of compound undo actions on the undo stack. a zero or a negative value imply an unlimited undo stack. infinite undo, infinite chaos, we love her. πŸ”₯

πŸ’œ -spacing1

  • Database Name: spacing1
  • Database Class: Spacing1

Requests additional space above each text line in the widget, using any of the standard forms for screen distances. if a line wraps, this option only applies to the first line on the display. this option may be overridden with -spacing1 options in tags. ✨

πŸ’œ -spacing2

  • Database Name: spacing2
  • Database Class: Spacing2

For lines that wrap (so that they cover more than one line on the display) this option specifies additional space to provide between the display lines that represent a single line of text. the value may have any of the standard forms for screen distances. this option may be overridden with -spacing2 options in tags. 🫢

πŸ’œ -spacing3

  • Database Name: spacing3
  • Database Class: Spacing3

Requests additional space below each text line in the widget, using any of the standard forms for screen distances. if a line wraps, this option only applies to the last line on the display. this option may be overridden with -spacing3 options in tags. literally the spacing trilogy, iconic. 🌈

πŸ’œ -startline

  • Database Name: startLine
  • Database Class: StartLine

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. pairing beautifully with -endline, no cap. πŸ’œ

πŸ’œ -state

  • Database Name: state
  • Database Class: State

Specifies one of two states for the text: normal or disabled. if the text is disabled then characters may not be inserted or deleted and no insertion cursor will be displayed, even if the input focus is in the widget. she's on do-not-disturb. πŸ’€

πŸ’œ -tabs

  • Database Name: tabs
  • Database Class: Tabs

Specifies a set of tab stops for the window. the option's value consists of a list of screen distances giving the positions of the tab stops, each of which is a distance relative to the left edge of the widget (excluding borders, padding, etc). each position may optionally be followed in the next list element by one of the keywords left, right, center, or numeric, which specifies how to justify text relative to the tab stop.

here's the justification lore, bestie:

  • left is the default β€” it causes the text following the tab character to be positioned with its left edge at the tab position.
  • right means that the right edge of the text following the tab character is positioned at the tab position.
  • center means that the text is centered at the tab position.
  • numeric means that the decimal point in the text is positioned at the tab position; if there is no decimal point then the least significant digit of the number is positioned just to the left of the tab position; if there is no number in the text then the text is right-justified at the tab position.

for example, -tabs {2c left 4c 6c center} creates three tab stops at two-centimeter intervals; the first two use left justification and the third uses center justification. ate. πŸŽ€

if the list of tab stops does not have enough elements to cover all of the tabs in a text line, then Tk extrapolates new tab stops using the spacing and alignment from the last tab stop in the list.

⚠️ tab distances must be strictly positive, and must always increase from one tab stop to the next (if not, an error is thrown). so no chaotic backwards tabs, sorry. 😭

the value of the -tabs option may be overridden by -tabs options in tags.

if no -tabs option is specified, or if it is specified as an empty list, then Tk uses default tabs spaced every eight (average size) characters. to achieve a different standard spacing β€” for example every 4 characters β€” simply configure the widget with:

-tabs "[expr {4 * [font measure $font 0]}] left" -tabstyle wordprocessor

🧚 that's the whole trick, you're welcome.

πŸ’œ -tabstyle

  • Database Name: tabStyle
  • Database Class: TabStyle

Specifies how to interpret the relationship between tab stops on a line and tabs in the text of that line. the value must be tabular (the default) or wordprocessor. note that tabs are interpreted as they are encountered in the text.

  • if the tab style is tabular then the n'th tab character in the line's text will be associated with the n'th tab stop defined for that line. if the tab character's x coordinate falls to the right of the n'th tab stop, then a gap of a single space will be inserted as a fallback.
  • if the tab style is wordprocessor then any tab character being laid out will use (and be defined by) the first tab stop to the right of the preceding characters already laid out on that line.

the value of the -tabstyle option may be overridden by -tabstyle options in tags. two styles, both valid, both gorgeous. πŸ’…

πŸ’œ -undo

  • Database Name: undo
  • Database Class: Undo

Specifies a boolean that says whether the undo mechanism is active or not. that's it. that's the option. (see also: -autoseparators and -maxundo, the whole undo squad 🫢)

πŸ’œ -width

  • Database Name: width
  • Database Class: Width

Specifies the desired width for the window in units of characters in the font given by the -font option. if the font does not have a uniform width then the width of the character 0 is used in translating from character units to screen units. yes, the zero. she's the standard. πŸ‘‘

πŸ’œ -wrap

  • Database Name: wrap
  • Database Class: Wrap

Specifies how to handle lines in the text that are too long to be displayed in a single line of the text's window. the value must be none or char or word.

  • a wrap mode of none means that each line of text appears as exactly one line on the screen; extra characters that do not fit on the screen are not displayed.
  • in the other modes each line of text will be broken up into several screen lines if necessary to keep all the characters visible.
  • in char mode a screen line break may occur after any character.
  • in word mode a line break will only be made at word boundaries.

choose your fighter. ⭐


(still going β€” part 1 of 14, don't go anywhere bestie πŸ’–)

✨ DESCRIPTION ✨

Okay so boom πŸ’₯ β€” the text command pops a brand-new window into existence (the one you name with the pathName argument, bestie, you pick it) and turns it into a text widget. Obsessed already.

You can toss extra options at it β€” the ones we talked about up above πŸ‘† β€” either right there on the command line or in the option database, and they configure stuff like its default background color and its relief. Cute, right? And after all that, the text command hands you back the path name of the shiny new window. That's the receipt 🧾.


So what does a text widget do, like actually? It displays one or more lines of text, and β€” this is the good part β€” it lets you edit that text. Main character energy: it's not just there to look pretty πŸ’….

Now here's where it gets juicy πŸ“. Text widgets support four different kinds of annotations on the text. Four! Count 'em:

  • tags 🏷️
  • marks πŸ“
  • embedded windows πŸͺŸ
  • embedded images πŸ–ΌοΈ

🏷️ Tags

Tags let different portions of the text be displayed with different fonts and colors. Yes bestie, you can make one paragraph look like a whole different aesthetic than the next. And it gets better β€” Tcl commands can be associated with tags too, so scripts get invoked when particular actions happen, like keystrokes and mouse button presses, but only in particular ranges of the text. Like, targeted. Specific. Iconic. 🎯 See TAGS below for all the deets.

πŸ“ Marks

The second kind of annotation is these floating markers in the text called β€œmarks”. Their whole job is keeping track of various interesting positions in the text as it gets edited β€” you know, so you don't lose your place when everything shifts around. Relatable honestly 😭. See MARKS below for more.

πŸͺŸ Embedded windows

Third annotation type: it lets you embed arbitrary windows right in the text widget. Arbitrary! Any window you want, just chillin' inside your text. See EMBEDDED WINDOWS below, iykyk.

πŸ–ΌοΈ Embedded images

And the fourth one lets Tk images get embedded in a text widget too. See EMBEDDED IMAGES below for the full rundown.


Oh and β€” not to bury the lede β€” the text widget also has a built-in undo/redo mechanism 🫢. Built in! You don't have to build it yourself, bestie, it's just there for you. See THE UNDO MECHANISM below.

And finally (for this little intro, anyway), the text widget allows for the creation of peer widgets πŸ‘―. These are other text widgets that share the same underlying data β€” text, marks, tags, images, etc. Same data, different widget. The way that works is genuinely so cool. See PEER WIDGETS below for more details.


✨ INDICES ✨

Okay bestie, here’s the tea β˜•: lots of widget commands for text take one or more indices as arguments. An index is just a string that points at a particular spot inside the text β€” like where to insert characters, or one endpoint of a range you’re about to delete. The syntax is:

base modifier modifier modifier ...

base gives you the starting point, and the modifiers adjust the index from there (move forward one character, back one line, etc.). Every index must contain a base, but the modifiers are optional. Most modifiers (as documented below) allow an optional submodifier. Valid submodifiers are any and display. If the submodifier is abbreviated, then it must be followed by whitespace, but otherwise there need be no space between the submodifier and the following modifier. Typically the display submodifier adjusts the meaning of the following modifier to make it refer to visual or non-elided units rather than logical units, but this is explained for each relevant case below. Lastly, where count is used as part of a modifier, it can be positive or negative, so base - -3 lines is perfectly valid (and equivalent to base +3lines). πŸ’…


the base forms, pick one bestie 🧚

The base for an index must have one of the following forms:

  • line.char β€” indicates the char'th character on line line. Lines are numbered from 1 for consistency with other UNIX programs that use this numbering scheme. Within a line, characters are numbered from 0. If char is end then it refers to the newline character that ends the line.
  • @x,y β€” indicates the character that covers the pixel whose x and y coordinates within the text’s window are x and y.
  • end β€” indicates the end of the text (the character just after the last newline).
  • mark β€” indicates the character just after the mark whose name is mark (see MARKS for details).
  • tag.first β€” indicates the first character in the text that has been tagged with tag. This form generates an error if no characters are currently tagged with tag.
  • tag.last β€” indicates the character just after the last one in the text that has been tagged with tag. This form generates an error if no characters are currently tagged with tag.
  • pathName β€” indicates the position of the embedded window whose name is pathName. This form generates an error if there is no embedded window by the given name.
  • imageName β€” indicates the position of the embedded image whose name is imageName. This form generates an error if there is no embedded image by the given name.

If the base could match more than one of the above forms β€” like a mark and an imageName both having the same value β€” then the form earlier in the above list takes precedence. If modifiers follow the base index, each one of them must have one of the forms listed below. Keywords such as chars and wordend may be abbreviated as long as the abbreviation is unambiguous. πŸŽ€


modifier menu πŸ› οΈ

  • + count ?submodifier? chars β€” adjust the index forward by count characters, moving to later lines in the text if necessary. If there are fewer than count characters in the text after the current index, then set the index to the last index in the text. Spaces on either side of count are optional. If the display submodifier is given, elided characters are skipped over without being counted. If any is given, then all characters are counted. For historical reasons, if neither modifier is given then the count actually takes place in units of index positions (see INDICES for details). This behaviour may be changed in a future major release, so if you need an index count, you are encouraged to use indices instead wherever possible.
  • - count ?submodifier? chars β€” adjust the index backward by count characters, moving to earlier lines in the text if necessary. If there are fewer than count characters in the text before the current index, then set the index to the first index in the text (1.0). Spaces on either side of count are optional. If the display submodifier is given, elided characters are skipped over without being counted. If any is given, then all characters are counted. For historical reasons, if neither modifier is given then the count actually takes place in units of index positions (see INDICES for details). This behavior may be changed in a future major release, so if you need an index count, you are encouraged to use indices instead wherever possible.
  • + count ?submodifier? indices β€” adjust the index forward by count index positions, moving to later lines in the text if necessary. If there are fewer than count index positions in the text after the current index, then set the index to the last index position in the text. Spaces on either side of count are optional. Note that an index position is either a single character or a single embedded image or embedded window. If the display submodifier is given, elided indices are skipped over without being counted. If any is given, then all indices are counted; this is also the default behaviour if no modifier is given.
  • - count ?submodifier? indices β€” adjust the index backward by count index positions, moving to earlier lines in the text if necessary. If there are fewer than count index positions in the text before the current index, then set the index to the first index position (1.0) in the text. Spaces on either side of count are optional. If the display submodifier is given, elided indices are skipped over without being counted. If any is given, then all indices are counted; this is also the default behaviour if no modifier is given.
  • + count ?submodifier? lines β€” adjust the index forward by count lines, retaining the same character position within the line. If there are fewer than count lines after the line containing the current index, then set the index to refer to the same character position on the last line of the text. Then, if the line is not long enough to contain a character at the indicated character position, adjust the character position to refer to the last character of the line (the newline). Spaces on either side of count are optional. If the display submodifier is given, then each visual display line is counted separately. Otherwise, if any (or no modifier) is given, then each logical line (no matter how many times it is visually wrapped) counts just once. If the relevant lines are not wrapped, then these two methods of counting are equivalent.
  • - count ?submodifier? lines β€” adjust the index backward by count logical lines, retaining the same character position within the line. If there are fewer than count lines before the line containing the current index, then set the index to refer to the same character position on the first line of the text. Then, if the line is not long enough to contain a character at the indicated character position, adjust the character position to refer to the last character of the line (the newline). Spaces on either side of count are optional. If the display submodifier is given, then each visual display line is counted separately. Otherwise, if any (or no modifier) is given, then each logical line (no matter how many times it is visually wrapped) counts just once. If the relevant lines are not wrapped, then these two methods of counting are equivalent.
  • ?submodifier? linestart β€” adjust the index to refer to the first index on the line. If the display submodifier is given, this is the first index on the display line, otherwise on the logical line.
  • ?submodifier? lineend β€” adjust the index to refer to the last index on the line (the newline). If the display submodifier is given, this is the last index on the display line, otherwise on the logical line.
  • ?submodifier? wordstart β€” adjust the index to refer to the first character of the word containing the current index. A word consists of any number of adjacent characters that are letters, digits, or underscores, or a single character that is not one of these. If the display submodifier is given, this only examines non-elided characters, otherwise all characters (elided or not) are examined.
  • ?submodifier? wordend β€” adjust the index to refer to the character just after the last one of the word containing the current index. If the current index refers to the last character of the text then it is not modified. If the display submodifier is given, this only examines non-elided characters, otherwise all characters (elided or not) are examined.

If more than one modifier is present then they are applied in left-to-right order. For example, the index end - 1 chars refers to the next-to-last character in the text, and insert wordstart - 1 c refers to the character just before the first one in the word containing the insertion cursor. Modifiers are applied one by one in this left to right order, and after each step the resulting index is constrained to be a valid index in the text widget. So, for example, the index 1.0 -1c +1c refers to the index 2.0. 🫢

Where modifiers result in index changes by display lines, display chars or display indices, and the base refers to an index inside an elided tag, that base index is considered to be equivalent to the first following non-elided index.


🏷️ TAGS 🏷️

The first form of annotation in text widgets is a tag. A tag is a textual string that is associated with some of the characters in a text. Tags may contain arbitrary characters, but it is probably best to avoid using the characters (space), +, or -: these characters have special meaning in indices, so tags containing them cannot be used as indices. There may be any number of tags associated with characters in a text. Each tag may refer to a single character, a range of characters, or several ranges of characters. An individual character may have any number of tags associated with it. πŸ’–

okay so bestie, tags have a whole hierarchy and it's genuinely giving ranked-competitive-reality-show energy πŸ‘‘. A priority order is defined among tags, and this order is used in implementing some of the tag-related functions described below. When a tag is defined (by associating it with characters or setting its display options or binding commands to it), it is given a priority higher than any existing tag. The priority order of tags may be redefined using the pathName tag raise and pathName tag lower widget commands. slay.

Tags serve three purposes in text widgets. First, they control the way information is displayed on the screen. By default, characters are displayed as determined by the -background, -font, and -foreground options for the text widget. However, display options may be associated with individual tags using the pathName tag configure widget command. If a character has been tagged, then the display options associated with the tag override the default display style. The following options are currently supported for tags:


✨ the tag display options (aka the glow-up menu) ✨

  • -background color β€” Color specifies the background color to use for characters associated with the tag. It may have any of the forms accepted by Tk_GetColor. πŸ’–
  • -bgstipple bitmap β€” Bitmap specifies a bitmap that is used as a stipple pattern for the background. It may have any of the forms accepted by Tk_GetBitmap. If bitmap has not been specified, or if it is specified as an empty string, then a solid fill will be used for the background. no notes.
  • -borderwidth pixels β€” Pixels specifies the width of a border to draw around the tag using any of the forms accepted by Tk_GetPixels. This option should be used in conjunction with the -relief option to provide the desired border. they're a package deal fr fr.
  • -elide boolean β€” Elide</c> specifies whether the data should be elided. Elided data (characters, images, embedded windows, etc.) is not displayed and takes no space on screen, but further on behaves just as normal data. so it's literally invisible but still THERE, main character who refuses to leave the group chat πŸ’€.
  • -fgstipple bitmap β€” Bitmap specifies a bitmap that is used as a stipple pattern when drawing text and other foreground information such as underlines. It may have any of the forms accepted by Tk_GetBitmap. If bitmap has not been specified, or if it is specified as an empty string, then a solid fill will be used.
  • -font fontName β€” FontName is the name of a font to use for drawing characters. It may have any of the forms accepted by Tk_GetFont. periodt.
  • -foreground color β€” Color specifies the color to use when drawing text and other foreground information such as underlines. It may have any of the forms accepted by Tk_GetColor.
  • -justify justify β€” If the first non-elided character of a display line has a tag for which this option has been specified, then justify determines how to justify the line. It must be one of left, right, or center. If a line wraps, then the justification for each line on the display is determined by the first non-elided character of that display line. iykyk.
  • -lmargin1 pixels β€” If the first non-elided character of a text line has a tag for which this option has been specified, then pixels specifies how much the line should be indented from the left edge of the window. Pixels may have any of the standard forms for screen distances. If a line of text wraps, this option only applies to the first line on the display; the -lmargin2 option controls the indentation for subsequent lines.
  • -lmargin2 pixels β€” If the first non-elided character of a display line has a tag for which this option has been specified, and if the display line is not the first for its text line (i.e., the text line has wrapped), then pixels specifies how much the line should be indented from the left edge of the window. Pixels may have any of the standard forms for screen distances. This option is only used when wrapping is enabled, and it only applies to the second and later display lines for a text line. bestie behaviour honestly.
  • -lmargincolor color β€” Color specifies the background color to use in regions that do not contain characters because they are indented by -lmargin1 or -lmargin2. It may have any of the forms accepted by Tk_GetColor. If color has not been specified, or if it is specified as an empty string, then the color used is specified by the -background tag option (or, if this is also unspecified, by the -background widget option). the fallback chain is so real 🫢.
  • -offset pixels β€” Pixels specifies an amount by which the text's baseline should be offset vertically from the baseline of the overall line, in pixels. For example, a positive offset can be used for superscripts and a negative offset can be used for subscripts. ✨ cute AND functional ✨.
  • -overstrike boolean β€” Specifies whether or not to draw a horizontal rule through the middle of characters. Boolean may have any of the forms accepted by Tcl_GetBoolean. very "this message was deleted" of it.
  • -overstrikefg color β€” Color specifies the color to use when displaying the overstrike. It may have any of the forms accepted by Tk_GetColor. If color has not been specified, or if it is specified as an empty string, then the color specified by the -foreground tag option is used.
  • -relief relief β€” Relief specifies the relief style to use for drawing the border, in any of the forms accepted by Tk_GetRelief. This option is used in conjunction with the -borderwidth option to enable to the desired border appearance. (yes, the original says "to enable to the desired border appearance" β€” i don't make the rules πŸ’…)
  • -rmargin pixels β€” If the first non-elided character of a display line has a tag for which this option has been specified, then pixels specifies how wide a margin to leave between the end of the line and the right edge of the window. Pixels may have any of the standard forms for screen distances. This option is only used when wrapping is enabled. If a text line wraps, the right margin for each line on the display is determined by the first non-elided character of that display line.
  • -rmargincolor color β€” Color specifies the background color to use in regions that do not contain characters because they are indented by -rmargin. It may have any of the forms accepted by Tk_GetColor. If color has not been specified, or if it is specified as an empty string, then the color used is specified by the -background tag option (or, if this is also unspecified, by the -background widget option).
  • -selectbackground color β€” Color specifies the background color to use when displaying selected items. It may have any of the forms accepted by Tk_GetColor. If color has not been specified, or if it is specified as an empty string, then the color specified by the -background tag option is used. selection look, activated 🌸.
  • -selectforeground color β€” Color specifies the foreground color to use when displaying selected items. It may have any of the forms accepted by Tk_GetColor. If color has not been specified, or if it is specified as an empty string, then the color specified by the -foreground tag option is used.
  • -spacing1 pixels β€” Pixels specifies how much additional space should be left above each text line, using any of the standard forms for screen distances. If a line wraps, this option only applies to the first line on the display. personal space, respect it.
  • -spacing2 pixels β€” For lines that wrap, this option specifies how much additional space to leave between the display lines for a single text line. Pixels may have any of the standard forms for screen distances.
  • -spacing3 pixels β€” Pixels specifies how much additional space should be left below each text line, using any of the standard forms for screen distances. If a line wraps, this option only applies to the last line on the display.
  • -tabs tabList β€” TabList specifies a set of tab stops in the same form as for the -tabs option for the text widget. This option only applies to a display line if it applies to the first non-elided character on that display line. If this option is specified as an empty string, it cancels the option, leaving it unspecified for the tag (the default). If the option is specified as a non-empty string that is an empty list, such as -tags { }, then it requests default 8-character tabs as described for the -tags widget option. (yes, that really is how it's written β€” -tags { } where you'd expect -tabs {}, but i'm not about to gaslight you by "fixing" it πŸ™ˆ)
  • -tabstyle style β€” Style specifies either the tabular or wordprocessor style of tabbing to use for the text widget. This option only applies to a display line if it applies to the first non-elided character on that display line. If this option is specified as an empty string, it cancels the option, leaving it unspecified for the tag (the default).
  • -underline boolean β€” Boolean specifies whether or not to draw an underline underneath characters. It may have any of the forms accepted by Tcl_GetBoolean.
  • -underlinefg color β€” Color specifies the color to use when displaying the underline. It may have any of the forms accepted by Tk_GetColor. If color has not been specified, or if it is specified as an empty string, then the color specified by the -foreground tag option is used.
  • -wrap mode β€” Mode specifies how to handle lines that are wider than the text's window. This option only applies to a display line if it applies to the first non-elided character on that display line. It has the same legal values as the -wrap option for the text widget: none, char, or word. If this tag option is specified, it overrides the -wrap option for the text widget. tag > widget, the tag ate and left no crumbs πŸ”₯.

πŸŽ€ when the options start fighting (conflict resolution) πŸŽ€

If a character has several tags associated with it, and if their display options conflict, then the options of the highest priority tag are used.

If a particular display option has not been specified for a particular tag, or if it is specified as an empty string, then that option will never be used; the next-highest-priority tag's option will used instead.

If no tag specifies a particular display option, then the default style for the widget will be used.

ngl that's the whole vibe check: highest priority wins, empty strings are a no, and if literally nobody claims an option then the widget's default takes it. no in-between, no drama πŸ’…βœ¨

The second glow-up of tags is event bindings 🫢 β€” like, you can hook bindings onto a tag pretty much the same way you'd hook them onto a widget class: whenever a particular X event happens on characters that carry that tag, boom, a given Tcl command runs. Tag bindings are literally how you give ranges of characters their own lil behaviors, and ngl that's what makes hypertext-y features even possible. For the deets, peep the pathName tag bind widget command description down below πŸ‘‡ Tag bindings are shared between all peer widgets (yep, including any bindings for the special sel tag β€” no gatekeeping there πŸ’…).

The third use for tags is managing the selection. See THE SELECTION below. And with the exception of the special sel tag, all tags are shared between peer text widgets and can be manipulated on an equal basis from any of those widgets. The sel tag though? She's independent, she exists separately in each peer text widget (but any tag bindings to sel are still shared β€” iconique of her ✨).


πŸŽ€ MARKS πŸŽ€

Okay so the second form of annotation in text widgets is a mark. Marks are for remembering particular places in your text β€” like lil bookmarks, if bookmarks had main character energy. They're kinda like tags in that they have names and they point at places in the file, but bestie, a mark is not associated with particular characters. Nope. A mark lives in the gap between two characters πŸ¦‹. Only a single position can be associated with a mark at any given time β€” one mark, one spot, periodt.

And here's the cute part: if the characters around a mark get deleted, the mark still sticks around; it just gets new neighbor characters πŸ™ˆ. Tags could never β€” if the characters containing a tag are deleted, that tag no longer has any association with characters in the file. Gone. Marks may be manipulated with the pathName mark widget command, and you can find out where they're at right now by using the mark name as an index in widget commands ✨.

Every mark also has a β€œgravity”, which is either left or right. Gravity is basically "what happens to my mark when text gets inserted right at the point of the mark?" If a mark has left gravity, it's treated like it's attached to the character on its left, so the mark stays to the left of any text inserted at the mark position. If the mark has right gravity, new text inserted at the mark position shows up to the left of the mark (so the mark stays rightmost, living its best rightmost life πŸ’…). The gravity for a mark defaults to right.

The name space for marks is different from the one for tags β€” so the same name can be used for both a mark and a tag, they'll just refer to different things. No collision, no drama 🫢.

Two marks have special significance, and they're kind of a big deal:

  • The mark insert is associated with the insertion cursor, as described under THE INSERTION CURSOR below πŸ‘‘.
  • The mark current is associated with the character closest to the mouse, and it's adjusted automatically to track the mouse position and any changes to the text in the widget. One exception tho: current isn't updated in response to mouse motions if a mouse button is down β€” that update gets deferred until all mouse buttons have been released πŸ™ˆ.
Neither of these special marks may be deleted. Absolutely not. Not allowed. πŸ”’

With the exception of those two special marks, all marks are shared between peer text widgets and may be manipulated on an equal basis from any peer. Slay 🌈.


🧚 EMBEDDED WINDOWS 🧚

The third form of annotation in text widgets is an embedded window. Each embedded window annotation makes a window show up at a particular point in the text β€” like a lil screenshot pasted into your paragraph, except it's a whole live widget πŸ’–. There can be any number of embedded windows in a text widget, and literally any widget can be used as an embedded window (subject to the usual rules for geometry management, which require the text window to be the parent of the embedded window, or a descendant of its parent β€” rules are rules bestie).

The embedded window's position on screen updates as the text is modified or scrolled, and it gets mapped and unmapped as it moves in and out of the visible area of the text widget. Each embedded window takes up one unit's worth of index space in the text widget, and it can be referred to either by the name of its embedded window or by its position in the widget's index space. And here's the cautionary tale 😭: if the range of text containing the embedded window is deleted, then the window is destroyed. Same vibe if the text widget as a whole is deleted β€” the window is destroyed too. πŸ’€

Okay, some specific lore you're gonna want:

Eliding an embedded window immediately after scheduling it for creation via pathName window create index -create will prevent it from being effectively created. Uneliding an elided embedded window that was scheduled for creation via pathName window create index -create will automatically trigger the associated creation script πŸŽ€. And after destroying an elided embedded window, the latter won't get automatically recreated. No respawns, sorry 🫢.

When an embedded window is added to a text widget with the pathName window create widget command, several configuration options may be associated with it. Those options can be modified later with the pathName window configure widget command. The following options are currently supported β€” drumroll please πŸ₯:

  • -align where β€” If the window isn't as tall as the line it's displayed in, this option decides where in the line the window sits. Where must be one of: top (align the top of the window with the top of the line), center (center the window within the range of the line), bottom (align the bottom of the window with the bottom of the line's area), or baseline (align the bottom of the window with the baseline of the line). Pick your fighter ✨
  • -create script β€” Specifies a Tcl script that may be evaluated to create the window for the annotation. If no -window option has been specified for the annotation, this script gets evaluated when the annotation is about to be displayed on the screen. Script must create a window for the annotation and return the name of that window as its result. Two substitutions get performed in script before evaluation: %W gets substituted by the name of the parent text widget, and %% gets substituted by a single % πŸ’…. If the annotation's window should ever be deleted, script will be evaluated again the next time the annotation is displayed. She's resilient like that.
  • -padx pixels β€” Pixels specifies the amount of extra space to leave on each side of the embedded window. It may have any of the usual forms defined for a screen distance. Personal space matters 🌸
  • -pady pixels β€” Pixels specifies the amount of extra space to leave on the top and on the bottom of the embedded window. It may have any of the usual forms defined for a screen distance. Same energy, vertical edition ⭐
  • -stretch boolean β€” If the requested height of the embedded window is less than the height of the line it's displayed in, this option lets you specify whether the window should be stretched vertically to fill its line. And if the -pady option has been specified as well, then the requested padding is retained even if the window is stretched 🫢. Stretch but make it cute.
  • -window pathName β€” Specifies the name of a window to display in the annotation. Ngl there's a lil gotcha here: if a pathName has been set, then later configuring a window to the empty string will not delete the widget corresponding to the old pathName. Rather, it removes the association between the old pathName and the text widget πŸ™ˆ. And if multiple peer widgets are in use, it's usually simpler to use the -create option if embedded windows are desired in each peer β€” iykyk, less headache πŸ’…

πŸ–ΌοΈ EMBEDDED IMAGES πŸ–ΌοΈ

Okay so the final form of annotation in text widgets? An embedded image, bestie. Each embedded image annotation makes an image show up at a specific point in the text. You can have literally any number of embedded images in a text widget, and one particular image can be embedded in multiple places in the same text widget. Obsessed with the reusability, honestly. ✨

The embedded image's position on the screen updates as the text gets modified or scrolled β€” it just follows along, main character energy. Each embedded image takes up one unit's worth of index space in the text widget, and you can refer to it either by its position in the widget's index space, or by the name it gets assigned when the image is inserted into the text widget with pathName image create. And if the range of text containing the embedded image gets deleted, that copy of the image is removed from the screen. Gone, periodt. πŸ’…

Eliding an embedded image immediately after scheduling it for creation via pathName image create index -create will prevent it from being effectively created. Uneliding an elided embedded image that was scheduled for creation via pathName image create index -create will automatically trigger the associated creation script. But β€” heads up β€” after destroying an elided embedded image, the latter won't get automatically recreated. 🫠

When an embedded image is added to a text widget with the pathName image create widget command, you get back a name unique to this instance of the image. That name can then be used to refer to this image instance. The name is taken to be the value of the -name option (described below). If the -name option isn't provided, the -image name is used instead. And if the imageName is already in use in the text widget, then #nn gets added to the end of the imageName, where nn is an arbitrary integer. That's what keeps the imageName unique, no cap. Once this name is assigned to this instance of the image, it does not change β€” even though the -image or -name values can be changed with pathName image configure. The name is forever. πŸ’–

When an embedded image is added to a text widget with the pathName image create widget command, several configuration options may be associated with it. These options can be modified later with the pathName image configure widget command. The following options are currently supported:

  • -align where β€” if the image isn't as tall as the line it's displayed in, this option decides where the image sits in that line. Where has to be one of: top (align the top of the image with the top of the line), center (center the image within the range of the line), bottom (align the bottom of the image with the bottom of the line's area), or baseline (align the bottom of the image with the baseline of the line). Pick your vibe. 🌈
  • -image image β€” specifies the name of the Tk image to display in the annotation. If image isn't a valid Tk image, then an error is returned. 😭
  • -name ImageName β€” specifies the name by which this image instance may be referenced in the text widget. If ImageName isn't supplied, then the name of the Tk image is used instead. If the imageName is already in use, #nn is appended to the end of the name as described above.
  • -padx pixels β€” pixels specifies the amount of extra space to leave on each side of the embedded image. It may have any of the usual forms defined for a screen distance.
  • -pady pixels β€” pixels specifies the amount of extra space to leave on the top and on the bottom of the embedded image. It may have any of the usual forms defined for a screen distance.

πŸŽ€ THE SELECTION πŸŽ€

Selection support is implemented via tags, bestie. If the -exportselection option for the text widget is true then the sel tag is associated with the selection:

  1. Whenever characters are tagged with sel the text widget claims ownership of the selection.
  2. Attempts to retrieve the selection are serviced by the text widget, returning all the characters with the sel tag.
  3. If the selection is claimed away by another application or by another window within this application, then the sel tag is removed from all characters in the text.
  4. Whenever the sel tag range changes, a virtual event <<Selection>> is generated. It might also be generated when selection is affected but not actually changed. Further, multiple selection changes could happen before events can be processed, leading to multiple events with the same visible selection. πŸ™ˆ

The sel tag is automatically defined when a text widget is created, and it may not be deleted with the pathName tag delete widget command. Furthermore, the -selectbackground, -selectborderwidth, and -selectforeground options for the text widget are tied to the -background, -borderwidth, and -foreground options for the sel tag: changes in either will automatically be reflected in the other. Slay, they're linked. πŸ’«

Also the -inactiveselectbackground option for the text widget is used instead of -selectbackground when the text widget doesn't have the focus. This lets you programmatically control how the sel tag is visualized for foreground and background windows β€” or to have sel not shown at all (when -inactiveselectbackground is empty) for background windows. Each peer text widget has its own sel tag which can be separately configured and set. πŸ‘‘


πŸ¦‹ THE INSERTION CURSOR πŸ¦‹

The mark named insert has special significance in text widgets. It's defined automatically when a text widget is created and it may not be unset with the pathName mark unset widget command. The insert mark represents the position of the insertion cursor, and the insertion cursor is automatically drawn at this point whenever the text widget has the input focus. Blink blink, bestie. ✨

The -blockcursor widget option controls the drawing of the cursor. However β€” and this is important, ngl β€” drawing the cursor as a solid blinking block is not exactly performed as in real or emulated terminals. The character at the cursor position is always drawn in its foreground color, i.e. not in "reverse video", which can lead to unwanted visual effects and even hide the character entirely when the cursor is in its on-state. 😭 So like, be aware of that.


πŸ’€ THE MODIFIED FLAG πŸ’€

The text widget can keep track of changes to the content of the widget by means of the modified flag. Inserting or deleting text sets this flag. The flag can be queried, set and cleared programmatically too. Whenever the flag changes state, a <<Modified>> virtual event is generated. See the pathName edit modified widget command for more details. 🫢


πŸ”₯ THE UNDO MECHANISM πŸ”₯

The text widget has an unlimited undo and redo mechanism (when the -undo widget option is true) which records every insert and delete action on a stack. Unlimited! We love to see it. πŸ‘‘

Boundaries (called "separators") are inserted between edit actions. The purpose of these separators is to group inserts, deletes and replaces into one compound edit action. When undoing a change, everything between two separators gets undone. The undone changes are then moved to the redo stack, so that an undone edit can be redone again. The redo stack is cleared whenever new edit actions are recorded on the undo stack. And the undo and redo stacks can be cleared to keep their depth under control.

Separators are inserted automatically when the -autoseparators widget option is true. You can insert separators programmatically as well. If a separator is already present at the top of the undo stack, no other will be inserted β€” which means two separators on the undo stack are always separated by at least one insert or delete action. iykyk πŸ’…

The <<UndoStack>> virtual event is generated every time the undo stack or the redo stack becomes empty or unempty.

The undo mechanism is also linked to the modified flag. This means undoing or redoing changes can take a modified text widget back to the unmodified state, or vice versa. The modified flag gets set automatically to the appropriate state. But β€” this automatic coupling does not work when the modified flag has been set by the user, until the flag has been reset again. Noted. 🫑

See below for the pathName edit widget command that controls the undo mechanism.

πŸ’– PEER WIDGETS πŸ’–

okay so here's the tea: the text widget keeps its own separate little stash of all its data β€” every line's textual contents, marks, tags, images, windows, and the whole undo stack. it's giving private vault energy. πŸ”

and like, you can't touch that data store directly (i.e. without a text widget as an intermediary), BUT β€” plot twist β€” you can create multiple text widgets, each of which shows a different view onto the same underlying data. those besties are called peer text widgets. 🫢

so when text gets added, deleted, edited, or coloured in any one widget, and when images, marks, and tags get adjusted β€” every single one of those changes shows up in all the peers. shared data, shared slay. ✨

basically all data and markup is shared, except for a few tiny details. let me break it down:

  1. the sel tag may be set and configured (in its display style) differently for each peer. each one gets its own little highlight moment. πŸ’…
  2. each peer has its own insert and current mark positions β€” but all other marks are shared. (yes bestie, the cursor is personal.)
  3. embedded windows, which are arbitrary other widgets, cannot be shared between peers. this means the -window option of embedded windows is independently set for each peer. (and it is advisable to use the -create script capabilities so each peer can create its own embedded windows as needed πŸŽ€)
  4. all of the configuration options of each peer (e.g. -font, etc) can be set independently β€” with the exception of -undo, -maxundo, and -autoseparators (i.e. all undo, redo and modified state issues are shared, no cap).

finally β€” and this is the part that lowkey blows my mind β€” any single peer doesn't have to contain all the lines from the underlying data store. when you create a peer, you can specify a contiguous range of lines (e.g. only lines 52 through 125). iconic. that lets a peer hold just a small portion of the overall text. the range of lines will expand and contract as text is inserted or deleted. 🌱

a peer will only ever display complete lines of text (one cannot share just part of a line β€” no half-lines, we don't do that here). so if the peer's contents contracts down to nothing (i.e. all complete lines in the peer widget have been deleted from another widget), then it is impossible for new lines to be inserted. 😭 the peer just becomes an empty shell on which the background can be configured, but which will never show any content (without manual reconfiguration of the start and end lines).

heads up: a peer which does not contain all of the underlying data store still has indices numbered from 1.0 to end. it's simply that those indices reflect a subset of the total data, and data outside the contained range is not accessible to the peer. so 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 -startline and -endline are what you use to control how much of the underlying data is contained in any given text widget. πŸ¦‹

also important: peers are really peers. deleting the "original" text widget will not cause any other peers to be deleted, or otherwise affected. they're independent queens. πŸ‘‘

see below for the pathName peer widget command that controls the creation of peer widgets.


⏳ ASYNCHRONOUS UPDATE OF LINE HEIGHTS ⏳

okay so to keep the user-experience responsive (we love a snappy GUI πŸ’…), the text widget calculates line metrics (line heights in pixels) asynchronously. and because of that, some commands of the text widget may return wrong results if the asynchronous calculations aren't finished at the time of calling. this applies to pathName count -ypixels and pathName yview. 😬

again, for performance reasons, it would not be appropriate to let these commands always wait for the end of the update calculation each time they're called. and honestly? in most use cases of these commands, a more-or-less inaccurate result does not really matter compared to execution speed. speed is the main character here. πŸ”₯

but in case an accurate result is needed (and if the text widget is managed by a geometry manager), one can resort to pathName sync and pathName pendingsync to control the synchronization of the view of text widgets. 🧚

the <<WidgetViewSync>> virtual event fires when the line heights of the text widget become obsolete (due to some editing command or configuration change), and again when the internal data of the text widget is back in sync with the widget view. the detail field (%d substitution) is either true (when the widget is in sync) or false (when it is not).

pathName sync, pathName pendingsync and <<WidgetViewSync>> apply to each text widget independently of its peers. no shared vibes on this one. 🌈

examples of use:

## Example 1:
# immediately complete line metrics at any cost (GUI unresponsive)
$w sync
$w yview moveto $fraction

## Example 2:
# synchronously wait for up-to-date line metrics (GUI responsive)
# before executing the scheduled command, but don't block execution flow
$w sync -command [list $w yview moveto $fraction]

## Example 3:
# init
set yud($w) 0
proc updateaction w {
set ::yud($w) 1
# any other update action here...
}
# runtime, synchronously wait for up-to-date line metrics (GUI responsive)
$w sync -command [list updateaction $w]
vwait yud($w)
$w yview moveto $fraction

## Example 4:
# init
set todo($w) {}
proc updateaction w {
foreach cmd $::todo($w) {uplevel #0 $cmd}
set todo($w) {}
}
# runtime
lappend todo($w) [list $w yview moveto $fraction]
$w sync -command [list updateaction $w]

## Example 5:
# init
set todo($w) {}
bind $w <<WidgetViewSync>> {
if {%d} {
foreach cmd $todo(%W) {eval $cmd}
set todo(%W) {}
}
}
# runtime
if {![$w pendingsync]} {
$w yview moveto $fraction
} else {
lappend todo($w) [list $w yview moveto $fraction]
}

bestie those examples ate, ngl. πŸ“š


πŸ‘‘ WIDGET COMMAND πŸ‘‘

the text command creates a new Tcl command whose name is the same as the path name of the text's window. this command may be used to invoke various operations on the widget. it has the following general form:

pathName option ?arg ...?

PathName is the name of the command, which is the same as the text widget's path name. Option and the args determine the exact behavior of the command. the following commands are possible for text widgets:

  • pathName bbox index β€” returns a list of four elements describing the screen area of the character given by index. the first two elements of the list give the x and y coordinates of the upper-left corner of the area occupied by the character, and the last two elements give the width and height of the area. if the character is only partially visible on the screen, then the return value reflects just the visible part. if the character is not visible on the screen then the return value is an empty list. (ghost character energy πŸ‘»)
  • pathName cget option β€” returns the current value of the configuration option given by option. Option may have any of the values accepted by the text command. πŸŽ€
  • pathName compare index1 op index2 β€” compares the indices given by index1 and index2 according to the relational operator given by op, and returns 1 if the relationship is satisfied and 0 if it is not. Op must be one of the operators <, <=, ==, >=, >, or !=. if op is == then 1 is returned if the two indices refer to the same character; if op is < then 1 is returned if index1 refers to an earlier character in the text than index2, and so on. it's literally just "who comes first" discourse. πŸ’€
  • pathName configure ?option? ?value option value ...? β€” query or modify the configuration options of the widget. if no option is specified, returns a list describing all of the available options for pathName (see Tk_ConfigureInfo for information on the format of this list). if option is specified with no value, then the command returns a list describing the one named option (this list will be identical to the corresponding sublist of the value returned if no option is specified). if one or more option-value pairs are specified, then the command modifies the given widget option(s) to have the given value(s); in this case the command returns an empty string. Option may have any of the values accepted by the text command. ✨
  • pathName count ?options? index1 index2 β€” counts the number of relevant things between the two indices. if index1 is after index2, the result will be a negative number (and this holds for each of the possible options). the actual items which are counted depend on the options given. the result is a list of integers, one for the result of each counting option given.

valid counting options are -chars, -displaychars, -displayindices, -displaylines, -indices, -lines, -xpixels, and -ypixels. the default value, if no option is specified, is -indices.

there is an additional possible option -update which is a modifier. if given (and if the text widget is managed by a geometry manager), then all subsequent options ensure that any possible out of date information is recalculated. this currently only has any effect for the -ypixels count (which, if -update is not given, will use the text widget's current cached value for each line). this -update option is obsoleted by pathName sync, pathName pendingsync and <<WidgetViewSync>>. πŸ’€

the count options are interpreted as follows:

  • -chars β€” count all characters, whether elided or not. do not count embedded windows or images.
  • -displaychars β€” count all non-elided characters. πŸ“
  • -displayindices β€” count all non-elided characters, windows and images.
  • -displaylines β€” count all display lines (i.e. counting one for each time a line wraps) from the line of the first index up to, but not including, the display line of the second index. therefore if they are both on the same display line, zero will be returned. by definition displaylines are visible and therefore this only counts portions of actual visible lines. 🌸
  • -indices β€” count all characters and embedded windows or images (i.e. everything which counts in text-widget index space), whether they are elided or not.

These are the count options, and yes, they are lowkey iconic:

  • -lines β€” counts every logical line (irrespective of wrapping) from the line of the first index up to, but not including, the line of the second index. So if they are both on the same line, bestie, zero will be returned. Logical lines are counted whether they are currently visible (non-elided) or not. πŸ‘‘
  • -xpixels β€” counts the number of horizontal pixels from the first pixel of the first index to (but not including) the first pixel of the second index. Trying to count the total desired width of the text widget (assuming wrapping is not enabled)? First find the longest line and then use β€œ.text count -xpixels "${line}.0" "${line}.0 lineend"”. πŸ’–
  • -ypixels β€” counts the number of vertical pixels from the first pixel of the first index to (but not including) the first pixel of the second index. If both indices are on the same display line, zero will be returned. To count the total number of vertical pixels in the text widget, use β€œ.text count -ypixels 1.0 end”, and to ensure this is up to date, use β€œ.text count -update -ypixels 1.0 end”. ✨

The command returns a positive or negative integer corresponding to the number of items counted between the two indices. One such integer is returned for each counting option given, so a list is returned if more than one option was supplied. For example β€œ.text count -xpixels -ypixels 1.3 4.5” is perfectly valid and will return a list of two elements. 🫢


pathName debug ?boolean?

If boolean is specified, then it must have one of the true or false values accepted by Tcl_GetBoolean. If the value is a true one then internal consistency checks will be turned on in the B-tree code associated with text widgets. If boolean has a false value then the debugging checks will be turned off. In either case the command returns an empty string. If boolean is not specified then the command returns on or off to indicate whether or not debugging is turned on. There is a single debugging switch shared by all text widgets: turning debugging on or off in any widget turns it on or off for all widgets. For widgets with large amounts of text, the consistency checks may cause a noticeable slow-down. 😭

When debugging is turned on, the drawing routines of the text widget set the global variables tk_textRedraw and tk_textRelayout to the lists of indices that are redrawn. The values of these variables are tested by Tk's test suite. πŸ’…

pathName delete index1 ?index2 ...?

Delete a range of characters from the text. If both index1 and index2 are specified, then delete all the characters starting with the one given by index1 and stopping just before index2 (i.e. the character at index2 is not deleted). If index2 does not specify a position later in the text than index1 then no characters are deleted. If index2 is not specified then the single character at index1 is deleted. Attempts to delete characters in a way that would leave the text without a newline as the last character will be tweaked by the text widget to avoid this. In particular, deletion of complete lines of text up to the end of the text will also delete the newline character just before the deleted block so that it is replaced by the new final newline of the text widget. The command returns an empty string. πŸŽ€

If more indices are given, multiple ranges of text will be deleted. All indices are first checked for validity before any deletions are made. They are sorted and the text is removed from the last range to the first range so deleted text does not cause an undesired index shifting side-effects. If multiple ranges with the same start index are given, then the longest range is used. If overlapping ranges are given, then they will be merged into spans that do not cause deletion of text outside the given ranges due to text shifted during deletion. 🌸

pathName dlineinfo index

Returns a list with five elements describing the area occupied by the display line containing index. The first two elements of the list give the x and y coordinates of the upper-left corner of the area occupied by the line, the third and fourth elements give the width and height of the area, and the fifth element gives the position of the baseline for the line, measured down from the top of the area. All of this information is measured in pixels. πŸ¦‹

If the current wrap mode is none and the line extends beyond the boundaries of the window, the area returned reflects the entire area of the line, including the portions that are out of the window. If the line is shorter than the full width of the window then the area returned reflects just the portion of the line that is occupied by characters and embedded windows. If the display line containing index is not visible on the screen then the return value is an empty list. πŸ’€

pathName dump ?switches? index1 ?index2?

Return the contents of the text widget from index1 up to, but not including index2, including the text and information about marks, tags, and embedded windows. If index2 is not specified, then it defaults to one character past index1. The information is returned in the following format:

key1 value1 index1 key2 value2 index2 ...

The possible key values are text, mark, tagon, tagoff, image, and window. The corresponding value is the text, mark name, tag name, image name, or window name. The index information is the index of the start of the text, mark, tag transition, image or window. One or more of the following switches (or abbreviations thereof) may be specified to control the dump: πŸ”₯

  • -all β€” Return information about all elements: text, marks, tags, images and windows. This is the default.
  • -command command β€” Instead of returning the information as the result of the dump operation, invoke the command on each element of the text widget within the range. The command has three arguments appended to it before it is evaluated: the key, value, and index. πŸ‘‘
  • -image β€” Include information about images in the dump results.
  • -mark β€” Include information about marks in the dump results.
  • -tag β€” Include information about tag transitions in the dump results. Tag information is returned as tagon and tagoff elements that indicate the begin and end of each range of each tag, respectively.
  • -text β€” Include information about text in the dump results. The value is the text up to the next element or the end of range indicated by index2. A text element does not span newlines. A multi-line block of text that contains no marks or tag transitions will still be dumped as a set of text segments that each end with a newline. The newline is part of the value. πŸ“
  • -window β€” Include information about embedded windows in the dump results. The value of a window is its Tk pathname, unless the window has not been created yet. (It must have a create script.) In this case an empty string is returned, and you must query the window by its index position to get more information. 🧚

pathName edit option ?arg ...?

This command controls the undo mechanism and the modified flag. The exact behavior of the command depends on the option argument that follows the edit argument. The following forms of the command are currently supported: πŸ’œ

  • pathName edit canredo β€” Returns a boolean true if redo is possible, i.e. when the redo stack is not empty. Otherwise returns false. ✨
  • pathName edit canundo β€” Returns a boolean true if undo is possible, i.e. when the undo stack is not empty. Otherwise returns false. ✨
  • pathName edit modified ?boolean? β€” If boolean is not specified, returns the modified flag of the widget. The insert, delete, edit undo and edit redo commands or the user can set or clear the modified flag. If boolean is specified, sets the modified flag of the widget to boolean. πŸŽ€
  • pathName edit redo β€” When the -undo option is true, reapplies the last undone edits provided no other edits were done since then, and returns a list of indices indicating what ranges were changed by the redo operation. Generates an error when the redo stack is empty. Does nothing when the -undo option is false. 🌈
  • pathName edit reset β€” Clears the undo and redo stacks. 🧹
  • pathName edit separator β€” Inserts a separator (boundary) on the undo stack. Does nothing when the -undo option is false. ⭐
  • pathName edit undo β€” Undoes the last edit action when the -undo option is true, and returns a list of indices indicating what ranges were changed by the undo operation. An edit action is defined as all the insert and delete commands that are recorded on the undo stack in between two separators. Generates an error when the undo stack is empty. Does nothing when the -undo option is false. πŸ’–
  • pathName get ?-displaychars? ?--? index1 ?index2 ...? β€” bestie this one pulls text out πŸ’– You give it index1 and it starts grabbing characters right there, and it keeps going until just before index2 β€” so the character at index2 itself does not come back, no cap. Skip index2 entirely and you just get the single character at index1. If there's literally nothing in that range (say index1 is past the end of the file, or index2 is less than or equal to index1) you get an empty string back, that's it. Embedded windows in the range? Their info does not get included in the returned string, periodt. Hand it multiple index pairs and you get multiple ranges back in a list β€” and heads up, invalid ranges will not be represented with empty strings in that list πŸ™ˆ The ranges come back in the exact order you passed them to pathName get. Add the -displaychars option and, inside each range, only the characters that aren't elided come back β€” which lowkey means some of your returned ranges can be empty strings.
  • pathName image option ?arg ...? β€” the ✨embedded image manipulation✨ command. What it actually does depends on the option that follows the image argument. These are the forms we currently support:
    • pathName image cget index option β€” gives you back the value of a configuration option for an embedded image. index says which image, and option names one specific configuration option β€” it's gotta be one of the ones listed in the EMBEDDED IMAGES section, iykyk.
    • pathName image configure index ?option value ...? β€” query or modify config options for an embedded image πŸ’… No option at all? You get a list describing every available option for the image at index (peep Tk_ConfigureInfo for the format of that list). Pass option with no value and you get back a list describing that one named option β€” and that list will be identical to the matching sublist of what you'd get with no option specified. Give it one or more option-value pairs and it modifies those option(s) to have those value(s); in that case the command returns an empty string. See EMBEDDED IMAGES for which options are supported.
    • pathName image create index ?option value ...? β€” makes a brand new image annotation πŸŽ€ which shows up in the text at the position given by index. You can throw in any number of option-value pairs to configure it. Returns a unique identifier you can use as an index to refer to this image later. See EMBEDDED IMAGES for the supported options and a description of that identifier.
    • pathName image names β€” returns a list whose elements are the names of all image instances currently embedded in window. slay.
  • pathName index index β€” returns the position corresponding to index, in the form line.char β€” where line is the line number and char is the character number. index can be any of the forms described up in INDICES, so go wild πŸ¦‹
  • pathName insert index chars ?tagList chars tagList ...? β€” drops all of the chars arguments in just before the character at index. One little quirk: if index points at the end of the text (that's the character after the last newline), the new text gets inserted just before the last newline instead 🫢 If you pass a single chars argument and no tagList, then the new text inherits any tags that are present on both the character before and the character after the insertion point β€” and if a tag is on only one of those two characters, it does not get applied to the new text. Specify tagList and it's a list of tag names: the new characters get all the tags in that list and no others, regardless of whatever tags are hanging around the insertion point. Multiple chars-tagList argument pairs work exactly like issuing a separate pathName insert widget command for each pair, in order. The final tagList argument can be left out 😌
  • pathName mark option ?arg ...? β€” mark manipulation central πŸ’… The exact behavior depends on the option after mark. Supported forms:
    • pathName mark gravity markName ?direction? β€” no direction? It returns left or right to tell you which of its adjacent characters markName is attached to. Give a direction and it has to be left or right β€” that becomes the new gravity of markName.
    • pathName mark names β€” returns a list whose elements are the names of every mark currently set. iconic.
    • pathName mark next index β€” returns the name of the next mark at or after index. If index is given in numerical form, the search kicks off at that index. If index is the name of a mark, the search begins immediately after that mark β€” and yes, it can still return a mark at the same position if multiple marks live at the same index. Those semantics mean mark next can step you through all the marks in a text widget in the same order as the mark info returned by the pathName dump operation πŸ”₯ Also: if a mark has been set to the special end index, it appears to be after end as far as pathName mark next is concerned. Empty string comes back if there are no marks after index.
    • pathName mark previous index β€” returns the name of the mark at or before index. Numeric index means the search starts with the character just before that index. If index is a mark name, the search begins immediately before that mark. And again, it can still return a mark at the same position when multiple marks share an index. So mark previous steps through every mark in a text widget in the reverse order of the mark info from pathName dump 🧚 Empty string if there are no marks before index.
    • pathName mark set markName index β€” sets the mark named markName to a position just before the character at index. If markName already exists it gets moved from its old spot; if it doesn't, a new mark is born ✨ Returns an empty string.
    • pathName mark unset markName ?markName markName ...? β€” removes the mark for each markName argument you pass. Removed marks won't be usable in indices and won't show up in future calls to pathName mark names. Returns an empty string.
  • pathName peer option args β€” creates and queries widget peers. Two forms, depending on option:
    • pathName peer create newPathName ?options? β€” creates a peer text widget with the given newPathName, plus any optional standard configuration options (same as for the text command). By default the peer gets the same start and end line as the parent widget, but you can override that with the standard config options πŸ’œ
    • pathName peer names β€” returns a list of this widget's peers (not including the widget itself, obvi). The order inside that list is undefined, so don't come for it πŸ™ˆ
  • pathName pendingsync β€” returns 1 if the line height calculations aren't up-to-date, 0 otherwise. vibe check on your line heights, basically.
  • pathName replace index1 index2 chars ?tagList chars tagList ...? β€” swaps out the range of characters between index1 and index2 with the given characters and tags. Peep the pathName insert section for how those tagList... arguments are handled, and the pathName delete section for how the indices are handled. One thing: if index2 is an index earlier in the text than index1, you get an error, sorry bestie 😭

The deletion and insertion are arranged so that no unnecessary scrolling of the window or movement of the insertion cursor happens β€” so bougie. On top of that, the undo/redo stack gets correctly modified if undo operations are active in the text widget. Returns an empty string.

  • pathName scan option args β€” implements scanning on text widgets. Two forms depending on option:
    • pathName scan mark x y β€” records x, y, and the current view in the text window, for use with later pathName scan dragto commands. Typically this one's tied to a mouse button press in the widget. Returns an empty string.
    • pathName scan dragto x y β€” computes the difference between its own x and y arguments and the x and y from the last pathName scan mark command for the widget. Then it adjusts the view by 10 times the difference in coordinates 😳 Usually hooked up to mouse motion events so it feels like you're dragging the text at high speed through the window. Returns an empty string.

🌸 the search era 🌸

pathName search ?switches? pattern index ?stopIndex?

okay so bestie, this one is a whole vibe β€” it goes digging through the text in pathName starting at index, looking for a run of characters that matches pattern. πŸ’… if it finds a match? you get back the index of the first character in the match as the result. if not? empty string, sorry babe, nothing for you. πŸ™ˆ

you can sprinkle in one or more of these switches (or abbreviations of them, we're chill like that) to steer the hunt:

  • -forwards β€” the search slides forward through the text, grabbing the first matching range that starts at or after wherever index is pointing. this is the default, it's the main character ✨
  • -backwards β€” the search goes backward, finding the matching range closest to index whose first character is before index (and ngl, it is not allowed to be at index, that's the rule πŸ’€). heads up though: for a whole bunch of reasons, backwards searches can be substantially slower than forwards ones (especially with -regexp), so if your code is performance-critical, please please please use forward searches. 🫢
  • -exact β€” exact matching only: the characters in the matching range have to be identical to those in pattern. also the default, slay πŸ’–
  • -regexp β€” treat pattern as a regular expression and match it against the text using regular expression rules (peep the regexp command and the re_syntax page for the deets). the default matching automatically passes both -lineanchor and -linestop to the regexp engine (unless -nolinestop is used), so that ^$ match the beginning and end of a line, and ., [^ sequences will never match the newline character \n. iconic behaviour honestly πŸŽ€
  • -nolinestop β€” this one lets . and [^ sequences match the newline character \n, which they otherwise will not do (see the regexp command for details). ⚠️ this option is only meaningful if -regexp is also given, and an error gets thrown otherwise. for example, to match the entire text, use pathName search -nolinestop -regexp ".*" 1.0. yw πŸ’œ
  • -nocase β€” ignore case differences between the pattern and the text. the lowercase girlies and the uppercase girlies are the same girlies πŸ’…
  • -count varName β€” the argument after -count is the name of a variable; if a match is found, the number of index positions between the beginning and end of the matching range gets stored in that variable. if there are no embedded images or windows in the matching range (and there are no elided characters if -elide is not given), this is equivalent to the number of characters matched. either way, the range matchIdx to matchIdx + $count chars will return the entire matched text. math is mathing ✨
  • -all β€” find all the matches in the given range and return a list of the indices of the first character of each match. if a -count varName switch is given, then varName is also set to a list containing one element for each successful match. and note β€” even for exact searches, the elements of this list may be different if there are embedded images, windows or hidden text. πŸ‘€ searches with -all behave very similarly to the Tcl command regexp -all, in that overlapping matches are not normally returned. for example, applying an -all search of the pattern "\w+" against "hello there" will just match twice, once for each word, and matching "Z[a-z]+Z" against "ZooZooZoo" will just match once. no cap 🧒
  • -overlap β€” when you're doing -all searches, the normal behaviour is that matches which overlap an already-found match will not be returned. this switch changes that so all matches which are not totally enclosed within another match are returned. for example, applying an -overlap search of the pattern "\w+" against "hello there" will just match twice (i.e. no different to just -all), but matching "Z[a-z]+Z" against "ZooZooZoo" will now match twice. πŸ”₯ an error will be thrown if this switch is used without -all. don't do that 🫠
  • -strictlimits β€” normally, the start and stop limits are checked with respect to the start of the matching text. with the -strictlimits flag though, the entire matching range must lie inside the start and stop limits specified for the match to be valid. strict queen πŸ‘‘
  • -elide β€” find elided (hidden) text as well. by default only displayed text is searched, which, fair 🫣
  • -- β€” this switch has no effect except to terminate the list of switches: the next argument will be treated as pattern even if it starts with -. the great separator πŸŽ€

the matching range may live within a single line of text, or it can run across multiple lines (if parts of the pattern can match a newline). for regular expression matching you can use the various newline-matching features β€” like $ to match the end of a line, ^ to match the beginning of a line, and to control whether . is allowed to match a new-line. 🌈

if stopIndex is specified, the search stops there: for forward searches, no match at or after stopIndex will be considered; for backward searches, no match earlier in the text than stopIndex will be considered. if stopIndex is omitted, the entire text gets searched β€” and when the beginning or end of the text is reached, the search continues at the other end until the starting location is reached again (wrap-around, we love a loop πŸ”). but if stopIndex is specified, no wrap-around will occur. which means, for example, if the search is -forwards but stopIndex is earlier in the text than startIndex, nothing will ever be found. sad but true 😭 see KNOWN BUGS below for a number of minor limitations of the pathName search command.


πŸ‘€ the see moment πŸ‘€

pathName see index

adjusts the view in the window so that the character given by index is completely visible. if index is already visible then the command does absolutely nothing (if it ain't broke πŸ’…). if index is a short distance out of view, the command adjusts the view just enough to make index visible at the edge of the window. and if index is far out of view, then the command centers index in the window β€” main character, center stage, lights on βœ¨πŸ‘‘


πŸ¦‹ sync β€” keeping the timeline straight πŸ¦‹

pathName sync ?-command command?

controls the synchronization of the view of the text widget. two flavours, pick your fighter:

pathName sync

immediately brings the line metrics up-to-date by forcing computation of any outdated line heights. the command returns immediately if there's no such outdated line heights, otherwise it returns only at the end of the computation. and it returns an empty string. ⏳

pathName sync -command command

schedules command to be executed (by the event loop) exactly once as soon as all line heights are up-to-date. if there are no pending line metrics calculations, the scheduling is immediate. the command returns the empty string. and β€” important β€” bgerror is called on command failure. 🚨


πŸŽ€ tag β€” the whole tag lifestyle πŸŽ€

pathName tag option ?arg ...?

this command is how you manipulate tags, bestie. the exact behavior depends on the option argument that follows the tag argument. currently supported forms, coming right up:

pathName tag add

pathName tag add tagName index1 ?index2 index1 index2 ...?

associate the tag tagName with all of the characters starting with index1 and ending just before index2 (so the character at index2 is not tagged β€” exclusive, we respect boundaries 🫢). a single command may contain any number of index1-index2 pairs, go off πŸ’…. if the last index2 is omitted then the single character at index1 is tagged. and if there are no characters in the specified range (e.g. index1 is past the end of the file, or index2 is less than or equal to index1) then the command has no effect at all. nothing. zero. zilch. πŸ’€

pathName tag bind

pathName tag bind tagName ?sequence? ?script?

this command associates script with the tag given by tagName. whenever the event sequence given by sequence occurs for a character that has been tagged with tagName, the script will be invoked. πŸ”” this widget command is similar to the bind command except that it operates on characters in a text rather than entire widgets. see the bind manual entry for complete details on the syntax of sequence and the substitutions performed on script before invoking it, iykyk.

if all arguments are specified then a new binding is created, replacing any existing binding for the same sequence and tagName (unless the first character of script is "+", in which case script augments an existing binding rather than replacing it β€” glow-up, not replacement ✨). in this case the return value is an empty string.

if script is omitted then the command returns the script associated with tagName and sequence (and an error occurs if there's no such binding πŸ™ˆ).

if both script and sequence are omitted then the command returns a list of all the sequences for which bindings have been defined for tagName. the full receipts πŸ“‹πŸ’–

okay so bestie, real talk: the only events you can bind to a tag are the mouse and keyboard ones (think Enter, Leave, Button, Motion, Key) or virtual events. Mouse and keyboard event bindings for a text widget use the current and insert marks respectively β€” those are the ones we talked about under MARKS earlier, iykyk. An Enter event fires for a tag when that tag first shows up on the current character, and a Leave event fires when it dips out. These can happen either because the current mark moved or because the character at that position changed. Important vibe check: these are not the same as Enter and Leave events for windows, okay? Mouse events go to the current character, while keyboard events go to the insert character. And if you use a virtual event in a binding, that binding only triggers if the virtual event is defined by an underlying mouse-related or keyboard-related event. no cap.


It is possible for the current character to have multiple tags, and for each of them to have a binding for a particular event sequence. When this happens, one binding is invoked for each tag, in order from lowest-priority to highest priority. If there are multiple matching bindings for a single tag, then the most specific binding is chosen (peep the manual entry for the bind command for the deets). The continue and break commands inside binding scripts are processed exactly the same way as for bindings created with the bind command. periodt.

If bindings are created for the widget as a whole using the bind command, then those bindings supplement the tag bindings. The tag bindings get invoked first, followed by bindings for the window as a whole. it's giving layered access, honestly.


pathName tag cget tagName option β€” this one returns the current value of the option named option associated with the tag given by tagName. Option can be any of the values accepted by the pathName tag configure widget command. simple as that πŸ’…


pathName tag configure tagName ?option? ?value? ?option value ...? β€” this is like the pathName configure widget command, except it modifies options for the tag tagName instead of the whole text widget. If no option is specified, the command returns a list describing all the available options for tagName (check Tk_ConfigureInfo for the format of that list). If option is specified with no value, you get a list describing just that one named option β€” and yes, it'll be identical to the corresponding sublist of the full list you'd get with no option. If one or more option-value pairs are specified, then the command modifies the given option(s) to have the given value(s) in tagName; in that case it returns an empty string. See TAGS above for all the options available for tags. slay.

pathName tag configure tagName ?option? ?value? ?option value
...?

pathName tag delete tagName ?tagName ...? β€” deletes all tag information for each of the tagName arguments. It removes the tags from all characters in the file and also deletes any other information associated with the tags, like bindings and display info. Returns an empty string. it's giving clean slate ✨


pathName tag lower tagName ?belowThis? β€” changes the priority of tag tagName so it's just lower in priority than the tag named belowThis. If belowThis is omitted, then tagName's priority is changed to make it the lowest priority of all tags. bow down to the bottom of the stack πŸ‘‘


pathName tag names ?index? β€” returns a list of names of all tags active at the character position given by index. If index is omitted, the return value describes all tags that exist for the text (this includes all tags named in a β€œpathName tag” widget command that haven't been deleted by a β€œpathName tag delete” widget command, even if no characters are currently marked with the tag). The list is sorted from lowest priority to highest priority. iconic.


pathName tag nextrange tagName index1 ?index2? β€” searches the text for a range of characters tagged with tagName where the first character of the range is no earlier than the character at index1 and no later than the character just before index2 (a range starting at index2 will not be considered). If several matching ranges exist, the first one is chosen. The return value is a list of two elements: the index of the first character of the range, and the index of the character just after the last one in the range. If no matching range is found, you get an empty string. If index2 isn't given, it defaults to the end of the text. forward search, bestie πŸ”


pathName tag prevrange tagName index1 ?index2? β€” same idea but backwards: searches for a range of characters tagged with tagName where the first character of the range is before the character at index1 and no earlier than the character at index2 (a range starting at index2 will be considered here). If several matching ranges exist, the one closest to index1 is chosen. Return value is a list of two elements: the index of the first character of the range, and the index of the character just after the last one in the range. If no matching range is found, empty string. If index2 isn't given, it defaults to the beginning of the text. back it up πŸ¦‹


pathName tag raise tagName ?aboveThis? β€” changes the priority of tag tagName so it's just higher in priority than the tag named aboveThis. If aboveThis is omitted, then tagName's priority is changed to make it the highest priority of all tags. main character energy at the top of the stack πŸ’…


pathName tag ranges tagName β€” returns a list describing all the ranges of text tagged with tagName. The first two elements describe the first tagged range, the next two describe the second range, and so on. The first element of each pair is the index of the first character of the range, and the second element is the index of the character just after the last one in the range. If there are no characters tagged with tagName, you get an empty string. it's giving receipts 🧾


pathName tag remove tagName index1 ?index2 index1 index2 ...? β€” removes the tag tagName from all characters starting at index1 and ending just before index2 (the character at index2 is not affected). A single command can contain any number of index1-index2 pairs. If the last index2 is omitted, the tag is removed from the single character at index1. If there are no characters in the specified range (e.g. index1 is past the end of the file, or index2 is less than or equal to index1), then the command has no effect. Returns an empty string. lowkey surgical 🩹


pathName window option ?arg ...? β€” this command is used to manipulate embedded windows. The behavior depends on the option argument that follows the window argument. The following forms are currently supported:

pathName window cget index option β€” returns the value of a configuration option for an embedded window. Index identifies the embedded window, and option specifies a particular configuration option, which must be one of the ones listed in the section EMBEDDED WINDOWS. peekaboo πŸ‘€

pathName window configure index ?option value ...? β€” query or modify the configuration options for an embedded window. If no option is specified, returns a list describing all available options for the embedded window at index (see Tk_ConfigureInfo for the format of this list). If option is specified with no value, you get a list describing just that one named option (identical to the corresponding sublist of the full list). If one or more option-value pairs are specified, the command modifies the given option(s) to have the given value(s); in that case it returns an empty string. See EMBEDDED WINDOWS for the supported options. glow-up time ✨

pathName window create index ?option value ...? β€” creates a new window annotation that will appear in the text at the position given by index. Any number of option-value pairs may be specified to configure the annotation. See EMBEDDED WINDOWS for the supported options. Returns an empty string. new window, who dis? πŸͺŸ

pathName window names β€” returns a list whose elements are the names of all windows currently embedded in window. roll call πŸ“‹


pathName xview option args β€” this command queries and changes the horizontal position of the text in the widget's window. It can take any of the following forms: πŸ‘€

πŸ’– pathName xview β€” horizontal-scroll realness

  • pathName xview β€” okay so this one returns a list with two elements. Each element is a real fraction between 0 and 1; together they describe the portion of the document's horizontal span that's visible in the window. Example: if the first element is .2 and the second is .6, then 20% of the text is off-screen to the left, the middle 40% is visible in the window, and 40% of the text is off-screen to the right. The fractions refer only to the lines actually visible in the window: if the lines in the window are all very short, so that they're entirely visible, the returned fractions will be 0 and 1, even if there are other lines in the text that are much wider than the window. These are the same values passed to scrollbars via the -xscrollcommand option. ✨
  • pathName xview moveto fraction β€” adjusts the view in the window so that fraction of the horizontal span of the text is off-screen to the left. fraction is a fraction between 0 and 1. πŸ’…
  • pathName xview scroll number what β€” shifts the view in the window left or right according to number and what. what must be pages, pixels, or units. If what is pages or units then number must be an integer; otherwise number may be specified in any of the forms acceptable to Tk_GetPixels, such as β€œ2.0c” or β€œ1i” (the result is rounded to the nearest integer value. If no units are given, pixels are assumed). If what is pages then the view adjusts by number screenfuls; if it is pixels then the view adjusts by number pixels; if it is units, the view adjusts left or right by number average-width characters on the display. If number is negative then characters farther to the left become visible; if it is positive then characters farther to the right become visible. πŸ‘‘

πŸ¦‹ pathName yview ?args?

This command is used to query and change the vertical position of the text in the widget's window. It can take any of the following forms:

  • pathName yview β€” returns a list containing two elements, both real fractions between 0 and 1. The first element gives the position of the first visible pixel of the first character (or image, etc) in the top line in the window, relative to the text as a whole (0.5 means it is halfway through the text, for example). The second element gives the position of the first pixel just after the last visible one in the bottom line of the window, relative to the text as a whole. These are the same values passed to scrollbars via the -yscrollcommand option. ⭐
  • pathName yview moveto fraction β€” adjusts the view in the window so that the pixel given by fraction appears at the top of the top line of the window. fraction is a fraction between 0 and 1; 0 indicates the first pixel of the first character in the text, 0.33 indicates the pixel that is one-third the way through the text; and so on. Values close to 1 will indicate values close to the last pixel in the text (1 actually refers to one pixel beyond the last pixel), but in such cases the widget will never scroll beyond the last pixel, and so a value of 1 will effectively be rounded back to whatever fraction ensures the last pixel is at the bottom of the window, and some other pixel is at the top. 🌈
  • pathName yview scroll number what β€” adjusts the view in the window up or down according to number and what. what must be pages, pixels, or units. If what is units or pages then number must be an integer; otherwise number may be specified in any of the forms acceptable to Tk_GetPixels, such as β€œ2.0c” or β€œ1i” (the result is rounded to the nearest integer value. If no units are given, pixels are assumed). If what is units, the view adjusts up or down by number lines on the display; if it is pages then the view adjusts by number screenfuls; if it is pixels then the view adjusts by number pixels. If number is negative then earlier positions in the text become visible; if it is positive then later positions in the text become visible. πŸ”₯
  • pathName yview ?-pickplace? index β€” changes the view in the widget's window to make index visible. If the -pickplace option is not specified then index will appear at the top of the window. If -pickplace is specified then the widget chooses where index appears in the window:
    1. If index is already visible somewhere in the window then the command does nothing.
    2. If index is only a few lines off-screen above the window then it will be positioned at the top of the window.
    3. If index is only a few lines off-screen below the window then it will be positioned at the bottom of the window.
    4. Otherwise, index will be centered in the window.

The -pickplace option has been obsoleted by the pathName see widget command (pathName see handles both x- and y-motion to make a location visible, whereas the -pickplace mode only handles motion in y). 🫢

  • pathName yview number β€” makes the first character on the line after the one given by number visible at the top of the window. number must be an integer. This command used to be used for scrolling, but now it is obsolete. πŸ’€

✨ BINDINGS ✨

okay so Tk literally just gives texts a whole set of class bindings for free, no setup, no cap πŸ’… here's the default behavior bestie gets out of the box. and real quick β€” in everything below, "word" depends on the value of the tcl_wordchars variable (iykyk, go peek at tclvars(n) for the deets).

  1. clicking mouse button 1 puts the insertion cursor at the closest edge of the character right under the mouse, sets input focus to this widget, and clears any selection in the widget. then if you drag with mouse button 1, it strokes out a selection between the insertion cursor and the character under the mouse. drag queen behavior fr πŸ–±οΈ
  2. double-click with mouse button 1 and it selects the word under the mouse and parks the insertion cursor at the start of that word. keep dragging after the double click and the selection strokes out in whole words. obsessed.
  3. triple-click with mouse button 1 β†’ selects the line under the mouse, insertion cursor goes to the start of the line. drag after a triple click and you're selecting whole lines. iconic.
  4. you can also adjust the ends of the selection by dragging with mouse button 1 while Shift is down β€” this adjusts whichever end of the selection was nearest to the mouse cursor when button 1 was pressed. and if the button was double-clicked before you dragged, the selection adjusts in units of whole words; triple-clicked means it adjusts in units of whole lines. slay.
  5. clicking mouse button 1 with Ctrl down repositions the insertion cursor without touching the selection. main character cursor energy.
  6. type any normal printing characters and they get inserted right at the insertion cursor. duh, but we said it. ✨
  7. drag with the middle mouse button (button 2, or button 3 in TkAqua) to adjust the view in the widget. and if you click the middle mouse button without moving the mouse, the selection gets copied into the text at the position of the mouse cursor. lowkey the Insert key does the same insert-selection thing, except it drops it at the position of the insertion cursor instead. 🫢
  8. drag the mouse outta the widget while button 1 is pressed and the entry will automatically scroll so more text is visible β€” but only if there's actually more text off-screen on the side where the mouse left the window. considerate queen.
  9. Left and Right move the insertion cursor one character left or right, and they also clear any selection in the text. hold Shift while typing Left or Right and the cursor moves and the selection extends to include the new character. Ctrl+Left / Ctrl+Right move by words, and Ctrl+Shift+Left / Ctrl+Shift+Right move by words and extend the selection. also Ctrl+b and Ctrl+f behave same as Left and Right respectively, and Meta+b / Meta+f behave same as Ctrl+Left and Ctrl+Right. two for one, we love efficiency. πŸ¦‹
  10. Up and Down move the insertion cursor one line up or down and clear any selection in the text. if Up or Right is typed with Shift down, the cursor moves and the selection extends to include the new character. Ctrl+Up / Ctrl+Down move by paragraphs (that's groups of lines separated by blank lines, bestie), and Ctrl+Shift+Up / Ctrl+Shift+Down move by paragraphs and extend the selection. Ctrl+p and Ctrl+n behave same as Up and Down respectively.
  11. Next and Prior move the insertion cursor forward or backwards by one screenful and clear any selection in the text. hold Shift while typing Next or Prior and the selection extends to include the new character. πŸ’–
  12. Ctrl+Next and Ctrl+Prior scroll the view right or left by one page β€” without moving the insertion cursor or affecting the selection. literally just vibes, no cursor drama.
  13. Home and Ctrl+a move the insertion cursor to the beginning of its display line and clear any selection in the widget. Shift+Home moves the insertion cursor to the beginning of the display line and extends the selection to that point. πŸŽ€
  14. End and Ctrl+e move the insertion cursor to the end of the display line and clear any selection in the widget. Shift+End moves the cursor to the end of the display line and extends the selection to that point.
  15. Ctrl+Home and Meta+&lt; move the insertion cursor to the beginning of the text and clear any selection in the widget. Ctrl+Shift+Home moves the insertion cursor to the beginning of the text and also extends the selection to that point. go to the top, periodt.
  16. Ctrl+End and Meta+&gt; move the insertion cursor to the end of the text and clear any selection in the widget. Ctrl+Shift+End moves the cursor to the end of the text and extends the selection to that point.
  17. the Select key and Ctrl+Space set the selection anchor to the position of the insertion cursor β€” and ngl they do not affect the current selection. Shift+Select and Ctrl+Shift+Space adjust the selection to the current position of the insertion cursor, selecting from the anchor to the insertion cursor if there wasn't any selection previously. anchor girlies rise. βš“
  18. Ctrl+/ selects the entire contents of the widget. all of it. every last character. πŸ‘‘
  19. Ctrl+\ clears any selection in the widget. bye bestie πŸ¦‹
  20. the F16 key (labelled Copy on many Sun workstations) or Meta+w copies the selection in the widget to the clipboard β€” if there is a selection. this action is carried out by the command tk_textCopy.
  21. the F20 key (labelled Cut on many Sun workstations) or Ctrl+w copies the selection in the widget to the clipboard and deletes the selection. this action is carried out by the command tk_textCut. and if there's no selection in the widget, then these keys have no effect. nothing happens. we move on. πŸ’…
  22. the F18 key (labelled Paste on many Sun workstations) or Ctrl+y inserts the contents of the clipboard at the position of the insertion cursor. this action is carried out by the command tk_textPaste.
  23. the Delete key deletes the selection, if there is one in the widget. if there's no selection, it deletes the character to the right of the insertion cursor.
  24. Backspace and Ctrl+h delete the selection, if there is one in the widget. if there's no selection, they delete the character to the left of the insertion cursor.
  25. Ctrl+d deletes the character to the right of the insertion cursor.
  26. Meta+d deletes the word to the right of the insertion cursor.
  27. Ctrl+k deletes from the insertion cursor to the end of its line β€” and if the insertion cursor is already at the end of a line, then Ctrl+k deletes the newline character. sneaky but valid. 🌸
  28. Ctrl+o opens a new line by inserting a newline character in front of the insertion cursor without moving the insertion cursor. cursor stays exactly where it was, no notes.
  29. Meta+Backspace and Meta+Delete delete the word to the left of the insertion cursor.
  30. Ctrl+t reverses the order of the two characters to the right of the insertion cursor. yes it's exactly as chaotic as it sounds and yes it's real. πŸ™ˆ
  31. Ctrl+x deletes whatever is selected in the text widget β€” after copying it to the clipboard. copy first, delete second, always.
  32. Ctrl+z undoes the last edit action if the -undo option is true. does nothing otherwise. 🧚
  33. Ctrl+Z (or Ctrl+y on Windows) reapplies the last undone edit action if the -undo option is true. does nothing otherwise. the redo girlies stay winning.

πŸ’€ real talk though: if the widget is disabled using the -state option, then its view can still be adjusted and text can still be selected β€” but no insertion cursor will be displayed and no text modifications will take place. read-only but make it fashion.

and if you wanna switch things up, the behavior of texts can be changed by defining new bindings for individual widgets or by redefining the class bindings. customize away bestie πŸ’œ

πŸ’€ KNOWN ISSUES πŸ’€

okay so, real talk β€” there are some known quirks and they're giving β€œiconic but slightly messy,” so let's get into it πŸ’…

🧚 ISSUES CONCERNING CHARS AND INDICES 🧚

Before Tk 8.5, the widget used the string chars to refer to index positions β€” and that category included characters, embedded windows, and embedded images. As of Tk 8.5, the text widget deals separately and correctly with chars and indices. But for backwards compatibility, the index modifiers +N chars and -N chars still refer to indices. You have to use a full form like +N any chars or -N any chars (etc.) to refer to actual character indices. This confusion may be fixed in a future release by making the widget correctly interpret +N chars as a synonym for +N any chars. fr fr, that's the situation 🫢

πŸš€ PERFORMANCE ISSUES πŸš€

Text widgets should run efficiently under a variety of conditions. The text widget uses about 2-3 bytes of main memory for each byte of text, so texts containing a megabyte or more should be practical on most workstations. Text is represented internally with a modified B-tree structure that makes operations relatively efficient even with large texts. Tags are included in the B-tree structure in a way that allows tags to span large ranges or have many disjoint smaller ranges without loss of efficiency. Marks are also implemented in a way that allows large numbers of marks. In most cases it is fine to have large numbers of unique tags, or a tag that has many distinct ranges. slay for the B-tree, honestly 🌈

One performance problem can arise if you have hundreds or thousands of different tags that all have the following characteristics: the first and last ranges of each tag are near the beginning and end of the text, respectively, or a single tag range covers most of the text widget. The cost of adding and deleting tags like this is proportional to the number of other tags with the same properties. In contrast, there is no problem with having thousands of distinct tags if their overall ranges are localized and spread uniformly throughout the text. lowkey a tag-layout vibe check πŸŽ€

Very long text lines can be expensive, especially if they have many marks and tags within them.

The display line with the insert cursor is redrawn each time the cursor blinks, which causes a steady stream of graphics traffic. Set the -insertofftime attribute to 0 to avoid this. not me optimizing away the blink drama πŸ’€

πŸ› KNOWN BUGS πŸ›

The pathName search -regexp sub-command attempts to perform sophisticated regexp matching across multiple lines in an efficient fashion (since Tk 8.5), examining each line individually, and then in small groups of lines, whether searching forwards or backwards. Under certain conditions the search result might differ from that obtained by applying the same regexp to the entire text from the widget in one go. For example, when searching with a greedy regexp, the widget will continue to attempt to add extra lines to the match as long as one of two conditions are true:

  • either Tcl's regexp library returns a code to indicate a longer match is possible (but there are known bugs in Tcl which mean this code is not always correctly returned);
  • or if each extra line added results in at least a partial match with the pattern.

This means in the case where the first extra line added results in no match and Tcl's regexp system returns the incorrect code and adding a second extra line would actually match, the text widget will return the wrong result. In practice this is a rare problem, but it can occur, for example:

pack [text .t]
.t insert 1.0 "aaaa\nbbbb\ncccc\nbbbb\naaaa\n"
.t search -regexp -- {(a+|b+\nc+\nb+)+\na+} 1.0

will not find a match when one exists of 19 characters starting from the first b. 😭

Whenever one possible match is fully enclosed in another, the search command will attempt to ensure only the larger match is returned. When performing backwards regexp searches it is possible that Tcl will not always achieve this, in the case where a match is preceded by one or more short, non-overlapping matches, all of which are preceded by a large match which actually encompasses all of them. The search algorithm used by the widget does not look back arbitrarily far for a possible match which might cover large portions of the widget. For example:

pack [text .t]
.t insert 1.0 "aaaa\nbbbb\nbbbb\nbbbb\nbbbb\n"
.t search -regexp -backward -- {b+\n|a+\n(b+\n)+} end

matches at 5.0 when a true greedy match would match at 1.0. Similarly if we add -all to this case, it matches at all of 5.0, 4.0, 3.0 and 1.0, when really it should only match at 1.0 since that match encloses all the others. the way regexp backwards search is out here being extra πŸ™ˆ


πŸ‘€ SEE ALSO πŸ‘€

πŸ”‘ KEYWORDS πŸ”‘

  • text
  • widget
  • tkvars

And that's the whole page, bestie β€” footer energy is Tk 8.5, text(n), plus the date line doing its little footer thing down there. mwah πŸ’–πŸ’…

πŸ“¦ where this page comes from