> - I don't think you need to allocate the gc with malloc, just put it > inside the wp directly and initialize it to grid_default_cell.
I do need to allocate it with malloc. If I don't, it's always there (not NULL), so it'll always have some value. That makes it impossible to tell what to do when wp->colgc == 8. Does that mean the pane's background should be the terminal default, or does that mean the user wanted this option unset, so that it takes the window's bg value? Note that wp->colgc does not always exist. It only exists (isn't NULL) if a user has explicitly set a color for a particular pane. Otherwise, it will be NULL, and the pane will get its color from the window, either w->apcolgc if the pane is the active pane and w->apcolgc isn't NULL, or just the window's default color (w->colgc), or the default terminal colors if w->colgc is NULL. > You shouldn't need to change tty_draw_line except to take > a struct window_pane argument. No, I need the loop in tty_draw_line to modify the cells it pulls from grid_view_peek to have the pane's default colors. Otherwise, after a redraw, the text on a pane will have the terminal's default colors, and just the EL would get the pane's defaults. > - I think the window colour can still be a window option but I would > drop it (or drop the pane colours and just do the window) for now and > add it as a separate change after one is working. Well, I suppose the window's color could be a window option. But the pane's color can't be, and it would be awkward for the active-pane's color to be one since it couldn't be a style. It'd have to be a string so you could set it to the empty string, otherwise it'd look like a style was always set. It seems odd to have different ways of setting the colors. > - I would drop get_wp_default_grid_colours in favour of a function in > tty.c that did something like: Your function would only work if someone had set an explicit color for the pane. And to get it to take the window's color and active-pane color into account would make it look much like get_wp_default_grid_colours. Based on what you've written, I wonder if you've got a different idea in mind on how setting a color works. Another way to do it (maybe what you had in mind?) would be to set the color for a pane when it is created. This way, a pane would always need wp->colgc, so it wouldn't make sense to malloc it. This could be updated when a user switches which pane is active, or explicitly sets a color. Also, if the pane stores its current color, you wouldn't have to figure it out with a function like get_wp_default_grid_colours. But you would need a flag to tell if the user had explicitly set the color or not, otherwise you wouldn't know if it was ok to update it when the window or active-pane colors were changed. Is that the model you had in mind? I think we have to make sure we're on the same page about this before I can proceed. ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
