Ditta what Trevor said. Our new app has both binary and livecodescript stacks. In the beginning I was "sloppy" and named some of the script only stacks (libraries, models, behaviors) with extension only ".livecode" in short order there is massive confusion
a) about what can and cannot be opened in a text editor. b) about what can be diff'ed with the git compare tools and other "gotchas" "huh? How come that stack did not open? no window? Maybe it's off screen?" one in fact wonders why this was no enforce in the new model from the get go. It gets worse if you try to engage collaboration and the new person on the team has not been there on the ground floor. "Hmmm, should we maybe document which of these are binary and which are livecodescript files" So not only for your own LC team's sanity, but for the clarity of interface between Livecode and the rest of the languages world, Ditto what Trevor said. In fact, is there a case to be made to enforce this at the engine level? BR On 3/24/17, 1:00 PM, "use-livecode on behalf of Trevor DeVore via use-livecode" <use-livecode-boun...@lists.runrev.com on behalf of use-livecode@lists.runrev.com> wrote: If everyone who posts files to GitHub differentiates binary stacks from script only stacks using the extension then it will be helpful going forward. As part of the submission process you have to send a search to them that shows how often the language extension is used. A search that doesn't show binary files would need to be submitted so the search would filter by .livecodescript. _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode