Re: ENB: I may reject or defer the v-lines branch

On Tue, Jul 18, 2017 at 3:14 PM, vitalije wrote: > > I suggest close #366 and mark it as "Won't Do". There are much more >> important projects we can work on. >> >> Well, until lines property gets any real case scenario to show if it can > give some substantial benefit, I

Re: ENB: I may reject or defer the v-lines branch

> > I suggest close #366 and mark it as "Won't Do". There are much more > important projects we can work on. > > Well, until lines property gets any real case scenario to show if it can give some substantial benefit, I must agree to close #366. Vitalije -- You received this message because

Re: ENB: I may reject or defer the v-lines branch

On Tue, Jul 18, 2017 at 12:58 PM, vitalije wrote: > One more idea. Possible places of getting out of sync are when user uses > some code outside Leo. > ​I appreciate your thoroughness. ​Imo, this item simply isn't worth the risk, including the risk of of subtle code

Re: ENB: I may reject or defer the v-lines branch

One more idea. Possible places of getting out of sync are when user uses some code outside Leo. If that external code is not aware of lines property it will never mess with it and it will never be broken by the presence of this property. The only way this external code can be hurt by this

Re: ENB: I may reject or defer the v-lines branch

On Tuesday, July 18, 2017 at 7:29:50 PM UTC+2, vitalije wrote: > > >> But doesn't this negate the supposed benefits of the lines property? It >> might even hurt performance. >> >> Yes it would hurt, but I believe it still can have some minor performance > advantage. It will be, however, gain

Re: ENB: I may reject or defer the v-lines branch

> > > But doesn't this negate the supposed benefits of the lines property? It > might even hurt performance. > > Yes it would hurt, but I believe it still can have some minor performance advantage. It will, however, be gain in readability and good step toward incorporating this new property.

Re: ENB: I may reject or defer the v-lines branch

On Tuesday, July 18, 2017 at 12:06:41 PM UTC-5, vitalije wrote: There are several possibilities for gently introduction of this property. > One would be to replace attribute `_bodyString` with yet another property > which when set directly can issue a warning to user and set the `_sync` >

Re: ENB: I may reject or defer the v-lines branch

On Tuesday, July 18, 2017 at 12:04:03 PM UTC-5, Edward K. Ream wrote: And I'm still unsure about the import code. > *First idea*: The import code should be fine. This is just a special case of the principle that code that doesn't use the v.lines property can use v._bodyString freely. *Second

Re: ENB: I may reject or defer the v-lines branch

On Tue, 18 Jul 2017 10:06:41 -0700 (PDT) vitalije wrote: > One question: Do we have somewhere examples of external files that > use all of Leo's directives that can be used for testing? If we don't > have it yet, is anybody willing to make or share such examples files > in

Re: ENB: I may reject or defer the v-lines branch

On Tuesday, July 18, 2017 at 12:10:12 PM UTC-5, vitalije wrote: > > Well, it seems while I was writing previous post, almost everything has > been already said. > Maybe, but I'm still glad you said it. Edward -- You received this message because you are subscribed to the Google Groups

Re: ENB: I may reject or defer the v-lines branch

Well, it seems while I was writing previous post, almost everything has been already said. -- 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

Re: ENB: I may reject or defer the v-lines branch

I am not sure what to think about this yet. I am in a middle of some experimenting/researching of reading and writing external files. The aim of my research is to make a good use of new v.lines property. Right now, I don't see great benefit of having it because in current Leo's code it is hard

Re: ENB: I may reject or defer the v-lines branch

On Tue, Jul 18, 2017 at 11:57 AM, Terry Brown wrote: 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

Re: ENB: I may reject or defer the v-lines branch

On Tuesday, July 18, 2017 at 11:37:45 AM UTC-5, Edward K. Ream wrote: ​Well, making v._bodyString a property would solve the compatibility > problem. > We already discussed this in #336. Vitalije correctly said this: > whoever uses

Re: ENB: I may reject or defer the v-lines branch

On Tue, 18 Jul 2017 11:37:43 -0500 "Edward K. Ream" wrote: > On Tue, Jul 18, 2017 at 10:02 AM, Edward K. Ream > wrote: > > To state my conclusion first: It would be intolerable to break > existing > > code *of which we have no knowledge*. That code

Re: ENB: I may reject or defer the v-lines branch

On Tue, Jul 18, 2017 at 10:02 AM, Edward K. Ream 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

ENB: I may reject or defer the v-lines branch

Rev 1cabf32 demonstrates, I think, that I now understand every changed line of the v-lines branch. This rev adds needed comments about what v._sync means. It also simplifies v.hasBody in a straightforward way. To state my conclusion first: It would be intolerable to break existing code *of