text(3tk)

✨ text(3tk) — Tk Built-In Commands, but make it a vibe ✨

okay bestie, welcome to text(3tk), aka the manual for the Tk text widget 💖 it's the whole hypertext editing widget situation, and honestly? it's giving main character energy. let's get into it.

---

🌸 NAME 🌸

text, tk_textCopy, tk_textCut, tk_textPaste — create and manipulate 'text' hypertext editing widgets. yes, all four, they're a little squad 🫶

---

✨ SYNOPSIS ✨

text pathName ?options?
tk_textCopy pathName
tk_textCut pathName
tk_textPaste pathName

---

👑 STANDARD OPTIONS 👑

these are the standard options, all iconic, all here, no cap:

• -background
• -borderwidth
• -cursor
• -exportselection
• -font
• -foreground
• -highlightbackground
• -highlightcolor
• -highlightthickness
• -insertbackground
• -insertborderwidth
• -insertofftime
• -insertontime
• -insertwidth
• -padx
• -pady
• -relief
• -selectbackground
• -selectborderwidth
• -selectforeground
• -setgrid
• -takefocus
• -xscrollcommand
• -yscrollcommand

💡 heads up bestie: the options manual entry has all the deets on the standard options, so if you need the lore, go there ✨

---

💅 WIDGET-SPECIFIC OPTIONS 💅

okay this is the juicy part, the options that are just for text widgets. each one comes with a Command-Line Name, a Database Name, and a Database Class, so let's go one by one 💖

---

🎀 -autoseparators / autoSeparators / AutoSeparators

Command-Line Name: -autoseparators Database Name: autoSeparators Database Class: AutoSeparators

specifies a boolean that says whether separators get automatically inserted into the undo stack. ngl, this one only matters when the -undo option is set to true — otherwise it's just sitting there looking cute with nothing to do 🙈

---

🦋 -blockcursor / blockCursor / BlockCursor

Command-Line Name: -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, fyi) then you just get a thin vertical line for the insertion cursor instead. lowkey minimalist. ✨

---

🌸 -endline / endLine / EndLine

Command-Line Name: -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 the trick that lets a text widget reflect only a portion of a much larger piece of text 👑

instead of an integer, you can also pass the empty string to this config option, which configures the widget to end at the very last line in the textual data store. cute, right?

---

💜 -height / height / Height

Command-Line Name: -height Database Name: height Database Class: Height

specifies the desired height for the window, measured in units of characters in the font that the -font option gives you. it must be at least one. can't be zero, bestie, we don't do that here 💅

---

🌈 -inactiveselectbackground / inactiveSelectBackground / Foreground

Command-Line Name: -inactiveselectbackground Database Name: inactiveSelectBackground Database Class: Foreground

