A femtolisp based emacs clone

A femtolisp based emacs clone

[edu500ac]

Dear Members of Gnu.Emacs.help,

A team of engineers, of which I am part, has decided to write a tiny version of
 Emacs. Well, there are many tiny versions of Emacs around: Microemacs, Zile, jmacs to name a few. However, the idea is to be in keeping with the Emacs Philosophy, and not only providing key-binding for Emacs compatibility. By Emacs philosophy, I mean that the new editor must be customizable through a Lisp dialect. The small group under the leadership of Hugh Barney has chosen femtolisp for writing macros and extensions to the editor. As a proof of concept, Hugh Barney designed the architecture of the editor and implemented the main editing functions in 2000 lines of C. The idea is that one should not need to program in C beyond these 2000 lines. Besides this, 2000 lines divided between 12 small files is easy to understand and modify. I mean, even if a developer wants to modify a C source file, s/he can do it easily. The C source files are classified according to their functionality. For instance, commandFemto.c contains the primitive commands; keyFemto.c contains keybyndings. I intend to write a comprehensive documentation on how to modify femto-Emacs C source files.

Initially, Hugh Barney named the new editor - atto. Then he changed the name to femto in acknowledgement of femtolisp. This core femtoEmacs has the following features:

1 - Multiple windows that one can open with C-x 2.

2 - C-x C-f to visit a new file. The arrows rotate the files in the directory.

3 - Multiple buffers.

4 - Utf8 for diacritics, etc.

5 - File browsing through the arrow keys

In summary, femtoEmacs has the keybindings and basic functionality of GNU-Emacs. Well, maybe not the whole functionality, but the authors are pushing in that direction. 

Ed Costa designed the interface with femtolisp and proposed the functions for the interaction between Lisp and femtoEmacs buffers and keybinding:

1 - insert, backward, forward-char, backward-char, etc.

2 - syntax highlighting

3 - parentheses checking (it is not working very well)

The project members have chosen femtolisp because it is small and fast, although they had flirted with TinyScheme. Femtolisp compiler takes less than 100 k on a Macintosh. Besides this, femtolisp is about 4 times faster than Python, slightly faster than Bigloo VM, has lexical scope, and can be made compatible with the language used in the book - Structure and Interpretation of Computer Programs.

By the way, femtolisp has lexical scope, backquote, vectors, IO and memory strings, compacting GC, support for direct use of C data types à la Python, proper tail recursion, printing and reading circular shared structures, exceptions, macros, equal and ordered comparison predicates that work on circular shared structures, etc.

Femto-Emacs is hosted on and can be cloned from github:

git clone https://github.com/FemtoEmacs/Femto-Emacs/

Our ultimate goal is to create a grass-root movement similar to neovim. This way, users will have a tiny emacs that is easy to maintain, but has enough functionality to be useful. We are needing collaboration for:

1 -- Generate mingw binaries for Windows. In general, Windows users do not know how to compile applications from source. Thus the need of binaries for this particular platform.

2 -- Improve the femtolisp interface. For the time being, the only functionalities that the lisp interface has are:

1 --  to move the cursor forward and backward

2 -- to insert text 

3 -- to receive text from selected regions 

4 -- to insert text from the clipboard

5 -- to move the cursor to the beginning of line and to the end of line

6 -- to define keywords for a given language

Collaborators are welcome to provide at least the most basic emacs functions.

Re: A femtolisp based emacs clone

[Gene]

On Sunday, August 21, 2016 at 4:15:05 PM UTC-4, edu5...@gmail.com wrote:
> Dear Members of Gnu.Emacs.help,
> 
> A team of engineers, of which I am part, has decided to write a tiny version of
>  Emacs. Well, there are many tiny versions of Emacs around: Microemacs, Zile, jmacs to name a few. However, the idea is to be in keeping with the Emacs Philosophy, and not only providing key-binding for Emacs compatibility. By Emacs philosophy, I mean that the new editor must be customizable through a Lisp dialect. 

To wit, Scheme is a lisp dialect and it's both BEEN used as the scripting language of EDWIN as distributed with MIT Scheme, AND the lisp engine of emacs is mutating towards Scheme.

Given how small/tiny a Scheme interpreter CAN be -- check out the dialect used in GIMP -- I can't imagine a picolisp interpreter smaller; and Lua seems both tiny and increasingly popular as a language embedded in apps, games, and even TI calculators.

If one wants the syntactic sugar of Picolisp at the cost of being less tiny then by all means HAVE AT IT.

Personally I see EDWIN, GNU Emacs, and GUILE becoming more interoperable as the future unfolds.

Cheers!
  Gene

Re: A femtolisp based emacs clone

[Rusi]

