6 ms·

> That way lies madness That way lies Emacs ;) That's the key difference between Emacs and most other editors: there's no limited API for extensions. There's

by yaantc 5y ago

> That way lies madness That way lies Emacs ;) That's the key difference between Emacs and most other editors: there's no limited API for extensions. There's a base C runtime, and all the lisp code on top is at the same level. There is no difference in access rights between a core Emacs package (coming with Emacs) and an additional, user installed package. Of course, there are a lot of documentation, conventions and best practices to support this. And all the code is accessible.

mastax 5y ago
What happens when multiple packages want to modify the same code?
- derefr 5y ago
  I have only the slightest passing knowledge of ELisp, but I believe it offers Aspect-Oriented Programming (AOP) facilities; most basically, chained decorators (i.e. replacing a function with your proxy for that function, where your definition of the function gets bound dynamically to the current definition of the function at eval-time; so the call your function makes to the “inner” function, could just be to another proxy wrapper function someone else already inserted.)
  - db48x 5y ago
    That is the most complicated description of it I have ever seen, but it is accurate. In total there are ten ways to combine new advice with the existing set of methods, but the most commonly used are :before, :after, and :around. All the :before functions are called first, then the outermost :around function (which may or may not call the next :around function), then finally the :after functions. Also it is common to define explicit hooks, which are just lists of functions that you will call at documented points. This is functionally identical to advice, except that it is also a good signal that the author intended you to do so. The terminology is interesting too. Advice is deliberately modeled after the generic method combinators in Common Lisp. One of the authors of the Common Lisp spec, Gregor Kiczales, went on to define the term “Aspect–Oriented programming” and later developed AspectJ. Although the phrase appears nowhere in the documentation for Emacs Lisp, it is definitely appropriate!
    - derefr 5y ago
      I'd love to hear a more-concise description of what I just flailed around trying to describe; I'm always in the market for pithy explanations :)
      - db48x 5y ago
        Hmm. I don’t think concision is really the right way to go; below a certain length a description just becomes less precise and useful rather than better. I think that my own description should have had another paragraph or two, looking back at it. Or maybe we could both be more concise by just telling people to go read The Art of the Metaobject Protocol.
- NoGravitas 5y ago
  Usually packages don't modify code in core Emacs or in other packages. Often, they use package-supplied "hooks" to add behavior to other packages. Failing that, there's the possibility of 'advising' functions to add/change behavior at certain points without actually monkeypatching. I've never seen a distributed package actually monkeypatch anything, though it is something you could do in your personal config.
  - natrys 5y ago
    Yeah and even in personal config one could use el-patch[1], to make monkeypatching future proof. [1] https://github.com/raxod502/el-patch https://github.com/raxod502/el-patch
- tikhonj 5y ago
  You know, I haven't thought much about this. I use a lot of third-party packages and have a lot of my own custom code, but things almost never interfere. In the few cases that crop up (for example, awkward interactions between org-mode's completion and the completion plugin system I use), it was so easy to add some code to my .emacs file to fix that problem that I had no real problems with it.
sroussey 5y ago
This is. Loser to the original Firefox extension model — pen access to everything. It later limited internal changes as internal stuff was external to extensions. It did allow powerful things like Firebug, which could not be build with todays modern and more secure locked down APIs.
- sroussey 5y ago
  This is similar to the original Firefox extension model… (Ug, the way autocorrect works sometimes..)
NoGravitas 5y ago
This article is especially interesting to me, as it shows how VS Code still doesn't have the "Emacs nature". Even though I'm a 30-year Emacs user, I do hesitate to recommend it to younger programmers because it's so alien, and VS Code has one of the essential characteristics of Emacs: the extension language and the implementation language are the same. But this article is a great example of how it doesn't — extensions are limited to using an extension API, rather than having full access to the application's internals. Maybe a good thing, if you're a mass-market product worried about malicious extensions. But I'll note that [rainbow-delimiters-mode](https://github.com/Fanael/rainbow-delimiters/ https://github.com/Fanael/rainbow-delimiters/) dates back to 2010, and has never noticeably slowed down loading or display of source files, even in languages with lots of delimiters like Lisp.
- deleted 5y ago
  [deleted]
- vbezhenar 5y ago
  I think that it's not about malicious extensions. It's about compatibility. If there's no public API, then all API is public and any code change will break something. So you either break extensions or don't change code at all. With public API you can change code while keeping public API working. And if something must be changed, the damage is limited and controlled.
  - db48x 5y ago
    The Emacs maintainers seem fairly conservative about changes to the Emacs runtime, but they have managed a number of extensive changes. It even has JIT compiling now. Partly this is because the nature of the Lisp language makes these changes easier, but it is also the case that many “extensions” are actually included with Emacs. There are over a 1.5 million lines of lisp code that are included in the Emacs repository, though most of them are not enabled by most users. Other extensions come from a wide variety of sources (and of course many users write their own code), but over the last 10 years most of them have been moved into installable packages hosted on elpa.gnu.org. There is a little over a million lines of code there. It takes just a couple of minutes to check out both git repositories (for Emacs and ELPA), so any time you want to change something in Emacs it is quite easy to search all of that and find out exactly what, if anything, you might break.
