codemuncher

Check out wind-move and and frame-move. On a Mac I bind the right command key to “super” and use that the prefix. I can then use super-arrow to move between windows and even frames. Before that I had to use the mouse more but this significantly speeds up my day.

In the end it’s not about which is THE way. It’s about building enough options to build an effective and efficient workflow. I’m glad emacs has useful mouse built in. I’m glad emacs has useful keyboard support built in too.

Once you’ve done things for a few years, it’s frustrating to be at the whims of ide developers. Remember the last must have ide? Atom. Gone. The needs of a multinational conglomerate comes before yours comrade. All animals are equal and Microsoft is the most equal.

Even IntelliJ - which is a great ide - is at the whim of how much jetbrains can make their business model work.

I like emacs because I’m off someone else’s upgrade schedule and forced obsolescence. My usage isn’t being measure and put into a data warehouse where some pm can figure out how to monetize. No vendor lock in. No data format lock in. This is the killer feature. I don’t have to give up my data to someone else’s cloud, I don’t have to agree to some restrictive license. I can just be, and compute without someone else needing to interject their wallet between me and my computer!

VSCode plug-ins is definitely playing in a rich man’s garden: https://code.visualstudio.com/api/extension-capabilities/overview

You’re allowed to do what they say you can do. There’s a list and it’s not infinite.

Part of the reason is VScode is very complex. Whereas the core of emacs is a lot simpler. It’s significantly easier to hook into the core of emacs and also safer too.

The emacs source code has about 250,00 lines of C. And about 1 million lines of elisp (including all bundled packages). You can change all of that elisp at run time.

Oh boy yet another treemacs question!

Elisp isn’t just a programming language it’s an execution environment and it doesn’t make a lot of sense to consider them separately.

For example the largest abstraction in elisp is the buffer. A lot of core language features revolve around and are greatly modified by the buffer. For example variable bindings can typically be overrides in buffer-local variables.

Furthermore there’s a lot of editor specifics that are interesting. Text properties are the least of which. Buffer narrowing is another. But what about… fields? Judicious use of fields limits where you can type into a buffer. Consider the customize user interface for example.

Basically emacs is a complete tui development environment.

I recently had cause to try to load some code into a JavaScript repl from a typescript project. Man what a nightmare.

The js ecosystem is very difficult to work with. Many options and browser issues are intertwined. Clever ideas abound… but that might be part of the issue.

JavaScript wouldn’t be an improvement over elisp imo. The theory is that a more accessible language would bring users, but many devs aren’t interested in anything but getting the job done with vs code and then going home.

And honestly the ridiculous quickness in which things get deprecated despite no replacement is a bad developer mindset.