6 ms·

I agree, but I think at least some of the animosity stems from how the author might not have been able to do this themselves if they wanted to: > Without being

I agree, but I think at least some of the animosity stems from how the author might not have been able to do this themselves if they wanted to: > Without being limited by public API design, we could use (2,3)-trees, recursion-free tree-traversal, bit-arithmetic, incremental parsing, and other techniques to reduce the extension's worst-case update time-complexity (that is the time required to process user-input when a document already has been opened) from \mathcal{O}(N + E)O(N+E) to \mathcal{O}(\mathrm{log}^3 N + E)O(log 3 N+E) with NN being the document size and EE the edit size, assuming the nesting level of bracket pairs is bounded by \mathcal{O}(\mathrm{log} N)O(logN). just hurts to see after having been burned by Apple's private APIs blocking legitimate app developers from doing something Apple will release next cycle themselves, even if it was to everyone's benefit and a net positive

dariusj18 5y ago
Yes, but I feel like extensions are not considered "apps" in a way that would make people feel they should be able to write anything they want to change the editor. That way lies madness.
- 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.
  - 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.
- mastax 5y ago
  Tale as old as time: VSCode vs Atom WebExtensions vs XUL Mod API vs patching game files Vim vs emacs
  - w0m 5y ago
    Oddly; I don't know anyone who ever did more than demo Atom...
    - neonbones 5y ago
      I used Atom before VSCode. I'm still in love with its minimalistic design and somehow font rendering in Atom better than in VSCode (still not sure why, I tried to play with settings and stuff, but nothing changed). It was the first prominent Sublime Text alternative with JS that I use every day and quickly wrote my extensions, hack it and play with it. There were even interesting decisions like a Rust-based rendering engine[1] using graphics without HTML and DOM (the same old problem with faster text rendering with web techs). In my opinion, the ONE big thing that killed Atom was LSP[2]. VSCode was slightly better in everything, but good performance and LSP destroyed Atom and damaged all other editors (like Sublime). But MS plays dirty here too. In VSCode, LSP works with many inner hacks. You can't get the same experience with LSP in other editors because some features are part of the editor, not just LSP. But I think LSP is excellent and use it in Emacs and Vim too. For Rust, it's maintained by the Rust team and the default "engine" for editors. Anyway, I'm still using Atom today with a minimalistic theme and setup to edit markdown files with code and as a text editor with a friendly GUI overall. 1) https://github.com/atom-archive/xray https://github.com/atom-archive/xray 2) https://langserver.org/ https://langserver.org/
maccard 5y ago
> I agree, but I think at least some of the animosity stems from how the author might not have been able to do this themselves if they wanted to What animosity? The animosity other people have on behalf of the author who has clearly said he has no beef with this series of events? If the author wanted to make algorithmic changes like the VS code team have done, I'm sure they would have been more than happy to discuss this on the open source issue tracker (which is very active). > just hurts to see after having been burned by Apple's private APIs blocking legitimate app developers from doing something Apple will release next cycle themselves, The big difference here being that the app developers are happy that this has happened, and they could have attempted to do this work because even though the APIs are private, the source is available and they readily take pull requests.
- thaumasiotes 5y ago
  > The big difference here being that the app developers are happy that this has happened I don't see why this would make a difference. Say I'm working on a project. There's a hole in my project. And you offer something to fill the hole. But your action can't then bind me to refrain from fixing my project. Once my project no longer has a hole in it, you've lost a line of business. But you've lost that line of business because it solved a problem that was correctly fixed. The situation now is obviously better than the situation before. If I needed permission from you to fix my own thing, how could that conceivably improve anything?

dariusj18 5y ago

Yes, but I feel like extensions are not considered "apps" in a way that would make people feel they should be able to write anything they want to change the editor. That way lies madness.

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.
- 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.
mastax 5y ago
Tale as old as time: VSCode vs Atom WebExtensions vs XUL Mod API vs patching game files Vim vs emacs
- w0m 5y ago
  Oddly; I don't know anyone who ever did more than demo Atom...
  - neonbones 5y ago
    I used Atom before VSCode. I'm still in love with its minimalistic design and somehow font rendering in Atom better than in VSCode (still not sure why, I tried to play with settings and stuff, but nothing changed). It was the first prominent Sublime Text alternative with JS that I use every day and quickly wrote my extensions, hack it and play with it. There were even interesting decisions like a Rust-based rendering engine[1] using graphics without HTML and DOM (the same old problem with faster text rendering with web techs). In my opinion, the ONE big thing that killed Atom was LSP[2]. VSCode was slightly better in everything, but good performance and LSP destroyed Atom and damaged all other editors (like Sublime). But MS plays dirty here too. In VSCode, LSP works with many inner hacks. You can't get the same experience with LSP in other editors because some features are part of the editor, not just LSP. But I think LSP is excellent and use it in Emacs and Vim too. For Rust, it's maintained by the Rust team and the default "engine" for editors. Anyway, I'm still using Atom today with a minimalistic theme and setup to edit markdown files with code and as a text editor with a friendly GUI overall. 1) https://github.com/atom-archive/xray https://github.com/atom-archive/xray 2) https://langserver.org/ https://langserver.org/

maccard 5y ago

> I agree, but I think at least some of the animosity stems from how the author might not have been able to do this themselves if they wanted to What animosity? The animosity other people have on behalf of the author who has clearly said he has no beef with this series of events? If the author wanted to make algorithmic changes like the VS code team have done, I'm sure they would have been more than happy to discuss this on the open source issue tracker (which is very active). > just hurts to see after having been burned by Apple's private APIs blocking legitimate app developers from doing something Apple will release next cycle themselves, The big difference here being that the app developers are happy that this has happened, and they could have attempted to do this work because even though the APIs are private, the source is available and they readily take pull requests.

thaumasiotes 5y ago
> The big difference here being that the app developers are happy that this has happened I don't see why this would make a difference. Say I'm working on a project. There's a hole in my project. And you offer something to fill the hole. But your action can't then bind me to refrain from fixing my project. Once my project no longer has a hole in it, you've lost a line of business. But you've lost that line of business because it solved a problem that was correctly fixed. The situation now is obviously better than the situation before. If I needed permission from you to fix my own thing, how could that conceivably improve anything?