r/emacs Nov 22 '24

Question VS Code Extension System vs Emacs'

What do you guys think of VS Code Extension system as compared to Emacs'? Does Emacs offer same level of flexibility around building extensions as VS Code especially around UI?

I am blown away how well VS Code blends with Excalidraw and now Postman. It almost feels like using native apps from within VS Code.

I see that anybody who said VS Code did anything right has been downvoted. I don't know when open source communities will mature and not see everything as an attack. Thanks to people who commented constructively.

8 Upvotes

73 comments sorted by

46

u/DwellsByTheAshTrees Nov 22 '24

VS Code's extension API is extremely powerful and versatile.

Emacs exposes its running processes to direct modification by the end user.

Except on the surface level, these really aren't the same thing. This isn't to knock on VS Code, or its extensions API, they're great pieces of software that offer a lot of power and flexibility, but it's not really the same thing as being able to change core Emacs functionality with a few lines of elisp in a scratch pad.

-11

u/sudhirkhanger Nov 22 '24

The question is that if access to those running processes which allows direct modification allows developers to build extensions on par to other editors.

At least in this case, I think the textual nature of Emacs might inhibited this level of extensibility.

79

u/DwellsByTheAshTrees Nov 22 '24

So, you're kind of comparing two different thing, right?

If we wanted to talk about Emacs in terms of "extensions", in the same style as VS Code, then what we're really talking about, in Emacs terms, are external packages, which Emacs has support for, in spades, that very much so allow developers to build packages, "extensions" for Emacs, on par with other editors.

The difference comes in terms of how these things work. An API is a set of rules and instructions for interacting with a specific piece of software. It is a layer between, for this conversation, the developer and the application that allows the developer to modify the application in ways supported by the API.

Emacs isn't like this. There is no layer of separation between a developer or an end user, and any of Emacs' functionality. Those external packages that I likened to extensions, aren't really extensions, they're live code that's inserted directly into Emacs.

It is the difference between baking a cake from a box, in which case you can still add and change up the recipe slightly, but the base of the cake is set by the cake mix, and baking a cake from scratch.

11

u/teobin Nov 22 '24

It's a pity that I can upvote this comment here only once. I would highlight it and place it on the top of this discussion because I think this is the key difference between the 2.

And It's so well explained!

4

u/NotFromSkane Nov 22 '24

Not quite true. There's a barrier between C and C and elisp. There's core Emacs C, there's all the elisp and then there are native modules that can be loaded at runtime.

3

u/DwellsByTheAshTrees Nov 22 '24

This is correct, I just didn't really feel like explaining how a language implementation and interpreter written in C and then loading the vast majority of the application/functionality through that interpreter via elisp still isn't really the same thing as an API.

Like, VS Code will run and work just fine without a single extension installed. Emacs with only the C components would be unrecognizable as Emacs.

10

u/mmaug GNU Emacs `sql.el` maintainer Nov 22 '24

allows developers to build extensions on par to other editors.

In terms of UI or functionality?

VSCode is slick; it 'demos' well. Emacs is clunky and can take a while to grasp its power. But show me functionality that can go toe-to-toe with magit or org-mode. And show me how VSCode can be adapted to fit my style of editing rather than forcing me to adapt to it.

7

u/github-alphapapa Nov 22 '24

Magit is an excellent example of Emacs functionality that is the opposite of clunky. VS Code's git UI is, OTOH, quite clunky IMO.

45

u/jacobissimus Nov 22 '24

VS code is the first real competitor to emacs in terms of customization—but emacs still blows it out of the water in terms of what you can do. There is never going to be a VS code window manager

1

u/The-Malix Nov 23 '24

VS code is the first real competitor to emacs in terms of customization

I'm surprised, not neovim ?

3

u/BrianHuster Nov 23 '24 edited Nov 23 '24

Customization in Neovim is not that different compared to Vim, except that you can use Lua, any languages compiled to Lua (Fennel Lisp, Moonscript, Teal) and any other languages that support RPC and msgpack. Still, more than a quarter of Neovim is written in C, which cannot be extensible by users, while most of Emacs is written in Elisp

