Re: Question: what is Emacs mode?

[Qiantan Hong <qhong@mit.edu>]

> Is it editor or OS?
> 
> From Emacs user viewpoint that abbreviation "editor/OS" actually makes
> sense as Emacs could be, almost could be the OS itself. 
Yes, and my understanding is that as long as some software commit to
a statement of the form “everything is X” (I call it ontology),
it will become an OS (because people will do everything with X).

- UNIX commit to “everything is file, aka big bagged of unstructured bits”

- Emacs (maybe unintentionally) makes everything text (with some attached 
text-properties). Alas now people are using text (w/ properties) 
to make outlines, tables, images…

- Browsers makes every data XML and every code JavaScript (line between
code and data is a little blurred, but definitely not like Lisp). You get what you 
get.

- Smalltalk commit to “everything is object”. And you get OS also.

This understanding is exactly what motivate me to start designing my
own editor/OS/computing environment. Now when you spell out the “X”
in “everything is X”, IMO it become apparent that the above examples
don’t make particularly good choices.

Everyone knows UNIX sucks (unstructured bits err), browser sucks
(no homoiconicity). Smalltalk lack a good editing protocol for
standard objects (you can’t forward-sexp backward-sexp to roam
in the object graph), while Emacs isn’t that structured. In fact, Emacs
is just a little bit better than UNIX in terms of ontology.

That makes me wonder if we can make a better environment by
committing to “everything *visual* is s-expr” (I don’t want to make
everything in the system s-expr, because sometimes hash tables and
vectors are fast. There’s a present/recognize system to map them
to visual s-expr when user want to see them). 
And then one can use the standard structured s-expr editing commands
to edit the whole live system.
The model is kind of like CLIM, except that it’s much more, because
CLIM doesn’t touch editing of presentations (the original AITR 794 did).

>> And finally, let me give the context that all those question arises:
>> I want to clean up the Emacs model, and apply it to a S-exp (tree)
>> based editor. So the practical question is: Can we find a
>> cleaner/more elegant version of the Emacs model, and generalize it
>> to tree document structure? Will we have node-local variables,
>> node-local modes, etc? If so, how will all those "attachments"
>> interact between, say, parents and children nodes?
> 
> I do understand the intention. Not that it is clearly explained.
> 
> Can you tell more about storing things in the tree?

As I said above, I’m going to use s-expr as the primary data structure,
a document is just an s-expr. That opens up some new possibilities 
but also associated problems:

(I just realized I think I answered most of them myself, but I’m not confident
with my answers)

1. Do we want node-local modes? 
    That looks very natural to have. We may edit our code using sexp-mode,
    but inside docstring, we could use doc-mode locally.
    This also covers lots of thing in Emacs that were done using text-properties.
    E.g. bold-mode and background-color-mode (not sure if they’re good idea though).

2. If we have node-local modes, what about node-local variables?
    Virtually all modes use buffer local variables. If we have node-local modes,
    do they all share the buffer-local environment? That sounds like a mess.
    This is one point where I can’t decide between introducing node-local variables,
    or try to figure out a “cleaner” version of modes that don’t need *-local variables.

3. Suppose we now have node-local variables and node-local modes, what’s the relation
    between those of parent nodes and child nodes?
    It seems natural to let child node inherit modes and variables from parent nodes.
    E.g., I might just turn on outline-mode on the ‘((Section title-A …)) node in
    (defun very-complex-function-that-require-a-paper ()
      ‘((Section title-A
         (Paragraph lorem ipsum)
          (Section subtitle-B
            (Paragraph lorem ipsum))))
        *code*)
    And it affects the whole sub-tree.
    However, are there cases that one don’t want a whole subtree to inherit a mode/variable?
    Can we safely assume they all get inherited?

If we assume yes, then we arrives at node-local first-class environment.
Each node may have an environment, chained to the environment of its parent.
It turns out that we don’t seem to need seperate window management as well,
each frame can just display a *frame-root-sexp* in window-mode, and some of it
child turns on buffer-mode, which essentially becomes buffers.

This raises another questions though. Apparently window-mode and buffer-mode
need to be exclusive. In emacs, there is one and only one exclusive set of modes,
managed by the major-mode variable. Are we sure there only need to be one exclusive set?