Live data from Hacker News

Emacs 31 is around the corner: The changes I'm daily driving

rahuljuliato.com

171–180 of 294 posts

Re: Emacs 31 is around the corner: The changes I'm daily driving

#171
post #154

Earlier quoted context omitted.

It annoys me so much to have learned that GTK text fields used to have an Emacs editing mode, which they've hidden behind an unaccessible configuration option, and now it's hopelessly broken in modern GTK version.

I spent a day or so hacking around with kanata[0], which is a kernel level keyboard remapping tool, that lets you define[1] keyboard mapping layers in a similar way you might with QMK firmware. When I hit the control or meta/alt/option key, it activates a layer where Emacs editing keys are emulated using the GTK equivalents. For example, C-a and C-e are mapped to home/end, etc. I preserve my macOS CMD-not-control-key…

This is so cool. Thank you!

Re: Emacs 31 is around the corner: The changes I'm daily driving

#172
post #100

If you do any kind of serious work, you need a text editor. Emacs is still one of the best around. It's fast. It's configurable. And it's under your control. You won't suddenly find your text editor "upgraded" with tons of new features you never asked for. It's all opt-in.

> It's fast. super slow on windows

That's surprising considering it was fast on computers from 30 years ago

Re: Emacs 31 is around the corner: The changes I'm daily driving

#173

Earlier quoted context omitted.

I use vi because I'm not a savage

You will be downvoted into oblivion. For speaking the truth. Vi-lets, engage!

why do we run from the police dad? they use emacs, we use vi, son.

Re: Emacs 31 is around the corner: The changes I'm daily driving

#174
post #75

"Is anyone still using emacs?" Yes, 34 years and no plans to switch. Emacs cursor movement keystrokes are quite widely supported elsewhere too which use GNU readline or implement at least subset themselves. Those work well also besides shells with Chromium/Chrome/Safari etc. many browsers input fields (address bar and text area). Cisco IOS, Juniper Junos, Netscreen load balancers too etc. IMHO makes jumping around CL…

Emacs keystrokes don't work in the textarea I'm using to write this comment in Google Chrome.

Specifically none of these do anything like what they do in Emacs: C-a, C-e, C-n, C-p, C-f and C-b.

This is on Linux, but ISTR finding the same state of affairs on MacOS many years ago during some previous iteration of this conversation.

They also don't work in VSCode.

Re: Emacs 31 is around the corner: The changes I'm daily driving

#175
> kill-region-dwim fixes a decades-old papercut. Set it to 'emacs-word and hitting C-w with no active region kills a word backwards instead of signalling an error.

Thank you! No more:

(defun cutregion-or-killword (beginning end) "Kills region if marked else backward kills word." (interactive "r") (if (use-region-p) (kill-region beginning end) (backward-kill-word 1)))

