Allow the attributes for a cell to be computed. #22

New Issue

glen · 2019-07-25T05:33:34Z

glen commented

2019-07-25 05:33:34 +00:00

Right now, each cell individually stores its attributes and although they can be set in a block, they cannot change based on the contents of cells, nor is there a way to update the format that's used for a certain purpose other than finding all of the cells and setting the attributes on each.

It would be very helpful to have computed and/or linked attributes. It seems to me that a teapot-ish way to do this would be to have an additional expression for the computed attribute, and when it is set, then when the attributes are needed, the expression is evaluated. If it resolves to a location, then the attributes of the cell at that location are used. Ideally that would have the effect that changing the attributes of that location would instantly cause all of the linked cells to change.

The only other alternative I hae thought of is to make Attribute objects another data type, and stop including attribute info in every cell, and anything that's not default has an associated attribute object, and have functions in the expression language that can create attributes, but there still has to be a way to set the attribute-generating expression for a cell, so it's not clear what one gains by this route which will surely be more effort. Maybe some amount of memory savings as the possible palette of attributes expands.

In any case, it would be good to implement some system.

Right now, each cell individually stores its attributes and although they can be set in a block, they cannot change based on the contents of cells, nor is there a way to update the format that's used for a certain purpose other than finding all of the cells and setting the attributes on each. It would be very helpful to have computed and/or linked attributes. It seems to me that a teapot-ish way to do this would be to have an additional expression for the computed attribute, and when it is set, then when the attributes are needed, the expression is evaluated. If it resolves to a location, then the attributes of the cell at that location are used. Ideally that would have the effect that changing the attributes of that location would instantly cause all of the linked cells to change. The only other alternative I hae thought of is to make Attribute objects another data type, and stop including attribute info in every cell, and anything that's not default has an associated attribute object, and have functions in the expression language that can create attributes, but there still has to be a way to set the attribute-generating expression for a cell, so it's not clear what one gains by this route which will surely be more effort. Maybe some amount of memory savings as the possible palette of attributes expands. In any case, it would be good to implement some system.

glen added the

enhancement

label 2019-07-25 05:33:34 +00:00

glen referenced this issue from a commit

2019-09-09 14:38:58 +00:00

Alleviate compile warnings on Linux and finalize programmable styles This change gets teapot to compile without warnings on OpenSUSE Tumbleweed with the extended warnings flags that were recently added. It also represents a more thoroughly (but not exhaustively) tested and debugged version of the expression-controlled style settings from an earlier commit. The facility should be ready for use. It also adds a better pretty-printer for Token values in gdb and extensive edits to the documentation. It fixes a bug in max/min introduced by the addition of the Bool type and the switchover to comparisons returning Bool. It modifies the display of values too long to fit in their cells to show an initial segment of their contents with a continuation mark rather than obscuring the contents completely. Closes #54. Closes #55. Closes #44. Closes #22. Closes #13.

glen closed this issue

2019-09-09 14:38:58 +00:00

Sign in to join this conversation.