Comments URL: https://news.ycombinator.com/item?id=46825214

Points: 2

# Comments: 0

The cost of slop is >40X drop in performance? Pick any metric that you care about for your domain perhaps that's what you're going to lose and is the effort to recover that practical with current vibe-coding strategies?

On OS X you can achieve this with Keyb, Karabiner Elements, etc. It's also easy to do with a programmable keyboard with ZMK/QMK. I've set up my Kinesis 360 Pro this way, being symmetrical means I can access every key easily. Hardware support for sticky keys also helps quite a bit.

  - popping the global mark to travel backwards to previous edit points would reuse the same Emacs window instead of using a window that is already showing the buffer. Fixed
  - I would accidentally destroy my window configuration w/ C-x 1. Fixed, use advice to automatically save the window configuration into a register if I invoke the command to remove all other windows. Now I can easily recover if I make that mistake.
  - I want to be able to select and then scroll any other open window w/o leaving the current one. Fixed
  - A crazy one. I collect note w/ links or whatever for reading/watching later, these are marked w/ a timestamp. My notes file is not an agenda file, i.e. not filled with todos / tasks. I made a hack to temporarily include the current non-agenda org-mode buffer in the agenda list and then show inactive timestamps. Now I can scan a day/week/month for interesting notes I took. This doesn't interact at all with my real agenda.
  - org-agenda opens items in weird places, use advice to fix it so that it always appears where I like.
  - fix inf-clojure so that it uses dep.edn as project root over .git

It used to be I mostly used IntelliJ for work/OSS and Emacs for org-mode. Now the situation is likely reversed. Emacs for work/OSS and IntelliJ only if I need step debugging/global refactoring.

  > My experience extending a core emacs function was an instructive and 
  > interesting exercise. I don't know what the future of emacs looks like in an
  > increasingly LLM-crazed world, but I hope that future  includes an open and
  > powerful way to extend and customize the tools we use to write software.

I can add my `.emacs` to the Claude context to get more precise answers. If it falls over on some package I can `M-x find-library` to add that library's source to the context. If the code it wrote doesn't work, I add the `Messages` buffer and the `Backtrace` buffer for errors. I eval the snippet, reprompt, rinse and repeat.

With this fast feedback loop (no restarting Emacs, just live coding), I've added a ton of customizations that in my twenty years of using Emacs previously just never felt like I had the time or enthusiasm for given higher priorities:

* Boring stuff: managing where modes open buffers in which windows

* More ambitious stuff: standard org-remark behavior isn't that natural for highlighting and making notes so I made a nicer Transient based thing for it.

* Stuff for work: a fast logging minor mode that font locks incrementally, disables all the save prompting, and handles ASCII color codes. Later I intend to linkify stack traces, linkify data so that they open pretty printed in a different buffer, collect errors and show an unobtrusive notification in the active window, etc. etc.

In two weeks, I've learned more Emacs than I did the 10 years prior. Most of all, this is a usage of LLMs that I can say I honestly love - improving my own day-to-day tools. Because Emacs is a text-oriented live programming environment - LLM integration just feels like it's on a completely different level.

Claude (or any good LLM) + Emacs is a killer app.

Comments URL: https://news.ycombinator.com/item?id=45118312

Points: 3

# Comments: 0

Hrm https://mitp-content-server.mit.edu/books/content/sectbyfn/b...

When we eventually remove the direct GCL dependency it will sadly be more for optics than anything else.