specifies the colour to use for the selection (that's the sel tag, iykyk) when the window does not have the input focus. and if it's empty — {} — then no selection is shown at all when the window doesn't have the focus. ghost mode fr fr 👻

---

🫶 -insertunfocussed / insertUnfocussed / InsertUnfocussed

Command-Line Name: -insertunfocussed Database Name: insertUnfocussed Database Class: InsertUnfocussed

specifies how to display the insertion cursor when the widget does not have the focus. must be one of:

• none — the default, which means: don't display the cursor at all 🙈
• hollow — which means: display a hollow box
• solid — which means: display a solid box

⚠️ ngl bestie, hollow and solid end up looking very similar when the -blockcursor option is false. so don't be shocked 💀

---

🍓 -maxundo / maxUndo / MaxUndo

Command-Line Name: -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 implies an unlimited undo stack — go off, infinite undo, we love to see it 🔥

---

🌸 -spacing1 / spacing1 / Spacing1

Command-Line Name: -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. and heads up: this option may be overridden with -spacing1 options in tags 👑

---

🦋 -spacing2 / spacing2 / Spacing2

Command-Line Name: -spacing2 Database Name: spacing2 Database Class: Spacing2

for lines that wrap (so they cover more than one line on the display), this option specifies additional space between the display lines that represent a single line of text. value can be any of the standard forms for screen distances. and yep — this one may be overridden with -spacing2 options in tags ✨

---

💖 -spacing3 / spacing3 / Spacing3

Command-Line Name: -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. and (say it with me) this option may be overridden with -spacing3 options in tags 🌸

---

⭐ -startline / startLine / StartLine

Command-Line Name: -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. same trick as -endline: this is what lets a text widget show only a portion of a bigger piece of text 👑

and once again, instead of an integer, you can pass the empty string to this config option, which configures the widget to start at the very first line in the textual data store 💅

---

🎀 -state / state / State

Command-Line Name: -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 sitting right in the widget. so rude but so effective 💀

---

🌈 -tabs / tabs / Tabs

Command-Line Name: -tabs Database Name: tabs Database Class: Tabs

specifies a set of tab stops for the window. the option's value is a list of screen distances giving the positions of the tab stops, and each one is a distance relative to the left edge of the widget (not counting borders, padding, etc). each position may optionally be followed, in the next list element, by one of these keywords:

• left — the text after the tab character gets positioned with its left edge at the tab position
• right — the right edge of the text after the tab character gets positioned at the tab position
• center — the text is centered at the tab position
• numeric — the decimal point in the text is positioned at the tab position. if there's no decimal point, then the least significant digit of the number is positioned just to the left of the tab position. and if there's no number in the text at all, then the text is right-justified at the tab position

left is the default, fyi ✨

example time, bestie, look:

-tabs {2c left 4c 6c center}

that creates three tab stops at two-centimeter intervals. the first two use left justification and the third uses center justification. slay 🎀

🌸 more tab lore: if the list of tab stops doesn't have enough elements to cover all 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. also — tab distances must be strictly positive, and must always increase from one tab stop to the next. if they don't, an error is thrown 💀

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

if no -tabs option is specified, or if it's specified as an empty list, then Tk uses default tabs spaced every eight (average size) characters. and if you want a different standard spacing — say, every 4 characters — just configure the widget like this:

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

periodt 💅

---

🫶 -tabstyle / tabStyle / TabStyle

Command-Line Name: -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 either tabular (that's 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 is associated with the n'th tab stop defined for that line. and if the tab character's x coordinate falls to the right of the n'th tab stop, then a gap of a single space is inserted as a fallback 🙈

if the tab style is wordprocessor, then any tab character being laid out uses (and is defined by) the first tab stop to the right of the preceding characters already laid out on that line ✨

and yep, the value of the -tabstyle option may be overridden by -tabstyle options in tags 💖

---

👑 -undo / undo / Undo

Command-Line Name: -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 whole option, but it's kind of a big deal 🔥

---

🌟 -width / width / Width

Command-Line Name: -width Database Name: width Database Class: Width

specifies the desired width for the window, in units of characters in the font that the -font option gives you. and if that font doesn't have a uniform width? then the width of the character "0" is used when translating from character units to screen units. iconic choice, tbh 🎀

---

🌈 -wrap / wrap / Wrap

Command-Line Name: -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:

• none — each line of text appears as exactly one line on the screen. extra characters that don't fit on the screen just... aren't displayed 🙈
• char — each line of text gets broken up into several screen lines if necessary, to keep all the characters visible, and a screen line break may occur after any character
• word — same idea (breaking lines up to keep everything visible), but a line break will only be made at word boundaries ✨

---

that's it for this part bestie, but we're not done — more of text(3tk) is coming your way, so stay tuned 💖✨

💖 DESCRIPTION 💖

okay bestie, here's the tea: the text command pops a brand new window into existence — the one you name with the pathName argument — and turns it into a text widget. iconic behavior honestly. you can also hand it extra options (the ones we already spilled about up above 👆) either on the command line or in the option database, and those configure the lil' details like the default background color and the relief. and then? the text command hands you back the path name of the new window. that's it, that's the return value, no cap. 🫶

so what does a text widget do, you ask? it shows off one or more lines of text, and — the best part — it lets you edit that text. main character energy fr fr. ✨

and here's where it gets spicy: text widgets support four different kinds of annotations on the text. four!! a whole squad of them:

• tags — these let different portions of the text show up with different fonts and colors 🌈. and it doesn't stop there, because you can hook Tcl commands onto tags too, so scripts get invoked when stuff happens — keystrokes, mouse button presses, all of it — but only in the particular ranges of text you tagged. so specific, so slay. peep the TAGS section down below for the full scoop.
• marks — these are floating markers in the text, literally called “marks”. their whole job is keeping track of interesting positions in the text while it's getting edited around them. ngb (never getting lost) 💅. more deets in MARKS below.
• embedded windows — this one lets you embed arbitrary windows right into a text widget. windows inside text?? yeah. revolutionary. go read EMBEDDED WINDOWS below.
• embedded images — and this one lets Tk images take up residence inside a text widget too 🎀. EMBEDDED IMAGES below has everything you need.

oh and bestie, there's MORE. the text widget comes with a built-in undo/redo mechanism, like it was born with it 😌. THE UNDO MECHANISM below is where that story lives.

and finally — as if all of that wasn't enough — the text widget lets you create peer widgets. these are other text widgets that share the exact same underlying data (text, marks, tags, images, etc). same soul, different body, iykyk. 🦋 check PEER WIDGETS below for the details.

---

🔮 INDICES 🔮 — pointing at exactly the right spot

okay so bestie, SO many of the text widget commands take one or more indices as arguments. An index is just a string that says "this exact place in the text, right here", like where to drop characters or one end of a range you're about to delete. The syntax is:

base modifier modifier modifier ...

base gives you the starting point, and the modifiers nudge the index from there (move forward a char, backward a char, whatever). Every single index must have a base, but the modifiers are totally optional. Most modifiers (all documented below 💖) let you tack on an optional submodifier. The valid submodifiers are any and display. If you abbreviate a submodifier, it has to be followed by whitespace — but otherwise there need be no space at all between the submodifier and the modifier after it. Typically display adjusts the meaning of the following modifier so it refers to visual or non-elided units instead of logical units, but each case gets explained below, iykyk.

And lastly: wherever count shows up as part of a modifier, it can be positive or negative, so base - -3 lines is perfectly valid (and it's equivalent to base +3lines 🌈).

the base forms 🎀

The base for an index has to be one of these:

• line.char — 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 — the character that covers the pixel whose x and y coordinates within the text's window are x and y.
• end — the end of the text (the character just after the last newline).
• mark — the character just after the mark whose name is mark (see MARKS for details 👀).
• tag.first — the first character in the text that's been tagged with tag. This form generates an error if no characters are currently tagged with tag 😭.
• tag.last — the character just after the last one in the text that's been tagged with tag. This form generates an error if no characters are currently tagged with tag 😭.
• pathName — 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 — 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 a base could match more than one of the forms above — like a mark and an imageName both having the same value, messy 😵‍💫 — then the form that appears earlier in the list takes precedence. Iconic, we love a strict hierarchy.

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.

the modifiers 💅

• + count ?submodifier? chars — nudge the index forward by count characters, moving to later lines in the text if it has to. If there are fewer than count characters in the text after the current index, then the index gets set 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 you give neither submodifier 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're encouraged to use indices instead wherever possible 🙏.
• - count ?submodifier? chars — nudge the index backward by count characters, moving to earlier lines in the text if it has to. If there are fewer than count characters in the text before the current index, then the index gets set 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 you give neither submodifier 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're encouraged to use indices instead wherever possible 🙏.
• + count ?submodifier? indices — nudge the index forward by count index positions, moving to later lines in the text if it has to. If there are fewer than count index positions in the text after the current index, then the index gets set to the last index position in the text. Spaces on either side of count are optional. Quick reminder that an index position is either a single character or a single embedded image or an embedded window. If display is given, elided indices are skipped over without being counted. If any is given, then all indices are counted — and that's also the default behaviour when no modifier is given ✨.
• - count ?submodifier? indices — nudge the index backward by count index positions, moving to earlier lines in the text if it has to. If there are fewer than count index positions in the text before the current index, then the index gets set to the first index position (1.0) in the text. Spaces on either side of count are optional. If display is given, elided indices are skipped over without being counted. If any is given, then all indices are counted — also the default behaviour when no modifier is given ✨.
• + count ?submodifier? lines — nudge the index forward by count lines while keeping the same character position within the line. If there are fewer than count lines after the line containing the current index, then the index gets set to the same character position on the last line of the text. Then, if that line isn't long enough to contain a character at the indicated character position, the character position gets adjusted to refer to the last character of the line (the newline). Spaces on either side of count are optional. If display is given, then each visual display line is counted separately. Otherwise, if any (or no modifier at all) is given, then each logical line counts just once, no matter how many times it's visually wrapped. If the relevant lines aren't wrapped, these two counting methods are equivalent 🫶.
• - count ?submodifier? lines — nudge the index backward by count logical lines while keeping the same character position within the line. If there are fewer than count lines before the line containing the current index, then the index gets set to the same character position on the first line of the text. Then, if that line isn't long enough to contain a character at the indicated character position, the character position gets adjusted to refer to the last character of the line (the newline). Spaces on either side of count are optional. If display is given, then each visual display line is counted separately. Otherwise, if any (or no modifier at all) is given, then each logical line counts just once, no matter how many times it's visually wrapped. If the relevant lines aren't wrapped, these two counting methods are equivalent 🫶.
• ?submodifier? linestart — move the index to the first index on the line. With the display submodifier this is the first index on the display line; otherwise it's the first index on the logical line.
• ?submodifier? lineend — move the index to the last index on the line (the newline). With the display submodifier this is the last index on the display line; otherwise it's the last index on the logical line.
• ?submodifier? wordstart — move the index to the first character of the word containing the current index. A word is any number of adjacent characters that are letters, digits, or underscores — or a single character that isn't one of those. If display is given, this only examines non-elided characters; otherwise all characters (elided or not) are examined.
• ?submodifier? wordend — move the index 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 display 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 get 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 that 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 🌟.

heads up bestie: 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. no cap.

---

🏷️ TAGS 🏷️

The first form of annotation in text widgets is a tag. A tag is a textual string that's associated with some of the characters in a text. Tags may contain arbitrary characters, but it's probably best to avoid the characters " " (space), +, or - — those 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. And an individual character may have any number of tags associated with it. it's giving "everyone gets a sticker" 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. 💅

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 🎀

• -background color — color is giving 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 is a bitmap 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. (so if you're not sure, it just goes solid, nbd 💅)
• -borderwidth pixels — pixels is 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 duo, fr fr 🫶
• -elide boolean — boolean says 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. Yes bestie, it's literally still there, just invisible — ghost mode 👻
• -fgstipple bitmap — bitmap is a bitmap 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. 🔤
• -foreground color — color is 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. (yes, each line — the vibe check happens per display line 👑)
• -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. Two options, two jobs, no overlap 💖
• -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. Wrapped lines said "us too" 😭
• -lmargincolor color — color is 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 real ✨
• -offset pixels — pixels is 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. ⬆️⬇️ iconic
• -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.
• -overstrikefg color — color is 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 is 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. (that's the manpage's own wording, bestie, we don't touch it 🫶)
• -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 is 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 is 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. 💖
• -selectforeground color — color is 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. Headroom only, babe ⬆️
• -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. Not me pointing out that yes, the manpage really does say -tags there — we keep it exactly as written, no cap 💯
• -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). Pick your fighter: spreadsheet girlie or essay girlie 📝
• -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 is 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 said "I'm the main character now" 👑

---

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. 🦋

Read that again bestie: empty string ≠ "use nothing cute", it means this tag isn't even in the running for that option. The next tag down gets its moment, and if nobody claims it, the widget default takes over. Periodt. 💅

okay so the SECOND thing tags are for? event bindings 💖 You can tie bindings to a tag basically the same way you'd tie them to a widget class — whenever particular X events happen on characters that carry the given tag, a given Tcl command gets executed. Tag bindings are how you give behaviors to whole ranges of characters, and lowkey that's the whole trick behind hypertext-like features. Wanna know the deets? Go read the description of the pathName tag bind widget command further down this page, iykyk. Also super important: tag bindings are shared between all peer widgets — including any bindings you set on the special sel tag. 👑

And the THIRD thing tags do? They manage the selection, bestie. That's a whole section — see THE SELECTION below. 🌸 And here's the tea: with the exception of the special sel tag, all tags are shared between peer text widgets, and you can manipulate them on an equal basis from any one of those widgets. The sel tag is different though — it lives separately and independently in each peer text widget. (But heads up 🙈 any tag bindings to sel are still shared.)

---

🌸 MARKS 🌸

The second form of annotation in text widgets is a mark. Marks are for remembering particular places in a text — like a little bookmark but make it precise. They're kind of like tags in that they have names, and they refer to places in the file... but that's where the similarity stops, because a mark is not associated with particular characters. Nope! A mark is associated with the gap between two characters. Only a single position may be associated with a mark at any given time. 💅

And here's the resilient part: if the characters around a mark get deleted, the mark still remains — it just has new neighbor characters now, slay. In contrast, if the characters containing a tag are deleted, then that tag no longer has an association with characters in the file. Bye tag. 💀

Marks may be manipulated with the pathName mark widget command, and you can figure out where they currently are 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 literally just: what happens to the mark when text gets inserted at the point of the mark?

• If a mark has left gravity, the mark is treated as if it were 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).

The gravity for a mark defaults to right. ⭐

Oh and 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, but they'll refer to different things. Not confusing at all, bestie, we stay unbothered. 💅

Two marks have special significance:

1. The mark insert is associated with the insertion cursor — as described under THE INSERTION CURSOR below. 🖱️
2. The mark current is associated with the character closest to the mouse, and it adjusts itself automatically to track the mouse position and any changes to the text in the widget. (One exception 🙈: current is not updated in response to mouse motions while a mouse button is down — the update gets deferred until all mouse buttons have been released.)

Neither of these special marks may be deleted. 🚫 Just... no.

And except for those two special marks, all marks are shared between peer text widgets, and may be manipulated on an equal basis from any peer. Periodt.

---

🪟 EMBEDDED WINDOWS 🪟

The third form of annotation in text widgets is an embedded window. Each embedded window annotation makes a window get displayed at a particular point in the text. You can have any number of embedded windows in a text widget — literally as many as you want, no cap — and any widget may 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. ✨)

The embedded window's position on the screen updates as the text is modified or scrolled, and it gets mapped and unmapped as it moves into and out of the visible area of the text widget. Each embedded window occupies one unit's worth of index space in the text widget, and you can refer to it either by the name of its embedded window or by its position in the widget's index space.

Now the drama 😭: if the range of text containing the embedded window is deleted, then the window is destroyed. Similarly, if the text widget as a whole is deleted, then the window is destroyed. It's giving consequences.

More elision tea, because this part matters: 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. 🫶

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

✨ -align where

If the window is not as tall as the line in which it's displayed, this option decides where the window sits in that line. where must be one of these values:

• 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.
• baseline — align the bottom of the window with the baseline of the line.

✨ -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 will be 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 will be performed in script before evaluation:

• %W will be substituted by the name of the parent text widget.
• %% will be substituted by a single %.

And if the annotation's window should ever be deleted, script will be evaluated again the next time the annotation is displayed. Iconic behavior tbh.

✨ -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. 🎀

✨ -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. 🎀

✨ -stretch boolean

If the requested height of the embedded window is less than the height of the line in which it's displayed, this option lets you say 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 will be retained even if the window is stretched. Slay.

✨ -window pathName

Specifies the name of a window to display in the annotation. But listen 👀 — note that 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 will remove 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 you want embedded windows in each peer. 🦋

🖼️ EMBEDDED IMAGES 🖼️

so the last lil flavor of annotation in text widgets is the embedded image, and bestie it's exactly what it sounds like. every embedded image annotation makes an image show up at one specific spot in the text. and you can have as many embedded images as you want in a single text widget — plus the same image can be embedded in multiple places inside the same widget. iconic behavior honestly. 👑

where that image sits on the screen updates itself as the text gets modified or scrolled, no cap. every embedded image eats up one unit's worth of index space in the text widget, and you can point at it either by its position in the widget's index space, or by the name it got assigned when you inserted it with pathName image create. and if the range of text holding that embedded image gets deleted? that copy of the image gets removed from the screen. gone. 💀

okay here's a niche situation that will absolutely bite you if you don't know it. if you elide an embedded image immediately right after scheduling it for creation via pathName image create index -create, that stops it from effectively being created. 💅 but — uneliding an elided embedded image that was scheduled for creation via pathName image create index -create will automatically trigger the associated creation script for you, bestie, it's got you. 🫶 and after you destroy an elided embedded image, that one won't get automatically recreated. so. keep that in mind.

now, when you add an embedded image to a text widget with the pathName image create widget command, you get back a name that's unique to this instance of the image. that name is what you use to refer to this image instance, and it's taken to be the value of the -name option (described below, patience babes ✨). if you didn't hand over a -name, then the -image name gets used instead. and if the imageName is already taken inside the text widget, then #nn gets tacked onto the end of the imageName, where nn is some arbitrary integer — that's how it guarantees the imageName is unique, periodt. once the name is assigned to this instance of the image it does not change, even if -image or -name get changed later with pathName image configure.

and when an embedded image gets added with the pathName image create widget command, a whole bunch of configuration options can ride along with it. you can change them later with the pathName image configure widget command. here's everything currently supported, no gatekeeping:

• -align where — if the image isn't as tall as the line it's sitting in, this decides where in the line the image shows up. where has to be one of: top (lines up the top of the image with the top of the line), center (centers the image within the range of the line), bottom (lines up the bottom of the image with the bottom of the line's area), or baseline (lines up the bottom of the image with the baseline of the line). pick your fighter. 🌈
• -image image — names the Tk image to display in the annotation. if image isn't a valid Tk image, then you get an error back. rude but fair.
• -name ImageName — the name this image instance can be referenced by inside the text widget. if ImageName isn't supplied, the name of the Tk image gets used instead. and if the imageName is already in use, #nn gets appended to the end of the name, same as described above. 💅
• -padx pixels — Pixels is the amount of extra space to leave on each side of the embedded image. it can take any of the usual forms defined for a screen distance.
• -pady pixels — Pixels is the amount of extra space to leave on the top and on the bottom of the embedded image. same deal, any of the usual forms defined for a screen distance.

---

✨ THE SELECTION ✨

selection support is implemented via tags, bestie. if the -exportselection option on the text widget is true, then the sel tag gets associated with the selection, and here's the whole lore:

1. whenever characters get tagged with sel, the text widget will claim ownership of the selection.
2. attempts to retrieve the selection get serviced by the text widget, which returns all the characters carrying the sel tag.
3. if the selection gets claimed away by another application, or by another window in this same application, then the sel tag gets removed from every character in the text. 😭
4. whenever the sel tag range changes, a virtual event <<Selection>> is generated. it might also be generated when the selection is affected but not actually changed. and further — multiple selection changes could happen before events can even be processed, which leads to multiple events with the same visible selection. yeah. 🙈

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 (nope, not even then). on top of that, the -selectbackground, -selectborderwidth, and -selectforeground options for the text widget are tied to the -background, -borderwidth, and -foreground options for the sel tag — change one and it's automatically reflected in the other, they're literally linked. also the -inactiveselectbackground option for the text widget gets used instead of -selectbackground when the text widget doesn't have the focus. this gives you programmatic control over how the sel tag is visualized for foreground and background windows, or lets you have sel not shown at all for background windows (that's when -inactiveselectbackground is empty). and each peer text widget has its own sel tag which can be separately configured and set. slay. 🎀

---

🦋 THE INSERTION CURSOR 🦋

the mark named insert is special in text widgets, main character energy fr. it gets 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 that insertion cursor will automatically be drawn at this point whenever the text widget has the input focus. she's always ready. 💅

---

⭐ THE MODIFIED FLAG ⭐

the text widget can keep track of changes to its content by means of the modified flag. inserting or deleting text will set that flag. and you can also query it, set it, and clear it programmatically. whenever the flag changes state, a <<Modified>> virtual event gets generated. for the deets, go peep the pathName edit modified widget command. 🔥

---

💜 THE UNDO MECHANISM 💜

the text widget has an unlimited undo and redo mechanism (when the -undo widget option is true) that records every single insert and delete action on a stack. every. single. one.

boundaries — called separators — get inserted between edit actions. their whole purpose is to group inserts, deletes and replaces into one compound edit action. so when you undo a change, everything between two separators gets undone. the undone changes then get moved over to the redo stack, so an undone edit can be redone again. the redo stack gets cleared whenever new edit actions are recorded on the undo stack. and you can clear both the undo and redo stacks to keep their depth under control. 🧚

separators get inserted automatically when the -autoseparators widget option is true. you can also insert them programmatically, no problem. but heads up: if a separator is already sitting at the top of the undo stack, no other one will be inserted. which means two separators on the undo stack are always separated by at least one insert or delete action. always. 💯

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. so undoing or redoing changes can take a modified text widget back to the unmodified state, or the other way around. the modified flag gets set automatically to the appropriate state for you. but — and this is the important bit — that automatic coupling does not work when the modified flag has been set by the user, not until the flag has been reset again. don't forget that part bestie. 😭

for the pathName edit widget command that controls the undo mechanism, look below. 👇

---

🫶 PEER WIDGETS 🫶

the text widget keeps a separate store of all its data about each line's textual contents, marks, tags, images and windows, plus the undo stack.

and while this data store can't be accessed directly (like, without a text widget acting as the middleman), you can create multiple text widgets where each one presents a different view of the very same underlying data. those are known as peer text widgets, and it's giving shared custody but make it cute. 💅

as text gets added, deleted, edited and coloured in any one widget, and as images, marks and tags get adjusted, all such changes are reflected in all peers. everything shares.

all data and markup is shared, except for a few small details. let's list them because they matter:

• first, the sel tag may be set and configured (in its display style) differently for each peer.
• second, each peer has its own insert and current mark positions — but all other marks are shared.
• third, embedded windows, which are arbitrary other widgets, cannot be shared between peers. which means the -window option of embedded windows is independently set for each peer. (it's advisable to use the -create script capabilities so each peer can create its own embedded windows as needed.)
• fourth, all of the configuration options of each peer (like -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 escaping that one. 🔥

finally, 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 (like, only lines 52 through 125) — that lets a peer contain just a small portion of the overall text. the range of lines will expand and contract as text is inserted or deleted. and the peer will only ever display complete lines of text (you cannot share just part of a line, sorry bestie, no half-lines).

now here's the sad part: if the peer's contents contract down to nothing (i.e. all complete lines in the peer widget got deleted from another widget), then it becomes impossible for new lines to be inserted. 😭 the peer just becomes an empty shell where you can configure the background, but it will never show any content — not without manual reconfiguration of the start and end lines. also note that a peer which doesn't contain all of the underlying data store still has indices numbered from 1.0 to end. it's just that those indices reflect a subset of the total data, and data outside the contained range isn't accessible to the peer. which means the command peerName index end may return pretty different values in different peers. same energy: commands like peerName tag ranges won't return index ranges outside of what's meaningful to the peer. and the configuration options -startline and -endline are how you control how much of the underlying data is contained in any given text widget. 💖

also, real talk: peers are really peers. deleting the "original" text widget will not cause any other peers to be deleted, or otherwise affected. she's independent, she's thriving. 👑

for the pathName peer widget command that controls the creation of peer widgets, look below. 👇

✨ ASYNCHRONOUS UPDATE OF LINE HEIGHTS ✨

okay so bestie, real talk 💅 — the text widget calculates its line metrics (that's line heights, in pixels btw) asynchronously, because it is obsessed with keeping your user-experience responsive. Which is iconic of it, truly. But it also means some commands of the text widget can hand you wrong results if those asynchronous calculations aren't finished at the time of calling 👀. This applies to pathName count -ypixels and pathName yview.

And like, again, for performance reasons 🏃‍♀️ it would not be appropriate to let these commands always wait for the end of the update calculation every single time they get called. In most use cases of these commands, a more-or-less-inaccurate result genuinely doesn't matter compared to execution speed. fr fr.

But when you do need an accurate result (and only if the text widget is managed by a geometry manager), you can resort to pathName sync and pathName pendingsync to control the synchronization of the view of text widgets. slay.

The <<WidgetViewSync>> virtual event fires when the line heights of the text widget become obsolete (because of some editing command or configuration change), and then it fires again when the internal data of the text widget is back in sync with the widget view. The detail field (that's the %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. periodt.

Examples of use, bestie, take notes 📝:

## 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]
}

---

🌸 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. no cap 💅

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.

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.
• -lines — count all logical lines (irrespective of wrapping) from the line of the first index up to, but not including the line of the second index. Therefore if they are both on the same line, zero will be returned. Logical lines are counted whether they are currently visible (non-elided) or not.
• -xpixels — count the number of horizontal pixels from the first pixel of the first index to (but not including) the first pixel of the second index. 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 — count 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 ...?

okay so bestie, this is THE deletion command, the one where you say bye-bye to a range of characters. If you give it both index1 and index2, it deletes everything starting at index1 and stopping just before index2 — so the character sitting at index2 is not deleted, she survives, she's safe. 🫶

But if index2 doesn't point somewhere later in the text than index1, then literally nothing gets deleted. Nothing. Zero. And if you don't specify index2 at all? Then just the single character at index1 gets yeeted into the void. 💀

Now here's the ✨tricky✨ part: any attempt to delete characters in a way that would leave the text without a newline as its last character gets tweaked by the text widget to avoid that situation. Specifically, deleting 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 gets replaced by the new final newline of the text widget. The command returns an empty string, periodt.

And if you pass more indices? Multiple ranges of text get deleted. All indices are checked for validity first, before any deletions happen at all — no half-finished chaos. Then they get sorted, and the text is removed from the last range to the first range, so the deleted text doesn't cause any undesired index-shifting side-effects. Iconic behavior tbh.

• If multiple ranges with the same start index show up, the longest range is the one that's used. bye to the short one. 🙈
• If you give overlapping ranges, they get merged into spans that don't cause deletion of text outside the given ranges due to text shifted during deletion.

---

🌸 pathName dlineinfo index

This one returns a list with five elements describing the area occupied by the display line containing index. Let's break down the lineup, bestie:

1. the x coordinate of the upper-left corner of the area occupied by the line
2. the y coordinate of the upper-left corner of that area
3. the width of the area
4. the height of the area
5. the position of the baseline for the line, measured down from the top of the area

All of this info is measured in pixels, no cap.

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 occupied by characters and embedded windows.

And if the display line containing index is not visible on the screen? Then the return value is an empty list. She's not there, she can't be measured, we move on. 🦋

---

🎀 pathName dump ?switches? index1 ?index2?

This returns the contents of the text widget from index1 up to, but not including index2 — and it's not just the text, it's the whole vibe: text, marks, tags, and embedded windows too. If index2 isn't specified, it defaults to one character past index1.

The info comes back in this exact 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 — and the index information is the index of the start of the text, mark, tag transition, image or window.

One or more of these switches (or abbreviations thereof) can 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 info as the result of the dump operation, invoke command on each element of the text widget within the range. The command has three arguments appended to it before it's evaluated: the key, the value, and the 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. no cap.
• -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 that case an empty string is returned, and you have to 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 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 isn't 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. fresh start, clean slate, we love a reset. 🧚

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 ...?

Return a range of characters from the text, bestie. The return value will be all the characters in the text starting with the one whose index is index1 and ending just before the one whose index is index2 (the character at index2 will not be returned, she stays home). If index2 is omitted then the single character at index1 is returned.

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 an empty string is returned. And if the specified range contains embedded windows, no information about them is included in the returned string.

If multiple index pairs are given, multiple ranges of text will be returned in a list. Invalid ranges will not be represented with empty strings in the list. The ranges are returned in the order passed to pathName get. 👑

If the -displaychars option is given, then, within each range, only those characters which are not elided will be returned. This may have the effect that some of the returned ranges are empty strings. yep, that's allowed.

---

💜 pathName image option ?arg ...?

This command is used to manipulate embedded images. The behavior depends on the option argument that follows the image argument. The following forms of the command are currently supported:

pathName image cget index option

Returns the value of a configuration option for an embedded image. Index identifies the embedded image, and option specifies a particular configuration option, which must be one of the ones listed in the section EMBEDDED IMAGES.

pathName image configure index ?option value ...?

Query or modify the configuration options for an embedded image.

• If no option is specified, returns a list describing all of the available options for the embedded image at index (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 option(s) to have the given value(s); in this case the command returns an empty string.

See EMBEDDED IMAGES for information on the options that are supported.

pathName image create index ?option value ...?

This command creates a new image annotation, which will appear in the text at the position given by index. Any number of option-value pairs may be specified to configure the annotation. Returns a unique identifier that may be used as an index to refer to this image. See EMBEDDED IMAGES for information on the options that are supported, and a description of the identifier returned.

pathName image names

Returns a list whose elements are the names of all image instances currently embedded in window. every single one, all the girlies. 🌈

🫶 pathName index index

okay so bestie, you hand it an index and it hands you back the position in the form line.char — that's line = the line number, char = the character number. And index can be literally any of the forms described up in INDICES, go wild. 💅

---

✨ pathName insert index chars ?tagList chars tagList ...?

inserts all of the chars arguments right before the character sitting at index. 🌸

tiny plot twist tho: if index points to the very end of the text — aka the character after the last newline — then nah, the new text goes in just before the last newline instead. 🙈

now the tag tea ☕:

• one 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. But if a tag is on only one of those two chars, it does not get applied to the new text. picky but fair.
• tagList specified? then it's a list of tag names, and the new characters get all the tags in that list and no others — completely ignoring whatever tags are hanging around the insertion point. main character behavior, no outside influence. 💅
• multiple chars-tagList pairs? it does the exact same thing as if you'd issued a separate pathName insert widget command for each pair, in order. one at a time, queued up. ⭐

The last tagList argument may be omitted.

---

🎀 pathName mark option ?arg ...?

this one is for manipulating marks 🏷️ and what it actually does depends on the option that follows the mark argument. these are the forms it supports rn:

pathName mark gravity markName ?direction?

no direction given? it returns left or right to tell you which of its adjacent characters markName is attached to. 👀

direction given? it has to be left or right, and the gravity of markName gets set to that value. periodt.

pathName mark names

returns a list, and the elements are the names of all the marks currently set. slay.

pathName mark next index

returns the name of the next mark at or after index.

• if index came in numerical form, the search for the next mark begins at that index.
• if index is the name of a mark, then the search begins immediately after that mark.

and yes it can still return a mark at the same position if there are multiple marks at the same index. these semantics mean you can use mark next to step through every single mark in a text widget in the same order as the mark info returned by the pathName dump operation. 🦋

if a mark has been set to the special end index, then it appears to be after end as far as pathName mark next is concerned. An empty string is returned if there are no marks after index.

pathName mark previous index

returns the name of the mark at or before index.

• if index is specified in numerical form, then the search for the previous mark begins with the character just before that index.
• if index is the name of a mark, then the search for the next mark begins immediately before that mark.

yeah it can still return a mark at the same position if there are multiple marks at the same index — same vibe as next. these semantics mean pathName mark previous can step through all the marks in a text widget in the reverse order as the mark information returned by the pathName dump operation. 🔥

An empty string is returned 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 position; if it doesn't exist, a brand new mark is created. 👑

This command returns an empty string.

pathName mark unset markName ?markName markName ...?

removes the mark corresponding to each of the markName arguments. the removed marks will not be usable in indices and will not be returned by future calls to pathName mark names. gone, deleted, no crumbs. 💀

This command returns an empty string.

---

🧚 pathName peer option args

this command creates and queries widget peers. two forms, depends 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, iykyk). by default the peer has the same start and end line as the parent widget, but you can override that with the standard configuration options. ✨

pathName peer names

returns a list of peers of this widget (and no, it does not include the widget itself, rude as that is). The order within this list is undefined. 🙈

---

💜 pathName pendingsync

returns 1 if the line heights calculations are not up-to-date, and 0 otherwise. a little vibe check for your line heights. ✅

---

🌈 pathName replace index1 index2 chars ?tagList chars tagList ...?

replaces the whole range of characters between index1 and index2 with the given characters and tags. 🌸

see the section on pathName insert for how the tagList... arguments are handled, and the section on pathName delete for how the indices are handled. and bestie, listen: if index2 corresponds to an index earlier in the text than index1, an error will be generated. ⚠️

The deletion and insertion are arranged so that no unnecessary scrolling of the window or movement of insertion cursor occurs. In addition the undo/redo stack are correctly modified, if undo operations are active in the text widget. 🎯

The command returns an empty string.

---

🍓 pathName scan option args

this implements scanning on texts. two forms, depending on option:

pathName scan mark x y

records x and y and the current view in the text window, for use with later pathName scan dragto commands. typically you'd wire this up to a mouse button press in the widget. It returns an empty string. 🖱️

pathName scan dragto x y

computes the difference between its x and y arguments and the x and y arguments from the last pathName scan mark command for the widget. then it adjusts the view by 10 times the difference in coordinates. 🔥 typically this gets tied to mouse motion events in the widget, so you get that effect of dragging the text at high speed through the window. the return value is an empty string.

---

🔍 pathName search ?switches? pattern index ?stopIndex?

searches the text in pathName starting at index for a range of characters that matches pattern. if a match is found, the index of the first character in the match is returned as the result; otherwise you get an empty string. 😭

one or more of these switches (or abbreviations of them) can control the search:

• -forwards — the search proceeds forward through the text, finding the first matching range starting at or after the position given by index. this is the default. ➡️
• -backwards — the search proceeds backward through the text, finding the matching range closest to index whose first character is before index (it is not allowed to be at index). heads up tho: for a variety of reasons, backwards searches can be substantially slower than forwards searches (especially when using -regexp), so it is recommended that performance-critical code use forward searches. 🐌
• -exact — use exact matching: the characters in the matching range must be identical to those in pattern. this is the default. 🎯
• -regexp — treat pattern as a regular expression and match it against the text using the rules for regular expressions (see the regexp command and the re_syntax page for details). the default matching automatically passes both the -lineanchor and -linestop options to the regexp engine (unless -nolinestop is used), so that ^$ match beginning and end of line, and ., [^ sequences will never match the newline character \n. 🧠
• -nolinestop — this allows . and [^ sequences to match the newline character \n, which they will otherwise not do (see the regexp command for details). this option is only meaningful if -regexp is also given, and an error will be thrown otherwise. ⚠️ for example, to match the entire text, use pathName search -nolinestop -regexp ".*" 1.0.
• -nocase — ignore case differences between the pattern and the text. 💅
• -count varName — the argument following -count gives the name of a variable; if a match is found, the number of index positions between beginning and end of the matching range will be stored in the 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. In either case, the range matchIdx to matchIdx + $count chars will return the entire matched text. 🎀

---

• -all — okay so this one finds every single match in the range you gave it, and returns a list of the indices of the first character of each match. If a -count varName switch is given, then varName gets set to a list containing one element for each successful match 🫶. ⚠️ but bestie, note that 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. So like, 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.
• -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 behaviour so that all matches which are not totally enclosed within another match are returned 💅. Example time: applying an -overlap search of the pattern \w+ against hello there will just match twice (i.e. no different to just -all, literally), but matching Z[a-z]+Z against ZooZooZoo will now match twice. An error will be thrown if this switch is used without -all — so don't do that 🙈.
• -strictlimits — normally, when you do any search, the start and stop limits are checked with respect to the start of the matching text. With the -strictlimits flag, the entire matching range must lie inside the start and stop limits specified for the match to be valid. stricter! iconique! 👑
• -elide — find elided (hidden) text as well. By default only displayed text is searched, so this is your "show me the secret stuff" button ✨.
• -- — 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 -. no cap 🎀.

---

The matching range may be within a single line of text, or run across multiple lines (if parts of the pattern can match a new-line). For regular expression matching one can use the various newline-matching features such as $ 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 at that index: 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 will be searched: when the beginning or end of the text is reached, the search continues at the other end until the starting location is reached again; if stopIndex is specified, no wrap-around will occur 🔄. Which means that, for example, if the search is -forwards but stopIndex is earlier in the text than startIndex, nothing will ever be found 💀. See KNOWN BUGS below for a number of minor limitations of the pathName search command.

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 nothing, chill. 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. If index is far out of view, then the command centers index in the window. main character energy, honestly 💅.

pathName sync ?-command command?

Controls the synchronization of the view of the text widget.

• pathName sync — immediately brings the line metrics up-to-date by forcing computation of any outdated line heights. The command returns immediately if there is no such outdated line heights, otherwise it returns only at the end of the computation. The command 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. bgerror is called on command failure.

pathName tag option ?arg ...?

This command is used to manipulate tags 🏷️. The exact behavior of the command depends on the option argument that follows the tag argument. The following forms of the command are currently supported:

• 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 (the character at index2 is not tagged, okay, just-before, pay attention 🫶). A single command may contain any number of index1-index2 pairs. If the last index2 is omitted then the single character at index1 is tagged. 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. nothing happens, no drama.
• 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. If all arguments are specified then a new binding is created, replacing any existing binding for the same sequence and tagName (if the first character of script is + then script augments an existing binding rather than replacing it). 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 (an error occurs if there is 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 only events for which bindings may be specified are those related to the mouse and keyboard (such as Enter, Leave, Button, Motion, and Key) or virtual events. Mouse and keyboard event bindings for a text widget respectively use the current and insert marks described under MARKS above. An Enter event triggers for a tag when the tag first becomes present on the current character, and a Leave event triggers for a tag when it ceases to be present on the current character. Enter and Leave events can happen either because the current mark moved or because the character at that position changed. Note that these events are different than Enter and Leave events for windows 🪟. Mouse events are directed to the current character, while keyboard events are directed to the insert character. If a virtual event is used in a binding, that binding can trigger only if the virtual event is defined by an underlying mouse-related or keyboard-related event.

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 occurs, 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 (see the manual entry for the bind command for details). continue and break commands within binding scripts are processed in the same way as for bindings created with the bind command.

If bindings are created for the widget as a whole using the bind command, then those bindings will supplement the tag bindings. The tag bindings will be invoked first, followed by bindings for the window as a whole. order matters bestie 🎀.

• pathName tag cget tagName option — this command returns the current value of the option named option associated with the tag given by tagName. Option may have any of the values accepted by the pathName tag configure widget command.
• pathName tag configure tagName ?option? ?value? ?option value ...? — this command is similar to the pathName configure widget command except that it modifies options associated with the tag given by tagName instead of modifying options for the overall text widget. If no option is specified, the command returns a list describing all of the available options for tagName (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 option(s) to have the given value(s) in tagName; in this case the command returns an empty string. See TAGS above for details on the options available for tags ✨.
• pathName tag delete tagName ?tagName ...? — deletes all tag information for each of the tagName arguments. The command removes the tags from all characters in the file and also deletes any other information associated with the tags, such as bindings and display information. The command returns an empty string. gone, deleted, never happened 💀✨.
• pathName tag lower tagName ?belowThis? — the priority glow-down ✨. This nudges tag tagName so it sits just lower in priority than the tag called belowThis. If you ghost belowThis entirely, then tagName gets yeeted all the way down to the lowest priority of all tags. Bottom of the pile, no cap.
• pathName tag names ?index? — hands you a list whose elements are the names of every tag that's active at the character position you give as index. Leave index off and you get the whole roster: every tag that exists for the text, which includes all tags that were named in a pathName tag widget command but never deleted by a pathName tag delete widget command — even the ones where literally zero characters are currently marked with the tag rn 💀. The list comes back sorted from lowest priority to highest priority. Order matters, bestie.
• pathName tag nextrange tagName index1 ?index2? — searching era 🔍. It hunts through 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. Heads up: a range that starts at index2 does not count. If multiple matching ranges exist, the first one wins. 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. No match? You get an empty string, sorry babe 😭. If index2 isn't given, it defaults to the end of the text.
• pathName tag prevrange tagName index1 ?index2? — same energy, opposite direction 🦋. 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 (and yes, a range starting at index2 is considered here — different rules than nextrange, don't mix them up 💅). 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 nothing matches, the return value is an empty string. If index2 isn't given then it defaults to the beginning of the text.
• pathName tag raise tagName ?aboveThis? — the priority glow-up 👑. Changes the priority of tag tagName so it's just higher in priority than the tag named aboveThis. Omit aboveThis and tagName becomes the highest priority of all tags. Main character energy, honestly.
• pathName tag ranges tagName — returns a list describing all the ranges of text tagged with tagName. First two elements describe the first tagged range in the text, next two describe the second range, and so on forever and ever 🌈. The first element of each pair is the index of the first character of the range, and the second element of the pair is the index of the character just after the last one in the range. If no characters are tagged with the tag, you get an empty string back.
• pathName tag remove tagName index1 ?index2 index1 index2 ...? — untagging time 🧹. Removes the tag tagName from all the characters starting at index1 and ending just before index2 (the character at index2 is not affected, okay?). A single command can hold any number of index1-index2 pairs — go off. If the last index2 is omitted, the tag gets removed from just the single character at index1. If there are no characters in the specified range (like, index1 is past the end of the file, or index2 is less than or equal to index1), then the command does absolutely nothing. This command returns an empty string.

---

pathName window option ?arg ...?

This one is for manipulating embedded windows 🪟✨. What it actually does depends on the option argument that comes right after the window argument. These are the forms that 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 names one specific configuration option, which has to be one of the ones listed in the EMBEDDED WINDOWS section. No improvisation, bestie.
• pathName window configure index ?option value ...? — query or modify the configuration options for an embedded window. Give it no option at all and it returns a list describing every available option for the embedded window at index (peep Tk_ConfigureInfo if you wanna know the format of that list). Give it an option with no value and it returns a list describing that one named option — that list will be identical to the corresponding 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 hold those value(s), and in that case the command returns an empty string. See EMBEDDED WINDOWS for what options are supported.
• pathName window create index ?option value ...? — creates a brand new window annotation, which shows up 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.
• pathName window names — returns a list whose elements are the names of all windows currently embedded in the window. The whole squad 💖.

---

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 these forms:

• pathName xview — returns a list containing two elements. Each element is a real fraction between 0 and 1, and together they describe the portion of the document's horizontal span that's visible in the window. Example: first element .2, second element .6 — that means 20% of the text is off-screen to the left, the middle 40% is visible in the window, and 40% is off-screen to the right 🎀. Important: the fractions refer only to the lines that are actually visible in the window. So if every line in the window is super short and entirely visible, you get back 0 and 1 even if there are other lines in the text that are way 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 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 given in any of the forms acceptable to Tk_GetPixels, like 2.0c or 1i (and the result gets rounded to the nearest integer value — if no units are given, pixels are assumed 😌). If what is pages, the view adjusts by number screenfuls; if it's pixels, the view adjusts by number pixels; if it's 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's positive then characters farther to the right become visible.

---

pathName yview ?args?

The vertical twin 🦋 — queries and changes the vertical position of the text in the widget's window. Forms go like this:

• pathName yview — returns a list with 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 (so 0.5 means it's 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. Same values that get passed to scrollbars via the -yscrollcommand option 💅.
• pathName yview moveto fraction — adjusts the view so 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 means the first pixel of the first character in the text, 0.33 means the pixel one-third of the way through the text, and so on. Values close to 1 indicate values close to the last pixel in the text — and yeah, 1 technically refers to one pixel beyond the last pixel 🙈 — but in those cases the widget will never scroll beyond the last pixel, so a value of 1 effectively gets rounded back to whatever fraction keeps the last pixel at the bottom of the window, with some other pixel at the top. It just refuses to go past the edge, periodt.

pathName yview scroll number what

okay so this one slides the view up or down in the window based on number and what, bestie. what HAS to be one of pages, pixels, or units — no other vibes allowed. If what is units or pages, then number must be an integer, no exceptions. Otherwise number can be anything Tk_GetPixels will accept, like “2.0c” or “1i” (and yeah, the result gets rounded to the nearest integer, and if you give no units at all, pixels are just assumed 💅).

So like — if what is units, the view moves up or down by number lines on the display. If it's pages, the view moves by number screenfuls. If it's pixels, the view moves by number pixels. Negative number? Earlier positions in the text become visible. Positive number? Later positions become visible. That's the whole deal ✨.

pathName yview ?-pickplace? index

This changes the view in the widget's window so that index is visible. If you don't pass -pickplace, then index just shows up at the top of the window, simple as that. But if -pickplace IS specified, the widget gets to choose where index lands in the window — main character energy, honestly:

1. If index is already visible somewhere in the window, the command does literally nothing. Obsessed with the efficiency 🫶.
2. If index is only a few lines off-screen above the window, it gets positioned at the top of the window.
3. If index is only a few lines off-screen below the window, it gets positioned at the bottom of the window.
4. Otherwise? index gets centered in the window. Boom, symmetric.

heads up bestie — the -pickplace option has been obsoleted by the pathName see widget command. And here's why: pathName see handles both x- and y-motion to make a location visible, whereas the -pickplace mode only handles motion in y. So like, it's giving half the range. Use see 💖

pathName yview number

This command 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, no negotiating. This command used to be used for scrolling, but now it is obsolete — it's a legacy queen, we still respect her, we just don't call her anymore 😭.

---

🎀 BINDINGS 🎀

Tk automatically creates class bindings for texts that give them the following default behavior. And because nothing in Tk is ever simple, in the descriptions below, “word” depends on the value of the tcl_wordchars variable. See tclvars(3tcl) if you wanna go read up on that 🌸.

1. Clicking mouse button 1 positions the insertion cursor at the closest edge of the character underneath the mouse cursor, sets the input focus to this widget, and clears any selection in the widget. Dragging with mouse button 1 strokes out a selection between the insertion cursor and the character under the mouse. ✨
2. Double-clicking with mouse button 1 selects the word under the mouse and positions the insertion cursor at the start of the word. Dragging after a double click will stroke out a selection consisting of whole words.
3. Triple-clicking with mouse button 1 selects the line under the mouse and positions the insertion cursor at the start of the line. Dragging after a triple click will stroke out a selection consisting of whole lines.
4. The ends of the selection can be adjusted by dragging with mouse button 1 while the Shift key is down; this will adjust the end of the selection that was nearest to the mouse cursor when button 1 was pressed. If the button is double-clicked before dragging then the selection will be adjusted in units of whole words; if it is triple-clicked then the selection will be adjusted in units of whole lines.
5. Clicking mouse button 1 with the Control key down will reposition the insertion cursor without affecting the selection. No harm, no foul, cursor just moves 🦋.
6. If any normal printing characters are typed, they are inserted at the point of the insertion cursor.
7. The view in the widget can be adjusted by dragging with the middle mouse button (button 2, or button 3 in TkAqua). If the middle mouse button is clicked without moving the mouse, the selection is copied into the text at the position of the mouse cursor. The Insert key also inserts the selection, but at the position of the insertion cursor. Yes, it's picky about where, we stan consistency 💅.
8. If the mouse is dragged out of the widget while button 1 is pressed, the entry will automatically scroll to make more text visible (if there is more text off-screen on the side where the mouse left the window).
9. The Left and Right keys move the insertion cursor one character to the left or right; they also clear any selection in the text. If Left or Right is typed with the Shift key down, then the insertion cursor moves and the selection is extended to include the new character. Control+Left and Control+Right move the insertion cursor by words, and Control+Shift+Left and Control+Shift+Right move the insertion cursor by words and also extend the selection. Control+b and Control+f behave the same as Left and Right, respectively. Meta+b and Meta+f behave the same as Control+Left and Control+Right, respectively. So many routes to the same place and honestly, iconic 🧚
10. The Up and Down keys move the insertion cursor one line up or down and clear any selection in the text. If Up or Right is typed with the Shift key down, then the insertion cursor moves and the selection is extended to include the new character. Control+Up and Control+Down move the insertion cursor by paragraphs (groups of lines separated by blank lines), and Control+Shift+Up and Control+Shift+Down move the insertion cursor by paragraphs and also extend the selection. Control+p and Control+n behave the same as Up and Down, respectively.
11. The Next and Prior keys move the insertion cursor forward or backwards by one screenful and clear any selection in the text. If the Shift key is held down while Next or Prior is typed, then the selection is extended to include the new character.
12. Control+Next and Control+Prior scroll the view right or left by one page without moving the insertion cursor or affecting the selection. Cursor stays put, selection stays put, only the view slides — very demure, very mindful 🫶
13. Home and Control+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 also extends the selection to that point.
14. End and Control+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. Control+Home and Meta+< move the insertion cursor to the beginning of the text and clear any selection in the widget. Control+Shift+Home moves the insertion cursor to the beginning of the text and also extends the selection to that point.
16. Control+End and Meta+> move the insertion cursor to the end of the text and clear any selection in the widget. Control+Shift+End moves the cursor to the end of the text and extends the selection to that point.
17. The Select key and Control+Space set the selection anchor to the position of the insertion cursor. They do not affect the current selection. Shift+Select and Control+Shift+Space adjust the selection to the current position of the insertion cursor, selecting from the anchor to the insertion cursor if there was not any selection previously.
18. Control+/ selects the entire contents of the widget. All of it. Every last character. Slay 👑
19. Control+\ clears any selection in the widget.
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 Control+w copies the selection in the widget to the clipboard and deletes the selection. This action is carried out by the command tk_textCut. If there is no selection in the widget then these keys have no effect — pressing them into the void does nothing 😭
22. The F18 key (labelled Paste on many Sun workstations) or Control+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 is no selection, it deletes the character to the right of the insertion cursor.
24. Backspace and Control+h delete the selection, if there is one in the widget. If there is no selection, they delete the character to the left of the insertion cursor.
25. Control+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. Control+k deletes from the insertion cursor to the end of its line; if the insertion cursor is already at the end of a line, then Control+k deletes the newline character.
28. Control+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, we love a stationary queen 💜
29. Meta+Backspace and Meta+Delete delete the word to the left of the insertion cursor.
30. Control+t reverses the order of the two characters to the right of the insertion cursor.
31. Control+x deletes whatever is selected in the text widget after copying it to the clipboard.
32. Control+z undoes the last edit action if the -undo option is true. Does nothing otherwise. (No -undo, no take-backs, that's the rule 🙈)
33. Control+Z (or Control+y on Windows) reapplies the last undone edit action if the -undo option is true. Does nothing otherwise. Yes, it's the redo. Yes, the keybinding overlap with #22 is real. No, we don't make the rules 💀

---

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. So it's like — readable, scrollable, selectable, but absolutely not taking edits. It's giving "look but don't touch" 🎀

The behavior of texts can be changed by defining new bindings for individual widgets or by redefining the class bindings. Go off, bestie, customize it 🌈

😭 KNOWN ISSUES 😭

Okay bestie, this is the part where the manual keeps it real and tells you what’s still a little cursed. No shade, just tea.

---

🧚 ISSUES CONCERNING CHARS AND INDICES 🧚

Before Tk 8.5, the widget used the string chars to refer to index positions (which included characters, embedded windows and embedded images). As of Tk 8.5 the text widget deals separately and correctly with chars and indices. For backwards compatibility, however, the index modifiers +N chars and -N chars continue to refer to indices. You must use any of the full forms +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.

TL;DR: +N chars is lowkey not “N characters” in the way your brain wants it to be. Use the full any chars form if you mean actual character indices. 💅

---

🔥 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.

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.

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 avoid this.

Heads up: if your cursor blink is causing graphics traffic like it’s running a whole influencer campaign, setting -insertofftime to 0 is the vibe. ✨

---

🐛 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.

Not me reading these examples like a thriller 💀 Regexp search across lines is giving “mostly iconic but sometimes messy,” and these are the exact cases where it gets a lil wrong.

---

👀 SEE ALSO 👀

• entry(3tk)
• scrollbar(3tk)

---

🔑 KEYWORDS 🔑

• text
• widget
• tkvars

---

Source/version/date tea, bestie: this page is from Tk, version 8.5, page text(3tk), and the footer didn’t print a separate date line — so that’s the whole vibe. Go slay your text widget, you absolute icon 💅✨🦋