(global-set-key (kbd "C-w") 'cutregion-or-killword)

Re: Emacs 31 is around the corner: The changes I'm daily driving

#176
post #75

"Is anyone still using emacs?" Yes, 34 years and no plans to switch. Emacs cursor movement keystrokes are quite widely supported elsewhere too which use GNU readline or implement at least subset themselves. Those work well also besides shells with Chromium/Chrome/Safari etc. many browsers input fields (address bar and text area). Cisco IOS, Juniper Junos, Netscreen load balancers too etc. IMHO makes jumping around CL…

There are so many fad technologies out there, but vim/emacs and unix command line in general are skills you can invest in that stay relevant for 40+ years.

Re: Emacs 31 is around the corner: The changes I'm daily driving

#177

Earlier quoted context omitted.

> Why not have a preset like (preset-base-ide-1), so we don't need 200 lines of configuration before we can function? Instead we could build off of a much closer starting point First you need to define what is that much better starting point? Something VSCode like? I find VS Code a bad example of software development tooling (anemic file management, integration with external tooling is cunbersome, VCS integration is…

IDEs exist to allow teams or entire divisions to hit the ground running with development, with a standard interface that everybody on the same team uses (a huge boon for collaboration), without a lot of time spent configuring or integrating the tools. All the integration is done by the vendor, often better than you can do it; the debugger integration in full-fat Visual Studio is still second to none. Grooming a perso…

I don’t mind IDE per se, Just like I don’t mind Game Consoles. It can be truly useful, as you say, to have something Plug-and-Play to hit the ground running.

But they often use subpar components (code editors, file managements, VCS,..). They are tailored to a specific standard and any deviation to that standard result in a lot of pain. So I much prefer documented tooling subset that can be integrated however you want than an IDE.

Also you usually spend more time using a system than learning it. Aiming thing to beginners increase longterm discomfort.

Re: Emacs 31 is around the corner: The changes I'm daily driving

#178
post #106

Earlier quoted context omitted.

Why is anyone using anything else?

I use vi because I'm not a savage

If emacs is not installed on a system, I use sed. In addition to not getting stuck inside it when you don't remember the magic exit incantation, you can immediately reuse the command on a different file. And it doesn't play sounds while you do it. Plus when you're typing the sed command, you can use emacs key bindings to move around!

Re: Emacs 31 is around the corner: The changes I'm daily driving

#179
post #106
post #75

"Is anyone still using emacs?" Yes, 34 years and no plans to switch. Emacs cursor movement keystrokes are quite widely supported elsewhere too which use GNU readline or implement at least subset themselves. Those work well also besides shells with Chromium/Chrome/Safari etc. many browsers input fields (address bar and text area). Cisco IOS, Juniper Junos, Netscreen load balancers too etc. IMHO makes jumping around CL…

Why is anyone using anything else?

I don't like keyboard-centric text editing. Yes GNU Emacs supports the mouse, but just like Vim the experience is miserable. You can spend a lot of time configuring it, but at some point you're just writing extensions of extensions just to get a basic GUI flow that isn't painful, and no matter what it'll never feel quite "right". The program just wasn't built with the idea of a mouse in mind, and bolting it on really wasn't sufficient.

Add onto that pretty nasty performance issues, internals that aren't exactly well thought-out, and the experience in general having a high background noise of jank, where it's not uncommon for simple things like rainbow parens to randomly break.

I understand why other people like it, but it's really just not for me. I'll stick with Lite-XL.

Re: Emacs 31 is around the corner: The changes I'm daily driving

#180
post #106

Earlier quoted context omitted.

Why is anyone using anything else?

I use vi because I'm not a savage

I'm a die-hard vimmer. I use vim-motions everywhere - they permeate my editors/IDEs, browsers, terminal, I use them system wide (e.g. to change volume or control media or my WM). One day I woke up with the realization of the fundamental truth - Emacs simply vims better. Much better than even Neovim. I just had to master Vim and grok some Lisp to arrive to that conclusion.

People fighting Vim vs. Emacs are materially wrong - they focus on superficial (albeit substantial) angle, instead of considering the core ideas behind them. Vim's augmentation of modality is an incredible, beautiful, practical concept. Lisp - yet another grandest idea in all history of computer science. And these ideas are not overlapping. Lisp-powered vimming grants you genuinely joyful experience - surprisingly empowering and enormously liberating.

Emacs' Lisp interpreter is so capable - accurately simulating vim in it is not impossible, while pretty much every other editor/IDE has failed - not a single VSCode plugin, not Sublime, not IntelliJ with IdeaVim have ever fully implemented vim motions to the degree where it doesn't feel foreign, while Evil-mode in Emacs feels like a built-in feature. Until recently, bolting Lisp into Vim seemed impossible, today you can get a pseudo-Lisp engine with Fennel. Even though it unlikely ever feel like Emacs.

If you're sticking to one thing only due to some muscle memory, sure you're not a savage, you're just a bit ignorant.

Post reply on HN