* Allow pasting tuple elements with spaces
* Improve how tuples treat leading space / +
* Allow typing [] to truncate a tuple run
* Include a [] at the end of a stream during deep copy
SpriteDecorator wraps other formats, providing the extra behavior of having a sprite background. This can be used to draw a sprite behind a single cell or behind a group of cells.
To get the z-ordering right, the info from SpriteDecorator is read during a new RenderBackground method, which happens before RenderData.
* Move RunFactory to model, since it's not a viewmodel piece
* Rename compressed Sprite/Palette runs to remove naming collision.
* Make a subfolder for all the image-related runs and related types.
* Make a subfolder for all the factory strategies.
* Cleanup using statements
* Document Run information on the factory strategies.
* Sort tests folder a bit
These don't have any custom data formats yet. The thing they do have is an implementation of an interface: ISpriteRun and IPaletteRun. These will form the basis of interaction with a new tool, SpriteTool, similar to how IStreamRun interacts with TextTool and ITableRun interacts with TableTool.
LZData isn't too complex, but it does involve many types of tokens, and thus many formats.
(1) the magic 1-byte header
(2) the 2-byte compressed token
(3) the 1-byte uncompressed token. This is really just raw data, but isn't the same as `None` because it can't be freely converted to a pointer or a length-token and shouldn't have the "this is text" right-click menu items
(4) the 1-byte section header. This is also similar to raw data, but we probably want to display it in a different color to make it obvious that it's a section header and not just an uncompressed byte.
Adding this new data format required that we define its behaviors for lots of things. For now, we'll assume that the only valid thing the user can do with an end token is to extend the table.
change tracking was previously done in the model, but exposed in the ViewModel via a data format. The problem with this is that it meant that all changed formats were wrapped in a new format, which would require a lot of work to fully validate.
The new implementation is still in the model, but exposed in the ViewModel through a new property on the HexElement. The data formats are unchanged.
WordRuns, like PointerRuns, can live anywhere in the file and don't require anchors to them. Instead of needing an anchor to them, they specify the name of a table that they are matched to. Whenever that table's length changes, the WordRun's value is automatically updated to match the table length.
* code quality improvements
* fix a crash when backspacing egg formats
* fix a crash when backspacing all the way to empty
* fix data corruption when edit-exiting multi-byte formats
*
The Egg Move stream has 2 types of data in it, each of which is 2 bytes long. Either it's a pokemon, or it's a move. (There's also the end, FF FF). This is the initial test to show that we can read an egg move stream from a format.
