summaryrefslogblamecommitdiffstats
path: root/2021/talks/build.md
blob: 7ec0da46660be021163c9a97123d17f070a92175 (plain) (tree)
1
2
3
4
5
6
7
8
9
10









                                                                                 
 
 

                                                                















                                                                  


















                                                                                                                                                                                                                                                                 
 
                                                           
 
                                                           
[[!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

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"]]