Massive spaces->tabs and trailing whitespace cleanup, hopefully for the last
time now I've configured emacs to make them displayed in really annoying
colours...
screen interactive programs to preserve the screen contents. When activated, it
saves a copy of the visible grid and disables scrolling into and resizing out
of the history; when deactivated the visible data is restored and the history
reenabled.
screen interactive programs to preserve the screen contents. When activated, it
saves a copy of the visible grid and disables scrolling into and resizing out
of the history; when deactivated the visible data is restored and the history
reenabled.
of characters which may be inserted or deleted is the screen width, not one
less (and similarly for lines and height); and if characters or lines are
deleted by moving the ones that follow, the space at the end needs to be
cleared.
This appears to solve long-standing redraw issues most visible when using the
force-width option then scrolling in view(1) or unwrapping lines in emacs.
of characters which may be inserted or deleted is the screen width, not one
less (and similarly for lines and height); and if characters or lines are
deleted by moving the ones that follow, the space at the end needs to be
cleared.
This appears to solve long-standing redraw issues most visible when using the
force-width option then scrolling in view(1) or unwrapping lines in emacs.
terminal to be switched between several different windows and programs
displayed on one terminal be detached from one terminal and moved to another.
ok deraadt pirofti
as UTF-8 in a separate array, the code does a lookup into this every time it
gets to a UTF-8 cell. Zero width characters are just appended onto the UTF-8
data for the previous cell. This also means that almost no bytes extra are
wasted non-Unicode data (yay).
Still some oddities, such as copy mode skips over wide characters in a strange
way, and the code could do with some tidying.
Split grid into two arrays, one containing grid attributes/flags/colours (keeps
the name grid_cell for now) and a separate with the character data (called
text). The text is stored as a u_short but is treated as a uint64_t elsewhere;
eventually the grid will have two arrays.
I'm not happy with the naming so that might change.
Still need to decide where to go from here. I'm not sure whether to combine
the peek/set functions together, and also whether to continue to treat the
text as a uint64_t (and convert to/from Unicode) or make it a char array
(of size one when UTF-8 disabled, eight when enabled) and keep everything
as UTF-8.
Also since UTF-8 will eventually become an attribute of the grid itself it
might be nice to move all the padding crap into grid.c.
Thomas Adam