ENB: Dubious idea: multi-dimentional outlines

[Edward K. Ream]

Innovation almost happens without a juicy problem. The problem that inspired these thoughts was this: how can we associate unit tests with (the code in) a Leo node?

One thought was to put one or more unit tests for node p in p.u, p's user data.  Clearly that's possible. Moreover, a script could discover and run such unit tests.

So p.u becomes another dimension of the outline. That is, p.u is another outline, "orthogonal" to the original outline. We've been here before, with the notion of colored links with Leo outline. The conclusion then (and spoiler alert, now) is that the concept isn't that useful. However, I would like to discuss this (dubious) idea in a bit more detail, just for fun.

Outlines all the way down

If p's user data can contain another outline, then any node p-prime in the new outline could contain yet another outline, contained in p-prime's user data. And so on... This has little or no appeal :-)

Gui problems

I have not been able to make sense of this idea in terms of screen elements, even if we stop at one additional level. We would need another pane to show the user data, and there would likely have to be various representations of the user data depending on what the various parts of the user data are. It would be like the VR pane, but showing p.u rather than p.b. Just as with the VR pane, we would need distinct code for each different kind of user data. But user data can contain (almost) anything, so the new pane could never be "complete".

Furthermore, the new pane, say the user data pane, would likely take a lot of screen real estate to show the user data. Most of the time that space would be wasted (almost useless).

How could the user data pane show yet another outline?  Does that second outline need yet another VR pane or another user data pane? It seems like the most complex thing that could possibly work :-)

A simpler way

Let's go back to the original problem: we want a way to associate unit tests with code. Links are the obvious way to do that.

Leo already has unl's (uniform node locators). There is nothing to prevent two-way unl's between code and unit tests. Each node (containing code to be tested) could contain a link to a tree containing zero or more unit tests. Each unit test could optionally contain a link back to the node being tested. So there is a (benign) many-to-one relationship between the links.

I noted above that the user data pane could never show all possible user data (in a friendly format). However, particular data could be shown using special case code. Terry's todo and backlink plugins are examples of specialized views of data. We could consider showing graphs of links, if that would be useful.

Other considerations

Links could take many forms besides unl's, including tags, or even file names (of the code to be tested).

Unit tests of outline-oriented code benefit from being included in unitTest.leo. That way the unit tests can use Leo's outline-oriented capabilities. The unit tests for leoAst.py were a great fit for pytest because they didn't need those outline-oriented features.

Summary

Associating code with unit tests would be useful, but putting tests in p.u is about the most complicated thing that might work :-)

Edward

[Thomas Passin]

On Tuesday, April 21, 2020 at 9:56:26 AM UTC-4, Edward K. Ream wrote:

Innovation almost happens without a juicy problem. The problem that inspired these thoughts was this: how can we associate unit tests with (the code in) a Leo node?

[snip]

 

Leo already has unl's (uniform node locators). There is nothing to prevent two-way unl's between code and unit tests. Each node (containing code to be tested) could contain a link to a tree containing zero or more unit tests. Each unit test could optionally contain a link back to the node being tested. So there is a (benign) many-to-one relationship between the links.

You may not remember, but I developed a script for the zettelkasten system that does something much like this.  Given that you have a node that contains a line :target: followed by the gnx of the target node, the script inserts the gnx of the current node into the target node if it doesn't already have it - to serve as a backlink - and then jumps to the target node.

This script could be the starting point for what you are thinking of.

[Edward K. Ream]

On Tue, Apr 21, 2020 at 9:41 AM Thomas Passin <tbp1...@gmail.com> wrote:

You may not remember, but I developed a script for the zettelkasten system that does something much like this.

I did remember. I just didn't remember to mention it :-)

Given that you have a node that contains a line :target: followed by the gnx of the target node, the script inserts the gnx of the current node into the target node if it doesn't already have it - to serve as a backlink - and then jumps to the target node.

This script could be the starting point for what you are thinking of.

I agree. Could you point me to the script?

Edward

[Thomas Passin]

Here you go.  I've included all of my zettel scripts.  The one I mentioned is zettel-goto-node.

[Marcel Franke]

Am Dienstag, 21. April 2020 15:56:26 UTC+2 schrieb Edward K. Ream:

One thought was to put one or more unit tests for node p in p.u, p's user data.  Clearly that's possible. Moreover, a script could discover and run such unit tests.

That's not really multidimensionl, just nested, as long as you don't utilize those data in a dedicated view.
Though, you could replace the existing tree or the editor with a stackwidget and allow people to choose alternate views on the graph.

We've been here before, with the notion of colored links with Leo outline.

 What do you mean with colored links? The declutter-code?

The conclusion then (and spoiler alert, now) is that the concept isn't that useful.

 If you mean the declutter-code, then it's no surprise. The implementation is aweful and halfassed, as usual.
I patched my leo to add support for p.u in there and at the end even outsourced the rules into p.u for dynamic handling.

That said, leos tree-redrawing-routine is really aweful there, calling the declutter-code some dozen (or even hundred?) times per second.

If p's user data can contain another outline, then any node p-prime in the new outline could contain yet another outline, contained in p-prime's user data. And so on... This has little or no appeal :-)

 

Just courious, why are you just looking at p.u? Who not also p.b? There can be significant structure in the body which is to simple for adding
it at the normal tree. I once experimented adding a "local outline" on the side for this stuff. Spoiler: allowing users to easily adding their
own parsers is crucial for this.

So my idea is: add another node-local outline which can be controlled by the user.

Furthermore, the new pane, say the user data pane, would likely take a lot of screen real estate to show the user data. Most of the time that space would be wasted (almost useless).

There is some rather simple solution: replace the editor. Make a tabwidget and add a register of data-views which according to
some rule or function loads the best fitting view for a node. The people then can decide which view they wanna use for which data, while the tabwidget still allows them to easily switch to alternate views. Allow plugins to add new views, and you can easily experiment with any view, without harming the existing GUI.

This would also solve some other problems the now existing editor has regarding big nodes and long lines for example.

[Edward K. Ream]

On Tue, Apr 21, 2020 at 10:45 AM Thomas Passin <tbp1...@gmail.com> wrote:

Here you go.  I've included all of my zettel scripts.  The one I mentioned is zettel-goto-node.

Thanks. I'll start there.

Edward

[Edward K. Ream]

On Wed, Apr 22, 2020 at 4:33 AM 'Marcel Franke' via leo-editor <leo-e...@googlegroups.com> wrote:

> If you mean the declutter-code, then it's no surprise. The implementation is aweful and halfassed, as usual.

I stopped reading here.

You are allowed to make disrespectful, insulting, remarks only about your own code, never about anyone else's. I found the words "as usual" particularly offensive.

Edward

[vili]

On Tuesday, April 21, 2020 at 3:56:26 PM UTC+2, Edward K. Ream wrote:

>>>>>Associating code with unit tests would be useful, but putting tests in p.u is about the most complicated thing that might work.

Of course. Conceptually, AFAICT, unit tests and code are in a similar relation as natural language text and code. Going to the roots of Leo, we are again dealing with Noweb and CWEB tools for tangled vs. separated/clean presentation but - with bigger chunks - not just snippets of code/text in a body text of a single node but, a collection of nodes on either side.

>>>>>There is nothing to prevent two-way unl's between code and unit tests. Each node (containing code to be tested) could contain a link to a tree containing zero or more unit tests. Each unit test could optionally contain a link back to the node being tested. So there is a (benign) many-to-one relationship between the links.

IMHO, it sholuld be two separated standard leo trees (tabs) with a solution for jumping from code to unit tests and back at the level of nodes.

BR, Vili