Jeff R: What emacs features do you want?

[Edward K. Ream]

Jeff R: I have moved off of Leo and now use Emacs, mostly for org-mode but also for whatever else is useful. Emacs itself has features that I can't give up, or at least am not willing to right now.

What are those features?  Adding them to Leo might make Leo substantially better.

Edward

[Joe Becker]

... Or, in the classic koan:


Does emacs have a Buddha nature?


Joe Buddha

[john lunzer]

Edward, I'm in a similar situation, I can give my own short experience.

The more one uses emacs the more it becomes obvious that it is not an editor or an IDE or a PIM, but simply contains all those things. emacs is not an integrated development environment (IDE) but rather an integrated computing environment (ICE, just coined). It is a collection of computing (editing, PIM, development, debugging, version control, system management) tools that work well together (seamlessly in many case, but certainly not perfect). 

Some may think this statement blasphemous but I think emacs and pharo are extremely similar in scope. That is to say in both cases you can (and are intended to) spend close to 100% of your time within the computing environment. In emacs the features that help facilitate this are dired, vc/magit, and term/shell-commands. 

I spend an enormous amount of my time in dired because it's just so well integrated into the rest of emacs. It is as if I have the entirety of my file system and network at my finger tips. I can run shell commands on any files/folders or subset of files/folders and any output goes directly into emacs; this helps keep me in emacs an out of the terminal. dired is further enabled by TRAMP which allows you to view the file system of remote computers via SSH. TRAMP also makes it seamless to edit files on those remote computers. 

vc/magit/diff-hl and other features make version control seamless and mostly painless. Being able to see which files have changed (in dired) and which lines of my code have changes (via icons in the gutter) at all times really helps keep my mind organized and focused. These features also help keep me out of the terminal. 

And then there is Org, which I'm sure you've gotten plenty of requests for features from. Leo is very much like Org. I use Org more like a Jupyter Notebook than anything else. What I utilize most is Org-babel. Org-babel allows you to run any kind of code from anywhere within an org file and save the results within the Org file. The nice thing is that the syntax highlighting is applied appropriately for every kind of block. For example, you can several different pieces of code in different languages with different syntax highlighting in the same file on the same screen at one time. I think Leo does quite a bit of what Org does already, they just do things differently.

I'm not there is anything I would recommend that Leo try to do that is currently does not that emacs does. You would, I believe, have to turn Leo into a full ICE; which I don't think has ever been the goal or aim of Leo. Perhaps this just sort of happens over time as features are accumulated.

If Leo had a multi-node body pane which reflected the indented structure/view shown in the tree pane then it would function more similarly to Org-mode than it does now. Whilst there is a benefit to the "focus" of seeing only one node at a time, in the cases where I use Org-mode I explicitly want/need to see multiple nodes at a time. Leo can't give this to me right now. I think this would really open Leo up opportunities for Leo, it would be a bit of a paradigm shift for Leo. I know that Terry has been working on this but I don't think there has been a release. If he doesn't have the time to finish it I'd recommend him passing it off to you (Edward) to at least experiment with.

[Edward K. Ream]

On Mon, Jun 24, 2019 at 8:00 AM john lunzer <lun...@gmail.com> wrote:

> [Emacs] is not an editor or an IDE or a PIM, but simply contains all those things. emacs is not an integrated development environment (IDE) but rather an integrated computing environment (ICE, just coined).

Many thanks for this excellent summary.

> [Emacs users] spend close to 100% of [their] time within the computing environment. In emacs the features that help facilitate this are dired, vc/magit, and term/shell-commands. 

> I spend an enormous amount of my time in dired because it's just so well integrated into the rest of emacs. It is as if I have the entirety of my file system and network at my finger tips. I can run shell commands on any files/folders or subset of files/folders and any output goes directly into emacs; this helps keep me in emacs an out of the terminal. dired is further enabled by TRAMP which allows you to view the file system of remote computers via SSH. TRAMP also makes it seamless to edit files on those remote computers. 

> vc/magit/diff-hl and other features make version control seamless and mostly painless. Being able to see which files have changed (in dired) and which lines of my code have changes (via icons in the gutter) at all times really helps keep my mind organized and focused. These features also help keep me out of the terminal.

Sound like great features.