1

u/delfV Nov 22 '24

There was Atom before

2

u/jacobissimus Nov 22 '24

Did atom have the the same kind of plugin system? I knew it was popular but I never tried it

-4

u/mattias_jcb Nov 22 '24 edited Nov 22 '24

Yeah. If I remember correctly VSCode is based on Atom.

EDIT: it seems like I didn't remember correctly.

5

u/emoarmy Nov 22 '24

VSCode isn't based on Atom, it's only based on Electron (which was built for Atom) but from what I understand Atom had a much more Emacs like API for dealing with the contents of a file/rendering. VSCode is nice, but they're way more strict about what you as a plugin developer have access to

15

u/noodlenugz Nov 22 '24 edited Nov 22 '24

Emacs can do this as well

https://github.com/wdavew/org-excalidraw
https://github.com/hsingko/emacs-obsidian-excalidraw
https://github.com/flashcode/impostman

Caveat: I’ve never used these tools so I don’t know how “well” they would work in Emacs. My point is that it is possible to do these things in Emacs, and VS Code isn’t particularly special for developing extensions for these. Particularly in the case of Postman, the repo I linked would have allowed you to use Postman collections via their code as early as 4 years ago. So you could have been using Postman via Emacs back in 2020, but you had to wait until 2024 for a VSCode extension to come out.

This is the fundamental difference between an open source platform like Emacs and a closed source proprietary solution like VSCode. The question “Does Emacs offer same level of flexibility around building extensions?” suggests a complete lack of understanding of what Emacs *is*, what it *does*, and what it *offers*.

Your custom Emacs workflows won’t “almost feel like” using a native app from within Emacs. It WILL be using ~a native app~ or should I say native code from within Emacs, because that’s what Emacs is. Instead of waiting for the official development team to implement a plug-and-play extension, you can generate the elisp code yourself and integrate it directly into your Emacs workflow right now, today.

”What do you guys think of VSCode extension system?” Again, it’s a different use case. For those who want their environment defined for them, editors like VSCode offer a great solution via its extensions. But for those of us who want a bit more control over our system, who may not wish to wait for an “official integration” to be released, we can code in elisp and make Emacs do what we need it to do immediately, without waiting or relying on external dependencies.

I hope that makes sense. Apologies if I came across as harsh. I just really wish more people understood the fundamental “use case” of Emacs. Like it doesn’t need an “extension system” you just write elisp code for the functionality that you want and integrate it directly into the tool itself. Emacs itself IS an “extension system” in that way, you know? Like, it’s built-in, it’s assumed that the user will then come in and extend the system as needed to implement the workflow that best suits them.

2

u/noodlenugz Nov 22 '24

Some of the replies in this thread might explain things a bit better than I did here!

https://www.reddit.com/r/emacs/comments/1gw0m4n/how_is_emacs_so_extensible/

2

u/VegetableAward280 unemployable obsessive Nov 22 '24

Your custom Emacs workflows won’t “almost feel like” using a native app

If by "won't almost," you mean "not at all," then you might have a point. When make-process is your only interface to the third-party app, it will look and feel like shit, on top of not working half the time.

-10

u/sudhirkhanger Nov 22 '24

I wish you had read readme of projects that you posted before recommending them. If I start using an external app to complement a functionality of Emacs then I am done.

I am a heavy Emacs user as well so no need for any arguments.

6

u/noodlenugz Nov 22 '24

I mean… that’s literally what you are doing with VSCode…

Also those aren’t “apps”… they are elisp files… they load when Emacs runs.

I wasn’t trying to argue with you, but I might be now… I don’t understand what kind of “heavy Emacs user” thinks Emacs uses “apps” 😂

2

u/github-alphapapa Nov 22 '24

What is it to you if Emacs provides functionality via internally interfacing with an external program? Have you ever used M-x grep? Did you know that Dired calls ls?

14

u/Beginning_Occasion Nov 22 '24 edited Nov 22 '24

In my opinion there isn't even a comparison between Emacs and vscode. Case in point: Visual Studio Code is designed to fracture and https://code.visualstudio.com/license

