This looks like a fairly long list for a 1.3.1 Getting rid of the excess debug/info output to the terminal, so that you can find errors in it more easily is my priority 1 feature need, and feels like a 1.3.1 kind of change.
Next would be avoiding the jumping back and forth between enclosing elements and child elements is pretty important. Right now every other step jumps back to the enclosing parent element. Longer term I think one thing we should try to plan is for the editor or (hex/bits display) highlighting of bytes/bits to track the infoset when debugging. I.e., when parsing, placing cursor on a specific infoset element should display the bits corresponding to it in the editor (or hex/bits display), and vice versa. This will require a richer infoset representation that exposes this information for use by the GUI, as opposed to just dumping out XML that is then displayed. This will require a daffodil enhancement to have state maintain the start position and length (in bits) of every element in the infoset. Another important thing is refactoring the delimiter scanning logic in Daffodil such that it is exposed for the debugger to display - users should be able to step through every nuance of scanning for a delimiter - displaying the set of delimiters it is looking for, whether it found one and which or not, highlighting the data that was isolated by this, etc. In general, each lengthKind in DFDL could use specific GUI support - e.g., lengthKind prefixed should display the length that has been discovered, highlight that part of the data for you, then use it to extract the value. Each lengthKind has its own support needs to make it clear for the user what is happening (or going wrong) But we should start with delimiter scanning. On Fri, Jul 7, 2023 at 11:01 AM Davin Shearer <da...@apache.org> wrote: > Greetings Daffodil developers and users! > > > > As v1.3.0 of the Apache Daffodil Extension for VS Code has been officially > released, it’s time to plan the next release. > > > > Since v1.3.0 was a huge feature release compared to v1.2.0, I propose that > we do a smaller (e.g., v1.3.1) release *before *we jump into v1.4.0. This > allows for some recovery and implementation of some short-term, but > important improvements, to set the stage for a larger release to follow. > Since > 1.3.1 can be smaller in scope, let’s try to target a release for August > 2023, then a larger one (e.g., v1.4.0) targeted for the fall > (October/November). > > > > Some features that I think would be appropriate for the smaller v1.3.1 > release targeted for this summer would include: > > > > Data Editor: > > • Merge single and multi-byte modes so they don’t need to be > manually selected, for example, if one byte is selected, then the Data > Editor should be automatically in single byte mode, and if more than one > byte is selected, the Data Editor should automatically switch into > muti-byte editing mode. > > • Add support for large file editing in the Data Editor (e.g., > being able to scroll and search around in large files - > https://github.com/ctc-oss/daffodil-vscode/discussions/95). > > • Being able to persist selections *after *the viewport loses > focus. > > • Implement “Save As” in addition to “Save”. > > • Incremental Search and Replace (currently Replace All is > implemented). > > • Ability to have multiple simultaneous Data Editors opened > sharing the same backend server (currently only one Data Editor can be > opened at one time). > > • Ability to view and edit bytes represented in binary where the > most significant bit can be the first bit of the byte, or the last bit of > the byte. > > • Content-type discovery using Apache Tika. > > • Initial implementation of a data profiler. > > • Allow the values in the data inspector to be editable. > > • Have an “overwrite only” mode that will keep the file size the > same, even when performing operations like Search and Replace where the > token sizes aren’t the same. > > > > IntelliSense: > > • Add additional/missing attribute completion snippets. > > • Refine snippet suggestions for specific element tags. > > • Refine the handling of auto-complete closing tags for > multi-line attributes (attribute split on multiple lines). > > • Setup IntelliSense unit *test *infrastructure. > > • Add semantic highlighting for XPath expressions. > > > > Reply to this thread if there are any other reasonably-small features that > you would like to see implemented in v1.3.1 and/or thoughts about the > release scheduling proposed here. > > > > Work on many of these items is already underway since the release cycle > for v1.3.0 took 4 candidates before it was approved. The development > team is tracking progress on the next release here: > https://github.com/orgs/apache/projects/258/views/1. > > > Thank you! >
