Emacs is fine, but buggy as hell. Their version of Lisp is clearly not suited for any large-scale development. (This trickles down hard into user experience, i.e., lack of parallelism or multithreading.)
> Emacs is fine, but buggy as hell. Is this so obvious as to go without examples? I'm no Emacs power user, nor even really an Emacs user, but it certainly conflicts with my understanding of core Emacs.
Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
261–270 of 340 posts
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#262Earlier quoted context omitted.
Someone created lem [0] which is basically an Emacs in Common Lisp. I don't know for concurrency but I hope it is designed to do so. Also there isn't org-mode. [0] : https://github.com/lem-project/lem
There have been several recreations of Emacs in Common Lisp over the years, including Hemlock, CEDAR, and Climacs. They never catch on, because they’re not compatible enough with the existing base of emacs lisp software. This also applies to Scheme, although it did get closer to compatibility once or twice. This is also closely tied to why emacs hasn’t been made much more parallelized - fundamentally, the design of e…
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#263I would use a more mainstream dynamic language like python or lua rather than emacs lisp. It has to be dynamic and maintain the flavor of repl-driven development (the whole point of emacs is that it’s one big X repl where today X is emacs lisp). It doesn’t have to be a lisp though.
It feels to me, people suggesting using anything other than Lisp haven't had sufficient, heartfelt experience with Lisps. Give me a Lisp any day, sure, Elisp might not be a best of Lisps, but it's a Lisp nonetheless, there's simply nothing better for evaluating things on the fly, there's no better language for rapid prototyping, for structural editing, for metaprogramming. One has to experience the flow, the fluidity…
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#264Allow for user controllable window layout within the frame, objectively the editor's only significant drawback.
What are you talking about? Emacs has incredibly good window control. It is in fact so good, people decided to build window managers on top of Emacs - see EXWM. Yes, the customization is complex and very confusing for beginners, but the levels of control are all there.
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#265- Use Common Lisp instead of Emacs Lisp. - Design a more modular architecture to make it easier to extend and maintain different components. - Design a more robust plugin system for development and distribution of extensions. - Implement better sandboxing and security measures for extensions. - Better APIs for extension developers. - better multi-threading support baked into the editor.
> - Implement better sandboxing and security measures for extensions. Why, pray tell, should this be of any concern at all? Sandboxing is used when the host is concerned about running programs that he doesn't trust. There is no reason that an Emacs package would require security measures around it, unless it were knowingly potentially malware. The only reality in which I could see this is if people were using proprie…
Trust? Trusting criminals doesn't stop them from committing crime.
You may trust your emacs color theme author. Pretty colors from an innocent artist. You run the theme code without any sandboxing. Everything is going well. Then the author adds a keyloger, project code scrapper, and phone-home feature in his theme.
You update all your emacs packages automatically without any code review. Then you start getting emails from your companies security team asking why you uploaded sensitive projects to a 3rd party.
Wouldn't it make more sense to restirct color themes to color and font related tasks? Why should a color theme be allowed to scrape sensitive code from your disk and upload it to a 3rd party without your consent?
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#266Earlier quoted context omitted.
It feels to me, people suggesting using anything other than Lisp haven't had sufficient, heartfelt experience with Lisps. Give me a Lisp any day, sure, Elisp might not be a best of Lisps, but it's a Lisp nonetheless, there's simply nothing better for evaluating things on the fly, there's no better language for rapid prototyping, for structural editing, for metaprogramming. One has to experience the flow, the fluidity…
Do you have a concrete example of something you can do in a lisp repl like emacs that would be impossible to build into a python repl?
This is a challenging question, it's difficult to answer in a short few sentences. One practical example that immediately comes to mind is the advising system of Emacs, where you can modify specific parts of any given function, which isn't easily achievable with Python.
In a Lisp REPL, you can modify the behavior of the REPL itself on the fly, e.g. advising it to print the execution time of each expression sent to the REPL. The homoiconic nature of Lisp allows us to treat the REPL's evaluation function as data, modify it, and immediately see the results. This level of runtime modification of language constructs is not possible in Python's REPL.
You can get very specific and start challenging that statement. We can talk about bytecode execution, and how you'd need to modify the bytecode at runtime or alter the interpreter's execution loop, or Python's function object structure, or method resolution order. We can talk about descriptor protocol which handles method binding, we can speculate about JIT complications, thread safety, garbage collection, etc. At the end, it all boils down to homoiconicity. The homoiconic nature of Lisp - Code As Data, Uniform representation, Meta-circular Evaluator, etc., all that makes the difference for the things that aren't realistically achievable in non-Lisp languages.
That opens up many interesting practical possibilities, like creating interesting DSLs with minimal syntactic overhead and runtime efficiency.
People love their favorite programming languages for their specific features. They get used to them, it's a matter of familiarity, they get attached to their language of choice. Almost every language book offers you some unprecedented magic with their language. And often programmers look at Lisp as just another programming language, missing the main point about Lisp, which is not one concrete language implementation but the idea as a whole.
Learning Lisp offers something fundamentally different. It's not just about acquiring a new syntax or set of features, but about gaining a new perspective on programming itself. Lisp provides insights into the nature of code and computation that are hard to fully grasp in other languages. The benefit of learning Lisp isn't necessarily in using it for every project, but in how it reshapes your thinking about programming. It can make you a better programmer in any language by deepening your understanding of abstraction, metaprogramming, and the relationship between code and data. Many concepts that originated in Lisp have influenced modern languages. Understanding Lisp can help you appreciate and more effectively use features in other languages that were inspired by Lisp, and that is a pretty much every PL in the TIOBE list.
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#267Earlier quoted context omitted.
What are you talking about? Emacs has incredibly good window control. It is in fact so good, people decided to build window managers on top of Emacs - see EXWM. Yes, the customization is complex and very confusing for beginners, but the levels of control are all there.
display-buffer-alist appeared only in version 24 and is still only a hack to bludgeon the editor into somewhat less insane condition than the default.
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#268Earlier quoted context omitted.
display-buffer-alist appeared only in version 24 and is still only a hack to bludgeon the editor into somewhat less insane condition than the default.
That was 12 years ago. Are you complaining that Emacs got sane window management "only" twelve years ago? Please don't ever get into Node.js ecosystem, the pace of accretion would make you cry, standing in the shower, rocking back and forth.
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#269Earlier quoted context omitted.
> Thank you for your long and thoughtful prose, so fitting for an emacs user. Are you hinting at the fact that I used Emacs to help me write that? Sure I did. Why wouldn't I use Emacs for writing, if all the tools I need are at my fingertips? I have a thesaurus, spellchecking, Google Translate and search, dictionaries, etymology lookup, word counter, Flesch-Kincaid reading ease tester, ChatGPT, Anthropic and other mo…
iLemming you clearly know how to interwebs, well met.
Yet, it's relatively rare for ideas (especially good ones) to become completely invalidated or rendered totally obsolete. Because ideas often retain their value in specific contexts.
I already told you my take on the idea of Vim and modality, it's a wonderful, beautiful, powerful, and pragmatic model. Now, Emacs builds on the cornerstone of another incredibly powerful idea - the idea of practical notation for lambda calculus, which is known as Lisp. Lisp probably can be crowned as one of the most important ideas in computer science. It's just hard to think of anything more influential than Lisp. Any programmer who dismisses the idea of Lisp based on one concrete implementation of it is misguided.
At some point, after many cycles of frustration, amazement, inspiration and awe you will learn to appreciate certain ideas. I'm not selling you Emacs or Vim here - not one concrete implementation of a concept. I'm just trying to tell you - some ideas are worth learning more, before dismissing them as needless or impractical.
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#270Earlier quoted context omitted.
That was 12 years ago. Are you complaining that Emacs got sane window management "only" twelve years ago? Please don't ever get into Node.js ecosystem, the pace of accretion would make you cry, standing in the shower, rocking back and forth.
Buddy I started using Emacs at version 1.8, and no display-buffer-alist is not "sane". Just maintaining a stable window arrangement in the frame is not something easily possible.
Overall, I'm personally happy with Emacs window management, it's highly customizable and extensible, it gives you powerful keyboard-centric control, it supports complex layouts, it is deeply integrated within Emacs' vast ecosystem. There are packages like ace-window, winum, winner-mode, golden-ratio, shackle, popwin, eyebrowse, perspective, window-purpose, etc. I don't know what you're complaining about, I guess because I have not seen something even better than that.