On Wed, Aug 8, 2018 at 7:56 AM, Terry Brown wrote:
>
I see plugin load time and settings processing as separate issues, so
not really sure how these two relate...
They don't. This discussion has grown way beyond unit testing.
The main point is that caching settings has no chance.
Edward
--
On Wed, 8 Aug 2018 01:15:04 -0700 (PDT)
"Edward K. Ream" wrote:
> On Monday, August 6, 2018 at 9:34:56 PM UTC-5, Terry Brown wrote:
>
> There may be existing personal plugins that would break if plugins
> were
> > loaded after the outline was fully loaded, but then again it's
> > possible to
On Wednesday, August 8, 2018 at 3:15:05 AM UTC-5, Edward K. Ream wrote:
Alas, saving settings (no matter where), is a form of caching! This is a
> fatal flaw, because there is no guarantee that the *present* settings
> files are in the cache. For example, the cache won't contain
>
On Monday, August 6, 2018 at 9:34:56 PM UTC-5, Terry Brown wrote:
There may be existing personal plugins that would break if plugins were
> loaded after the outline was fully loaded, but then again it's possible
> to devise code that breaks in response to any change in Leo, it's
> impossible
On Tue, 7 Aug 2018 04:58:43 -0500
"Edward K. Ream" wrote:
> On Mon, Aug 6, 2018 at 9:34 PM, Terry Brown
> wrote:
>
> I don't think we should say plugin loading time shouldn't be changed
> to
> > reduce complexity, although that doesn't mean making such a change
> > is any kind or priority or
On Mon, Aug 6, 2018 at 9:34 PM, Terry Brown wrote:
I don't think we should say plugin loading time shouldn't be changed to
> reduce complexity, although that doesn't mean making such a change is
> any kind or priority or that it even needs to happen.
>
A good summary. Let's see the
On Mon, 6 Aug 2018 07:11:49 -0500
"Edward K. Ream" wrote:
> On Fri, Aug 3, 2018 at 10:56 AM, vitalije wrote:
>
> Plugins can affect the load process.
> >>
> >> Yes, I know they can. But do they do this?
>
> How should I know? People are free to create their own private
> plugins for special
On Fri, Aug 3, 2018 at 10:08 AM, Terry Brown wrote:
> Re gui layers etc., I've mentioned it before, but I wonder how using
> something like
> https://pythonhosted.org/blinker/
> would work, performance wise.
>
I don't think performance will be an issue.
Imo, something like this is worth
On Fri, Aug 3, 2018 at 10:56 AM, vitalije wrote:
Plugins can affect the load process.
>>
>> Yes, I know they can. But do they do this?
>
How should I know? People are free to create their own private plugins for
special purposes. In particular, plugins might want to monkey-patch Leo.
Edward
On Fri, Aug 3, 2018 at 10:56 AM, vitalije wrote:
My initial post on this thread was quite a long one, tackling many things
> at once. So is Edward's reply. I can't discuss ATM every Edward's point but
> I will focus just on the settings and plugins stuff. The other points are
> very well worth
My initial post on this thread was quite a long one, tackling many things
at once. So is Edward's reply. I can't discuss ATM every Edward's point but
I will focus just on the settings and plugins stuff. The other points are
very well worth discussing but let's skip them for now.
How do you
Re gui layers etc., I've mentioned it before, but I wonder how using
something like
https://pythonhosted.org/blinker/
would work, performance wise.
Imagine being able to say:
body_change = signal('body-change')
...
body_change.send('reformat', gnx=gnx, body=new_body)
and not needing to know /
On Mon, Jul 30, 2018 at 2:50 PM, vitalije wrote:
During the last two weeks I have felt at times being very stupid or more
> precisely doing stupid and unnecessary work. The only way I could force
> myself to continue this work is by telling myself over and over again that
> this is just
On Tuesday, July 31, 2018 at 4:53:36 AM UTC+2, Terry Brown wrote:
>
> I think going through so much of the Leo codebase as you have done in
> the last couple of weeks you've come up with something of a catalog of
> things that might benefit from different approaches, in some cases the
>
I think going through so much of the Leo codebase as you have done in
the last couple of weeks you've come up with something of a catalog of
things that might benefit from different approaches, in some cases the
benefit of hindsight, for that matter.
I can't put together a detailed response right
This thread is primarily intended for Leo developers. It might be long and
boring for other readers. So read it at your own risk.
If I had looked more thoroughly in unitTests.leo earlier I would never make
a proposition to incorporate new data model in Leo and make all unit tests
pass. I
16 matches
Mail list logo
