Instead of replicating Emacs, how about replicating the actual Genera Lisp machine?

[tuhdo]

As title suggests, I think you can follow the features described in Genera Lisp machine manuals and make it real in Lem. If this succeeds, Lem would be a unique piece of software not even Emacs can compete.

Here is one manual: http://bitsavers.trailing-edge.com/pdf/symbolics/software/genera_8/Genera_User_s_Guide.pdf

Another manual on Concordia, a document design and viewer system: http://bitsavers.trailing-edge.com/pdf/symbolics/software/genera_8/User_s_Guide_to_Symbolics_Concordia_Book_Design.pdf

A demo (starts at 30:05): https://www.youtube.com/watch?v=jACcgLfyiyM&t=1805s

[Sasanidas]

I think Genera (and other lispOS for that matter) are really interesting from a OS design perspective, but doing an Emacs like editor is already a monumental task, and the Lem project is still very small both in user and collaborators, changing the scope to that even more monumental task, I don't think it would have any benefit to it.
(this is my opinion I don't talk on behalf of the project).

[cxxxr]

Well, I have a longing for genera and some of the features are affected.
And I have already seen some of the videos and documents.

I would like to hear which specific functions you think are useful.

[tuhdo]

I think Genera (and other lispOS for that matter) are really interesting from a OS design perspective, but doing an Emacs like editor is already a monumental task, and the Lem project is still very small both in user and collaborators, changing the scope to that even more monumental task, I don't think it would have any benefit to it. (this is my opinion I don't talk on behalf of the project).

I don't think replicating Emacs is actually easier in its current state. After all, it got over 38 years of development already. Even Emacs tried to replicate many features from Lisp machine, e.g. the Slime debugger and other features are very close to it. Also, I don't think we need to replicate everything from the Lisp OS like Lisp file system and implementation details specific to Lisp hardware, but its user interface, on how the GUI is designed to interact with users.

This can actually save time since we got an abundance of well-documented manuals, as expected from a commercial system.

@cxxxr Off the top of my head, I can think of these:

• Everything is fully inspectable in the system: imagine anywhere you can click, you get the actual Lisp code that you can modify. As you can see from the demo video, text on the screen is not simply text, but are objects with text as their representation. The REPL can track already printed objects and if you click on the previously printed objects on screen and change it, the REPL completion adapts to the new change immediately (demo around 36:00)

• Better REPL: in the demo, the Lisp machine can also print non-Lisp objects, like a list of directories similar to Dired, and then you can interact with it right on the REPL; or a graphical object, e.g. a circle drawn with Lisp code and then you can represent it with a string (around 1:02:50) and this string/graphical circle can be used as a command. The circle is mouse sensitive. Since Lem is made with SDL, isn't it possible to make the REPL graphical aware and be able to print all kinds of textual/non-textual objects?

• The interactions between the mouse and the system feels natural because of objects displayed on screen. In Emacs or Linux terminal, you only work with text and for that reason, the keyboard is much faster and the mouse is neglected.

I will read more on the docs and share interesting features.

[cxxxr]

Indeed, some of those functions can already be done with lem.

• Printing with micros:micros-print associates it with an object and can be clicked on
• Type ",ls" in the REPL to display the current list of files and click on them.

However, the association between shapes and objects is a work in progress.

I would be grateful if you could tell us more about other features.

[tuhdo]

@cxxxr After briefly reading through these manuals, here are my findings:

• Most of the features in Emacs are the same as Zmacs editor in Genera, e.g. input editing commands (character, word, line, paragraph, screen, region, search and replace), buffer commands, windows commands, the modeline. The vocabulary and key bindings are almost the same as well. Other OS-related features like process, file system, network, memory management etc. are already done by SCBL. You can find these features in Genera Handbook and Users Guide to Symbolic Computer. So, implementing the default Emacs is a good progress.

• However, there is one thing in particular, that is GUI programming in Genera. You should have a look at Programming The User Interface manual. This includes information on:

• Creating, modifying, and controlling windows
• Obtaining user input from the keyboard and mouse
• Formatting tables, tree graphs, and other graphics output
• Using the Command Processor facility

It defines how object are presented so that you can inspect it. Not sure currently we can click on something on the buffer and inspect its structure and code that processes it? You should have a look at this document to set a future vision for UI programming. I believe that with a well-defined UI framework, people can create applications for Lem that can match Emacs. It would be great to create real GUI right inside your buffer.

After searching for a while, I realized McClim tried to implement Genera GUI framework, but currently stuck with X backend. If you're on Linux, it's easy to get it up and running for a test with Clouseau, a GUI inspector written with McClim and imo it's much better the one in Slime. You can watch the demo here: https://www.youtube.com/watch?v=-1LzFxTbU9E.

To test it out is easy:

(ql:quickload "mcclim")
(asdf:load-system "clouseau")
(clouseau:inspect ...lisp form...) ;; -> this will pop out the Clouseau inspector

A screenshot of Clouseau inspector from McClim website:

You can click anything to inspect it, down to each character. It would be great if something like that will be available in the future.

Similarly, a demo of McClim's REPL:

As you can see, since Lem already has a graphical backend and you are already implementing graphical buffer, replicate the above features should be very feasible.

Type ",ls" in the REPL to display the current list of files and click on them.

I'm on Windows and does not have this command.

[Sasanidas]

Sorry if I didn't understand the question correctly, indeed as @cxxxr point out, there are a few features that are already implemented by Lem. Still, I'm a big fan of McCLIM and opened an issue on the main repository regarding the implementation of a front-end for Lem using McCLIM (https://codeberg.org/McCLIM/McCLIM/issues/1345).

As an interesting point, McCLIM does have a backend for SDL2 (https://codeberg.org/McCLIM/McCLIM/src/branch/backend-sdl2/Backends/SDL2) and except for Windows (wich with WSL should be possible to run X applications), it should also work on Mac.

[Sasanidas]

I'll close this issue given that it seems like the conversation ended, feel free to open it again if that's not the case 👍

[vindarel]

(I used the "convert to a discussion" button)