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 -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/a584a34b-d104-2c16-e72a-c49ac72323a2%40riseup.net.
