Hacker News Reader

I actually just started using emacs recently, specifically doom emacs. It works smoothly out of the box and is super easy to enable LSP for.

I'm not going to try to convince anybody to switch, but if you ever try emacs again, would definitely recommend trying out doom emacs.

Same. I actually switched from VSCode, and I like it much better :)

I switched from Emacs to VSCode to doom emacs and will not be going back anytime soon. For people who mainly want to focus on development, I would say it is fine to break the conventional vim/emacs wisdom that you should start from scratch.

> Its largest competitor, VSCode, Just Works most of the time! You load a file, it detects your intent, and it will install the necessary extensions _along with any additional system packages necessary_. Compare this to Emacs, where it's usually quite unclear what packages to use and what tools they need to operate. Eglot? lsp-mode? Which language major mode, and which language server? How do I get them to work with company mode and so forth?

If you actually think that what VSCode can do here is remotely equivalent to what Emacs can do after customization, then I suspect you don't really understand Emacs.

Yes, VSCode does an excellent job getting you to 80%-90% of where you want to be. But because of the lack of a deep extension language (or to be fair to Emacs, an extensible implementation language), VSCode will make it very hard to get to precisely where you want to be.

Maybe that's OK for a lot of people. But those of us who have used Emacs for quite some time are quite attached to that "final 10-20%", and you can keep your language servers and "detecting my intent" and just leave us be with the way we do things.

For that last 10% of esoteric power, _I still launch Emacs_.

Eventually VSCode will be able to do such things, too.

It's not even that - My problem is that I depend on emacs for the first 50% of my workflow, not the last 50%. For example, I use key chords for every common operation - ;h ;j k; l; move between panes, xz invokes M-x, kj brings up the buffer list, z\ and z- split panes, etc. I barely go ten seconds without using one of occur, change-inner, a 500-element kill ring, consult-yank-pop, tramp, magit, etc. Emacs works so well for me not because it has crazy extensions, but because its extensibility goes so deep that you can bring the crazy extensions deep into the tightest loops in your interaction with the editor where you can gain the greatest benefits.

VSCode allows you to write in Javascript what Emacs allows you to write in elisp. What's missing?

Probably just about a couple of million lines of existing elisp (or more relevantly, the functionality therein).

If you're not a professional web developer, spending 80 hours learning how to modify Emacs will give you much more control over Emacs than the control you get from spending 80 hours learning how to modify VSCode.

Or ar least that was my experience though I was in my prime when I learned Emacs decades ago and almost 60 years old when I spent the 80 hours learning how to modify VSCode.

(I feel I have barely scratched the surface of VSCode and of web tech.)

Web tech gives you a greater degree of control: e.g., Emacs Lisp cannot put red sqiggles under text like VSCode does, but rather limits the user interface essentially to one large "textarea" (though in contrast to TTY interfaces, Emacs has good support for the mouse), but it is very rare for me to want web tech's greater degree of control.

One more thing. For years I went without internet access in my home, yet during those years I continued my habit of doing my emacs modifying at home: all I needed to do was make sure I had the Emacs Lisp reference manual and the Emacs Lisp source-code package installed. On every Linux distro I have used, these are standard packages, and they are all the information I needed to make most of the modifications I made to my local Emacs environment. In contrast, although there are troves of documentation on web tech, I have never succeeded in making a usable offline local copy of any of these troves, and wouldn't consider trying to modify (or explore the internals of) VSCode without constant access to the net.

While true it also means that there is a way larger group of people skilled enough to develop new plugins in js.

> Web tech gives you a greater degree of control: e.g., Emacs Lisp cannot put red sqiggles under text like VSCode does, but rather limits the user interface essentially to one large "textarea" (though in contrast to TTY interfaces, Emacs has good support for the mouse), but it is very rare for me to want web tech's greater degree of control.

Emacs can certainly apply red squiggles and many other rich text formatting, through the use of faces (which is how all syntax highlighting is implemented). Emacs also has a rich text-properties API through which any part of a buffer's text may be propertized with metadata. And it also provides overlays, which "overlay" text, also optionally with additional properties, without modifying the buffer text itself.

Together, these features are used to implement GUIs such as the Customization system with widgets, buttons, clickable links, collapsible sections, etc., as well as red-squiggle-style linting tools like flymake, flycheck, and LSP-related tools.

Do you have a screenshot or a sexpr I can eval to produce the red squiggles in my Emacs?

> as well as red-squiggle-style linting tools like flymake, flycheck, and LSP-related tools.

Thanks. I now know how to make red squiggles in my Emacs.

This makes sense primarily if you assume people who stick to Emacs do so because of its SW development capabilities.

As a person who hangs out amongst Emacs communities, this profile is not the norm.

I used Emacs for software development and git interfacing.

I tried organizing my knowledge with org-roam. I tried maintaining org todo lists. I tried having an active org-agenda. I tried...

But what I do more than eight hours a day, every week day, is read, write and debug code. Emacs was once the best, it is now not so great.

I've been using Emacs for over two decades, now. It's painful that it fell behind so quickly.

I tried org-roam too and it just feels like a bad joke compared to VSCode's foam. Foam has a real time graph of your notes. In org-roam, you need to call a method to get a static graph open in your browser. In theory, you can click the nodes in the org-roam graph to go to your notes... but it doesn't work out of the box for me. Whereas in Foam I can just ctrl+click on a node and bam, i'm in the file I want to be.

I also really like that Foam lets me edit files in markdown in the left window while seeing the rendered version in the right window. The trade-off is this seems to waste screen real estate like there's no tomorrow, but with a 4k screen, I think it's worth the trade-off.

If only VSCode had sane buffer control, and the idea of buffers.

I use VSCode with Emacs key bindings for certain development. The lack of uniformity inconveniences me a lot.

But indeed, VSCode is the closest thing to Emacs in its spirit.

JavaScript: "Lisp in C's clothing"

https://www.crockford.com/javascript/javascript.html

No, it's not. It's nothing like Lisp and will never be, simply because it misses the biggest (arguably most important) feature of Lisp - homoiconicity.

But sure, if you squint your eyes - pretty much every single modern programming language would be "like a Lisp" Why? Because there's not a single programming language in use today that was not influenced by ideas first pioneered in Lisp.

I haven't given them a close look, but there is a project called "zile" that - AFAIU - aims to create an emacs-like editor using Lua instead of Lisp. Which sounds amazing to me.

Also, there's another project to replace emacs' lisp interpreter / bytecode VM with GNU Guile, which started out as an embeddable Scheme interpreter, but apparently these days it is a JIT compiler that supports Scheme, Javascript, and elisp. Which means Guile-Emacs could absorb all of that elisp code without a problem, probably make it run faster, too, but also open the door for people that don't feel comfortable with elisp. More importantly, maybe, this project could bring people from different language communities together.

Again, I have not spent much time looking into the project, so consider all of what I'm writing hearsay. But things are happening.