Re: c.executeScript() - revision 551016a5 (vitalije 2017-07-13 23:09:37) broke several of my programs

2017-07-18 Thread SegundoBob
On Tuesday, July 18, 2017 at 1:02:25 PM UTC-7, Edward K. Ream wrote: > > > I apologize for the inconvenience. > > Rev 911001d reverts 551016a. I have just reopened#439: execute-script > should execute unselected code between @language directives >

Re: PHP colorizer mode

2017-07-18 Thread Adrian
Hi Edward, I know this is a small thing, but did you get a chance to look at what I might be able to do to fix this? On Sunday, July 9, 2017 at 10:38:50 AM UTC-5, Adrian wrote: > > Thanks! > > On Sunday, July 9, 2017 at 10:34:16 AM UTC-5, Edward K. Ream wrote: >> >> On Sun, Jul 9,

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

2017-07-18 Thread Edward K. Ream
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

2017-07-18 Thread vitalije
> > 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: c.executeScript() - revision 551016a5 (vitalije 2017-07-13 23:09:37) broke several of my programs

2017-07-18 Thread Edward K. Ream
On Tue, Jul 18, 2017 at 2:21 PM, SegundoBob wrote: > I use c.executeScript() in several programs. Revision 551016a5 by > vitalije broke them. > ​Thanks for this report. I apologize for the inconvenience. I have been aware of this change but have not gotten around to

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

2017-07-18 Thread Edward K. Ream
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: New backend for Leo Cacher

2017-07-18 Thread Edward K. Ream
On Tue, Jul 18, 2017 at 2:22 PM, Terry Brown wrote: > On Mon, 17 Jul 2017 11:05:51 -0700 (PDT) > vitalije wrote: > > > Fixed at 8d6a7ab. My fault, sorry about that. Recently, I have > > switched to Python3, and now I am making Python2 crashers. > >

Re: New backend for Leo Cacher

2017-07-18 Thread Terry Brown
On Mon, 17 Jul 2017 11:05:51 -0700 (PDT) vitalije wrote: > Fixed at 8d6a7ab. My fault, sorry about that. Recently, I have > switched to Python3, and now I am making Python2 crashers. I've switched SQLITE = True in three Leo installs and not seen any problems since 8d6a7ab.

c.executeScript() - revision 551016a5 (vitalije 2017-07-13 23:09:37) broke several of my programs

2017-07-18 Thread SegundoBob
I use c.executeScript() in several programs. Revision 551016a5 by vitalije broke them. I am using c.executeScript() to execute a node body that begins with "@language python" yet I get the ""no script selected" error message in the log pane. I have not yet looked into g.getScript(), but if

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

2017-07-18 Thread vitalije
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

2017-07-18 Thread vitalije
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

2017-07-18 Thread vitalije
> > > 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

2017-07-18 Thread Edward K. Ream
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

2017-07-18 Thread Edward K. Ream
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

2017-07-18 Thread Terry Brown
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

2017-07-18 Thread Edward K. Ream
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

2017-07-18 Thread vitalije
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

2017-07-18 Thread vitalije
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

2017-07-18 Thread Edward K. Ream
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

2017-07-18 Thread Edward K. Ream
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

2017-07-18 Thread Terry Brown
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

2017-07-18 Thread Edward K. Ream
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

Re: Leo now displays trailing whitespace.....

2017-07-18 Thread Josef
On Wednesday, 12 July 2017 10:52:36 UTC+2, Edward K. Ream wrote: > > ​Thanks for all this work. I'll probably just stick with the > show-invisibles command​. I can see the results of that command clearly, > and I won't start obsessing about trailing whitespace ;-) > > > The show-invisibles

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

2017-07-18 Thread Edward K. Ream
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

Re: Is it possible to add time in log pane?

2017-07-18 Thread zhaohe wang
It works fine. Thanks! 在 2017年7月18日星期二 UTC+8下午7:17:06,Edward K. Ream写道: > > On Tuesday, July 18, 2017 at 5:00:26 AM UTC-5, Edward K. Ream wrote: > > See #531: Optionally report timestamp when issuing file-related messages >> >> > > Rev

Re: Is it possible to add time in log pane?

2017-07-18 Thread Edward K. Ream
On Tuesday, July 18, 2017 at 5:00:26 AM UTC-5, Edward K. Ream wrote: See #531: Optionally report timestamp when issuing file-related messages > > Rev 3806c39

Re: How does instant update work in Pharo?

2017-07-18 Thread Edward K. Ream
On Monday, July 17, 2017 at 4:03:27 PM UTC-5, Edward K. Ream wrote: > [imp.reload(g) crashes Leo...Imo this is *not* a real bug in c.executeScriptHelper, or leoGlobals.py or anywhere else. It just means that one dasn't reload the leoGlobals module Two more observations: 1. imp.reload *can*

Re: Is it possible to add time in log pane?

2017-07-18 Thread Edward K. Ream
On Mon, Jul 17, 2017 at 5:02 PM, Terry Brown wrote: ​​ > 07:31:20 wrote: base.py > 07:31:20 wrote: test_views.py > 07:31:20 saved: joyroost.leo > 07:38:20 wrote: test_views.py > 07:38:20 saved: joyroost.leo > 07:42:18 wrote: test_views.py > 07:42:18 saved: joyroost.leo >

Re: Is it possible to add time in log pane?

2017-07-18 Thread zhaohe wang
Good job, I want it! 在 2017年7月18日星期二 UTC+8上午6:03:00,Terry Brown写道: > > On Mon, 17 Jul 2017 16:07:36 -0500 > "Edward K. Ream" wrote: > > > On Mon, Jul 17, 2017 at 3:42 PM, Terry Brown > > > wrote: ​ > > > ​ > > it would take up a bunch of scree > >