5 ms·

I am going to go out on a limb here and defend Elisp. I think that for what it was designed to be (a complete scripting language for a text editor) it does ever

by dokyun 2y ago

I am going to go out on a limb here and defend Elisp. I think that for what it was designed to be (a complete scripting language for a text editor) it does everything that it needs to do very well, and much more. Much of these arguments do basically boil down to "Emacs Lisp basically isn't [some other language]", or misconceptions about the philosophy of how the system is designed. I have hacked a considerable amount in both Elisp and CL and I can state that I actually prefer the way Elisp does some things over the way Common Lisp does--this is not to say that CL does things the wrong way--the matter is that they have different purposes. Emacs combined with Elisp in itself constitutes a complete programming system; all of its components are designed around it. The language being integrated into Emacs makes writing Elisp programs a very fluid and intuitive experience: things like the fact that the documentation and the place where a function was defined is available at any time makes /understanding/ the system easy, and the actual documentation itself is often quite well written, and the Info manuals will most often explain everything you need to know about a package. Common Lisp+SLIME shares some of this convenience, but not to the extent that Elisp truly does. Certain points like the fact that Emacs isn't multithreaded are thrown around by people who don't have the intuition that multithreading isn't the right thing for a lot of applications. The added complexity that multithreading would add to Emacs would seriously outweigh the usefulness it would provide. Emacs already has a decent process model, and having to deal with only a single shared state makes programs much cleaner. At the very least if it all comes down to a dick measuring contest, the base GNU Emacs provides 100000000x more utility in its packages in a fraction of the memory space than VS code or Vim ever will. Emacs has its fair share of killer apps like Magit that provide such a clean interface to something that it makes using it worth it for that alone.

_19qg 2y ago
> Certain points like the fact that Emacs isn't multithreaded are thrown around by people who don't have the intuition that multithreading isn't the right thing for a lot of applications. GNU Emacs has a lot of applications where it is the right thing. It's no longer the simple editor. It comes with more than a million lines of Lisp code implementing all kinds of complex features: like various network client applications, IDEs, ... > Common Lisp+SLIME shares some of this convenience, but not to the extent that Elisp truly does SLIME is mostly implemented in Emacs Lisp. A lot of other Lisp systems can locate all source code and all documentation. It's not so much a special feature of Emacs Lisp, but its development environment. It's also not necessary that the IDE and Lisp runs in the same process / same machine to be able to look up documentation and code. It may be convenient in GNU Emacs, but any such editor can provide such features for programming language implementations.
- znpy 2y ago
  > GNU Emacs has a lot of applications where it is the right thing. It's no longer the simple editor. It comes with more than a million lines of Lisp code implementing all kinds of complex features: like various network client applications, IDEs, ... Multi-threading has landed in emacs anyway, by the way: https://www.gnu.org/software/emacs/manual/html_node/elisp/Threads.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Th...
  - lispm 2y ago
    see the word "limited" in the documentation. It's some kind of "cooperative thread" mechanism...
    - medo-bear 2y ago
      We can also use SBCL's multi threading in Elisp https://git.sr.ht/~hajovonta/glue/tree/master/item/README.org https://git.sr.ht/~hajovonta/glue/tree/master/item/README.or...
      - lispm 2y ago
        Yes, that runs Common Lisp code in an external Common Lisp instance via a SLIME / SLY connection, using the CL thread features. It can use Bordeaux-Threads as API for threads in various CL implementations. https://github.com/sionescu/bordeaux-threads https://github.com/sionescu/bordeaux-threads
  - medstrom 2y ago
    I experimented with that, but it doesn't use more than one CPU core, so it's more of a proof of concept at the moment. You could use it to make non-blocking user experience perhaps, but you could also do it using `while-no-input` or a library like deferred.el or my https://github.com/meedstrom/asyncloop https://github.com/meedstrom/asyncloop. Anyway, there is `make-process` for multicore work. Takes some boilerplate and studying, but no more than with threads.
