Re: cross-platform file references - how to deal with?

[john lunzer]

Would it be possible to to add {{sep}} as a shorthand for {{os.sep}} and 
{{getConfig()}} as a shorthand for {{c.config.getString()}}? 

I think these would be perhaps the two most common use of of path 
expression evaluations. Would be nice to have them be a little shorter.

On Tuesday, September 5, 2017 at 4:02:55 PM UTC-4, Edward K. Ream wrote:
>
> On Tue, Sep 5, 2017 at 11:05 AM, jkn 
> > wrote:
>  
>
>> I was looking at the 'Directives Reference' page myself last night, but 
>> missed the (rather short) 'Path Expressions' section. Perhasp if it were to 
>> be a bit bigger, say by incorporating your example above, that might help?
>>
>
> ​Done.  See this section 
> . The example uses 
> {{os.sep}}.
>
> 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: Cross pollination: Hopscotch: dynamic browser-style IDE and Leisure: document-based computing environment

[john lunzer]

On Tuesday, September 5, 2017 at 3:52:55 PM UTC-4, Edward K. Ream wrote:
>
>
> When I was first learning to program, I often wanted to find some "magic" 
> that would make tasks easier.  Now, I have enough experience to know about 
> how much work a task will take.  However, this might blind me to other 
> approaches that would, in fact, be much better/elegant.  Vitalije's new 
> read code could be called an example.
>

It's nice to know my search for programming "magic" is an *ailment* that 
others have experienced.

Part of Leo's "magic" that has attracted me more than other outline based 
programming tools is that it aspires to be (in the outlining editor sense) 
language agnostic. As an engineer this is a huge consideration for me. I 
should clarify that I'm not looking for the "next big thing". The farther 
civilization expands digitally the more "legacy" code we will have. Despite 
being "legacy" that code is likely going to be still be responsible for 
people's lives and because the effort of updating or porting the code would 
be prohibitive. 

To survive in the future every engineer/programmer is going to need a tool 
that will break down any program in any language into structured code. What 
is structured code? When I develop a larger program in Leo my outline tree 
naturally take on an organized structure that is beyond the limits of what 
the structuring elements of the language provides. I will also do the same 
thing when integrating external code, after Leo does its standard parsing 
and tree construction I go in and move things around so that code/nodes are 
grouped using some classification/categorization logic that is project/code 
dependent.

-- 
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: cross-platform file references - how to deal with?

[Edward K. Ream]

On Wed, Sep 6, 2017 at 10:27 AM, john lunzer  wrote:

> Would it be possible to to add {{sep}} as a shorthand for {{os.sep}} and
> {{getConfig()}} as a shorthand for {{c.config.getString()}}?
>

​Rev ceca81e defines {{sep}} as {{os.sep}}, but I see no way to pass
arguments to getConfig as you want.  So the best that can be done is:​

@file {{c.config.getString('my-dir')}}{{sep}}myFile.py

In other words, g.os_path_expandExpression doesn't support macros, and
likely never will.

I've also updated the docs for path expressions
.

Hmm, I suppose as a "special dispensation" Leo could define  c.getString as
c.config.getString, but I'm not sure that it's a good idea, and I'd rather
not do this just before a new release. It's a global addition to the
namespace, and not entirely trivial to do.

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: cross-platform file references - how to deal with?

[john lunzer]

I totally agree with that logic. If you *were* going to add it to the c 
namespace I would name it c.getConfig (which is more descriptive as to what 
it is doing) rather than c.getString. 

On Wednesday, September 6, 2017 at 12:01:58 PM UTC-4, Edward K. Ream wrote:
>
> On Wed, Sep 6, 2017 at 10:27 AM, john lunzer  > wrote:
>
>> Would it be possible to to add {{sep}} as a shorthand for {{os.sep}} and 
>> {{getConfig()}} as a shorthand for {{c.config.getString()}}? 
>>
>
> ​Rev ceca81e defines {{sep}} as {{os.sep}}, but I see no way to pass 
> arguments to getConfig as you want.  So the best that can be done is:​
>
> @file {{c.config.getString('my-dir')}}{{sep}}myFile.py
>
> In other words, g.os_path_expandExpression doesn't support macros, and 
> likely never will.
>
> I've also updated the docs for path expressions 
> .
>
> Hmm, I suppose as a "special dispensation" Leo could define  c.getString 
> as c.config.getString, but I'm not sure that it's a good idea, and I'd 
> rather not do this just before a new release. It's a global addition to the 
> namespace, and not entirely trivial to do.
>
> 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: OT: (Kinda) "Learning How to Learn" from Coursera

[john lunzer]

On Friday, August 25, 2017 at 10:19:53 AM UTC-4, Edward K. Ream wrote:

> I would like to learn more about web technologies.  I'll start by 
> replicating the appearance of Joe Orr's Leo Viewer page 
> .
>

Been thinking about this and a future web UI for Leo. With the dynamic and 
constantly changing nature of the web and web technologies it seems like 
the best investment would be to implement a web GUI front-end which is 
actually an abstraction layer to a messaging protocol which defines a 
generic (but based on Leo's needs) GUI API. It would then be the 
responsibility of the "Leo Web Client" to implement the display logic and 
UI event logic and communicate to Leo using the defined API. Leo would 
require no knowledge of the client implementation.

I sort of got the idea from this article about the cost of X-to-Javascript 
transpilers . The long term view 
is that if your goal is putting your application into a browser you're 
better off learning and working in Javascript on the client/browser side. 
There is a good analogy about learning German if you live and work in 
Germany and about how much it would cost to hire a translator full time for 
an extend period. 

But that doesn't mean we all need to switch to Javascript, just that the 
best tool for the job if you're interacting with an application inside a 
browser is Javascript. I think you can (and should) write your application 
logic on whatever platform you see fit and implement server/client 
communication. 

I will make sure to say I have very little experience with web technologies 
or implement a system as described and I know almost no Javascript. Maybe 
it's a naive notion or maybe I'm making it overly complicated. I think 
these thoughts put into perspective what a huge undertaking it would be to 
write a web front-end. I would be interested to get some feedback. 

-- 
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.