> And then there is Org, which I'm sure you've gotten plenty of requests for features from. Leo is very much like Org. I use Org more like a Jupyter Notebook than anything else. What I utilize most is Org-babel. Org-babel allows you to run any kind of code from anywhere within an org file and save the results within the Org file.

As you say, Leo does this, but a bit differently.

> If Leo had a multi-node body pane which reflected the indented structure/view shown in the tree pane then it would function more similarly to Org-mode than it does now.

I don't have a clear picture for this. Can you explain further?

Edward

[john lunzer]

Sure, I've made a mock up to aid understanding. In this example, typically the "header" nodes would not contain "body" text but it does not mean they can't. Any node could have the same header/body split as the "child" nodes in this example. Perhaps a better name for this type of body pane would be a "tree body pane". The important thing is that the view in the body pane reflects the view in the tree pane, really the only difference between them is that the body pane also shows the body text for each node. Interestingly the body pane as shown here is what you see when in Org mode, It doesn't have a "tree pane". 

To be clear I'm not advocating that Leo's body pane be converted to this. I'm suggesting this as a new and different type of body pane, where you could switch between this new type of body pane and a conventional single node body pane, depending on your preference.

My understanding from past conversation is that Terry has put quite some work into something similar. I believe he has shown us his own mock-ups/demos, though, I don't believe he incorporated the tree-like indentation in the body pane as I have shown here.

[Edward K. Ream]

On Tue, Jun 25, 2019 at 7:36 AM john lunzer <lun...@gmail.com> wrote:

Sure, I've made a mock up to aid understanding.

Thanks for the picture. As you say, it's like org mode.  BTW, it's also like MORE.

the body pane as shown here is what you see when in Org mode, It doesn't have a "tree pane". 

I have just created #1228 for this.

To be clear I'm not advocating that Leo's body pane be converted to this. I'm suggesting this as a new and different type of body pane, where you could switch between this new type of body pane and a conventional single node body pane, depending on your preference.

It should be possible to embed multiple "real" body panes in the outline without much fuss.

My understanding from past conversation is that Terry has put quite some work into something similar.

I'm not aware of the work.

Edward

[Arjan]

Whilst there is a benefit to the "focus" of seeing only one node at a time, in the cases where I use Org-mode I explicitly want/need to see multiple nodes at a time.

This is something I would really like to be able to use in Leo. Both for writing text as well as code, being able to see the preceding and following node contents would be very beneficial. In my opinion there are a few important drawbacks to the current situation:

1. There's a need to hold a lot of the context in your head (e.g. how did I start the previous paragraph? What function name did I use in the parent node? Etc.). This takes up space in working memory.

2. When it's urgent enough that you need to look up this context, it takes several key strokes, plus you lose focus on the position where you were working. If you can just scroll up or down to see this context, without having to navigate and maybe fold nodes, then scroll back, you do not lose the visuo-spatial sense of where you were, even if you'd scroll the selected node out of view. I.e. you remember how much scrolling you'd have to do to get back. At least that's how it works for me.

3. Because of 1 and 2, I tend to avoid creation of more fine-grained nodes to structure my work, even though it would otherwise be beneficial.

I found a few places where this idea was discussed before:

Feb 2017 https://groups.google.com/d/msg/leo-editor/qkcmQGL7fdw/l3DvLAoVCgAJ

Sep 2017 https://groups.google.com/d/msg/leo-editor/7OANSWcoOzg/b_tXlLTzAgAJ "multi-pane editing"

Cheers,

Arjan

[Edward K. Ream]

On Tue, Jun 25, 2019 at 8:47 AM Arjan <arjan...@gmail.com> wrote:

Whilst there is a benefit to the "focus" of seeing only one node at a time, in the cases where I use Org-mode I explicitly want/need to see multiple nodes at a time.

This is something I would really like to be able to use in Leo. Both for writing text as well as code, being able to see the preceding and following node contents would be very beneficial.

#1228 should help considerably.  All the changes will be in the code that draws (redraw) the outline.  It should be easy to create a command that toggles between the legacy outline view and the "unified" view.

Edward

[Jeff R.]

I apologize for my slow response. I do not know whether I am remotely close to the intended audience for Leo, but I can say that Leo does not feel far from the type of tool I would use  on a regular basis.

