4 ms·

No, you're not getting he gist here. Browsers are nothing like Emacs in design philosophy(except Nyxt, which gets close, but falls a bit short due to intrinsic

No, you're not getting he gist here. Browsers are nothing like Emacs in design philosophy(except Nyxt, which gets close, but falls a bit short due to intrinsically having to deal with a bunch of JS; an excellent example of my point, come to think of it). Take Firefox for example. It has extensions, but they're intrinsically limited by the fact that they're sandboxed and can only interact with the browser through a limited API. And yes, you could certainly extend it arbitrarily by changing the C++/Rust/whatever code and recompiling it. But it's not designed to be extended that way by users. In emacs, the configuration is really just patches applied to the code at runtime. There fundamentally is nothing you can't do through the configuration. But why Lisp you say? Precisely because Lisp is a dynamic meta-programming language, which is the ideal paradigm for this. It can be molded to be a highly abstracted configuration language without losing the ability to run arbitrary code. You get all the upside of JSON, YAML, XML and other configuration languages with none of the downside of being limited in what you can do. Adding javascript to the mix just complicates this simple and elegant model. You gain nothing in extensibility, and will probably lose quite a lot unless you take extreme effort to avoid it through clever design.

PurpleRamen 3y ago
> Take Firefox for example. It has extensions, but they're intrinsically limited by the fact that they're sandboxed and can only interact with the browser through a limited API. That's design, a choice. It used to be different in old Firefox, and other browsers are different in that aspect even today. But to be fair, I mainly meant the page-context, not the application-context. Most normal web browser support userscript, bookmarklets and debugging some way or another. Or should I say, still. Because this is a bit in decline. And if you take something like web- or electron-apps, the page-context becomes the app itself. All just a matter of implementation and architecture. > There fundamentally is nothing you can't do through the configuration. You can't patch the C-core, can you? Another necessary implementation-detail. > Precisely because Lisp is a dynamic meta-programming language, which is the ideal paradigm for this. It was ideal when Emacs was created. Today, we have many alternatives. > You gain nothing in extensibility, Except more ability, more heritage, more users... At the end, it's all a matter of managing the tradeoffs, the implementation-details.
- samus 3y ago
  > You can't patch the C-core, can you? Another necessary implementation-detail. The C core contains low-level things or performance-sensitive things that one really doesn't want to patch. Nevertheless, lots of things in the C core are configurable and extendable through hooks. > Except more ability, more heritage, more users... At the end, it's all a matter of managing the tradeoffs, the implementation-details. Regarding heritage, you can't get more than Enacs has, which was around when GUI didn't even exist yet. Users who are put off by the choice of configuration language are unlikely to be productive extension writers [edit: in any language].
- deleted 3y ago
  [deleted]
adamc 3y ago
Also, on a pragmatic level... I think an ecology built around scripting in multiple languages (because you have to support emacs lisp -- that's what things are written in now) will actually make it more confusing to do future development, and now debugging/extending other people's packages requires competence with both languages -- potentially, anyhow. You end up fracturing the community. Something as simple as getting advice for solving a problem on web forums would also be affected by the dichotomy. I think that might be worse for newbies. Still, I think it's fine to run the experiment, and see if that is what people want.

PurpleRamen 3y ago

> Take Firefox for example. It has extensions, but they're intrinsically limited by the fact that they're sandboxed and can only interact with the browser through a limited API. That's design, a choice. It used to be different in old Firefox, and other browsers are different in that aspect even today. But to be fair, I mainly meant the page-context, not the application-context. Most normal web browser support userscript, bookmarklets and debugging some way or another. Or should I say, still. Because this is a bit in decline. And if you take something like web- or electron-apps, the page-context becomes the app itself. All just a matter of implementation and architecture. > There fundamentally is nothing you can't do through the configuration. You can't patch the C-core, can you? Another necessary implementation-detail. > Precisely because Lisp is a dynamic meta-programming language, which is the ideal paradigm for this. It was ideal when Emacs was created. Today, we have many alternatives. > You gain nothing in extensibility, Except more ability, more heritage, more users... At the end, it's all a matter of managing the tradeoffs, the implementation-details.

samus 3y ago
> You can't patch the C-core, can you? Another necessary implementation-detail. The C core contains low-level things or performance-sensitive things that one really doesn't want to patch. Nevertheless, lots of things in the C core are configurable and extendable through hooks. > Except more ability, more heritage, more users... At the end, it's all a matter of managing the tradeoffs, the implementation-details. Regarding heritage, you can't get more than Enacs has, which was around when GUI didn't even exist yet. Users who are put off by the choice of configuration language are unlikely to be productive extension writers [edit: in any language].
deleted 3y ago
[deleted]

adamc 3y ago

Also, on a pragmatic level... I think an ecology built around scripting in multiple languages (because you have to support emacs lisp -- that's what things are written in now) will actually make it more confusing to do future development, and now debugging/extending other people's packages requires competence with both languages -- potentially, anyhow. You end up fracturing the community. Something as simple as getting advice for solving a problem on web forums would also be affected by the dichotomy. I think that might be worse for newbies. Still, I think it's fine to run the experiment, and see if that is what people want.