[[!meta title="How to build an Emacs"]] [[!meta copyright="Copyright © 2021 Fermin MF"]] [[!inline pages="internal(2021/info/build-nav)" raw="yes"]] # 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: # 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"]]