> The strength of emacs is that once you can program it it's extremely easy to write extensions for it
It's not easy by many miles. It's possible but learning the emacs-environment to some aceptable level can take much time and toll.
> Compared to this writing extensions for vscode, for example, is much more convoluted.
Depends on your competence and tooling I would say. From what I've seen, it isn't much harder than writing something midly complex for emacs, But very simple stuff is easier done in emacs, something like single functions. But those have the price that you need to learn emacs lisp on decent enough level first.
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.
Depends on the perspective of-course. I mean, LISP is a real barrier, but once you got over the parenthesis and suck-up some quirks [1], you can get productive quite easily.
Here are two example extensions from my `init.el`.
(defun hh-curl (url)
"Create tmp buffer with curl output"
(interactive "sURL: ")
(let ((buffer url))
(with-output-to-temp-buffer buffer
(shell-command (format "curl -s %s" url) buffer)
(pop-to-buffer buffer))))
(defun hh-insert-date ()
"Insert current date in ISO format"
(interactive)
(insert (format-time-string "%Y-%m-%d")))
It's really not all that much syntax.
You can get interactive help by navigating to a function call and press `C-h f`.
Installation is trivial: Just drop it to init.el.
Use this function my typing `M-x hh <tab>` to see all my extensions, if I forgot the name.
I have bound hh-insert-date to a key b/c I use it frequently.
I'm not talking about lisp or syntax. Learning that is fast. But this is worthless. Learning syntax is fast in any language after a certain point of knowledge.
The juice is in the batteries. The datatypes, the libraries, the environment. Getting to know how to do the most simple things can be very cumbersome in any language, and especially in something old and loaded like emacs.
There is a reason why popular external libs like s.el or f.el are so widely used, and why emacs-projects itself has started modernizing on that front. But those are things you don't know as a beginner.
After spending lots of time customizing various software from macOS to Emacs to Vim to AppleScript to iOS with Workflow, I've come to the conclusion the language and environment are practically irrelevant. There are simply two kinds of people:
1. People who complain about this or that problem in the environment (and say that's why they don't customize it).
2. People who learn and use the environment.
These two groups exist in every one of these communities. There just a fact of life in the world of customization.
(PS: I'm trying to put this in the most neutral way possible, I'm trying not to make any judgements here, personally I'm a customizer, but I'll be the first to admit that I waste a lot of time customizing, and I won't make the argument that customizing is inherently better, just that I prefer it. The point is, the very nature of customizing is what makes it hard, the quirks of the individual environment just don't seem to make much a difference.)
> 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.
I'm not sure what you're saying here? How does another "useful tooling-language" help if your goal is to customize your editor? I guess what you're saying is why don't you write those customizations in another environment like Bash? The easy answer is you want the bells and whistles of the editor, e.g., you want to process your current selection, for example I have a customization to quickly archive the selected piece of text (I often want to remove some text quickly without having to think about whether I might want it again later). I have lots of little customizations like that.
I'm referencing the "1 hour-task", which from my understanding usually does not demand to customize the editor itself. I mean what task would even demand customizing the editor, which would not be possible with other environments like bash, python, ruby, powershell?
> The easy answer is you want the bells and whistles of the editor, e.g., you want to process your current selection, for example I have a customization to quickly archive the selected piece of text
But you don't need elisp for this. Interweaving external tools is possible in any mature editor, including emacs.
> I'm referencing the "1 hour-task", which from my understanding usually does not demand to customize the editor itself.
I your task involves the same kind of editing, for example, then in emacs it's trivial to write a custom function and bind a key to it, making your task much easier.
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.
It's not easy by many miles. It's possible but learning the emacs-environment to some aceptable level can take much time and toll.
> Compared to this writing extensions for vscode, for example, is much more convoluted.
Depends on your competence and tooling I would say. From what I've seen, it isn't much harder than writing something midly complex for emacs, But very simple stuff is easier done in emacs, something like single functions. But those have the price that you need to learn emacs lisp on decent enough level first.
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.