Re: ENB: Why I think keyword args are benign

[David Szent-Györgyi]

On Tuesday, April 24, 2018 at 8:38:37 AM UTC-4, Edward K. Ream wrote:
>
>
> It looks like json.dumps may have problems with p.v.unknownAttributes 
> fields.
>
> Again, not a gotcha, but something must be done.
>

Have you had time to look into AXON as a better-for-the-purpose alternative 
to JSON 
?  

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Non essential features are harmful (or not)

[Offray Vladimir Luna Cárdenas]

Thanks Vitalije, Edward and Terry for this discussion,

I can go into code details and so, maybe at that level your points are
valid. From the user experience, I would say that using trees to setup
themes is cumbersome (and preferences and to enable/disable plugins).
Maybe there is and important principle there, but exposing Leo potential
users to all this complexity (particularly the non-programmers) could
result in a lot of incidental complexity. Something with check boxes and
scrolling menus and options (like atom and tools alike) could help with
settings and plugins use and discovery and may simplify underlying code.

This thread reminds me of the 20K lines of code principle for human
understandability of software systems [1] and the Smalltalk culture of
fighting actively against incidental complexity (see [3], for example).
Of course this is not easy, but any discussion and action in this line
should be visible and supported.

[1] https://news.ycombinator.com/item?id=3291085
[2] http://www.vpri.org/pdf/tr2011004_steps11.pdf
[3] http://cuis-smalltalk.org/

Cheers,

Offray

On 27/04/18 13:53, vitalije wrote:
>
> Really?  What modules, classes, methods and functions trouble you?
>
> The actual design principle that I consciously follow /all the
> time/ is that modules and classes should hide all details about an
> easily understood /idea./ In other words, Leo's design is about
> making modules and classes completely independent from each
> other.  That's what makes Leo stable.  To the first approximation,
> nothing else matters, and certainly not details about kwargs.
>
>
> It's not about kwargs, but yes they have made me think and try to
> describe and define what is it that make things worse than they need
> to be. 
>
> If you really did follow the principle of hiding details and making
> classes and modules as much independent of each other many classes
> would look differently. For example one of the most basic element of
> Leo's data is certainly VNode. And yet one can not instantiate VNode
> class without acquiring full blown commander, which in VNode is known
> as context. In the comment of context attribute is explicitly declared
> that it is called context to indicate its limited usage. However this
> field is used not only as a holder of hiddenRootNode  but there is a
> method on VNode that knows about c.frame.body.wrapper and knows that
> c.frame.body.wrapper has setInsertPoint, setYScrollPosition...
> It also knows indirectly about c.fileCommands.gnxDict.
>
> Now, whichever module needs to access VNode class, can't just import
> leo.core.leoNodes and use it. It needs to acquire commander instance
> before.
>
> Recently, we discussed the copying and pasting outline. It delegates
> its task to fileCommands. FileCommands OTOH knows about
> c.frame.resizePaneToRatio, c.selectPosition, c.frame.initialRatios,
> c.atFileCommands.readAll, c.frame.body.onBodyChanged...
>
> It seems to me that copying and pasting outlines should belong just to
> VNode. I would expect that v instance knows best how to encode itself
> into a string, and to decode itself from string. There is no real need
> for v instance to know anything about c.fileCommands,
> c.atFileCommands, c.frame.body.wrapper ... You could say that
> fileCommands is designed to encode/decode vnodes. But why then it
> selects position, sets frame ratios ... If we want to extract
> encode/decode functionality from v in its own module, that's o.k. But
> extracted module in that case should be even lower level then vnode.
> It shouldn't know about any other functionality than VNode class. If
> fileCommands need to provide reading and saving Leo documents, then it
> would probably use the same low level helper module as Vnodes for
> encoding/decoding them from/to string. Additionally it may provide
> some gui related values like aspect ratios and selection. But it
> should not apply those values directly to c.frame.body.wrapper ... It
> should return those values to the commander and let the commander to
> apply those values (if it finds necessary to do so).
>
> I could write many more examples but these few would suffice to make
> my point clear. 
>
> ​Leo is a programming environment.  In principle, we don't know
> how people have /already used/ uA's.​
>  ​
>
>
> Exactly we don't know but we act as if we are certain that there are
> users who put in uA's some exotic data. IMO there was no need to
> introduce such level of flexibility before. Once upon a time there was
> no support for uA's at all. And then it was created based not on real
> user needs, but on the FNMW principle as flexible as possible no
> matter how expensive it may become. 
>
> Do not misunderstand me. I really don't mind using pickle as a format.
> My point is just that we need to be aware of costs it incurs, and at
> least to think about whether we have to pay the full price or we can
> live with the less flexible one. 
>
> Not a single 

