Back to the schedule
Previous: How to help Emacs maintainers?
Next: M-x Forever: Why Emacs will outlast text editor trends

How to build an Emacs

Fermin MF

Q&A: live
Duration: 16:54

If you have questions and the speaker has not indicated public contact information on this page, please feel free to e-mail us at emacsconf-submit@gnu.org and we'll forward your question to the speaker.

Talk

Q&A

Description

Work in progress: main talk does not have captions (Volunteered: João Pedro)

This talk does not have captions yet. Would you like to help caption this talk? You may be able to start with these autogenerated captions and timing information.

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)

Back to the schedule
Previous: How to help Emacs maintainers?
Next: M-x Forever: Why Emacs will outlast text editor trends