3 ms·

- 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 r

by nabla9 2y ago

- 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.

shprd 2y ago
> Use Common Lisp instead of Emacs Lisp. Interesting, why not a scheme? Is it because the popularity in the industry? I don't know much about Emacs or lisps and looking to understand better
- nabla9 2y ago
  Scheme is smaller, has more static and less interactive philosophy. CL has most things you need straight out of the box. It's more like operating system than programming language. Exactly what Emacs wants to be.
- aidenn0 2y ago
  elisp is more like CL than it is like Scheme; RMS was aware of CL when he was working on emacs, but was suspicious of some of its new features (like lexical binding).
  - anthk 2y ago
    Emacs' Elisp it's pretty close to Common Lisp, any CL user can learn Elisp in days (and the opposite it's true too). There's even a port of PAIP exercises into Elisp: https://github.com/yfuna/paip-el https://github.com/yfuna/paip-el
az09mugen 2y ago
For the Common Lisp part, someone created lem [0], but for the other points I can't tell. I know there is an extension manager being developped, but am not able to judge the robustness. Also that there isn't org-mode. [0] : https://github.com/lem-project/lem https://github.com/lem-project/lem
dokyun 2y ago
> - 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 proprietary Emacs extensions, in which case I would entirely understand it, because then people would be willingly running malware inside their editor. Perhaps this the stance VS Code users like to take towards extensions?
- tmtvl 2y ago
  Well, Emacs does ship with a browser (because of course it does, that kind of thing is what makes Emacs so amazing) and we all remember the XZ Utils near-backdoor, so I think that security measures would be useful for people who decide to use a less trustworthy archive like MELPA or who install extensions with package-vc.
  - anthk 2y ago
    Just create another user account and test your new stuff there.
    - jrootabega 2y ago
      How does one just test for malicious code?
      - jrootabega 2y ago
        Oh, I think I see the strategy: just declare a problem trivial and then don't follow up in any way whatsoever. Genius!
  - dokyun 2y ago
    The biggest security nightmare that web browsers have to deal with is that they are always continuously running random JavaScript. Emacs' browser doesn't handle JS, which is a good thing for a simple browser. Emacs doesn't share this problem in that the Elisp that you run is all chosen by you, and it's always free and never obfuscated. I don't really see how the XZ backdoor is relevant to this conversation, since these types of exploits are the fear of server operators, and generally not people who run user programs like Emacs on their desktop. A rogue Elisp function could delete all of the files in your home directory if it wanted to, but people don't really complain about that because being able to delete files is a desirable function. If you ask me, Emacs is a program where user freedom is and should be the ultimate goal. Adding security features that the user has to jump around 'for his own good' and only really serve as idiot nets are dubiously effective and only hinder this freedom. If someone wants to install a package from a source other than the official archives, then the trust is placed in him to actually look at the source code he's received. Even if you install an official package you should still look at the code, as it's quite useful to know what's going on inside it when you want to configure it or add functionality. The vast majority of packages I use are a single file and tend to not take up more than a few screens, so they are easily understandable.

by nabla9 2y ago

shprd 2y ago

> Use Common Lisp instead of Emacs Lisp. Interesting, why not a scheme? Is it because the popularity in the industry? I don't know much about Emacs or lisps and looking to understand better

nabla9 2y ago
Scheme is smaller, has more static and less interactive philosophy. CL has most things you need straight out of the box. It's more like operating system than programming language. Exactly what Emacs wants to be.
aidenn0 2y ago
elisp is more like CL than it is like Scheme; RMS was aware of CL when he was working on emacs, but was suspicious of some of its new features (like lexical binding).
- anthk 2y ago
  Emacs' Elisp it's pretty close to Common Lisp, any CL user can learn Elisp in days (and the opposite it's true too). There's even a port of PAIP exercises into Elisp: https://github.com/yfuna/paip-el https://github.com/yfuna/paip-el

az09mugen 2y ago

For the Common Lisp part, someone created lem [0], but for the other points I can't tell. I know there is an extension manager being developped, but am not able to judge the robustness. Also that there isn't org-mode. [0] : https://github.com/lem-project/lem https://github.com/lem-project/lem

dokyun 2y ago

> - 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 proprietary Emacs extensions, in which case I would entirely understand it, because then people would be willingly running malware inside their editor. Perhaps this the stance VS Code users like to take towards extensions?

tmtvl 2y ago
Well, Emacs does ship with a browser (because of course it does, that kind of thing is what makes Emacs so amazing) and we all remember the XZ Utils near-backdoor, so I think that security measures would be useful for people who decide to use a less trustworthy archive like MELPA or who install extensions with package-vc.
- anthk 2y ago
  Just create another user account and test your new stuff there.
  - jrootabega 2y ago
    How does one just test for malicious code?
    - jrootabega 2y ago
      Oh, I think I see the strategy: just declare a problem trivial and then don't follow up in any way whatsoever. Genius!
- dokyun 2y ago
  The biggest security nightmare that web browsers have to deal with is that they are always continuously running random JavaScript. Emacs' browser doesn't handle JS, which is a good thing for a simple browser. Emacs doesn't share this problem in that the Elisp that you run is all chosen by you, and it's always free and never obfuscated. I don't really see how the XZ backdoor is relevant to this conversation, since these types of exploits are the fear of server operators, and generally not people who run user programs like Emacs on their desktop. A rogue Elisp function could delete all of the files in your home directory if it wanted to, but people don't really complain about that because being able to delete files is a desirable function. If you ask me, Emacs is a program where user freedom is and should be the ultimate goal. Adding security features that the user has to jump around 'for his own good' and only really serve as idiot nets are dubiously effective and only hinder this freedom. If someone wants to install a package from a source other than the official archives, then the trust is placed in him to actually look at the source code he's received. Even if you install an official package you should still look at the code, as it's quite useful to know what's going on inside it when you want to configure it or add functionality. The vast majority of packages I use are a single file and tend to not take up more than a few screens, so they are easily understandable.