On Monday, August 22, 2016 at 1:45:05 AM UTC+5:30, edu5...@gmail.com wrote:
> Dear Members of Gnu.Emacs.help,
> 
> A team of engineers, of which I am part, has decided to write a tiny version of
>  Emacs. Well, there are many tiny versions of Emacs around: Microemacs, Zile, jmacs to name a few. However, the idea is to be in keeping with the Emacs Philosophy, and not only providing key-binding for Emacs compatibility. By Emacs philosophy, I mean that the new editor must be customizable through a Lisp dialect. The small group under the leadership of Hugh Barney has chosen femtolisp for writing macros and extensions to the editor. As a proof of concept, Hugh Barney designed the architecture of the editor and implemented the main editing functions in 2000 lines of C. The idea is that one should not need to program in C beyond these 2000 lines. Besides this, 2000 lines divided between 12 small files is easy to understand and modify. I mean, even if a developer wants to modify a C source file, s/he can do it easily. The C source files are classified according to their functionality. For instance, commandFemto.c contains the primitive commands; keyFemto.c contains keybyndings. I intend to write a comprehensive documentation on how to modify femto-Emacs C source files.
> 
> Initially, Hugh Barney named the new editor - atto. Then he changed the name to femto in acknowledgement of femtolisp. This core femtoEmacs has the following features:
> 
> 1 - Multiple windows that one can open with C-x 2.
> 
> 2 - C-x C-f to visit a new file. The arrows rotate the files in the directory.
> 
> 3 - Multiple buffers.
> 
> 4 - Utf8 for diacritics, etc.
> 
> 5 - File browsing through the arrow keys
> 
> In summary, femtoEmacs has the keybindings and basic functionality of GNU-Emacs. Well, maybe not the whole functionality, but the authors are pushing in that direction. 
> 
> Ed Costa designed the interface with femtolisp and proposed the functions for the interaction between Lisp and femtoEmacs buffers and keybinding:
> 
> 1 - insert, backward, forward-char, backward-char, etc.
> 
> 2 - syntax highlighting
> 
> 3 - parentheses checking (it is not working very well)
> 
> The project members have chosen femtolisp because it is small and fast, although they had flirted with TinyScheme. Femtolisp compiler takes less than 100 k on a Macintosh. Besides this, femtolisp is about 4 times faster than Python, slightly faster than Bigloo VM, has lexical scope, and can be made compatible with the language used in the book - Structure and Interpretation of Computer Programs.
> 
> By the way, femtolisp has lexical scope, backquote, vectors, IO and memory strings, compacting GC, support for direct use of C data types à la Python, proper tail recursion, printing and reading circular shared structures, exceptions, macros, equal and ordered comparison predicates that work on circular shared structures, etc.
> 
> Femto-Emacs is hosted on and can be cloned from github:
> 
> git clone https://github.com/FemtoEmacs/Femto-Emacs/
> 
> Our ultimate goal is to create a grass-root movement similar to neovim. This way, users will have a tiny emacs that is easy to maintain, but has enough functionality to be useful. We are needing collaboration for:
> 
> 1 -- Generate mingw binaries for Windows. In general, Windows users do not know how to compile applications from source. Thus the need of binaries for this particular platform.
> 
> 2 -- Improve the femtolisp interface. For the time being, the only functionalities that the lisp interface has are:
> 
> 1 --  to move the cursor forward and backward
> 
> 2 -- to insert text 
> 
> 3 -- to receive text from selected regions 
> 
> 4 -- to insert text from the clipboard
> 
> 5 -- to move the cursor to the beginning of line and to the end of line
> 
> 6 -- to define keywords for a given language
> 
> Collaborators are welcome to provide at least the most basic emacs functions.

If you want to write code for the fun of it… Go for it!!
If however you want to improve on gnu-emacs it may be better to discuss what are
the significant problems as of this point
Best as I can see all your features are there or can be added with some elisp
into gnu-emacs quite easily

Re: A femtolisp based emacs clone

[edu500ac]

Hi Rusi.

I don't want to improve on gnu-emacs. It is my favorite editor, and I think that it has every feature that one may need in a text editor. 

The main goal of the femtoemacs project is to provide a tiny emacs clone, for opening small text files with minimum start up. Well, there are small clones that are used to fulfill this niche. To name a few: Zile, jmacs, microEmacs, etc. By the way, femtoemacs is based in one of these clones, to wit, atto and Anthony's editor. What I miss in these clones is the possibility of extending them in Lisp. This is my favorite feature in Emacs. Therefore, femtolisp is a tiny Emacs that one can customize in Lisp. It is a replacement for Zile, jmacs ou microEmacs, not for Emacs. 

