Learning elisp and becoming comfortable within the Emacs ecosystem is definitely a daunting task, but once you do learn elisp then modifying Emacs to how you want it to be is extremely easy.
Other editors require creating a plugin/extension that follows some sort of guidelines (or you can just modify the source code).
They recommend a plugin to have several files and to have JSON to specify specifics of the extension.
Compared to emacs, all you really need to do is put (message "hello world") in your .emacs file.
Granted, it's not quite fair to compare Emacs and VS Code in this fashion. VS Code has a system in place for having an extension whereas Emacs treats your .emacs file as an extension of itself. Part of Emacs is written in elisp, and when Emacs runs it runs the code in your .emacs file just like other elisp code (this statement is probably not entirely true, but it's just a simplified way of viewing it).
To be quite honest, I really wish all other text editors had something equivalent to Emacs .emacs file. If VS Code ran a js file on startup I'd be very happy.
Regarding this point:
> But the question is, if you already can code, then why bother with creating elisp-code or an vc code-extension? Today there is a good change that you already known some useful tooling-language.
You can take advantage of existing tooling for Emacs - you can actually get away with quite a lot in Emacs without knowing any elisp. The barrier to entry to try out code snippets from the internet is extremely low - all you need to do is copy-paste.
That being said, this is a double-edged sword. Once you start copy-pasting a ton of snippets there's a chance that things may conflict and break. You'll need to start learning how to use Emacs' debugging tools and you'll probably have to familiarize yourself with elisp.
In addition to that, the tooling depends on what other Emacs users have created - if you're trying to do something in Emacs that other Emacs users haven't worked with then you may need to learn elisp. The existing tooling for Emacs is quite great, I haven't found too many things that didn't have tooling, or if there wasn't any tooling, then there's something that is generic enough to work with what I'm trying to do.
> For example, here's VS Code's "Hello World" plugin anatomy:
Yes, boilerplate like this is typical with frameworks. It's a tradeoff with some benefits and a price. IIRC there are some cli-commands for generating and handling this, so it's probably less effort than it seems.
> Compared to emacs, all you really need to do is put (message "hello world") in your .emacs file.
Depends on what you are doing. For packages, emacs also has boilerplate. And if you add elpa or melpa there is even more to do. At the end the only real difference is the lack of simple adaptability in VS Code. And I'm not enough of an expert on this topic to know whether it's even completly true.
> To be quite honest, I really wish all other text editors had something equivalent to Emacs .emacs file. If VS Code ran a js file on startup I'd be very happy.
Considering VS Code is just a browser under the hood, I wonder whether it wouldn't be possible to do something similar out of the box to some degree. I can understand that that they have some tighter control over GUI-stuff, but considering you can hot-load extensions I would assume there are some ways for this and they are probably just bad. Maybe some emacs-culture should leek to vs code to make this happen.
I heard atom editor is better in that regard, but also worse in performance.
For the record, I've written customizations in most major text editors, here's how I'd rank them in ease of customization, from easiest to hardest:
Emacs = Vim > Atom > BBEdit > TextMate > Visual Studio Code
It mainly comes down to whether a text editor has a built-in place to quickly add customizations, and whether there's a DSL to quickly wrap shell commands. Visual Studio Code has neither.
(Admittedly wrapping shell commands is just the approach to writing customizations that I personally prefer.)
I don't know about that. I agree they're roughly equivalent in some respects, but elisp is way nicer than vimscript, which is horrifying. Honestly elisp being nicer than vimscript is the primary reason I switched from vim to evil-mode/emacs.
Learning elisp and becoming comfortable within the Emacs ecosystem is definitely a daunting task, but once you do learn elisp then modifying Emacs to how you want it to be is extremely easy.
Other editors require creating a plugin/extension that follows some sort of guidelines (or you can just modify the source code).
For example, here's VS Code's "Hello World" plugin anatomy: https://code.visualstudio.com/api/get-started/extension-anat...
They recommend a plugin to have several files and to have JSON to specify specifics of the extension.
Compared to emacs, all you really need to do is put (message "hello world") in your .emacs file.
Granted, it's not quite fair to compare Emacs and VS Code in this fashion. VS Code has a system in place for having an extension whereas Emacs treats your .emacs file as an extension of itself. Part of Emacs is written in elisp, and when Emacs runs it runs the code in your .emacs file just like other elisp code (this statement is probably not entirely true, but it's just a simplified way of viewing it).
To be quite honest, I really wish all other text editors had something equivalent to Emacs .emacs file. If VS Code ran a js file on startup I'd be very happy.
Regarding this point: > But the question is, if you already can code, then why bother with creating elisp-code or an vc code-extension? Today there is a good change that you already known some useful tooling-language.
You can take advantage of existing tooling for Emacs - you can actually get away with quite a lot in Emacs without knowing any elisp. The barrier to entry to try out code snippets from the internet is extremely low - all you need to do is copy-paste.
That being said, this is a double-edged sword. Once you start copy-pasting a ton of snippets there's a chance that things may conflict and break. You'll need to start learning how to use Emacs' debugging tools and you'll probably have to familiarize yourself with elisp.
In addition to that, the tooling depends on what other Emacs users have created - if you're trying to do something in Emacs that other Emacs users haven't worked with then you may need to learn elisp. The existing tooling for Emacs is quite great, I haven't found too many things that didn't have tooling, or if there wasn't any tooling, then there's something that is generic enough to work with what I'm trying to do.
Ex: company-mode (https://github.com/company-mode/company-mode) for auto complete can work for programming languages that do not have a company-mode backend, there's also dumb-jump for getting to definitions(https://github.com/jacktasia/dumb-jump).