Re: Scripting Leo - tutorial slide show. position p:

[lewis]

In the script, I used print rather than g.es
print(' '*p.level(),p.h)
and the output to a console window is correctly indented.

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Scripting Leo - tutorial slide show. position p:

[lewis]

I'm working through the slide tutorial scripting leo 
, and noticed 2 
issues.

1. Log output
I followed the script, running it on Leodocs and a small test file. On both 
LeoDocs and the test file, the output is flat (suggesting all nodes are 
level 0) not indented position p: 0 for top-level nodes, 1 for their 
children, as the tutorial states.

2. Performance 'Not responding'
Run the script on LeoDocs: after the log output completes, it hangs with a 
not responding for ~65seconds.

Regards
Lewis

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

New 5.7.2 branch, and schedule for 5.7.2

[Edward K. Ream]

I have just created the 5.7.2 branch containing the candidate code for Leo 
5.7.2.

For testing purposes, the 5.7.2 branch is equivalent to devel. The only 
changes to the 5.7.2 code base will be bug fixes, which will then be merged 
back into devel.  As a result, the devel branch remains open to further 
changes.

Bugs continue to be reported against the new key-handling code, so extended 
testing is necessary.

The new release date for Leo 5.7.2 is Friday, May 4.  That date will slip 
further if more key-related or caching bugs appear.

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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: keys2 branch merged into devel

[Edward K. Ream]

On Fri, Apr 27, 2018 at 10:24 PM, lewis  wrote:

> I'm seeing weird backspace behaviour in headline.
>

​Fixed at a4182a5d2.  This was a recent bug, not directly related to
key-handling.

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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: keys2 branch merged into devel

[Terry Brown]

On Fri, 27 Apr 2018 20:24:47 -0700 (PDT)
lewis  wrote:

> I'm seeing weird backspace behaviour in headline. 
> Create a node test1. Use backspace to delete characters from the
> headline. Backspace deletes fine if you start from eol.
> 
> Place cursor before 'test1' and proceed to backspace. When you reach
> the beginning of the node it pastes 'test1' into the headline. It
> then copies the new headline and pastes it with each press.
> Same behaviour if you place cursor anywhere before the eol.
> 
> Backspace is working as expected in node body text.
> 
> Regards
> Lewis

Just in case it helps I noticed that Ctrl-A backspace didn't seem to
work to clear the log, as it used to.  Trivial workaround Ctrl-A delete
instead, but just mentioning in case it's diagnostic for Lewis's issue.

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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: LeoU: Formal code review of vnode class

[vitalije]

O.k. No more complains from me.
Vitalije

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Non essential features are harmful (or not)

[Edward K. Ream]

On Fri, Apr 27, 2018 at 1:53 PM, vitalije  wrote:

> Really?  What modules, classes, methods and functions trouble you?
>>
>> It's not about kwargs, but yes they have made me think and try to
> describe and define what is it that make things worse than they need to be.
>

​I've responded in full detail in this new thread
.

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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

LeoU: Formal code review of vnode class

[Edward K. Ream]

This post will be pre-writing for a LeoU issue. Recent discussions 
 about 
Leo's design have stimulated this post.

Here, I'd like to simulate a formal code review of Leo's vnode (VNode) 
class.  I'll wear three hats: the presenter, the secretary and the project 
manager.  I'll use Vitalije's comments as a starting point for a 
discussion. This discussion would not normally be part of a code view, but 
imo it's a good teachable moment.

