structile 6.3.0__tar.gz → 6.8.0__tar.gz

{structile-6.3.0/structile.egg-info → structile-6.8.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: structile
-Version: 6.3.0
+Version: 6.8.0
 Summary: A spatial editor and diff tool for structured data, inline in Jupyter
 License-Expression: Apache-2.0
 Requires-Python: >=3.8

structile-6.8.0/VERSION

@@ -0,0 +1 @@
+6.8.0

{structile-6.3.0 → structile-6.8.0}/structile/dom_lite.js

@@ -25,6 +25,13 @@ function __structileBuildElement(node){
       return Object.prototype.hasOwnProperty.call(attrs, name) ? attrs[name] : null;
     },
     hasAttribute: function(name){ return Object.prototype.hasOwnProperty.call(attrs, name); },
+    // A real DOM Element's own attributes is a live NamedNodeMap, not a
+    // plain object — Object.keys(attrs) already works here (this module's
+    // own `attrs` IS a plain object) but wouldn't on a real DOM element, so
+    // an interpreter wanting attribute names on BOTH paths (e.g. one that
+    // treats a whole element's attribute set as a flat record) needs the
+    // one method both actually share: Element.getAttributeNames().
+    getAttributeNames: function(){ return Object.keys(attrs); },
     attributes: attrs,
     // Bare tag-name lookup only (no class/id/attribute selectors) — a depth-
     // first search of this element's own descendants, matching the one way
@@ -68,3 +75,18 @@ function __structileUnmarkSets(v){
   if (v && typeof v === "object"){ const o = {}; for (const k of Object.keys(v)) o[k] = __structileUnmarkSets(v[k]); return o; }
   return v;
 }
+// No-op stub — the real __structileTagSource (structile.html, near
+// parseMarkupWithSpans) records XML selection-sync provenance against a
+// REAL DOM node's __structileSpan, something this DOM-lite element never
+// has (no position tracking here at all, see the file banner above). This
+// module is loaded ahead of every interpreter script run through
+// run_interpreter_source (interpreters.py's select_interpreter/convert()
+// paths only — never anything selection-sync itself touches, since the
+// browser always re-runs interpretXML client-side for interactive
+// rendering), so a bundled interpreter calling __structileTagSource
+// unconditionally while building its value must still find SOMETHING by
+// that name here, or every such call throws a ReferenceError and breaks
+// candidate selection/convert() outright. Doing nothing is the correct
+// behavior, not a placeholder for a future real implementation — this
+// path has no raw source text to point a span at in the first place.
+function __structileTagSource(){}