By way of background, I am an attorney and I run a solo law practice. I use emacs, and particularly orgmode, to track various aspects of my practice, including scheduling, time tracking, note taking, and brief drafting. It really does everything I need in those regards, and importing all of this functionality, or even the bare functionality that would make me be able to switch from orgmode would be a huge task and not really what it seems is Leo’s target.

Outside of the organizing my life  aspect of my practice, I am also constantly working on a book of research on my areas of practice (constitutional law). My practice area is  academic. In this arena, Leo is superior to orgmode, due mostly to the use of clones. With my subject area it is impossible to create an outline that does not make heavy use of clones if it is being efficient. And clones make the outline so much more clear and easy to work though. But I can’t justify using a second text editor for this because orgmode is good enough for this purpose (and can be customized to whatever extent needed). But there are other things I like about Leo (python over elisp, for example) that still make me long to be able to make it a centerpiece of my workflow.

Beyond orgmode, I find that Emacs is much more inviting to customization. I know how to do some coding, and have taught myself python and elisp in the last handfull of years. I do not have the time to do anything serious, but I write scripts for various tasks that I routinely use. In emacs, I understand how to easily create commands, even complex ones, and bind them to shortcuts. I can easily make use of hooks and insertion and movement commands, manipulate text, and really do whatever transformations I can imagine (within a text editor). While I think python is a much more powerful and useful language, my impression is that Leo does not create such an inviting environment (in terms of inviting and enabling users to customize the text editing experience) by comparison. It is very possible that I simply have not looked deep enough, or know enough about python to know how to do all of the things elisp brings to the surface (buffer movement commands, commands like save-excursion, save-restriction, buffer switching, font-locking, etc.).

As I said, I also write programs from time to time and think Leo is much superior to org-babel.

So, the short answer is that I really need orgmode or a viable replacement for it, and I recognize that this is well outside of Leo’s mission, hence my question about Leo inside emacs.

Thanks for inviting further feedback.

[Edward K. Ream]

On Tue, Jun 25, 2019 at 2:32 PM Jeff R. <jrfili...@gmail.com> wrote:

I do not know whether I am remotely close to the intended audience for Leo, but I can say that Leo does not feel far from the type of tool I would use  on a regular basis.

Heh.  I think your interest suffices to make you one of the target audience.

I am also constantly working on a book of research on my areas of practice (constitutional law). My practice area is  academic. In this arena, Leo is superior to orgmode, due mostly to the use of clones. With my subject area it is impossible to create an outline that does not make heavy use of clones if it is being efficient. And clones make the outline so much more clear and easy to work though. But I can’t justify using a second text editor for this because orgmode is good enough for this purpose (and can be customized to whatever extent needed). But there are other things I like about Leo (python over elisp, for example) that still make me long to be able to make it a centerpiece of my workflow.

There is never any reason to apologize for using multiple editors.

Beyond orgmode, I find that Emacs is much more inviting to customization.

... 

While I think python is a much more powerful and useful language, my impression is that Leo does not create such an inviting environment (in terms of inviting and enabling users to customize the text editing experience) by comparison. It is very possible that I simply have not looked deep enough, or know enough about python to know how to do all of the things elisp brings to the surface (buffer movement commands, commands like save-excursion, save-restriction, buffer switching, font-locking, etc.).

It's easy to customize existing Leonine features, which includes many emacs features.  However, adding missing features would require more work.  Please consider requesting particular emacs-like features.  For example, I have no idea what save-restriction or font-locking do.

So, the short answer is that I really need orgmode or a viable replacement for it, and I recognize that this is well outside of Leo’s mission, hence my question about Leo inside emacs.

Many thanks for these comments.  All Leo devs rely on newcomers for new perspectives.  Otherwise, we stick pretty much to our to-do lists :-)

Edward

[Offray Vladimir Luna Cárdenas]

Hi,

Many interesting use case from your original perspective. Leo was my main outliner to (de)construct complex text, as a researcher and PhD student. Clones are a killer feature on that front and I still use Leo to read and organize code which has been written by others.

On your particular request maybe you could see the other way around: Emacs inside Leo. I imagined long ago that the body pane is the (console) editor of choice of the user (Vim, Emacs, Nano, Micro) and is embedded there. All shortcuts and expected behavior from this editor work as expected (is just a console), but it is improved by all the meta-organizing capabilities of Leo. This would imply that embedded editors work in collaboration with Leo tree and such approach would imply to make embedded editor and Leo provide services to each other. I don't know if Pyzo explorations and its server architecture give a hint on that front, but now that we are thinking in this "blue space plane" of ideas, that could be an worthy exploration.

