[[!meta title="How to build an Emacs"]]
[[!meta copyright="Copyright © 2021 Fermin MF"]]
[[!inline pages="internal(2021/info/build-nav)" raw="yes"]]

<!-- You can manually edit this file to update the abstract, add links, etc. --->


# How to build an Emacs
Fermin MF



[[!inline pages="internal(2021/info/build-schedule)" raw="yes"]]

This is a deep dive in the Emacs philosophical and technical
aspect on what makes our beloved GNU Emacs
what it it. It's also a talk about the early LISP machines and
fascinating were those days of experimentation and engineering.

It will continue with the Emacs benefits/trade-offs from an
user/developer stand points, what things can be improved and
what can be an hypothetical path on how to build a software that
can also be called Emacs.

As a last part, I'll talk about CEDAR, an Emacs that I've been
developing in Common Lisp, the project goals
and the challenges.

For more details about CEDAR: <https://gitlab.com/sasanidas/cedar>

# Discussion

Pad:

-   Q1: Which level of compatibility with GNU Emacs do you want to achieve?
    -   A: I want to achieve 100% compatibility (when possible)
-   Q2: Are you then planning to reimplment all Emacs C primitives?
    -   A:No, the underlayer would be different
-   Q3: Do you plan on doing something to ease interaction between redundant "components" in both Elisp and Common Lisp (like CLOS and EIEIO)? How about semantic differences between both?
    -   A: (Probably answered by voice.)
-   Q4: Have you used Nyxt, which is Emacs-like and written in Common Lisp? If so, what did you think about it?
    -   A: I think it's a great project and I would like to use it as a my main Browse (with the firefox extension layer)
-   Q5: "Emacs is a great operating system, just lacking a good editor." How do you feel about the push to use Emacs as a full computing interface, and do you think Cedar could thrive in some of the fully common lisp system ideas that might catch on (like Robert Strandh's proposed CLOSOS)?
    -   A: I think CEDAR can achieve more integration with the OS (the same as the CL implementations) but I think the goal of been a good Emacs is good enought

IRC nick: akrl

- I think the performance stuff is mostly orthogonal to elisp.  ex. very large files or files with really long lines grind horribly.
- agreed, it's typically the massive amount of code that needs to interact with eachother that causes the slowdown but Emacs Lisp itself seems fairly performant.
- there is a WIP CL implementation written called SICL :) 
  - akrl: yes but is bootstrapped from SBCL, so... :)
- I know of three or four other attempts to write CL Emacsen. All long dead...
- fundamentally there are not very many CL developers: there are probably many more elisp developers by now. C (and C++, and Java, and heck probably F# and Rust) have way more developers, so will always be more likely to gain enough momentum to not just die
- the fashionable languages have lots of users but tend to fade away, CL is undead for ages... I would help in a CL implementation
- I think everyone should write their own editor at some point.  It's a very good learning experience.
  - Alan Kay says a similar thing about writing your own operating system
  - With Emacs you get both! :-)
- I would love to see '#_' reader macro in Elisp for comments. core.async port and maybe, immutable collection (but that one is too much to ask)
- isn't that what Xi-editor tried to build on?
  - it's definitely what xray tried to build on
- akrl: I'm extremely skeptical on the feasibility of reaching 100% compatibility :) (with an approachable effort)
  

[[!inline pages="internal(2021/captions/build)" raw="yes"]]

[[!inline pages="internal(2021/info/build-nav)" raw="yes"]]