rtpg 2y ago
> Certain points like the fact that Emacs isn't multithreaded are thrown around by people who don't have the intuition that multithreading isn't the right thing for a lot of applications. The added complexity that multithreading would add to Emacs would seriously outweigh the usefulness it would provide. Emacs already has a decent process model, and having to deal with only a single shared state makes programs much cleaner. I theoretically understand this but having to deal with company-mode providers that, when they start performing badly, start hanging everything is not fun! Obviously thread-count and async-codestyle-ease are not the same thing, but given the world of LSPs and plugins that do I/O on the main thread (this is a big enough reason to have async interfaces that are actually used) it would be good to have some effort spent there
- medstrom 2y ago
  Yes, on the particular issue of company/corfu, I'm actually tempted to see if we can't just specify that the work of `completion-at-point-functions` must be done in an external process. Then calling `completion-at-point` would never directly call third-party code that may block the main thread. Maybe for speed, `completion-at-point` would keep a fairly recent `dump-emacs-portable` image, and spin up external processes using that, with has the bonus that the completion-at-point-functions get to inspect current state.
- taeric 2y ago
  I'm curious what makes you so sure those plugins will actually use multithreading appropriately? Emacs already has methods to communicate with processes off the main thread, right?
  - deleted 2y ago
    [deleted]
  - rtpg 2y ago
    So some of this stuff is "communicate with an external process", and I feel like many things in that space do the right thing (if only because if you don't it's immediately visible). I have a lot of issues with "pure elisp" plugins though. Things where these plugins are doing a lot of string munging, and it's fast in testing because the tests aren't that big. But you can easily hit some edge case where suddenly you're looking for occurrences of `e` in Moby Dick so now each letter press takes a second (fortunately computers are still fast!) If completion frameworks were async-by-default, at least that stuff wouldn't hang everything for me. At least that's my theory.
smitty1e 2y ago
Can't have it both ways. Elisp is either a scripting language for a text editor, OR a fully-featured programming language for doing All The Things.
- seanw444 2y ago
  It's a jack of all trades, master of one.
- binary132 2y ago
  Maybe I’m misunderstanding you, but why exactly can’t a general-purpose scripting language be used as a scripting language for a text editor?
  - smitty1e 2y ago
    My point is that the advertising needs to pick a course and steer it. As a technical matter, I agree with you.
eviks 2y ago
> I think that for what it was designed to be (a complete scripting language for a text editor) it does everything that it needs to do very well, and much more. Performance is something that needs to be done well in this target domain, and it fails
- binary132 2y ago
  emacs lisp has a gccjit backend by default now that is quite performant
zelphirkalt 2y ago
> Certain points like the fact that Emacs isn't multithreaded are thrown around by people who don't have the intuition that multithreading isn't the right thing for a lot of applications. The added complexity that multithreading would add to Emacs would seriously outweigh the usefulness it would provide. Emacs already has a decent process model, and having to deal with only a single shared state makes programs much cleaner. I disagree with this point. Emacs does not have a useful process model, or at least it cannot be used to the full extend, because of shared global mutable state. This is exactly the issue, not a practical thing. If it were not for all the usage of mutable (and mutated) global state, Emacs could actually benefit from running many things concurrently, without annoying users with blocking behavior. This is of course a huge task to refactor Emacs like that. I can only hope, that some day we will get there, because I see it as one fatal flaw, that could over time kill Emacs. Yes, Emacs as it is is super useful, but more and more things come up, that will be better off running concurrently and in parallel. Just to name a few: Package compilation, waiting for LSP stuff, anything that waits for network, like tramp, running source blocks in org-mode (org-babel), syntax highlighting of big files, magit stuff like rendering huge diffs in a magit status buffer ... All of those things could benefit from being able to use multiple cores and improve Emacs' snappiness and speed. All of these come before even changing anything about elisp the language.
- Conscat 2y ago
  I'm pretty sure out of the box, Emacs can native compile packages in parallel ( https://www.jamescherti.com/emacs-native-compilation-config-jobs/ https://www.jamescherti.com/emacs-native-compilation-config-... ) unless I'm misunderstanding something. Elpaca, which is the package manager I use, can download and install packages in parallel. lsp-bridge intercepts Emacs' LSP client and in my experience significantly reduces perceived latency for clangd.
  - lispm 2y ago
    > Emacs can native compile packages in parallel via external "jobs"
  - deleted 2y ago
    [deleted]