Cheers,

Offray

--
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+...@googlegroups.com.
To post to this group, send email to leo-e...@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/c60fb7b1-8bfe-4cbc-91fe-ab1c6d8c3027%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Edward K. Ream]

On Mon, Jun 24, 2019 at 8:00 AM john lunzer <lun...@gmail.com> wrote:

I think emacs and pharo are extremely similar in scope. That is to say in both cases you can (and are intended to) spend close to 100% of your time within the computing environment. In emacs the features that help facilitate this are dired, vc/magit, and term/shell-commands. 

I spend an enormous amount of my time in dired because it's just so well integrated into the rest of emacs. [snip]]

vc/magit/diff-hl and other features make version control seamless and mostly painless. [snip]

 

Leo is very much like Org. I use Org more like a Jupyter Notebook than anything else. What I utilize most is Org-babel. [snip] Leo does quite a bit of what Org does already, they just do things differently.

[snip] 

If Leo had a multi-node body pane which reflected the indented structure/view shown in the tree pane then it would function more similarly to Org-mode than it does now. [snip].

Many thanks for these comments.   One of my goals for Leo is for it to have all the features in this discussion of emacs. I am not going to rewrite Leo in elisp.  Instead, I'm going to write the appropriate parts of emacs in python.  Or use Almar Klein's code ;-)

Edward

[Jeff R.]

I apologize it's taken me to long to follow up.

Again, for the record, I am a professional who codes for fun, and who enjoys writing tools that I use in my job. I know some python, elisp, and cs basics and use linux. (For example, I do not know what Pyzo is or what it does!)

Here are the reasons why I use emacs:

1. Orgmode

I do everything in orgmode, and by extension, emacs. Scheduling, task management, time tracking, note taking. I am able to change the views of the outline to show my daily agendas. I get warning of upcoming deadlines. I can view a calendar.

For this, I think Leo, through the use of clones, would be well suited. But doing that is itself a huge project. Orgmode has been built collectively for many years, and it would be very difficult to build a version of it that would draw away an experienced emacs user. If done well, it would also attract new users. If really well, that plus python might do it.

2. Elisp