In many situations, I need a small editor for a mobile computer or for a cloud computer. It would be great if I had emacs in such a situations, but emacs is large big and difficult to install for this kind of applications. I could use jmacs or Zile in my cloud computer, but in doing so I would give up Lisp customization. With femtoemacs, I will keep lisp scripting. To make a long story short, if you feel the need of using jmacs or microEmacs, then femtoemacs may be a good replacement for these editors, since you can customize it in femtolisp or scheme.

As for femtolisp, it was developed by Jeff Bezanson, the same person that created the Julia language. It is one of the fastest interpreters around, and can be made fully compatible with Scheme.

Re: A femtolisp based emacs clone

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 623 bytes --]


() edu500ac@gmail.com
() Mon, 22 Aug 2016 14:32:35 -0700 (PDT)

   In many situations, I need a small editor for a mobile
   computer or for a cloud computer.

Have you (and your team) considered paring-down GNU Emacs?
Something like temacs + some small set of essential .el files?
If so, why was that approach rejected?

-- 
Thien-Thi Nguyen -----------------------------------------------
 (defun responsep (type via)
   (case type
     (technical (eq 'mailing-list via))
     ...))                              748E A0E8 1CB8 A748 9BFA
--------------------------------------- 6CE4 6703 2224 4C80 7502

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: A femtolisp based emacs clone

[James K. Lowden]

On Mon, 22 Aug 2016 14:32:35 -0700 (PDT)
edu500ac@gmail.com wrote:

> In many situations, I need a small editor for a mobile computer or
> for a cloud computer. It would be great if I had emacs in such a
> situations, but emacs is large big and difficult to install for this
> kind of applications. 

To your point, my biggest disappointment with emacs is its
client-server model.  We have tramp.  We have remote-X.  For
high-latency connections, though, I always revert to terminal emuiation.
For some reason, it's the most responsive.  Hurrah for 1982.  

What we don't have is something like HTTP (or RDP), where the UI agent
is local and the "editing" is executed on the remote, minimizing the
communication between the two. It's funny to think that the interaction
between the GUI and the daemon should need high bandwidth, given that
the data rate is limited by the ability of the human to type and read.
Why should transmitting a page to the GUI be more expensive than
transmitting a page to an xterm?  

Imagine if "emacs --daemon" opened a TCP port instead of a unix domain
socket.  You start emacsclient on whatever gadget you have.  Maybe
it's a Windows box; maybe it's an iPad.  Maybe there's a javascript
implementation, and it runs in the browser.   You connect to your
editor daemon, deal with your document.  Save, exit, disconnect.  If
Amtrak finds a dead spot, you're summarily disconnected, but when you
resume, the client -- just like HTTP -- learns from the server what the
current display looks like, rebuilds it, and you start again.  

If you want to build something new and light, I'd suggest separating
the concern of editing a document from interacting with a user.  It's
not a new idea: arguably screen, sed, and ed do it.  But there's no
editor I know designed for unreliable, slow connections, which often as
not is what the Internet still is .  

--jkl

Re: A femtolisp based emacs clone

[Yuri Khan]

On Wed, Aug 24, 2016 at 10:52 AM, James K. Lowden
<jklowden@speakeasy.net> wrote:

> Imagine if "emacs --daemon" opened a TCP port instead of a unix domain
> socket.  You start emacsclient on whatever gadget you have.  Maybe
> it's a Windows box; maybe it's an iPad.  Maybe there's a javascript
> implementation, and it runs in the browser.   You connect to your
> editor daemon, deal with your document.  Save, exit, disconnect.

This is an interesting idea but you’d have to deal with the issue of
drawing the line: what runs on server and what runs on client.

The one extreme we have now with Tramp is that the server only knows
enough to read and write files, and the client does all the editing.
This requires the client to transfer the file back and forth, and it
is clunky if you already work on the server via ssh and need to edit a
file. (You have to switch context and direct your local Emacs to visit
a specially-formatted filename.)

The other extreme is that the client only does low-level display and
input, and all the editing and rendering happens server-side. This is
available with X forwarding. However this requires all customizations
to also reside on the server, which is unrealistic.

The sweet spot would keep the editor state and basic editing functions
on the server and run display, input and customizations on the client.

Re: A femtolisp based emacs clone

[edu500ac]

Interesting enough, my first idea was to develop a modern clone of the screen-editor, as you have suggested. Therefore, I contacted the owner of the site se-editor.org and asked him whether it would be difficult to add utf8 to his distribution. The answer was that he did not have time and will for doing the job. However, I wrote a clone of the screen-editor in Haskell. The problem with my Haskell screen-editor clone is that Haskell is very hard to install. Then I found atto, an emacs clone written by Hugh Barney. It had the same limitation as the screen-editor, but Hugh Barney was willing to add unicode and parenthesis highlight to atto. The only thing missing was a language for customization. The choice of languages narrowed to Tiny Scheme and femtolisp. Since femtolisp is much faster than Tiny Scheme, almost every member of the group voted for femtolisp. To make a long story short, the femtoemacs team members aims at something similar to the screen-editor. However, they think that it would be a bonus if some compatibility with emacs could be retained.

Conclusion: All team members agree with your post in almost every aspect. The problems you listed are exactly the problems we have.

Re: A femtolisp based emacs clone

[Stefan Monnier]

> To your point, my biggest disappointment with emacs is its
> client-server model.  We have tramp.  We have remote-X.  For
> high-latency connections, though, I always revert to terminal emuiation.
> For some reason, it's the most responsive.  Hurrah for 1982.  

Indeed.  I think you could get the best of both worlds by using an
approach similar to Tramp but running a little tramp-daemon on the other
end, such that we can use a more efficient communication protocol
(e.g. when saving a file we could locally diff it against the last
version (of which the remote daemon would also keep a copy), and then
only send the diff).

This said, even using such a daemon it might be difficult to get good
performance: part of the problem is the number of round-trips.
E.g. when saving a file we have to check if the file was modified in the
mean time and whether saving into a new inode would change the owner
(etc...), which each require a round-trip.  To get rid of these
round-trips, we'd have to shortcut this code and delegate the
higher-level "save file" operation to the remote server, which then has
to perform those tasks but still obeying the locally set customizations
about how to do each one of those tasks.

> not a new idea: arguably screen, sed, and ed do it.  But there's no
> editor I know designed for unreliable, slow connections, which often as
> not is what the Internet still is .  

IIRC the plan9 editor was designed with such a client/server idea.
How well did it work in such high-latency situations I don't know, tho.


        Stefan

Re: A femtolisp based emacs clone

[Ben Bacarisse]

"James K. Lowden" <jklowden@speakeasy.net> writes:
<snip>
> Imagine if "emacs --daemon" opened a TCP port instead of a unix domain
> socket.

It can, can't it?  It may be that the protocol does not work well in the
situation you discuss below, and it might not offer the right level of
security, but it may be worth a try.

> You start emacsclient on whatever gadget you have.  Maybe
> it's a Windows box; maybe it's an iPad.  Maybe there's a javascript
> implementation, and it runs in the browser.   You connect to your
> editor daemon, deal with your document.  Save, exit, disconnect.  If
> Amtrak finds a dead spot, you're summarily disconnected, but when you
> resume, the client -- just like HTTP -- learns from the server what the
> current display looks like, rebuilds it, and you start again.  

<snip>
-- 
Ben.

Re: A femtolisp based emacs clone

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Indeed.  I think you could get the best of both worlds by using an
> approach similar to Tramp but running a little tramp-daemon on the other
> end, such that we can use a more efficient communication protocol
> (e.g. when saving a file we could locally diff it against the last
> version (of which the remote daemon would also keep a copy), and then
> only send the diff).
>
> This said, even using such a daemon it might be difficult to get good
> performance: part of the problem is the number of round-trips.
> E.g. when saving a file we have to check if the file was modified in the
> mean time and whether saving into a new inode would change the owner
> (etc...), which each require a round-trip.  To get rid of these
> round-trips, we'd have to shortcut this code and delegate the
> higher-level "save file" operation to the remote server, which then has
> to perform those tasks but still obeying the locally set customizations
> about how to do each one of those tasks.

A while ago, Tramp has tried this approach, using the FISH protocol
(<https://en.wikipedia.org/wiki/Files_transferred_over_shell_protocol>).
Experience was bad wrt performance, so Tramp removed this protocol meanwhile.

But I'm open to restart such an implementation, if there would be a
better protocol. Preferred an existing one, but we could also design an
own (and write then the server part as well).

>         Stefan

Best regards, Michael.

Re: A femtolisp based emacs clone

[Stefan Monnier]

> A while ago, Tramp has tried this approach, using the FISH protocol
> (<https://en.wikipedia.org/wiki/Files_transferred_over_shell_protocol>).
> Experience was bad wrt performance, so Tramp removed this protocol meanwhile.

I think the problem is round-trips, so the current
file-name-handler-alist operations just don't cut it.

We could either put higher-level ops in there (like `save-buffer'),
which implies replicating the whole `save-buffer' behavior, which is
a lot of work and likely to be not 100% faithful.

Or we could introduce new low-level ops that are asynchronous, and then
rewrite save-buffer to use them.  IOW save-buffer would start with
a bunch of calls like `start-getting-file-attributes' which could
immediately be passed on to the remote side, and later on checks the
return value of those calls as and when needed.


        Stefan