On Tue, 18 Jul 2017 11:37:43 -0500 "Edward K. Ream" <[email protected]> wrote:
> On Tue, Jul 18, 2017 at 10:02 AM, Edward K. Ream <[email protected]> > wrote: > > To state my conclusion first: It would be intolerable to break > existing > > code *of which we have no knowledge*. That code might use > > v._bodyString *without* checking v._sync. > > > > ​Well, making v._bodyString a property would solve the compatibility > problem. There would be a substantial cost to using this property, so > it shouldn't be used in Leo's core or plugins. > > In the new scheme, v._bodyString would issue a warning for every > distinct set of g.callers(). I've used this pattern before. > > But perhaps all this should be a thought experiment, and we really > *can* live with v._bodyString as it is now. Please let me know your > thoughts. I'd thought of the property option too - that and the fact that v._bodyString starts with an underscore which is a clear indication you fiddle with it at your own risk would seem to make it reasonable to trial the v-lines branch. I'm not familiar enough with the relevant core code to know how valuable the addition is - splitting / joining the body string when required doesn't seem onerous enough to warrant the extra (admittedly well isolated) complexity, but if there are big payoffs in outline loading code, maybe it's worth doing. Cheers -Terry -- 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 https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