The benefit elisp is that, with just a bit of knowledge, I can write custom functions on the fly, bind them to a shortcut, and be done. While not always pretty of the best tool for the job)))))), elisp opens the possibility of customization. The languge itself provides simple functions for navigating the buffer, navigating betwen buffers, text entry, changing color, etc. (I don't know if there is python library that does this.) It is simple to record macros, switch modes, install packages, and there is a large community.

If I could do this with python, and write code that takes effect immediately and channges functionality in real time, I would love
that. I have no idea whether this is how Leo is, or whether this is common, etc. (I have also no idea what Pyzo is, or most anything else discussed on this listserv.)

Emacs also does an excellent job of exposing its documentation. For example, if you want to see the value of a variable and documentation for it, you press C-h v, and then you'll be prompted for the varialbes name, and the results can be searched through with fuzzy matching. The same can be done with functions with C-h f. You can also navigate to the source code, which shows the source, and all callers and callees. To me this is much more important than dired. I know people swear by magit but I have not learned how to use it.

Also if you want to see some quick videos of emacs-style tricks, checkout the emacs rocks videos on youtube.

Also, elisp is awesome and fun. Not always the most ideal tool, but it's a lisp and that makes it cool.

Regardless, if you could do orgmode--or something like it--in Leo I think that would be a big selling point. It would for me, at least, since python is just easier to use than elisp, no matter how cool it is.

Offered for whatever it is worth.

[john lunzer]

On Thursday, August 1, 2019 at 9:03:36 PM UTC-4, Jeff R. wrote:

For this, I think Leo, through the use of clones, would be well suited. But doing that is itself a huge project. Orgmode has been built collectively for many years, and it would be very difficult to build a version of it that would draw away an experienced emacs user. If done well, it would also attract new users. If really well, that plus python might do it.

There is an important point here, org-mode is kind of an emacs within emacs. It's drowning in "organization" features, which is what many people reference when they talk about org. Leo does have some plug-ins that probably fill in some of the gaps. I think issue 1228 has the potential to start creating some legitimate comparisons between the two tools.

 

If I could do this with python, and write code that takes effect immediately and channges functionality in real time, I would love
that. I have no idea whether this is how Leo is, or whether this is common, etc.

This is a long standing point of conversation in this community. It's a little harder to pull this off in the way emacs does it. Don't forget that emacs/elisp uses global scoping/namespace by default. Because everything in the program is visible and modifiable by any piece of code it makes it super easy to "customize". Scoping and namespaces are much more controlled and isolated in Python and so any kind of "live" customization has to be intentionally built into a program's structure.

 

Emacs also does an excellent job of exposing its documentation. For example, if you want to see the value of a variable and documentation for it, you press C-h v, and then you'll be prompted for the varialbes name, and the results can be searched through with fuzzy matching. The same can be done with functions with C-h f. You can also navigate to the source code, which shows the source, and all callers and callees. 

This is a great point and one I often forget about but use ~400 times a day.  Honestly, I don't think I could use emacs without this. A built-in documentation/help system would go a long way in Leo's accessibility. 

[Edward K. Ream]

On Thu, Aug 1, 2019 at 8:03 PM Jeff R. <jrfili...@gmail.com> wrote:

Here are the reasons why I use emacs: [org mode and elisp].

Thanks for this.  It lead me to a big aha, which I'll describe in another post.

1.

The benefit elisp is that, with just a bit of knowledge, I can write custom functions on the fly, bind them to a shortcut, and be done.

That's what @command and @button do.  They aren't statically bound, so you can change the contents of an @button node/tree and re-execute it with the new code.

The language itself provides simple functions for navigating the buffer, navigating between buffers, text entry, changing color, etc.

Leo's api does all this, using the predefined c, g and p values.

Emacs also does an excellent job of exposing its documentation.

Leo's help-for commands are loosely based on the emacs equivalent.  ipython/jupyter do better at this kind of thing.

Also if you want to see some quick videos of emacs-style tricks, checkout the emacs rocks videos on youtube.

I am aware of this series.  BTW, Leo used to have emacs-style macros.  We retired them because nobody seemed to care.  Of course, as soon as we did that, people started to complain.

Regardless, if you could do orgmode--or something like it--in Leo I think that would be a big selling point. It would for me, at least, since python is just easier to use than elisp, no matter how cool it is.

Imo, Leo is org mode on steroids.  The problem isn't with Leo's outlining, the problem is trying to keep up with the huge number of users continually improving emacs.  Which lead to the Aha...

Edward

[Edward K. Ream]

On Friday, August 2, 2019 at 7:19:47 AM UTC-5, Edward K. Ream wrote:

Thanks for this.  It lead me to a big aha, which I'll describe in another post.

Here it is.

Edward

[Offray Vladimir Luna Cárdenas]

Hi,

Just some comments, now that I have the time.

On 24/06/19 8:00 a. m., john lunzer wrote:
>
>
> The more one uses emacs the more it becomes obvious that it is not an
> editor or an IDE or a PIM, but simply contains all those things. emacs
> is not an integrated development environment (IDE) but rather an
> integrated computing environment (ICE, just coined). It is a
> collection of computing (editing, PIM, development, debugging, version
> control, system management) tools that work well together (seamlessly
> in many case, but certainly not perfect). 
>
> Some may think this statement blasphemous but I think emacs and pharo
> are extremely similar in scope. That is to say in both cases you can
> (and are intended to) spend close to 100% of your time within the
> computing environment. In emacs the features that help facilitate this
> are dired, vc/magit, and term/shell-commands.

I share your thoughts. For me Emacs and Pharo are kind of modern
survivals of long gone ideas of computing from the Symbolics machines
and the Dynabook, with cohesive computing experiences and environments
to support them. Symbolics, done on Lisp (hence elisp) and the Dynabook
done in Smalltalk (hence Pharo). Both, Pharo and Emacs survived by being
able to run inside a hosted operative system, while keeping their ideas
about an Integrated Computing Environment (as you coined, ICE) that you
inhabit most of the time. Org Mode and (in some way) Grafoscopio, bring
outlining capabilities to the Emacs and Pharo ICE's, respectively (but
Org Mode is far mature that Grafoscopio). Because of the original vision
Emacs and Pharo bring live coding and meta-system capabilities to the
ICE, being able to change it in real time from a single language.

