The difference between VSCode and Emacs is the difference between an extensible text editor, and an editor that was designed to be extended, molded, and shaped as you work. At any time within Emacs, you can evaluate Lisp code to extend or modify its functionality. What's more, the always-on presence of Lisp turns Emacs into a computing environment with strong editing primitives, rather than a text editor with stuff bolted onto it. I use it to automate tedious tasks, where it serves as a sort of Lisp-programmable super-shell that can ingest data from processes and network connections into buffers, as well as the inverse, all under the control of a powerful programming language.
I'd like to hear more about how you use Emacs as a "super-shell". Do you avoid shell scripts entirely in favor of Emacs Lisp? You mentioned network connections - do you actually do scripting with Elisp's networking primitives?
I've long felt that this was an obvious and good use of Emacs - as a central coordination point for the entirety of one's computational life, with everything manipulated programmatically from a single programming environment with both rich UI capabilities and a full-fledged programming language. No other project seems to understand the value of such a central point... but still, there are many ways Elisp could improve to make this kind of usage easier.
> I'd like to hear more about how you use Emacs as a "super-shell". Do you avoid shell scripts entirely in favor of Emacs Lisp?
No. But I do use Emacs Lisp to automate certain tasks and then wrap them up in an Emacs interface -- like highlighting some JSON to submit to an API endpoint, or using ivy to select a Docker container to start or stop.
> You mentioned network connections - do you actually do scripting with Elisp's networking primitives?
Emacs provides an OOTB way to hit API endpoints in the form of 'request'. So it's not just the networking primitives, but the utilities built on those primitives that Emacs comes with.
> there are many ways Elisp could improve to make this kind of usage easier.
Emacs Lisp has had two major warts: speed, and the lack of lexical scoping and CL-like constructs. The latter is largely addressed. The former is being worked on with efforts like gccemacs.
Why? A good Lisp will give you a decent ride around the block. Even without reaching code-data-equivalence enlightment, it's a fast way to round your knowledge of various paradigms and approaches.
> At any time within Emacs, you can evaluate Lisp code to extend or modify its functionality.
This is also true for VS Code (with JavaScript instead of Emacs Lisp of course). VS Code is just a bit more organized on the surface, giving it significant advantages over emacs in that regard, but also a bit more closed in culture.
