You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, a JavaScript/CoffeeScript symbol definition can read neighboring cells via this.neighbor, but it cannot modify such symbols. It wouldn't make much sense to modify previously processed symbols (unless we want to force them to be reprocessed...), but it'd be useful for making a symbol that represents the top-left corner of a bigger graphic.
For example, consider this gadget diagram:
||
--AA--
--AA--
||
To make this work nicely, we can define A to be a gadget graphic that occupies a 2x2 grid of symbols (but has viewBox still set to a single grid cell), and then to replace with blanks the corresponding symbols, resulting in this effective input:
||
--A --
-- --
||
This would let natural ASCII art work with symbols that are larger than one grid cell.
Combined with neighbor reading, you could even make the A symbol depend on the erased symbols. For example:
||
--A2--
--LR--
||
In this case 2LR could be additional input to the A symbol, read via this.neighbor. It gets erased by A anyway so it's free space to provide information.
An issue with implementing this in the current SVG Tiler is that we currently load all symbols from mappings before we actually execute the dynamic symbol functions, so changing the key in the second stage wouldn't affect the already-run first stage. But perhaps we should instead evaluate and run each symbol together. Reasons why it matters:
Context provides symbol (a Symbol object, as opposed to key which is a string). I admit I didn't even remember that we provided this.
Currently, a JavaScript/CoffeeScript symbol definition can read neighboring cells via
this.neighbor
, but it cannot modify such symbols. It wouldn't make much sense to modify previously processed symbols (unless we want to force them to be reprocessed...), but it'd be useful for making a symbol that represents the top-left corner of a bigger graphic.For example, consider this gadget diagram:
To make this work nicely, we can define
A
to be a gadget graphic that occupies a 2x2 grid of symbols (but has viewBox still set to a single grid cell), and then to replace with blanks the corresponding symbols, resulting in this effective input:This would let natural ASCII art work with symbols that are larger than one grid cell.
Combined with neighbor reading, you could even make the
A
symbol depend on the erased symbols. For example:In this case
2LR
could be additional input to theA
symbol, read viathis.neighbor
. It gets erased byA
anyway so it's free space to provide information.An issue with implementing this in the current SVG Tiler is that we currently load all symbols from mappings before we actually execute the dynamic symbol functions, so changing the key in the second stage wouldn't affect the already-run first stage. But perhaps we should instead evaluate and run each symbol together. Reasons why it matters:
Context
providessymbol
(aSymbol
object, as opposed tokey
which is a string). I admit I didn't even remember that we provided this.Context
currently provides thekey
of dynamic symbols including version numbers. This actually seems like a bug (mentioned in Caching symbol expansions outside DynamicSymbol #50).The text was updated successfully, but these errors were encountered: