Re: Progress report: embedding neovim in Leo

['tfer' via leo-editor]

While this may be important towards the physical integration of the Qt pane 
that will be the gui frontend for the Neovim core, this doesn't need to be 
finished to start working on the "plumbing" that will need set up between 
Leo and the neovim core, e.g., nvim.exe.

The "plumbing" is msgpack calls to the neovim core and some msgpack calls 
from neovim to a as yet unwritten interface in Leo.  For experiments you 
can just have Leo talk to a separately running instance of the stock Qt 
fronted Neovim.

I think my first experiments with this were with juypyter notebooks,  I was 
translating that work to leo files, not such what state that is in, but 
I'll attach those files.

Tom 

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


neovim_remote-api.leo
Description: Binary data

Re: Scoop, a new way to install?

['tfer' via leo-editor]

I should mention that what I have used scoop for so far, is to install 
ripgrep, and Neovim.

As a plus, it looks like scoop will let you known if an app has a newer 
version available.

Tom

-- 
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: Updates to LeoVue

[Edward K. Ream]

On Sat, Oct 13, 2018 at 3:26 PM Joe Orr  wrote:

> Facelift for LeoVue and some new features. More screenshots so should
> better convey the advantages.
>
> https://kaleguy.github.io/leovue
>

Many thanks for all this.  I've just added a link to LeoVue to Leo's
wikipedia page .

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: Request - mode to open Leo files read-only

[jkn]

On Saturday, October 13, 2018 at 12:39:37 PM UTC+1, Edward K. Ream wrote:
>
>
>
> On Sat, Oct 13, 2018 at 6:24 AM jkn > 
> wrote:
>
> Occasionally I would like to protect myself from changing any files within 
>> Leo. Would it be possible to have a command-line option for all files to be 
>> open read-only?
>>
>
> I think so.  --read-only would disable the save-* commands.  I've just 
> created #995  for 
> this.
>
> But suppose you forget that --read-only is in effect.  You write code for 
> an hour before trying to save.  Leo tells you that you can't save.  Now you 
> have to remember what changes you made, open another copy of Leo, and save 
> your changes.  This might dissuade you from using --read-only.
>
> Another option is to use git to manage your files...
>
> Edward
>

Hi Edward
Thanks for #995. Yes, you'd ideally want some clear way of indicating 
that Leo was operating in this mode. Perhaps a different (configurable?) 
window border colour, or similar. Though ... do people really 'write code 
for an hour before trying to save'?

In part this suggestion is de to my workflow re. OwnCloud and Leo files, 
and my ... discomfort ... with the way Leo treats updated files (or at 
least the prompts thereof). Git is another method, although FWIW I think it 
doesn't work well over owncloud.

Regards
jon N

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

Updates to LeoVue

[Joe Orr]

Facelift for LeoVue and some new features. More screenshots so should 
better convey the advantages.

https://kaleguy.github.io/leovue

* @cover for cover page
* Added bootstrap-vue, so bunch of new components, like carousel
* Fixes to improve wiki operation
* Fixes to improve JSON feed + template to content
* Preloads local markdown files so search works on local markdown files, 
makes LeoVue better candidate for documenting Github project.

Any documentation or feature suggestions welcome. Lots of features of Leo 
I'm not using and don't know about, and could either be explained or added. 

This is the Leo installation info page:
https://kaleguy.github.io/leovue/#/t/7/

I tried the windows installer on a couple of different machines and it 
didn't work, so I'm just pointing people to the zip file of 5.3 which has 
everything and works. The installation instructions on the main site are 
way too complicated for regular users. If the 5.3 zip could be updated, 
that would be great.


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

Scoop, a new way to install?

['tfer' via leo-editor]

Having to set up a new laptop to work with Leo and follow some of the 
current lines of development, I came across a new command line installer 
for Windows, scoop.  It is written in Powershell and to install a 
particular app scoop can run off a json file in the git repo.

Currently, I clone Leo-Editor to a local repo, Install Python 3 with all 
the bells and whistles by using Anaconda.  I usually run Leo from a special 
powershell session under Cmdr.

Tom 

-- 
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: Progress report: embedding neovim in Leo

[Edward K. Ream]

On Sat, Oct 13, 2018 at 8:40 AM Edward K. Ream  wrote:

The leo-editor-contrib branch now contains neovim.leo, a study outline for
> the python-client code .
>

The C++ sources for the stand-alone neovim-qt app are here
.  mainwindow.cpp

is probably a good starting point for creating a nvim window in Leo.  I
don't see any other reasonable starting point.

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.

Progress report: embedding neovim in Leo

[Edward K. Ream]

The leo-editor-contrib branch now contains neovim.leo, a study outline for 
the python-client code .

This is elegant code, surely the simplest code that could possibly work.  
The use of functools.partial 
 is particularly nifty.

The following code works, on both Linux and Windows, but only partially:

import os
import sys
import PyQt5.QtWidgets as QtWidgets
from neovim import attach

class NeovimWindow(QtWidgets.QMainWindow):
def __init__(self, nvim):
super().__init__()
self.nvim = nvim

app = QtWidgets.QApplication(sys.argv)
nvim = attach('child', argv=['nvim', '--embed'])
window = NeovimWindow(nvim)
window.show()

The call to attach returns the expected result.  However, nvim does not 
appear in the window.  How could it?  attach knows nothing of the window!  
It would take special magic indeed for this to work.

It's quite possible that only a few more lines of code are needed, but I'll 
have to read the docs to discover what they might be...

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: Simplifying Leo's undo logic

[Edward K. Ream]

On Saturday, October 13, 2018 at 7:30:24 AM UTC-5, Edward K. Ream wrote:

Vitalije's recent discussions of functional programming has indirectly lead 
> me to a tentative plan to simplify Leo's undo logic.
>

I made more than the usual number of typos in the original post.  They have 
been corrected on leo-editor, but not in your email notifications. #996 
 also contains the 
corrections.

In several places I meant to say undoer.start instead of undoer.before and 
similarly, I meant to say undoer.end instead of undoer.after. New names 
make it possible to mix the old and new ways of implementing undo.

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: Dreaming big dreams

[Edward K. Ream]

On Sat, Oct 13, 2018 at 8:00 AM Terry Brown wrote:

> Hmm.  This suggests creating unl's linking code to their tests.
>
> You don't really even need an UNL, if you have a convention a button
> can work out whether you're looking at the test or the code, and switch
> between them, see
> https://groups.google.com/d/msg/leo-editor/pdvXCZePi_I/8a4gtobvAwAJ


Well done.  I am going to start using pytest, at the very least to support
#994 .

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: Dreaming big dreams

[Terry Brown]

On Sat, 13 Oct 2018 06:06:29 -0500
"Edward K. Ream"  wrote:

> > .../foo/test/test_my_module.py->test_my_func()
> > 
> Thanks for this.  So for every @file x.py, we would create an @file
> test/x.py. It's a reasonable solution.
> 
> Leo makes the idea of "near" meaningless, there's plenty of ways to
> jump between these pieces of code easily.
> > 
> Hmm.  This suggests creating unl's linking code to their tests. These
> tests could be @test nodes or @file nodes containing, say, pytest
> test functions. I should have thought of this before.  It's a great
> solution.

You don't really even need an UNL, if you have a convention a button
can work out whether you're looking at the test or the code, and switch
between them, see
https://groups.google.com/d/msg/leo-editor/pdvXCZePi_I/8a4gtobvAwAJ

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.

Simplifying Leo's undo logic

[Edward K. Ream]

Vitalije's recent discussions of functional programming has indirectly lead 
me to a tentative plan to simplify Leo's undo logic.


*A thought experiment*
Suppose Leo outlines behaved kinda like Python strings.  You never actually 
change a Python string, you only compose new strings.

Of course, Leo would have to be super careful about how it composed new 
outlines. Rather than creating a new copy of the entire outline, there 
would have to be some kind of transaction-based mechanism behind the 
scenes.  Like a db.

I'm not keen to do this, perhaps for obvious reasons, but it did get me 
thinking about undo transactions.

*Transaction-based undo*

At present, Leo has several before and after undoer methods.  Instead, 
suppose there were only two public methods: undoer.before and undoer.after.

- undoer.start starts an undo transaction, which may consist of several 
parts.  For example:

data = c.undoer.start(undo_type) # data represents the transaction.

- undoer.end ends the transaction, and "commits" the transaction. 
undoer.after does nothing if the transaction is empty.

c.undoer.end(data)

This scheme can form the basis of an @undoable decorator.

Initially, a transaction is an empty container. Undoable commands would add 
to the transaction in one of several ways, much like the old begin/end 
methods of the present undoer.  Something like:

- data.change_headline(p, old, new)
- data.change_body(p, old, new)
- data.clone(p)
- data.mark(p)
- data.move(p1, p2)
- data.sort(p)

Unlike the old way, all transactions support multiple sub-transactions.  
For example,  a single transaction could handle the change-all command.

*Summary*

The new scheme is simpler for client (command) code, and behind the scenes 
as well.

The new scheme can be the basis for an @undoable decorator.

The new scheme would be a major change to Leo's code, but seems worth 
doing. I have just created #996.

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: my 2 cents to embedding Leo into other editor or vice versa

[Edward K. Ream]

On Sat, Oct 13, 2018 at 5:51 AM vitalije  wrote:

> Heh.  I just realized that Vitalije's post was first made in February, not
>> yesterday,
>
>
> I was also surprised to see new topic and "me" as author of it.  For a
> moment I thought it was some bug in google. :-)
>

Hehe.  I thought exactly the same thing.

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: Request - mode to open Leo files read-only

[Edward K. Ream]

On Sat, Oct 13, 2018 at 6:24 AM jkn  wrote:

Occasionally I would like to protect myself from changing any files within
> Leo. Would it be possible to have a command-line option for all files to be
> open read-only?
>

I think so.  --read-only would disable the save-* commands.  I've just
created #995  for this.

But suppose you forget that --read-only is in effect.  You write code for
an hour before trying to save.  Leo tells you that you can't save.  Now you
have to remember what changes you made, open another copy of Leo, and save
your changes.  This might dissuade you from using --read-only.

Another option is to use git to manage your files...

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: Unit Testing Nodes

[Edward K. Ream]

On Sat, Oct 13, 2018 at 1:49 AM vitalije  wrote:

> I usually make clone of the whole content of a module being tested as a
> first child of a @test node, and put there in the @test node @others
> directive at the top of body. After @others I write code that tests some
> function from the module.
>
> Quite often I start developing a module without creating an external file.
> The whole development module is under one node that is cloned under several
> @test nodes, and only after I am satisfied with the code, I just make
> another clone and put it under some @clean or @file node as the only top
> level child to create external file.
>

Yes, I often use the same work flow. This is related to this FAQ entry

.

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.

Request - mode to open Leo files read-only

[jkn]

Hi Edward
a small suggestion/request. Occasionally I would like to protect myself 
from changing any files within Leo. Would it be possible to have a 
command-line option for all files to be open read-only?

Thanks
Jon N

-- 
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: Unit Testing Nodes

[Edward K. Ream]

On Fri, Oct 12, 2018 at 5:23 PM MN  wrote:

For the examples you gave (and your other comments in the group), it seems
> like I cannot put the unit test in its own node (even as a sibling)?
>

I'm not sure I understand what you mean, but it's not wise to put @test
nodes as children of @file, @auto or @clean nodes.

But Terry's suggestion of using unl's to link functions to their
corresponding @test nodes (or a tree of @test nodes) seems like an
excellent workaround.

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: Dreaming big dreams

[Edward K. Ream]

On Fri, Oct 12, 2018 at 11:59 PM Matt Wilkie  wrote:

Newbies only need to know how to search outlines, and which outlines to
>> search, especially LeoDocs.leo, leoSettings.leo and CheatSheet.leo.
>> Really, how hard is it to scan the top-level nodes in leoSettings.leo?
>>
>
> I think this speaks to the mode of learning with a browser open on one
> side pointed at the docs (and google and forums and stack overflow and ...)
> and the program-to-learn-about on the other side, experimenting and trying
> out the things being read about in the browser. Things which don't have
> browser-discoverable things to read are harder to learn using this common
> pattern.
>

Leo's online documentation are mostly for those who haven't installed Leo
yet.

There is no need to have a browser open.  The browser view is less useful,
and less organized, than LeoDocs.leo and CheatSheet.leo.If that weren't
true I would not have created Leo in the first place.

Python has built in help available in any interactive session, but it's
> easier to use a reference page
>  than print it inline
> with the code and then losing track of the previous command:
>

LeoDocs.leo, CheatSheet.leo *are* the reference pages.

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: Dreaming big dreams

[Edward K. Ream]

On Thu, Oct 11, 2018 at 4:37 PM MN  wrote:

How do I know which commands I write are automatically undoable and which
>> ones are not? My script to alter commenting behavior seems undoable without
>> my putting any effort into making it so.
>>
>
I would have to see your script to know whether, and why, it is undoable.
Perhaps your script calls onBodyChanged.

>
> Macros have been removed.  Leo's scripting is much more powerful.
>
>
> I hope you'll remove it from the docs, then.
>

It's on the list.

> Going off topic, I view this as a false dichotomy. One can have macros
> /and/ scripting. Certainly scripting is more powerful, but for most of the
> things I use macros in Emacs, it would be a step backwards to write a
> script. Most of the time I define and run a macro in under a minute.
>

It's not off topic.  I removed macros after asking whether anyone ever used
them.  At that time, nobody said they did.  Of course, they could be
brought back.

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: Dreaming big dreams

[Edward K. Ream]

On Thu, Oct 11, 2018 at 2:19 PM Terry Brown  wrote:

> - Why can't we put unit tests near the code being tested?
>
> I'd argue (for Python) for using the best in class unit testing
> framework's practice.  pytest puts tests for
>
> .../foo/my_module.py->my_func()
>
> in
>
> .../foo/test/test_my_module.py->test_my_func()
>

Thanks for this.  So for every @file x.py, we would create an @file
test/x.py. It's a reasonable solution.

Leo makes the idea of "near" meaningless, there's plenty of ways to jump
> between these pieces of code easily.
>

Hmm.  This suggests creating unl's linking code to their tests. These tests
could be @test nodes or @file nodes containing, say, pytest test functions.
I should have thought of this before.  It's a great solution.

> As you said elsewhere "One of my biggest mistakes has been not using existing
> tools."


I don't feel that way about unit testing.  @test nodes are easy-to-use
wrappers around unitTest.TestCase. Their only real drawback is that setup
and teardown aren't easy to do.

> knowing I'm going to want to use pytest for any other project, causes me
> to not write unit tests for Leo.
>

You are welcome to create pytest unit tests for Leo.  They don't have to
reside in unitTest.leo.

unitTest.leo already scans for doctests in all of Leo's core files.  It
could easily run pytest on all test files in leo/core/test.  I've just
created #994  for this.

> > - Why can't we use javascript, or prolog within Leo?
>
> The richtext plugin runs a WYSIWYG HTML editor in javascript in Leo, so
> I think javascript shouldn't be hard.  Chances are the plugins broken /
> needs maintenance, and while we could blame Qt's web support history
> for that, to be fair all code needs maintenance.
>

The plugin uses QtWebKit, which doesn't get as much development work as
Mozilla, Chrome, etc.

What I want is to use javascript in a separate process, communicating with
both Leo and your favorite browser.

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: my 2 cents to embedding Leo into other editor or vice versa

[vitalije]

>
> Heh.  I just realized that Vitalije's post was first made in February, not 
> yesterday, 


I was also surprised to see new topic and "me" as author of it.  For a 
moment I thought it was some bug in google. :-)

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: Dreaming big dreams

[Edward K. Ream]

On Thu, Oct 11, 2018 at 1:19 PM Offray Vladimir Luna Cárdenas <
off...@riseup.net> wrote:

> I think that converting Leo to other languages makes little sense from a
> practical point, but exploring Leo ideas in other environments makes a lot
> of sense (and viceversa).
>

I agree.

> What I would like to see is more decoupling between the different parts of
> Leo, and Leo offering "outlining" services to data and documents coming
> from different places (including Jupyter notebooks, the file system,
> internet, data bases and so on).
>
Yes.  I think this is on the main line of the big dreams discussion.

> This is difficult, because there is a tension between providing an
> integrated experience easy for beginners and decoupling Leo so it can offer
> its advantages to other communities and users. So my approach would be to
> select specific communities and enhance Leo for them, starting with the Leo
> community itself and the proposal for outlines exemplifying particular
> workflows for users. I will try to expand a little bit on this:
>
>- Maria is a writer. She will like to use Leo to write prose and
>organize her writings. So she creates a Leo outline and starts to write
>several places of her work: characters, plot and publishing. For each of
>those she creates a Leo node and puts more children nodes, showing all
>characters, the plot parts and subplots and the publishing artifacts: a
>book in PDF and EPUB formats. Maria uses Leo clones when she needs to
>showcase how different parts of her work are connected and combines light
>formats for describing what she is doing: YAML for characters and their
>attributes and Markdown for prose in plot and publishing. Because Leo
>support all this formats and also directives, buttons and scripts, Maria is
>able to create the publishing she wants and automatize the process to focus
>in what she cares about: good storytelling. She can share a .leo document
>template so other writers can benefit from her workflow. The more technical
>part of the template (directives, buttons and scripts) was created with the
>help of the Leo community, where Maria started to share their early
>templates without any automatic behavior.
>
> This should be doable, with relatively minimal effort.  We would want
buttons to export/save to pdf, epub and yaml.

>
>- Gonzalo is a developer. He needs to read and understand code wrote
>by others and to adapt some pieces for his own needs and create new scripts
>that can be used with other code to suits his needs...
>
> c.recursiveImport is the main tool for this.  It's the foundation of
recursive import scripts.  Just yesterday I found some more bugs in
c.recursiveImport, while I was studying the neovim code.

>
>- Rosana is a data scientist. She needs to load data from several
>sources and experiment with it interactively by making queries and
>visualizations...
>
> This is likely the most challenging for Leo at present.  Imo, we want
better tools for dealing connecting with other environments in separate
processes.

Once we have the different user stories, we try to see how Leo in its
> actual form can help to this people or how need to be changed. The
> important part of the stories is to think that all different Leo users are
> creating outlines and hope to see a particular behavior to make their life
> easier. We could try to track the original outlines and how they were
> changed with the help of the community and also how some functionality was
> incorporated in Leo to make it more usable for them.
>

Well, this is the endless documentation problem.

> For example live Markdown rendering could be enabled by writing something
> in the Leo command line or from a graphical preview, without going into
> complex @settings files.
>

Live Markdown rendering already exists.  Put this in any body node:

@language md
# My Headline
My body

Open the view-rendered pane with vr-show, and start typing in the body pane.

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: my 2 cents to embedding Leo into other editor or vice versa

[Edward K. Ream]

On Saturday, October 13, 2018 at 5:17:45 AM UTC-5, Edward K. Ream wrote:
>
> On Wed, Feb 21, 2018 at 2:42 AM vitalije  wrote:
>
> Last summer I had this idea of using another open source editor and adding 
>> features unique to Leo. I did considered several editors implemented in 
>> browser or browser-like environment. That includes Atom, but also 
>> LightTable, NightCode, and few others. Even old jEdit came to my mind.
>>
>
Heh.  I just realized that Vitalije's post was first made in February, not 
yesterday, and that I replied in February pretty much as I have done today.

Anyway, I'm not sorry for the "duplicate" reply.  It's still a great idea.

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: my 2 cents to embedding Leo into other editor or vice versa

[Edward K. Ream]

On Wed, Feb 21, 2018 at 2:42 AM vitalije  wrote:

Last summer I had this idea of using another open source editor and adding
> features unique to Leo. I did considered several editors implemented in
> browser or browser-like environment. That includes Atom, but also
> LightTable, NightCode, and few others. Even old jEdit came to my mind.
>
> All these editors offer writing some kind of extension or plugin.
>
> After a while I thought that easiest way to connect the two is
> implementing some kind of special file system. In this (let's call it
> LeoFS), filenames are gnxes and file content is the body or maybe (headline
> + '\n' + body). All these editors have some kind of tree representation of
> the file system which can be enhanced to draw Leo icons and headlines
> instead of filenames. When they update file, LeoFS would update
> corresponding body. LeoFS could be easily implemented using leoBridge.
>

Very interesting. I assume that by "corresponding body" you mean c.p.b.

I realized through these (thought) experiments, that the one thing that
> makes Leo best editor for me is not its code, editing features, look, ...,
> but this brilliant idea *at-others* and also scripting. Scripting is
> something that lot of other text editors support, but* at-others* is
> uniquely Leo's. Add support for at-others to any other scripting text
> editor and you've got Leo.
>
You would also need section references, but your point is well taken.
@others was the first thing I added when doing the MORE prototype
.  Section references are
part of cweb, so I didn't need to invent them.

Leo's API and data model is also essential, imo, but Leo's bridge gives you
that.  Of course, Leo's bridge gives you @others and section references too.

I am amazed how no one has implemented such feature in any other editor yet.
>

Perhaps nobody else has ever thought of LeoFS.  Most of the world (except
Smalltalk folks) seems obsessed with flat files.


> Due to the lack of time I had to abandon this idea but it still burns in
> the back of my head waiting for a better time to be realized.
>

Adding Leonine features to another popular editor would be extremely
valuable for us Leonistas. LeoFS is a brilliant idea.

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: Three dimensional graphs

[Edward K. Ream]

On Fri, Oct 12, 2018 at 11:27 AM Terry Brown  wrote:

> Funny you should bring up a third dimension, I've been experimenting
> with something along these lines, although not within Leo :-/  No
> doubt inspired by various discussions on this list (sea of nodes,
> colored threads, Kent's mysterious extra dimensions :-).  Data model
> is basically a set of nodes shared between a set of graphs.  So nodes
> might be things like a reference to a filesystem file, or a todo item,
> or some notes, and the graphs might have names like "Files", "Todo",
> "Kanban", "Tests", "Docs". The idea is that the same nodes can
> participate in different graphs.  Data's stored in a DB.
>
> I haven't got very far yet, basically trying to work out if this can
> be visualized with a tree (specifically, can you represent more than
> on graph in the same tree), and how to do that.
>

Thanks for these ideas. They are interesting, and it's a good time for more
adventurous ideas.

Sharing data in a DB might work well with client/server code.  And who
knows, perhaps cross-file clones might be possible.

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: Unit Testing Nodes

[vitalije]

I usually make clone of the whole content of a module being tested as a 
first child of a @test node, and put there in the @test node @others 
directive at the top of body. After @others I write code that tests some 
function from the module. 

Quite often I start developing a module without creating an external file. 
The whole development module is under one node that is cloned under several 
@test nodes, and only after I am satisfied with the code, I just make 
another clone and put it under some @clean or @file node as the only top 
level child to create external file.

This works very well for me when developing Python. When I am writing in 
CoffeeScript I use cloned content of a module in two different external 
files: one is a regular CoffeeScript module, and the other is saved under 
/test/ folder and usually in a file named "test_.coffee". 

[image: leo-unit-testing.png]
For example in the above picture you can see two @clean nodes:

   1. @clean coffee/ev-3.coffee
   2. @clean test/spec/spec3-1.coffee

Both of this two nodes have under them cloned node `ev-3 kod` which 
contains all definitions (functions, constants, singleton instances, ...).  
Node named 'izEvidencije` contains just some comments and @others line. So, 
all those definitions are defined and present in both files 
coffee/ev-3.coffee and test/spec/spec3-1.coffee. In the spec3-1.coffee 
there is a node `specifikacije` which contains all specs that are 
describing (and testing) behavior of ev-3.coffee module.

For Python development, it is even easier because Leo executes test nodes 
on the fly, so there is no need for the external test file, but if you do 
wish to create test files and use some other test runner you can use the 
same technique as in the above example for CoffeeScript.

HTH
Vitalije

On Saturday, October 13, 2018 at 12:23:32 AM UTC+2, MN wrote:
>
> Any node, but @test or @button nodes are easiest to use.
>>
>> Is that defined somewhere? 
>>>
>>
>> Yes, in the next sentence.
>>
>
> The sentence can be parsed in two ways:
>
> "This node (in the Leo outline) defines your development environment. You 
> can use an @test node, an @button node, or an @command node"
>
> I read it as "There is something called a dev node" and "You can make a 
> dev node a @test, @button or @command node". It sounded like a dev node is 
> a node with a special property  (e.g. a cloned node is visually different 
> from a regular node), and then you can make THAT dev node a @test node. I 
> think a better phrasing would be:
>
> "A dev node is defined as any node that is either a @test, @button or 
> @command node."
>
> For the examples you gave (and your other comments in the group), it seems 
> like I cannot put the unit test in its own node (even as a sibling)?
>
> On Fri, Oct 12, 2018 at 2:11 AM Edward K. Ream  > wrote:
>
>> On Thursday, October 11, 2018 at 4:17:07 PM UTC-5, MN wrote:
>>
>> > What is a dev node?
>>
>> Any node, but @test or @button nodes are easiest to use.​
>>
>> Is that defined somewhere? 
>>>
>>
>> Yes, in the next sentence.
>>
>> Suppose I have a node whose contents are:
>>>
>>> from operator import mul
>>>
>>> def factorial(number):
>>> if number < 0:
>>> raise ValueError
>>> if number == 0:
>>> return 1
>>> return reduce(mul, range(number+1), 1)
>>>
>>> It's a simple function. Imagine this is a helper function that will be 
>>> used by some other function that interacts with Leo. It is not saved to any 
>>> file (beyond the .leo file, of course). I would like to create a unit test 
>>> for this. What is the best way? 
>>>
>>
>> There are several ways.
>>
>>
>> *1. Use Python doctests *
>>
>> Here is a tested code: Create a node, @test factorial, whose body is: 
>>
>> import doctest
>> from operator import mul
>>
>> def factorial(number):
>> """
>> >>> factorial(5)
>> 120
>> """
>> if number < 0:
>> raise ValueError
>> if number == 0:
>> return 1
>> return reduce(mul, range(number+1), 1)
>>
>> doctest.run_docstring_examples(factorial, globals(), name='factorial')
>>
>> Execute the code with with Ctrl-B, or with one of the 
>> run-*-unit-tests-locally commands.
>>
>> This will fail, for different reasons, on both Python 2 and 3.
>>
>> *2. Define unit tests using UnitTest.TestCase*
>>
>> Alternatively, you can define explicit tests.  Here is tested code.
>>
>> import unittest
>> from operator import mul
>>
>> def factorial(number):
>> if number < 0:
>> raise ValueError
>> if number == 0:
>> return 1
>> return reduce(mul, range(number+1), 1)
>> 
>> class TestFactorial(unittest.TestCase):
>>
>> def test1(self):
>> self.assertTrue(factorial(5)==120)
>>   
>> suite = unittest.TestLoader().loadTestsFromTestCase(TestFactorial)
>> unittest.TextTestRunner(verbosity=1).run(suite)
>>
>> Again, you can run this with Ctrl-B, or with one of Leo's unit test 
>> commands.