22.3 Redisplay Piece by Piece

As you can begin to see redisplay is complex and also not well documented. Chuck no longer works on XEmacs so this section is my take on the workings of redisplay.

Redisplay happens in three phases:

1. Determine desired display in area that needs redisplay. Implemented by redisplay.c
2. Compare desired display with current display Implemented by redisplay-output.c
3. Output changes Implemented by redisplay-output.c, redisplay-x.c, redisplay-msw.c and redisplay-tty.c

Steps 1 and 2 are device-independent and relatively complex. Step 3 is mostly device-dependent.

Determining the desired display

Display attributes are stored in display_line structures. Each display_line consists of a set of display_block’s and each display_block contains a number of rune’s. Generally dynarr’s of display_line’s are held by each window representing the current display and the desired display.

The display_line structures are tightly tied to buffers which presents a problem for redisplay as this connection is bogus for the modeline. Hence the display_line generation routines are duplicated for generating the modeline. This means that the modeline display code has many bugs that the standard redisplay code does not.

The guts of display_line generation are in create_text_block, which creates a single display line for the desired locale. This incrementally parses the characters on the current line and generates redisplay structures for each.

Gutter redisplay is different. Because the data to display is stored in a string we cannot use create_text_block. Instead we use create_text_string_block which performs the same function as create_text_block but for strings. Many of the complexities of create_text_block to do with cursor handling and selective display have been removed.