TacticalCoder 2y ago
About the multithreaded thing: it's not as if everything was single-threaded. There are cases where Emacs shall offload the work to something working in the background. Be it a LSP server or generating thumbnails for a directory with thousands of pictures seen from image-dired: Emacs is totally usable while other processes / async calls are doing their things in the background. > the base GNU Emacs provides 100000000x more utility in its packages in a fraction of the memory space than VS code or Vim ever will. Emacs has its fair share of killer apps like Magit that provide such a clean interface to something that it makes using it worth it for that alone And now that Microsoft created LSP (IMO not because they're kind hearted but as a totally dick move to piss off JetBrains who was gaining too much developers momentum and becoming a threat to the "developers, developers, developers" mantra) and that Emacs supports LSP, suddenly those things an IDE did really better than Emacs are much smaller. I'm not saying there aren't a few things an IDE from JetBrains shall be better at than Emacs for a particular language: but on average the gap on those things got way narrower. And Emacs can do a shitload of things an IDE doesn't: configuration/tailoring to your way of working comes to mind. I wrote an IntelliJ plugin back in the days: not fun. I much prefer to write elisp to enhance Emacs. I was using IntelliJ IDEA back before some commenting here were born: I was an early IntelliJ IDEA adopter (when it was barely usable on Linux btw). But I never stopped using Emacs. Every other IDE became slower and "piggyer" at a rate outpacing the now dog-slow advances in CPU/RAM on personal computers (I'm running an AMD 7700X atm, so not too bad of a machine). Meanwhile at every single release Emacs became more efficient. The switch to "native complication" was a gigantic speed boost. As I like to point out: the "Emacs meaning Eight Megabytes And Constantly Swapping" joke was true back in the frigging nineties. Yup, on a 486 with 8 MB of RAM it was quite something to run Emacs. But nowadays we all have about 16 to 64 GB of RAM on our systems. And Emacs is still Emacs. When something survives decades and has stuff like Magit and org-mode which many revere, it has to do something right. If there's a problem with elisp is that it's... Old? But it did survive. It is usable. It's problems and how to work around them are well known. And it's rock stable. My custom Emacs/elisp code configuration is about 3 000 lines of elisp. I think I made one change/commit in six months to my Emacs configuration. It's that solid. > At the very least if it all comes down to a dick measuring contest ... Oh also... At times I have Emacs' uptime surpassing that possible of a Windows consumer OS (which needs to be rebooted regularly due to mandatory updates). Basically the only time when I reinstall Emacs is when I upgrade to either the new Debian stable distro or when I upgrade to a new PC: when it comes out, I install it (I prefer to install from scratch, YMMV) and then use the opportunity to fetch the latest Emacs and compile it from source. I don't remember the last time I did it: it was when Debian 12 stable came out.
eadmund 2y ago
> The language being integrated into Emacs makes writing Elisp programs a very fluid and intuitive experience: things like the fact that the documentation and the place where a function was defined is available at any time makes /understanding/ the system easy, and the actual documentation itself is often quite well written, and the Info manuals will most often explain everything you need to know about a package. Common Lisp+SLIME shares some of this convenience, but not to the extent that Elisp truly does. I think that all (or a lot of?) the Emacs niceties could be grafted into a hypothetical EMACS package in Common Lisp. There’s no reason why an Emacs in Common Lisp wouldn’t still be able to jump to a definition, or to documentation, or whatever. It could still implement advice. And the entire thing would be hackable at runtime, unlike the current Emacs situation where everything but the core runtime is hackable. And there would be packages instead of having to prefix every package’s function with the package name. Common Lisp is definitely not perfect, but it would probably be a better base for Emacs than Elisp is. Elisp is not bad — at least it’s a Lisp, not Lua or Javascript — but it’s really not great.
- dokyun 2y ago
  > There’s no reason why an Emacs in Common Lisp wouldn’t still be able to jump to a definition, or to documentation, or whatever. It could still implement advice. Sorry if you were confused by my wording; SLIME is able to do all of this--and I am not intending to badmouth SLIME either, it's a very great and well-featured system. However, it plays the odd role of having to bridge the gap between Emacs, and the various CL implementations it's meant to support. Things like documentation of functions really come down to the implementation you're using. The de-facto source of documentation for Common Lisp is the HyperSpec, which is a collection of HTML documents. If it doesn't already exist I would like to write a hack to make these documents render inside Emacs itself. I think I should clarify the idea that Common Lisp itself is merely a /language/. Unless you're only writing strictly ANSI CL, real programs depend on the facilities provided by the implementation; it isn't a complete programming system until you give it an environment. SBCL+SLIME, or Allegro or LispWorks or a Lisp machine constitute full programming systems in the same way Emacs+Elisp does by itself. >And the entire thing would be hackable at runtime, unlike the current Emacs situation where everything but the core runtime is hackable. Ever since Elisp has begun to be compiled into native code, I've become hopeful of the idea that eventually the core components written in C will eventually be subsumed by Elisp itself. However, I am also concerned that this will also degrade the overall performance of the system; not because compiled Elisp wouldn't be performant enough but because hackers might be likely to rewrite these components in a negligent way (the same way they have written modules which are the source of many of the relevant complaints, like LSP and company-mode)--see my other comment in this thread about the internals of the Lisp machine system. However, having said that, I think a good enough majority of the runtime is hackable that it escapes being a problem. Much of the window system, for example is exposed to Elisp: one of my projects recently has been to write a drop-in replacement for the X window context menus that spawn text frames instead. >And there would be packages instead of having to prefix every package’s function with the package name. Packages with namespaces are one thing that would have been nice to have, but it's lack of them is well entrenched enough at this point to remain, and it isn't really a problem once you get used to it.
