I'm currently using IntelliJ + Rust plugin. The one thing I miss is Emacs-level extensibility. In particular, as far as I could tell, scripting IntelliJ required building a new Java / Kotlin / Scala project, importing the IntelliJ classes, building a *.jar into a plugin, loading that plugin, and restarting IntelliJ.
I have recently leveled up a bit in JS / TS programming. For those using VSCode + Rust, how is VSCode 'dynamic extensibility' ? Does it rival Emacs / ELisp?
It's been a while for me, but still I think it's safe to say: not even close! The VSCode extension APIs are extensive and capable - given the range and quality of available extensions that's a given. But there's nothing 'dynamic' about them. There's quite a bit of project ceremony, you need an 'extension host' kerfuffle arrangement for testing, and the APIs are hefty Microsofty things with big surfaces.
I can't see anyone writing a VSCode extension for something transient or small-project-specific. I wouldn't be surprised if someone's written an extension to itself host lighter-weight editor scripting for these kinds of purposes.
Emacs and VSCode are wildly different beasts, even though if you glint at VSCode just right you see the same core idea in there of an editing core that has its functionality extended though plugins.
That said, I never really could get used to VSCode. The main reasons for that are input (trying to do Emacs key chord emulation in pretty much anything else is analogous to trying to emulate a machine of the future on one of the past: don't hold your breath for it to be done in a usable way), Magit (as of now the uncontested Superior™️ Git interface), keyboard macros (another one of those features seemingly unique to Emacs).
Given these things, it likely means I'm stuck with it for the foreseeable future.
So the question is, what does Emacs mean to you, other than "Emacs Lisp"?
I'm not sure if I understand your question. When I think of Emacs, I think of:
being open to open a scratch buffer, write some s-exp, hit C-x C-e and evaluate it
be able to extend nearly everything by over writing dynamically scoped config variables
being able to compose / combine subprocedures to define new procedures
In contrast, I can't do any of these in IntelliJ. I have some options I can configure for the Rust plugin, and that is about it.
I'm wondering, given JS has a repl, whether it is possible to do these types of configs in VSCode.
However, from the responses of @closed and @jjpe , it appears the answer is "not easily"
I'm not using VSCode these days, so could be a bit out of date, but I think that's about right. You can only add to existing extensions by using whatever configuration or extension points they choose to provide. Beyond that you'd have to fork their repo and create your own extension.
Neither is there an obvious way to quickly open up a buffer to run useful scripts. There are various repls, eg for js/ts QuokkaJS (or the open-source GitHub - axilleasiv/vscode-javascript-repl-docs: JavaScript REPL is a javascript playground for Visual Studio Code with live feedback as you type, besides your code), but I don't think any offers access to VSCode's APIs. There is a somewhat related project http://vsc-base.org/, which does offer VSCode access of some sort. It's not a blessed part of VSCode, and I don't know how far along it is.
Just to double check, you're aware of the scripting console? Having not used it I can see it being too limited or clumsy for equivalent things, but the keywords all seem to be there.
Given this I think it's likely VSCode won't appeal to you as much as Emacs does.
However, it can't hurt to try it out. What have you got to lose?
Even if you end up not using it, it can be useful to know what other are talking about when referring to certain parts of VSCode.
As an aside, Emacs 28 and 29 have some major improvements to performance.
Emacs 28 introduces AOT native compiling which gives Emacs as a whole a pretty nice performance boost, and Emacs 29 introduces tree-sitter to the project, and added a bunch of modes on top of them. This is exciting because again, it will lead to improved performance, but it will also lead to better syntax highlightingÂą.
Âą Regexes are an awful way of doing syntax highlighting. It performs poorly, and has exactly the same modeling deficiency that trying to parse HTML or a PL with regexes does i.e. no access to a stack.
I think you can actually do all those things in IntelliJ. There’s ide scripting console:
Physically, IntelliJ and Emacs are pretty close — a single process running a VM for a highly dynamic language. The difference rather lies in degree of convenience of such interactivity.
VS Code is a different beast — the editor and the plug-in run in separate processes, the API between them is a well-defined IPC. At the same time, writing an extension for VS Code is actually much easier than for IJ. Eg, I have one personal extension for things I need.
@simonbuchan @matklad : re IntelliJ IDE Scripting Console
I'm aware of it, but did not have good experiences. In the past -- more than a year ago -- I'm not sure what I did wrong -- I managed to crash the entire IntelliJ process by goofing around in the IDE Scripting Console (and not purposely trying to crash it, not calling System.exit, not throwing exceptions, not deref-ing null, just simple querying.) Since then, I've been very wary of dealing with the scripting console.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.