hoseja 5y ago
This is the only viable extension/modding architecture.
dariusj18 5y ago
I gotta say, "That way lies madness" == "That way lies Emacs" gave me a good chuckle. But your point is good, there are ways to do it, but VSCode has already started down the road of security first, and the emacs model would certainly not function in a sandbox.

by yaantc 5y ago

mastax 5y ago

What happens when multiple packages want to modify the same code?

derefr 5y ago
I have only the slightest passing knowledge of ELisp, but I believe it offers Aspect-Oriented Programming (AOP) facilities; most basically, chained decorators (i.e. replacing a function with your proxy for that function, where your definition of the function gets bound dynamically to the current definition of the function at eval-time; so the call your function makes to the “inner” function, could just be to another proxy wrapper function someone else already inserted.)
- db48x 5y ago
  That is the most complicated description of it I have ever seen, but it is accurate. In total there are ten ways to combine new advice with the existing set of methods, but the most commonly used are :before, :after, and :around. All the :before functions are called first, then the outermost :around function (which may or may not call the next :around function), then finally the :after functions. Also it is common to define explicit hooks, which are just lists of functions that you will call at documented points. This is functionally identical to advice, except that it is also a good signal that the author intended you to do so. The terminology is interesting too. Advice is deliberately modeled after the generic method combinators in Common Lisp. One of the authors of the Common Lisp spec, Gregor Kiczales, went on to define the term “Aspect–Oriented programming” and later developed AspectJ. Although the phrase appears nowhere in the documentation for Emacs Lisp, it is definitely appropriate!
  - derefr 5y ago
    I'd love to hear a more-concise description of what I just flailed around trying to describe; I'm always in the market for pithy explanations :)
    - db48x 5y ago
      Hmm. I don’t think concision is really the right way to go; below a certain length a description just becomes less precise and useful rather than better. I think that my own description should have had another paragraph or two, looking back at it. Or maybe we could both be more concise by just telling people to go read The Art of the Metaobject Protocol.
NoGravitas 5y ago
Usually packages don't modify code in core Emacs or in other packages. Often, they use package-supplied "hooks" to add behavior to other packages. Failing that, there's the possibility of 'advising' functions to add/change behavior at certain points without actually monkeypatching. I've never seen a distributed package actually monkeypatch anything, though it is something you could do in your personal config.
- natrys 5y ago
  Yeah and even in personal config one could use el-patch[1], to make monkeypatching future proof. [1] https://github.com/raxod502/el-patch https://github.com/raxod502/el-patch
tikhonj 5y ago
You know, I haven't thought much about this. I use a lot of third-party packages and have a lot of my own custom code, but things almost never interfere. In the few cases that crop up (for example, awkward interactions between org-mode's completion and the completion plugin system I use), it was so easy to add some code to my .emacs file to fix that problem that I had no real problems with it.

sroussey 5y ago

This is. Loser to the original Firefox extension model — pen access to everything. It later limited internal changes as internal stuff was external to extensions. It did allow powerful things like Firebug, which could not be build with todays modern and more secure locked down APIs.

sroussey 5y ago
This is similar to the original Firefox extension model… (Ug, the way autocorrect works sometimes..)

NoGravitas 5y ago

This article is especially interesting to me, as it shows how VS Code still doesn't have the "Emacs nature". Even though I'm a 30-year Emacs user, I do hesitate to recommend it to younger programmers because it's so alien, and VS Code has one of the essential characteristics of Emacs: the extension language and the implementation language are the same. But this article is a great example of how it doesn't — extensions are limited to using an extension API, rather than having full access to the application's internals. Maybe a good thing, if you're a mass-market product worried about malicious extensions. But I'll note that [rainbow-delimiters-mode](https://github.com/Fanael/rainbow-delimiters/ https://github.com/Fanael/rainbow-delimiters/) dates back to 2010, and has never noticeably slowed down loading or display of source files, even in languages with lots of delimiters like Lisp.

deleted 5y ago
[deleted]
vbezhenar 5y ago
I think that it's not about malicious extensions. It's about compatibility. If there's no public API, then all API is public and any code change will break something. So you either break extensions or don't change code at all. With public API you can change code while keeping public API working. And if something must be changed, the damage is limited and controlled.
- db48x 5y ago
  The Emacs maintainers seem fairly conservative about changes to the Emacs runtime, but they have managed a number of extensive changes. It even has JIT compiling now. Partly this is because the nature of the Lisp language makes these changes easier, but it is also the case that many “extensions” are actually included with Emacs. There are over a 1.5 million lines of lisp code that are included in the Emacs repository, though most of them are not enabled by most users. Other extensions come from a wide variety of sources (and of course many users write their own code), but over the last 10 years most of them have been moved into installable packages hosted on elpa.gnu.org. There is a little over a million lines of code there. It takes just a couple of minutes to check out both git repositories (for Emacs and ELPA), so any time you want to change something in Emacs it is quite easy to search all of that and find out exactly what, if anything, you might break.

hoseja 5y ago

This is the only viable extension/modding architecture.

dariusj18 5y ago

I gotta say, "That way lies madness" == "That way lies Emacs" gave me a good chuckle. But your point is good, there are ways to do it, but VSCode has already started down the road of security first, and the emacs model would certainly not function in a sandbox.