My dominant emotion is relief :-) As my last post shows, @auto, no matter how improved, will not (and can not) replace @file for power, reliability and speed.
The @auto project seemed like a good idea at the time, but I have no regrets at killing it. The new @auto code is complex, buggy and inherently fragile. It could be endlessly "improved" without making it significantly more useful. I can no longer justify further work on the project. As always, Kent's comments have been an invaluable guide. It's important that he isn't likely to use the new features. There are several improvements that can and should be made: 1. Revising the importers so they are line-oriented rather than character oriented. This promises to make the JavaScript importer far more reliable than it is at present. 2. Associating uA's with imported nodes, as Kent requested. This can be done by adding a uA to the @auto node itself, as both Kent and Eric have suggested. If/when I get around to this, I'll use far simpler unl-resolution code. The unl's will only refer to imported nodes, not any additional organizer nodes. This moots the need to do *any* reorganization of the imported file: almost all the new @auto code will go away. 3. Improving the parse-body command. At present, this command inserts what is, in effect, the body text of an @auto node. This is easiest at the code level, but annoying for the user. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
