my 2 cents to embedding Leo into other editor or vice versa

[vitalije]

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. The main challenge would be to find some kind of multi platform python library for implementing file system. I don't remember if I had search for such a thing or not. I remember reading about fuse (pyfuse, or something similar). 

By the way jEdit has its own internal file system interface which allows users to just plug-in their own implementation and it works well on Linux, Windows and Mac. jEdit also supports scripting in several languages including python(jython).

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.

I am amazed how no one has implemented such feature in any other editor yet. 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.

Vitalije

[Edward K. Ream]

On Wed, Feb 21, 2018 at 2:42 AM, vitalije <vita...@gmail.com> 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.

​Interesting.

After a while I thought that easiest way to connect the two is implementing some kind of special file system.

​Or a representation of one. I'll say more about this in another thread.
​

 

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.

​@others was born on March 5, 1996, in the first hour of prototyping Leo using MORE.

I am amazed how no one has implemented such feature in any other editor yet. 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.

​@others is natural only in the context of nodes and section references.  True, node could be mapped onto files, but the motivation requires literate programming.

Many thanks for your comments.  They are important.

My focus for now is on exploration, no matter what I appear to be saying ;-)

Edward

[Matt Wilkie]

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.

 [...]

I am amazed how no one has implemented such feature in any other editor yet. 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.

Here's one my smouldering embers: A long time ago, before I ever considered learning how to script or program, I was intensely involved and enthused with Wiki's in general and TWiki in particular. One of the problems inherent in text-based wiki's, 99% of them, is how to reference and store media such as pictures, sound, videos, pdfs, .... For the most part all of the wiki engines solve the reference part more or less succinctly and sometimes elegantly. Unfortunately the accessories storage part is shoved to the side -- usually one big heap with some kind of human illegible machine generated index. (This isn't unique to wiki's. This same 'media ghetto' solution is used by almost every content management system I've had occasion to use.)

 

My conceptual solution to this was/is "What If Topics Were Folders?", topics being the twiki version of Nodes. Basically: every topic is a container, within the container if the default file exists, display that using the filetype's default rendering mechanism (think web servers and index.html). Media files could be "attached" simply by storing in the same container and then referenced with a link from the default file. Any topic can contain other topics, and thus media files, recursively. A text file would be the global default rendering file, but that could be changed for a local topic/branch to use video or audio or graph instead.

 

All this is a really long way of saying: I agree with you. Filesystems are a smashing great idea. Nodes are a smashing great idea. Putting them together would be awesome.

 

 matt

[Edward K. Ream]

On Sun, Mar 4, 2018 at 10:56 PM, Matt Wilkie <map...@gmail.com> wrote:

​> ​

My conceptual solution to this was/is "What If Topics Were Folders?"

​I always liked the MacOS scheme of allowing folders to be treated as files with attributes. But Linux and Windows don't do this, so Leo has to have sentinel lines.  Except now, with @clean, it doesn't.

Edward

[rengel]

My conceptual solution to this was/is "What If Topics Were Folders?", topics being the twiki version of Nodes. Basically: every topic is a container, within the container if the default file exists, display that using the filetype's default rendering mechanism (think web servers and index.html). Media files could be "attached" simply by storing in the same container and then referenced with a link from the default file. Any topic can contain other topics, and thus media files, recursively. A text file would be the global default rendering file, but that could be changed for a local topic/branch to use video or audio or graph instead.

This has been solved in TheBrain: https://thebrain.com/

Alas, it's not open source.

Reinhard

[Edward K. Ream]

On Wed, Feb 21, 2018 at 2:42 AM vitalije <vita...@gmail.com> 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

[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 <vita...@gmail.com> 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

[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

[Edward K. Ream]

On Sat, Oct 13, 2018 at 5:51 AM vitalije <vita...@gmail.com> 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