jmclnx 2y ago
Posted from eww in emacs as a test :) Yes, I tend to think this is more "It is not like...

by dokyun 2y ago

_19qg 2y ago

> Certain points like the fact that Emacs isn't multithreaded are thrown around by people who don't have the intuition that multithreading isn't the right thing for a lot of applications. GNU Emacs has a lot of applications where it is the right thing. It's no longer the simple editor. It comes with more than a million lines of Lisp code implementing all kinds of complex features: like various network client applications, IDEs, ... > Common Lisp+SLIME shares some of this convenience, but not to the extent that Elisp truly does SLIME is mostly implemented in Emacs Lisp. A lot of other Lisp systems can locate all source code and all documentation. It's not so much a special feature of Emacs Lisp, but its development environment. It's also not necessary that the IDE and Lisp runs in the same process / same machine to be able to look up documentation and code. It may be convenient in GNU Emacs, but any such editor can provide such features for programming language implementations.

znpy 2y ago
> GNU Emacs has a lot of applications where it is the right thing. It's no longer the simple editor. It comes with more than a million lines of Lisp code implementing all kinds of complex features: like various network client applications, IDEs, ... Multi-threading has landed in emacs anyway, by the way: https://www.gnu.org/software/emacs/manual/html_node/elisp/Threads.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Th...
- lispm 2y ago
  see the word "limited" in the documentation. It's some kind of "cooperative thread" mechanism...
  - medo-bear 2y ago
    We can also use SBCL's multi threading in Elisp https://git.sr.ht/~hajovonta/glue/tree/master/item/README.org https://git.sr.ht/~hajovonta/glue/tree/master/item/README.or...
    - lispm 2y ago
      Yes, that runs Common Lisp code in an external Common Lisp instance via a SLIME / SLY connection, using the CL thread features. It can use Bordeaux-Threads as API for threads in various CL implementations. https://github.com/sionescu/bordeaux-threads https://github.com/sionescu/bordeaux-threads
- medstrom 2y ago
  I experimented with that, but it doesn't use more than one CPU core, so it's more of a proof of concept at the moment. You could use it to make non-blocking user experience perhaps, but you could also do it using `while-no-input` or a library like deferred.el or my https://github.com/meedstrom/asyncloop https://github.com/meedstrom/asyncloop. Anyway, there is `make-process` for multicore work. Takes some boilerplate and studying, but no more than with threads.

rtpg 2y ago

medstrom 2y ago
Yes, on the particular issue of company/corfu, I'm actually tempted to see if we can't just specify that the work of `completion-at-point-functions` must be done in an external process. Then calling `completion-at-point` would never directly call third-party code that may block the main thread. Maybe for speed, `completion-at-point` would keep a fairly recent `dump-emacs-portable` image, and spin up external processes using that, with has the bonus that the completion-at-point-functions get to inspect current state.
taeric 2y ago
I'm curious what makes you so sure those plugins will actually use multithreading appropriately? Emacs already has methods to communicate with processes off the main thread, right?
- deleted 2y ago
  [deleted]