Leo, as I have told several times, brings this meta-system capabilities
to the operative system, flat file word, by adding emergent organizing
and execution operations to such files, as defined by the user. The live
coding part is still missing (despite of the @button and @command
utilities) and that's why some of us have talked about IPython
integration and a services architecture.

>  
>
> I spend an enormous amount of my time in dired because it's just so
> well integrated into the rest of emacs. It is as if I have the
> entirety of my file system and network at my finger tips. I can run
> shell commands on any files/folders or subset of files/folders and any
> output goes directly into emacs; this helps keep me in emacs an out of
> the terminal. dired is further enabled by TRAMP which allows you to
> view the file system of remote computers via SSH. TRAMP also makes it
> seamless to edit files on those remote computers. 
>
> vc/magit/diff-hl and other features make version control seamless and
> mostly painless. Being able to see which files have changed (in dired)
> and which lines of my code have changes (via icons in the gutter) at
> all times really helps keep my mind organized and focused. These
> features also help keep me out of the terminal.

I think that Emacs is far better integrated with the host OS that Pharo,
but Pharo is getting there. I think this is related with the primary way
of interaction with the system. While Emacs is more text based, Pharo is
more graphical, so that did that the kind of experience on both
environments focused on the strong points. Emacs in disguising as a text
editor and Pharo in disguising as an Integrated Development Computing
Environment. With Iceberg, Pharo is improving its DVCS integration,
particularly with Git.

With all this I want to underline that that the issue seems to be how
you internalize the hosted environment in your ICE. Leo, Pharo and Emacs
share this concern, but with pretty different approaches.

>
> And then there is Org, which I'm sure you've gotten plenty of requests
> for features from. Leo is very much like Org. I use Org more like a
> Jupyter Notebook than anything else. What I utilize most is Org-babel.
> Org-babel allows you to run any kind of code from anywhere within an
> org file and save the results within the Org file. The nice thing is
> that the syntax highlighting is applied appropriately for every kind
> of block. For example, you can several different pieces of code in
> different languages with different syntax highlighting in the same
> file on the same screen at one time. I think Leo does quite a bit of
> what Org does already, they just do things differently.

Grafoscopio was my attempt to integrate a Jupyter and Leo like
experience, build into Pharo (after unsuccessful attempts to make it in
Python). Because it happened in the context of a Design and Creation PhD
research, that used software as a way to understand and communicate the
problem of moldable artifacts to a grassroots community, and because was
my first program done in Pharo, software was not the only center and a
lot of quality improvements are possible.

I think that many of us are interested in the way we can use computers
to organize our thought and that's why we use outliners and explore what
is being done in that front on other places (Emacs, Org Mode, Mind
mapping, Pharo, etc.). The way we are sharing our concerns and
approaches in this list, make it kind of a unique place.

>
> I'm not there is anything I would recommend that Leo try to do that is
> currently does not that emacs does. You would, I believe, have to turn
> Leo into a full ICE; which I don't think has ever been the goal or aim
> of Leo. Perhaps this just sort of happens over time as features are
> accumulated.
>
> If Leo had a multi-node body pane which reflected the indented
> structure/view shown in the tree pane then it would function more
> similarly to Org-mode than it does now. Whilst there is a benefit to
> the "focus" of seeing only one node at a time, in the cases where I
> use Org-mode I explicitly want/need to see multiple nodes at a time.
> Leo can't give this to me right now. I think this would really open
> Leo up opportunities for Leo, it would be a bit of a paradigm shift
> for Leo. I know that Terry has been working on this but I don't think
> there has been a release. If he doesn't have the time to finish it I'd
> recommend him passing it off to you (Edward) to at least experiment with.
>

I think that Leo as an ICE will be a progressive construction. And will
be different depending on the user. My biggest requirement was live
coding, a la Jupyter, but now that I have that with Grafoscopio, my use
of Leo is more focused in deconstructing others (file based) software. I
use it more to understand other's code and scape from the linear
narrative behind it, imposed by the OS.

I will like to see Leo evolving to a service based way of internalizing
and interacting with the host environment, instead of mainly by
importing and exporting files, because I think that it is already superb
on the front and, as the recently posted Aha on Emacs and Vim modes
show, bidirectional services instead of files can be a more powerful way
to think about what Leo brings to the table of empowering computing
experiences.

Cheers,

Offray