Comment by to3m | Hacker News Reader

Comment by to3m | Hacker News Reader

Stuff seems to be very easy to get working in VSCode, whereas almost everything is a bit of a faff to set up in Emacs. Getting decent Go support in VSCode took about 1 minute, for example, and the only problem I've found with it is that now I've got to use Go. Emacs on the other hand... well, I haven't even bothered. It's almost certainly going to be a complete bind. (And even if it isn't, my statement is worded in such a way that I'm actually still right.)

Once you've been using VSCode for a while, though, you'll start to wonder just why you can't move that stupid sidebar to some other place on the screen.

Or maybe you'll wonder why you can't see its individual components in different windows. Why are they all stuck as like tabs of the same panel?

Come to think of it, why can you only split the editing window twice?

And considering it's all driven off a dynamic language, how come there's so much damn boilerplate when it comes to writing an extension? And where's the in-editor JS REPL akin to M-: or the scratch buffer? (Actually, now I've even asked that question, I'm sure I've just missed something obvious, because there has to be one, and it must be there.)

Don't even get me started on how to share configs between multiple systems... (there's an addon that'll upload them to gists but there doesn't seem to be any way to have system-specific configs, something that Emacs solves inherently because its config files are just Lisp code)

Also, VSCode doesn't work properly with my favourite font on Windows.

And I'm not going to mention org-mode.

> "where's the in-editor JS REPL"

Can use Code Runner for evaluating JS in a REPL...

https://marketplace.visualstudio.com/items?itemName=formulah...

Can also use the Shell Arguments feature of the Integrated Terminal to start up a JS REPL when opening a new terminal window...

https://code.visualstudio.com/docs/editor/integrated-termina...

> "there doesn't seem to be any way to have system-specific configs"

Just use Git, and only clone the repos for the system settings you're interested in using. So, if you have a Git repo for VS Code settings on PC 1, don't clone it on PC 2. Not that hard is it.

> "And I'm not going to mention org-mode."

I think you just did. It looks like someone wanted to implement it in VS Code ( https://github.com/jsonreeder/vscode-org-mode ) but there were issues holding it back from being implemented fully, such as:

https://github.com/Microsoft/vscode/issues/3422

The org-mode reference is "rhetoric". That's the Latin for "#thatsthejoke" :)

Regarding the REPL - what I mean is, run a snippet that executes in the context of the editor. Like, in emacs, you can execute ``(defun fred () (interactive) (insert "fred"))'' from the scratch buffer, and now you've got a new editor command: fred. Run it with M-x (the closest Emacs analogue to the Command Palette). Bind it to a key, maybe: ``(global-set-key (kbd "<f6>") 'fred)''. Good for prototyping, debugging addons, or just writing quick one-off things.

And as for Git, I don't really understand the suggestion. I have a Git repo for Emacs settings that works on all my PCs: Linux, OS X (terminal), OS X (GUI), Windows (non-work), Windows (work). If there's anything that needs to be different on one or the other, I just do ``(when (tom--is-osx) ...stuff...)'' or whatever. tom--is-osx is a function that's something like ``(defun tom--is-osx () (eq system-type 'darwin))'', and so on for the other systems I use. I check for my work PC by examining the hostname.

For VSCode, on the other hand, there's only one settings.json (and it's right out of the way, in some fiddly folder structure that's laid out like there's no real user-serviceable parts inside, which gives me pause - but that's a separate issue). In my case, most of it wants to be the same on every system. Some bits want to be different. I'd also like my plugins list to be synced as well. Doesn't seem to be any good support for that either.

(This stuff is easy to do with Emacs, because Emacs doesn't have a settings file per se, just a file with Lisp commands in it that, when run, leave the system in the desired state. So you can have ifs, along with anything else you like, because it's just code.)

> "The org-mode reference is "rhetoric". That's the Latin for "#thatsthejoke" :)"

I got what you were doing with it (suggesting it in a jokey way as if it wouldn't be fair to even bring it up), I was just using it as an opening to discuss alternative org-mode implementations. Emacs may have the canonical one, but it's not like it's impossible to implement elsewhere.

> "Regarding the REPL - what I mean is, run a snippet that executes in the context of the editor"

Is that not covered by the Code Runner extension I suggested earlier?

> "And as for Git, I don't really understand the suggestion."

Multiple Git repos, each one covering different system settings. In other words, if you work across two PCs, one Git repo for PC 1, another Git repo for PC 2. Alternatively, you could organise it in the same repo under different branches. If you know Git you'll know what I'm suggesting is trivially easy.

The Code Runner looks like it just runs a script and puts the output in a VSCode panel, which is not the same thing. VSCode is written in something that compiles to Javascript, right? So, while you're running VSCode, there's a JS VM that's running the VSCode code. So what I'm missing is a way to be able to run your own code inside the same VM that the editor's code is running in, giving it full access to all the objects and state that the editor's code is in.

You can use this to write ad-hoc extensions that disappear when you quit, or just experiment with the extension functionality. This is typically how you start and then iterate on extensions in Emacs.

I completely identify with your frustration over the lack of support for multiple windows.

<political-request> Anyone else who shares that frustration, please vote here if you get a chance: https://github.com/Microsoft/vscode/issues/10121 </political-request>

I've used emacs for a long time (13 years now I think) and while I've been super impressed at the progress emacs has made (MELPA, helm, etc) it continues to be cludgey to support other languages.

That said, Go is actually one of the best supported languages because of the CLI tooling it offers. Company mode also completed Golang super well and with flycheck it all works pretty much out of the box.

I suggest also adding gometalinter[1] and its flycheck support [2], which also works quite well and allows you to have more linters available

[1] https://github.com/alecthomas/gometalinter [2] https://github.com/favadi/flycheck-gometalinter

Reply on news.ycombinator.com