- rtpg 2y ago
  So some of this stuff is "communicate with an external process", and I feel like many things in that space do the right thing (if only because if you don't it's immediately visible). I have a lot of issues with "pure elisp" plugins though. Things where these plugins are doing a lot of string munging, and it's fast in testing because the tests aren't that big. But you can easily hit some edge case where suddenly you're looking for occurrences of `e` in Moby Dick so now each letter press takes a second (fortunately computers are still fast!) If completion frameworks were async-by-default, at least that stuff wouldn't hang everything for me. At least that's my theory.

smitty1e 2y ago

Can't have it both ways. Elisp is either a scripting language for a text editor, OR a fully-featured programming language for doing All The Things.

seanw444 2y ago
It's a jack of all trades, master of one.
binary132 2y ago
Maybe I’m misunderstanding you, but why exactly can’t a general-purpose scripting language be used as a scripting language for a text editor?
- smitty1e 2y ago
  My point is that the advertising needs to pick a course and steer it. As a technical matter, I agree with you.

eviks 2y ago

> I think that for what it was designed to be (a complete scripting language for a text editor) it does everything that it needs to do very well, and much more. Performance is something that needs to be done well in this target domain, and it fails

binary132 2y ago
emacs lisp has a gccjit backend by default now that is quite performant

zelphirkalt 2y ago

> Certain points like the fact that Emacs isn't multithreaded are thrown around by people who don't have the intuition that multithreading isn't the right thing for a lot of applications. The added complexity that multithreading would add to Emacs would seriously outweigh the usefulness it would provide. Emacs already has a decent process model, and having to deal with only a single shared state makes programs much cleaner. I disagree with this point. Emacs does not have a useful process model, or at least it cannot be used to the full extend, because of shared global mutable state. This is exactly the issue, not a practical thing. If it were not for all the usage of mutable (and mutated) global state, Emacs could actually benefit from running many things concurrently, without annoying users with blocking behavior. This is of course a huge task to refactor Emacs like that. I can only hope, that some day we will get there, because I see it as one fatal flaw, that could over time kill Emacs. Yes, Emacs as it is is super useful, but more and more things come up, that will be better off running concurrently and in parallel. Just to name a few: Package compilation, waiting for LSP stuff, anything that waits for network, like tramp, running source blocks in org-mode (org-babel), syntax highlighting of big files, magit stuff like rendering huge diffs in a magit status buffer ... All of those things could benefit from being able to use multiple cores and improve Emacs' snappiness and speed. All of these come before even changing anything about elisp the language.

Conscat 2y ago
I'm pretty sure out of the box, Emacs can native compile packages in parallel ( https://www.jamescherti.com/emacs-native-compilation-config-jobs/ https://www.jamescherti.com/emacs-native-compilation-config-... ) unless I'm misunderstanding something. Elpaca, which is the package manager I use, can download and install packages in parallel. lsp-bridge intercepts Emacs' LSP client and in my experience significantly reduces perceived latency for clangd.
- lispm 2y ago
  > Emacs can native compile packages in parallel via external "jobs"
- deleted 2y ago
  [deleted]

TacticalCoder 2y ago

About the multithreaded thing: it's not as if everything was single-threaded. There are cases where Emacs shall offload the work to something working in the background. Be it a LSP server or generating thumbnails for a directory with thousands of pictures seen from image-dired: Emacs is totally usable while other processes / async calls are doing their things in the background. > the base GNU Emacs provides 100000000x more utility in its packages in a fraction of the memory space than VS code or Vim ever will. Emacs has its fair share of killer apps like Magit that provide such a clean interface to something that it makes using it worth it for that alone And now that Microsoft created LSP (IMO not because they're kind hearted but as a totally dick move to piss off JetBrains who was gaining too much developers momentum and becoming a threat to the "developers, developers, developers" mantra) and that Emacs supports LSP, suddenly those things an IDE did really better than Emacs are much smaller. I'm not saying there aren't a few things an IDE from JetBrains shall be better at than Emacs for a particular language: but on average the gap on those things got way narrower. And Emacs can do a shitload of things an IDE doesn't: configuration/tailoring to your way of working comes to mind. I wrote an IntelliJ plugin back in the days: not fun. I much prefer to write elisp to enhance Emacs. I was using IntelliJ IDEA back before some commenting here were born: I was an early IntelliJ IDEA adopter (when it was barely usable on Linux btw). But I never stopped using Emacs. Every other IDE became slower and "piggyer" at a rate outpacing the now dog-slow advances in CPU/RAM on personal computers (I'm running an AMD 7700X atm, so not too bad of a machine). Meanwhile at every single release Emacs became more efficient. The switch to "native complication" was a gigantic speed boost. As I like to point out: the "Emacs meaning Eight Megabytes And Constantly Swapping" joke was true back in the frigging nineties. Yup, on a 486 with 8 MB of RAM it was quite something to run Emacs. But nowadays we all have about 16 to 64 GB of RAM on our systems. And Emacs is still Emacs. When something survives decades and has stuff like Magit and org-mode which many revere, it has to do something right. If there's a problem with elisp is that it's... Old? But it did survive. It is usable. It's problems and how to work around them are well known. And it's rock stable. My custom Emacs/elisp code configuration is about 3 000 lines of elisp. I think I made one change/commit in six months to my Emacs configuration. It's that solid. > At the very least if it all comes down to a dick measuring contest ... Oh also... At times I have Emacs' uptime surpassing that possible of a Windows consumer OS (which needs to be rebooted regularly due to mandatory updates). Basically the only time when I reinstall Emacs is when I upgrade to either the new Debian stable distro or when I upgrade to a new PC: when it comes out, I install it (I prefer to install from scratch, YMMV) and then use the opportunity to fetch the latest Emacs and compile it from source. I don't remember the last time I did it: it was when Debian 12 stable came out.