See the summary for conclusions.

*Presentation*

The VNode class contains all data in an outline, as well as crucial, 
low-level operations on those data. There is no other place to store 
node-related data!  In particular, the position class concerns itself only 
with traversing the tree. The position class contains *no* node-related 
data.

The VNode class is one of the foundations of Leo's scripting. As a result, 
none of the ivars or methods of the VNode class can change in any way. That 
is, all of the ivars of the VNode class are "official". Scripts can, and 
do, access these ivars directly.

Theoretically, it would be possible to add new kwargs to VNode methods, but 
that is extremely unlikely. It would also be possible to add new ivars to 
the VNode class, but uA's make that unnecessary.

The properties of the VNode class, v.b, v.h, v.gnx, v.u, allow higher-level 
access to various VNode ivars, but in some cases Leo's code accesses the 
corresponding ivars directly, for greater performance.

*Discussion*

Here I'll respond to Vitalije's comments in detail.  This would typically 
not happen during a formal code review, but these comments will give me a 
chance to more fully explain the design of the VNode class. 

> one of the most basic element of Leo's data is certainly VNode. And yet 
one can not instantiate VNode class without acquiring full blown commander, 
which in VNode is known as context. In the comment of context attribute is 
explicitly declared that it is called context to indicate its limited 
usage. 

Perhaps the "context" kwarg should just be called "c", but of course that 
can't be done now.  Almost all of Leo's classes have access to "c", the 
present commander.  There is nothing wrong with that.

What *data hiding* means to me is that the *boundary *between the "inside" 
and the "outside" of a class is (relatively) strict.  As far as the 
"context" arg goes, the caller (creator) of VNode instances does not need 
to know *anything *about how the VNode class uses the context.

The clients of the VNode class must not (and do not) know *anything *about 
how the methods of the VNode class work.  All methods (of all classes) 
*must* be black boxes.

> However [the context ivar] is used not only as a holder of hiddenRootNode 
but there is a method on VNode that knows about c.frame.body.wrapper and 
knows that c.frame.body.wrapper has setInsertPoint, setYScrollPosition...

The VNode class must know everything about c.hiddenRootNode.  It's another 
VNode instance.

The vnode class must contain the v.scrollBarSpot ivar.

Yes, it would be possible to use c.restoreCursorAndScroll() instead of 
v.restoreCursorAndScroll(). Ditto for c/v.saveCursorAndScroll().  But such 
changes would have *no *consequences for Leo's architecture.

> [The VNode class] also knows indirectly about c.fileCommands.gnxDict.

To my knowledge, this is not true.  The VNode class does not in any way 
become entangled with other classes merely because v.context exists! The 
VNode class knows *nothing* about how other classes use gnx's.

> Now, whichever module needs to access VNode class, can't just import 
leo.core.leoNodes and use it. It needs to acquire commander instance before.

True, but so what?  Every class in Leo has access to a commander instance 
via its "c" ivar.  That's why all Leonine scripts have the "c" var 
predefined.  Imo, it's useless to complain about this.

However, this comment does suggest creating c.new_vnode method:

import leo.core.leoNodes as leoNodes
# already exists in leoCommands.py
...
def new_vnode(self, gnx=None):
c = self
return leoNodes.VNode(context=c, gnx=gnx)

The (small) advantage is that clients of c.new_vnode(gnx) would no longer 
need to import leo.core.leoNodes.

> Recently, we discussed the copying and pasting outline. It delegates its 
task to fileCommands. FileCommands OTOH knows about 
c.frame.resizePaneToRatio, c.selectPosition, c.frame.initialRatios, 
c.atFileCommands.readAll, c.frame.body.onBodyChanged...

> It seems to me that copying and pasting outlines should belong just to 
VNode. I would expect that v instance knows best how to encode itself into 
a string, and to decode itself from string. 

The VNode class does know about unicode.  v._headString and v._bodyString 
contain unicode characters. The v.b and v.h setter properties call 
v.setBodyString() and v._setHeadString(), which handle the conversion to 
unicode.

Ironically, the reason this is not