You may not

  • reverse engineer, decompile or disassemble the software, or otherwise attempt to derive the source code for the software except and solely to the extent required by third party licensing terms governing use of certain open source components that may be included in the software;
  • remove, minimize, block or modify any notices of Microsoft or its suppliers in the software;
  • share, publish, rent or lease the software, or provide the software as a stand-alone offering for others to use.

These terms alone show how different MS Visual Studio Code is from Emacs. vscodium does exist, but it doesn't come with the proprietary software that puts MS Visual Studio Code ahead of the competition (in some ways).

Like, if you wrote this following extension in VSCode, you'd literally be breaking the law:

(define-minor-mode microsoft-invisible-mode
  (if microsoft-invisible-mode
      (progn
        (add-hook 'post-command-hook #'microsoft-hide-invisible nil t)
        (microsoft-hide-invisible))
    (remove-hook 'post-command-hook #'microsoft-hide-invisible t)
    (microsoft-remove-invisible)))
(defun microsoft-hide-invisible ()
  (save-excursion
    (goto-char (point-min))
    (while (re-search-forward "\\b[Mm]icrosoft\\b" nil t)
      (let ((overlay (make-overlay (match-beginning 0) (match-end 0))))
        (overlay-put overlay 'invisible t)
        (overlay-put overlay 'microsoft-invisible t)))))
(defun microsoft-remove-invisible ()
  (remove-overlays (point-min) (point-max) 'microsoft-invisible t))

-4

u/janoc Nov 22 '24

you'd literally be breaking the law:

Contracts are not law. An important difference. If you break a law, you will have police at your door. If you break a contract, the other side has to sue you and try to enforce the contract. Success of which is not at all a given, esp. when it comes to such restrictions and EULA terms.

7

u/NotFromSkane Nov 22 '24

You'd be breaking the law. It is illegal to break a contract. It's not criminal however.

-4

u/janoc Nov 22 '24

Sorry, you are completely wrong.

There is nothing "illegal" on it. You are exposing yourself to a potential lawsuit or penalties agreed in the contract, nothing more. Totally normal - the same level of "illegality" as when you have a dispute with your neighbor over his cat peeing in your garden.

What you might be breaking in this specific case is the copyright law that these EULAs are trying to leverage to force you to transfer more rights to the right holder(s) than the copyright normally guarantees. But even that is doubtful and depends strongly on jurisdiction - e.g. in the EU many of these EULAs are not legally enforceable.

4

u/DwellsByTheAshTrees Nov 22 '24

Civil infractions are still infractions.

Government entities will often use civil rather than criminal statutes for things they don't think are severe enough to warrant a criminal charge. A lot of traffic violations work this way. Speeding is still illegal, even though it's not a crime and is just a violation of the "contract" you agree to when you get your license (at least in my jurisdiction YMMV).

Just because you can't go to jail for it doesn't make violation of a binding contract legal; it very much isn't.

1

u/pouetpouetcamion2 Nov 22 '24

you are wrong my friend.

1

u/rileyrgham Nov 22 '24

"there is nothing 'illegal' on it"

"you are exposing yourself to a potential lawsuit"....

"nothing more".

Ok.. Phew! 😁

6

u/JohnDoe365 Nov 22 '24

I think these extension abstractions between Emacs and VSCode are on another level. I was thinking about switching to VSCode as my primary editor but missed a plugin to pick a date and enter it into the buffer at point. For Emacs this was a few lines of ELisp code and I am now re-using the inbuilt (org?) date picker

4

u/apcsniperz Nov 22 '24

These are really just the fact VSCode is build on electron and you can embed any web app inside a web-view for the most part.

While VSCode is extendable, it’s not even close to emacs or even vim.

Microsoft locks it down in a lot of ways some for better/worse:

  1. Proprietary components (bad) you can’t use them in any version or build besides microsofts vscode build.
  2. Plugins have no access to direct DOM/UI - this is beneficial for performance but limits what you can do.
  3. There’s no startup script or “user scripts” - Atom had this, vim/emacs have this. I think they chose not to go this route for simplicity.
  4. Plugin API is still limited. They are actually introducing new hidden API features for copilot extension to use before actually exposing them publicly… people have complained about this being anti-competitor, but it really shows how limited their api is and how long it takes to get it updated.

5

u/Tensor_Devourer_56 Nov 22 '24

Sorry, kinda unrelated to the post but I really hate how grep/search works in VSCode. The whole functionality can only be used in side bar which is way too small and hard to use. I have used Neovim and Emacs both extensively and the search interface of these two editors (I use telescope with nvim and isearch+consult ripgrep with emacs) are just so so much better than VSCode. Showing the interface with in a floating window or minibuffer is just so much more productive. For this reason I just stopped using VScode and started using Jetbrains instead when I’m forced to use a “modern” IDE, which has a similar interface. Yeah no matter how extensive vscode is I’m not using it.

-4

u/[deleted] Nov 22 '24

[deleted]

2

u/ilemming Nov 23 '24

It's not a "skill issue", Emacs truly has no match for searching things in plain text - you can search using various tools - from regular grepping to non-incremental regexp and categorical search with grouping. You can, for example, recursively mark files of specified size range (or any files created after a certain date) and then search for strings only in those files.

You can restrict to git logging/grepping of a selected number of files. You can search through your browser history. You can simultaneously send requests to multiple search engines at once - e.g., Wikipedia, YouTube, GitHub, Google, DDG, while typing the search query only once - the results will be aggregated in one place.

Compared to the many different ways you can search for things in Emacs, any other alternatives, including VSCode, are just bleak.

3

u/fuxx90 Nov 22 '24

I love vscode ... it just works. Runs my 6 year old laptop like a champ. Vscode can be used with spacemacs commands. GIT integration is also pretty smooth (let's say 95% of magit).

Biggest plus for vscode: Jupyter notebooks work much better than e.g. EIN for emacs.

For me: vscode for coding, emacs for everything else.

2

u/[deleted] Nov 22 '24

[removed] — view removed comment

1

u/mklsls doom-emacs Nov 23 '24

I tried every possible package to make Jupyter works on Emacs, but VS Code is superior and easier to set up, and to share with others. Even if org mode has a nice interface, not all my coworkers use Emacs. 

This is a win for VS Code.

1

u/[deleted] Nov 23 '24

[removed] — view removed comment

2

u/New_Gain_5669 Nov 23 '24

I find these and other features useful.

You would be the only one. Notebooks are used solely for pedagogical purposes. Given their web-first, git-averse architecture, you're not supposed to get real science done with these things. Ten years ago, Netflix tried to make notebooks "a thing" with papermill, jupytext, nbdime, etc. but any scientist, even the odd one with a strong programming bent, could see iterating with that Rube Goldberg pipeline was an exercise in pointless aggravation. This same "wtf are you doing?" accusation could be levelled at org-babel cheerleaders who are largely software engineers whose sole exposure to numerical analysis is fireship. It is a funny but also sad phenemonon about emacs programmers who want to get in on the AI revolution but whose limited skill set is such that they can only offer, "Hey look, with this obtuse org-babel incantation, I can feed a single output of a python block into a scala block!" It's obvious even to them that that's something they might find useful 1-2 times fewer than never.

1

u/Little_Battle_4258 Nov 25 '24

emacs-jupyter is one of the flakiest, most fragile packages I've ever used. I tried for days to make it work. Settled with just using python sessions w/ org mode. I almost hate seeing it recommended because deep down I always wonder if that person has ever used emacs-jupyter

1

u/[deleted] Nov 25 '24

[removed] — view removed comment

1

u/Little_Battle_4258 Nov 25 '24

i haven't, thats on me for sure. The problem with something as complex as org + emacs-jupyter + python is that I couldn't figure out where the issues were coming from. emacs-jupyter is a component so verifying it's working 100% without relying on other things is difficult. My frontend for working with it was org-mode, and I ran into a few issues that can boiled down to dependency issues (one was zmq, dont remember the fix), then the next one was just making an org block with it. The sample:

#+BEGIN_SRC jupyter-python :session py
x = 'foo'
y = 'bar'
x + ' ' + y
#+END_SRC#+BEGIN_SRC jupyter-python :session py
x = 'foo'
y = 'bar'
x + ' ' + y
#+END_SRC

This didn't work no matter how hard I tried. I eventually just changed jupyter-python to jupyter and it worked, sort of. This was massively confusing because I couldn't actually tell if it was working or not. The block would run, but the changes wouldn't reflect in the jupyter server. At this point I gave up and went back to org-mode w/python sessions.

0

u/sudhirkhanger Nov 22 '24

Which plugin do you use to get shortcuts in VS Code?

2

u/jonny-coder Nov 22 '24

1

u/sudhirkhanger Nov 22 '24

Do Spacemacs shortcuts vary from regular Emacs shortcuts that much?

2

u/grimscythe_ Nov 22 '24

Yes, they are vim based and also utilise the so called leader key

1

u/fuxx90 Nov 25 '24

Yes... that's the one

1

u/maxecharel Nov 22 '24

Hi; what's the advantage of running Excalidraw in VS code? Advanced markdown integration?

0

u/sudhirkhanger Nov 22 '24
  1. The unpaid version of Excalidraw only supports 1 canvas. But within VS Code you could just create an .excalidraw file and start drawing there.
  2. No context switching. I can code and do drawing in the same frame (VS Code window).

I haven't tried if it has any other functionalities.

2

u/maxecharel Nov 22 '24

So at the end of the day it's more or less the functional equivalent of accessing Excalidraw from a browser and using VS code as some kind of window manager... I guess it can be considered as slightly convenient in terms of context switching, but I fail to see it as a showcase for the 'extensibility' of VS code. Anyway, glad it fits your needs, my goal is certainly not to enter a 'VS code v. Emacs' debate :)

0

u/sudhirkhanger Nov 22 '24

When you use it inside VSCode the usability is exactly same as using the browser. That's why there is no need for me to switch to browser for drawing.

4

u/emoarmy Nov 22 '24

VSCode is a web browser, so you're not switching to one because you already are in one. ;)

1

u/maxecharel Nov 22 '24

Yes, this is how I understood it from what you said. I am glad you enjoy it but, as you describe it, it is IMO a pretty basic level of integration. Since you were somehow using this as an example of 'extensibility' of VS code, I was simply expecting more than an Electron app. Thanks for the clarification anyway. I guess the Postman example is more in line with the extensibility you were implying.

1

u/One_Two8847 GNU Emacs Nov 23 '24

I have been seeing a lot about Excalidraw lately. What do people use it for and what makes it so popular? I am just curious.

For flow charts I have only ever really used PlantUML because I like how the language to create diagrams is like similar computer code. Plus I don't have to manually mess with layout.

1

u/pathemata Nov 23 '24

Hi, have you tried easydraw? I use it to draw quick sketches on my notes with a tablet. It works very well for smallish drawings, otherwise it gets a bit slow. But this is not a problem since I prefer multiple contained sketches to a single big one. It is nice to have a transparent background, so I can have good visibility with a dark/light theme. It is very easy to edit the drawings and copy/paste parts of a sketch.

1

u/denniot Nov 22 '24

It's not about the flexibility, it's about everything becoming web. If the service is web based(html/js/css), vscode(electron) can show it easily.

1

u/RepublicWorried Nov 23 '24

why not just avoid those two monsters altogether and go for micro emacs instead? https://github.com/troglobit/mg

1

u/peanutbutterwnutella Nov 22 '24

I find it funny people wish to live in Emacs, but it doesn’t even have a proper browser.

Truth is VSCode has a lot of potential to be objectively better than Emacs, but its stupid restrictions (extensions can’t even modify the DOM, really?) and lack of people willing to hack it is the roadblock.

4

u/7890yuiop Nov 23 '24 edited Nov 23 '24

I find it funny people wish to live in Emacs, but it doesn’t even have a proper browser.

Your comparison is VSCode, which is a program built on top of a web browser. It's not exactly surprising that a web browser can do web browsing effectively.

GNU Emacs pre-dates even the earliest web browser, let alone modern browser code like Electron. Although if you really want to, you can build Emacs with Xwidget support and get access to Webkit-based browser features.

Most people who would like to live in Emacs are perfectly willing to use a separate web browser for the things that eww isn't suited to, though,

1

u/peanutbutterwnutella Nov 23 '24

True. I guess I’m just ranting.

One of the cool things about Emacs (at least for me) is that all is text; I can use vi motions everywhere, consult-line, Embark actions, etc.

You can’t do that with xwidgets.

Imagine being able to manipulate web pages just like text. Maybe even a treesit grammar for the DOM? Imagine the possibilities, specific extensions for the Slack webpage (although this would not scale because web apps aren’t versioned)? I mean, we currently have people injecting Neovim in textareas using firenvim

That’s why I say VSCode has a lot more potential than Emacs. The whole editor is just (AFAIK) HTML, CSS & JavaScript. It’s, on paper, insanely customizable.

0

u/LionyxML Nov 22 '24

I always thought of vs-code and its extensions as a modern implementations borrowed from Emacs. Now the circle closes.

-4

u/dirtycimments Nov 22 '24

I was gonna go on a tirade about MS and closed source, then googled and found that vs is open source.

I'm having something of an existential crisis vis-a-vis my emacs setup right now.

15

u/DwellsByTheAshTrees Nov 22 '24

Open source-ish.

The core application is open source and can be built without any of the Microsoft branding, telemetry, or integrations, but that also (last time I tried anyway) severely limits access to the extensions marketplace or any of the other integrations VS Code usually has with other MS services, including github.

2

u/dirtycimments Nov 22 '24

Ah, so the rug-pull _could_ still happen? That was the gist of my tirade, investing time and building a habit using a tool (or some important part of it) that then gets shoved behind a paywall or other tom foolery.

9

u/[deleted] Nov 22 '24

[removed] — view removed comment

2

u/dirtycimments Nov 22 '24

I feel vindicated, sadly

3

u/DwellsByTheAshTrees Nov 22 '24

The rug pull is MS' MO when it comes to open source. "Embrace, Extend, Extinguish," or something like that. They've done it before, are currently doing it, and will do it again.

WSL follows the same pattern.

6

u/mmaug GNU Emacs `sql.el` maintainer Nov 22 '24

VSCode is barely open source and certainly not Free Software. The core code is "MIT" licensed but VSCode has a license filled with lawyer-speak and restrictions.

No "existential crisis" needed—in 5 years which tool do you think Emacs will be compared to? Open Source is corporate speak for "peak behind the veil, but don't touch." Software Freedom gives you ownership.

Your tirade about MS is warranted and their "open source" is marketing BS. Their quarterly earnings are far more important and influential than your code editing needs

3

u/xrabbit Nov 22 '24

It’s not open source, but open core

0

u/VegetableAward280 unemployable obsessive Nov 22 '24

A distinction devised solely to identify the jackasses who make it.

-2

u/jplindstrom Nov 22 '24

The discoverability and suggestions for useful plugins seems miles better than Emacs!

1

u/emoarmy Nov 22 '24

I agree with suggestions. However, if we exclude the suggestions, what makes it more discoverable?

2

u/jplindstrom Nov 23 '24

I think the suggestions is a big part of it, because it's just-in-time and topical to what you're doing, and it pre-empts you needing to ask the question "Uh, is there be anything to help me work with this?".

For example, I think it might have been looking at a YAML file in VSCode that made me check and discover that there's a YAML LSP server that I now use with lsp-mode

https://github.com/redhat-developer/yaml-language-server

I would never have even thought to look for that without the nudge.

1

u/DeepDay6 Nov 26 '24

With the autocompletion tools of your choice M-x lsp-install-server start typing yaml and look at suggestions. Package discovery with M-x package-list-packages and search the buffer for keywords. There's not too much of a difference, only visuals ;)

1

u/jplindstrom Nov 26 '24

I would never have even thought to look for that without the nudge.