eadmund 2y ago

> The language being integrated into Emacs makes writing Elisp programs a very fluid and intuitive experience: things like the fact that the documentation and the place where a function was defined is available at any time makes /understanding/ the system easy, and the actual documentation itself is often quite well written, and the Info manuals will most often explain everything you need to know about a package. Common Lisp+SLIME shares some of this convenience, but not to the extent that Elisp truly does. I think that all (or a lot of?) the Emacs niceties could be grafted into a hypothetical EMACS package in Common Lisp. There’s no reason why an Emacs in Common Lisp wouldn’t still be able to jump to a definition, or to documentation, or whatever. It could still implement advice. And the entire thing would be hackable at runtime, unlike the current Emacs situation where everything but the core runtime is hackable. And there would be packages instead of having to prefix every package’s function with the package name. Common Lisp is definitely not perfect, but it would probably be a better base for Emacs than Elisp is. Elisp is not bad — at least it’s a Lisp, not Lua or Javascript — but it’s really not great.

dokyun 2y ago
> There’s no reason why an Emacs in Common Lisp wouldn’t still be able to jump to a definition, or to documentation, or whatever. It could still implement advice. Sorry if you were confused by my wording; SLIME is able to do all of this--and I am not intending to badmouth SLIME either, it's a very great and well-featured system. However, it plays the odd role of having to bridge the gap between Emacs, and the various CL implementations it's meant to support. Things like documentation of functions really come down to the implementation you're using. The de-facto source of documentation for Common Lisp is the HyperSpec, which is a collection of HTML documents. If it doesn't already exist I would like to write a hack to make these documents render inside Emacs itself. I think I should clarify the idea that Common Lisp itself is merely a /language/. Unless you're only writing strictly ANSI CL, real programs depend on the facilities provided by the implementation; it isn't a complete programming system until you give it an environment. SBCL+SLIME, or Allegro or LispWorks or a Lisp machine constitute full programming systems in the same way Emacs+Elisp does by itself. >And the entire thing would be hackable at runtime, unlike the current Emacs situation where everything but the core runtime is hackable. Ever since Elisp has begun to be compiled into native code, I've become hopeful of the idea that eventually the core components written in C will eventually be subsumed by Elisp itself. However, I am also concerned that this will also degrade the overall performance of the system; not because compiled Elisp wouldn't be performant enough but because hackers might be likely to rewrite these components in a negligent way (the same way they have written modules which are the source of many of the relevant complaints, like LSP and company-mode)--see my other comment in this thread about the internals of the Lisp machine system. However, having said that, I think a good enough majority of the runtime is hackable that it escapes being a problem. Much of the window system, for example is exposed to Elisp: one of my projects recently has been to write a drop-in replacement for the X window context menus that spawn text frames instead. >And there would be packages instead of having to prefix every package’s function with the package name. Packages with namespaces are one thing that would have been nice to have, but it's lack of them is well entrenched enough at this point to remain, and it isn't really a problem once you get used to it.

jmclnx 2y ago

Posted from eww in emacs as a test :) Yes, I tend to think this is more "It is not like...