5 ms·

Sort of depends on what is meant by a plug-in architecture. I think it's begging the question a bit. I can compare writing extensions to Firefox and extensions

by troels 12y ago

Sort of depends on what is meant by a plug-in architecture. I think it's begging the question a bit. I can compare writing extensions to Firefox and extensions to Emacs and it's pretty much the same experience, if that helps?

hollerith 12y ago
>depends on what is meant by a plug-in architecture. I'll give examples. I love how easy it is to change or customize Emacs. E.g., if I want to change what happens when I right click on some text, I can do so (and have done so) by writing some Emacs Lisp code (and only 27 lines of Emacs Lisp code at that) -- leaving the parts of Emacs written in C completely untouched. In other words, in Emacs (and IIUC Light Table), with very few exceptions, all of the editor’s functionality is exposed via "APIs" (and in Emacs, it would be accurate to replace "APIs" with "variables and functions" since Emacs does not have classes and such) written in a high-level scripting language (Emacs Lisp or ClojureScript). The same cannot be said of Textmate, Sublime Text or Lime Text. What one can say of those three, though, is that they all have a plug-in architecture. So, my question, again, is whether the OP is correct in his assertion that -- at least for people who are in the habit of frequently changing many different aspects of their editor -- having a plug-in architecture is no substitute for having virtually all of the editor's functionality exposed via "APIs" written in a high-level language.
- girvo 12y ago
  Interestingly, once you enable the developer tools, Komodo is very similar to what you're describing. Pretty much everything is exposed as an API to the JavaScript environment, you can change stuff on the fly and the like. It also has a Python API for certain features. I think that's a consequence of being based on XUL, a web browser is similar to emacs in terms of runtime extensibility, though not 100% of the way there.
hollerith 12y ago
>I can compare writing extensions to Firefox and extensions to Emacs and it's pretty much the same experience, if that helps? Yes, that helps. When I go to the Add-on Manager and select the tab labelled "Extensions", I see a list of things like Adblock Plus. Are those things what you meant when you wrote "extensions to Firefox". If not, then, well, an example would be great.
- troels 12y ago
  Yes, it is. But I think Staltek may be right in that Firefox essentially takes the same approach as emacs and lets extensions access the main application runtime directly (Although with some security constraints).
Steltek 12y ago
That's a flawed comparison. Firefox takes the Emacs approach. All of Firefox is built of XUL, Javascript, and the gang. Lots of apps expose a C plugin API, many apps expose some scripting. I don't think the population of apps exposing a comprehensive scripting API that mirrors the internal C structure is that large. Chrome might be better.You can't do whatever you want with Chrome, it has to be published to the scripting interface first. Early versions of Chrome had trouble supporting a lot of common Firefox extensions for this reason.

by troels 12y ago

hollerith 12y ago

>depends on what is meant by a plug-in architecture. I'll give examples. I love how easy it is to change or customize Emacs. E.g., if I want to change what happens when I right click on some text, I can do so (and have done so) by writing some Emacs Lisp code (and only 27 lines of Emacs Lisp code at that) -- leaving the parts of Emacs written in C completely untouched. In other words, in Emacs (and IIUC Light Table), with very few exceptions, all of the editor’s functionality is exposed via "APIs" (and in Emacs, it would be accurate to replace "APIs" with "variables and functions" since Emacs does not have classes and such) written in a high-level scripting language (Emacs Lisp or ClojureScript). The same cannot be said of Textmate, Sublime Text or Lime Text. What one can say of those three, though, is that they all have a plug-in architecture. So, my question, again, is whether the OP is correct in his assertion that -- at least for people who are in the habit of frequently changing many different aspects of their editor -- having a plug-in architecture is no substitute for having virtually all of the editor's functionality exposed via "APIs" written in a high-level language.

girvo 12y ago
Interestingly, once you enable the developer tools, Komodo is very similar to what you're describing. Pretty much everything is exposed as an API to the JavaScript environment, you can change stuff on the fly and the like. It also has a Python API for certain features. I think that's a consequence of being based on XUL, a web browser is similar to emacs in terms of runtime extensibility, though not 100% of the way there.

hollerith 12y ago

>I can compare writing extensions to Firefox and extensions to Emacs and it's pretty much the same experience, if that helps? Yes, that helps. When I go to the Add-on Manager and select the tab labelled "Extensions", I see a list of things like Adblock Plus. Are those things what you meant when you wrote "extensions to Firefox". If not, then, well, an example would be great.

troels 12y ago
Yes, it is. But I think Staltek may be right in that Firefox essentially takes the same approach as emacs and lets extensions access the main application runtime directly (Although with some security constraints).

Steltek 12y ago

That's a flawed comparison. Firefox takes the Emacs approach. All of Firefox is built of XUL, Javascript, and the gang. Lots of apps expose a C plugin API, many apps expose some scripting. I don't think the population of apps exposing a comprehensive scripting API that mirrors the internal C structure is that large. Chrome might be better.You can't do whatever you want with Chrome, it has to be published to the scripting interface first. Early versions of Chrome had trouble supporting a lot of common Firefox extensions for this reason.