hckrnws

I managed to get this working with gemini by using a proxy [1] and the following config (I used quelpa)

    (use-package efrit
    :quelpa (efrit :fetcher git :repo "steveyegge/efrit")
    :init
    (setq efrit-model "gemini-2.5-pro")
    ;; (setq efrit-api-url "https://generativelanguage.googleapis.com/v1beta/opena
    (setq efrit-api-url "http://127.0.0.1:8089/v1/messages")
    :config (defun efrit--get-api-key () (key-from-file "~/.keys/gemini.txt")) ; this isn't needed, it's set by the proxy
    :ensure t)

Initially I thought you could send it directly to Gemini but apparently you need to proxy and translate the responses.

[1] Seems sketchy, use at your risk: https://github.com/coffeegrind123/gemini-for-claude-code

Congrats on getting it running! This thing is a huge POC (and arguably a POS) so be careful with it.

It's terrible at multi-step tasks right now. I'm evolving it to work more like claude code.

Neat. As a Claude Code plan user can I use this ? I've never tried the API access method.

Claude is remarkably effective at writing elisp I surprisingly found. I had it whip up a mode today for something today (Notation3/N3 RDF triples) complete with etags support, etc. and it just... did it.

Clever name. For thos curious Efrit is Genie in Arabic and possibly the same in neighboring languages such as Persian and Turkish..

> For thos curious Efrit is Genie in Arabi

More precisely, as I understand it, “genie" is an anglicization of its Arabic equivalent, “jinn"; Efrit is a specific kind of jinn.

Genie comes from Latin via French, it's not (just) a transliteration.

https://www.etymonline.com/word/genie

https://en.wikipedia.org/wiki/Genius_(mythology)

I think it might be 'e' for 'emacs' (there's precedent: eglot, eldoc, eshell, erc, emms) combined with 'ifrit', since "efrit" is a much less common spelling.

Yes, that's exactly why I chose it. It starts with an 'e' and it's not a super common spelling, so it wasn't taken.

Countries of origin kind of affect what's common. Where I'm from will write it efrit

I wonder if this could be updated to use OpenRouter in a similar way to Emigo[1] was aiming to do.

(I use the past tense, because Emigo has not been updated in a quarter of a year, which seems as if it may as well be decades in the timeline of this sort of stuff.)

[1] https://github.com/MatthewZMD/emigo

Once emacs starts modifying its own lisp haven’t we unleashed agi?

Certainly someone can figure out how to close emacs.. right?

It will never do anything else though - there is not existential threat.

It appears to have a feature overlap with gptel; would be nice to highlight the differences.

Looks like efrit requires an Anthropic API Key, or at least that is what the README says, while gptel works with several different remote or local backends?

Off topic but without going RTFM, is there a guide that goes through setting up emacs 'with the modern way'? I have done it before but in a mish-mash way where I want something that tells how to go from configuring comp-speed, elpaca, eglot, auto treesitter etc

I somewhat recently settled on using use-package and straight — I highly recommend this approach. You can get pretty far using what comes with emacs and adding a bit more.

You can see how I do it in my emacs config[1] but it's a little bit special with meow[2] for a colemak keyboard. There's a youtube channel that I've skimmed[3] that helped me modernize my config by relying more on emacs' basic features.

[1] https://github.com/green7ea/dotfiles/tree/master/.emacs.d [2] https://github.com/meow-edit/meow [3] https://www.youtube.com/c/SystemCrafters

There is a few solid prepackaged systems around now. Doom emacs is very comprehensive. Similar systems also exist rather than starting from nothing.

Elisp is a programming language that supports many ways to do things so there is lots of ways people do things.

Keep the defaults until you need something, then you install it.

Trying to make emacs into VS Code in 2025 is as stupid as trying to make emacs into eclipse in 2005 or notepad in 1985.

Modern Emacs has pretty good defaults. Still, to get a much better quality of life, one usually has to manually install magit, treemacs, yasnippet, company-mode, ace-window, vertico + orderless (or similar), relevant programming language modes, and language servers for them.

What you actually mean:

>I have a set of packages I find useful. You may not. Install them anyway and waste 6 months trying to understand how to use things that you don't yet need.

I have a whole set packages and DE improvements I've install/written for literate programming. I don't suggest everyone install noweb and friends for better productivity despite how useful they are.

Literate programming is niche, even more than using Emacs. Using git is mainstream, and magit is considered one of the best git clients ever; some people even install and use Emacs exclusively for running it, not for text editing.

I have Emacs set up like VSCode. I feel it surpasses VSCode, even because it's Emacs.

One way is to start with bedrock https://git.sr.ht/~ashton314/emacs-bedrock You will understand your config. Packages like elpaca and auto treesitter, just follow their readme's.

Or if you don't feel like learning the details, go with doom.

There's also https://github.com/MiniApollo/kickstart.emacs.

When I was using emacs I did it just using the internal stuff except for avy. You can get very far without extensions, though you may need lsp mode if you do frontend work.

Indeed you can get quite far with only the built-in modes. One pain point though is the lack of many major modes, for example there’s no built-in markdown-mode, json-mode, julia-mode, or typst-mode, to mention a few.

I recently did try to run Emacs without any packages for a while. To my surprise, AUCTeX was not one of the packages I missed, the built-in latex-mode works well. I did miss CDLaTeX though.

What is the modern way? Emacs is self documented like vim. Vim has the :help command, emacs have the Control + h prefix (or <f1> for an overview). You can start with a minimal config like Emacs Bedrock or Prelude, and then learn about those options first.

But the manual is very well written and worth the read. Emacs has its own culture, and the sooner you learn the conventions, the smoother your path will be.

> What is the modern way?

Pretty sure they mean something that at least involves use-package, vertico/consult/etc. or equivalent, company or corfu, project.el or projectile, and magit.

> You can start with a minimal config like Emacs Bedrock or Prelude, and then learn about those options first.

Prelude seems nice but I wouldn’t call it minimal unless you’re comparing to Doom and Spacemacs.

BTW project.el is now built-in; more and more good things receive canonical built-in implementations that are actually good.

I'm fascinated by this and the recent claude-code-ide package: https://github.com/manzaltu/claude-code-ide.el

But, I cannot seem to get past this error when I run claude-code-ide: "Symbol’s function definition is void: project-root" I know this is defined in project.el, but claude has been surprisingly unhelpful at fixing this issue.

I'm feeling a bit frustrated by the state of emacs packages lately. I've used emacs for 30 years and it feels like things are getting worse.

I'm sorry it's not working. I've used emacs for almost 40 years and I'm definitely contributing to it being worse, by uploading efrit in its current state. But people were asking me for it. Damned if you do and all that.

I'm more than happy to work with you to get it working, with the caveat that it actually kind of sucks right now. It's no Claude Code. But I am quickly evolving it in that direction.

This project does not work for me either. Drat.

  This is turn 4. Focus on any remaining tasks that haven't been completed yet.   Don't repeat work that was already done in previous turns.
  Assistant: I notice from the context that we're in a directory that might be related to a xxx project. Let me try to find and open the yyyy.ts file.                                                               
  [Result: Error: Unknown tool 'resolve_path']

Yeah it really kind of sucks right now, it's more of a proof of concept.

I'm working on evolving it into something that's not so transactional -- it will work more like claude code. Didn't realize it was going to hit the front page today. I'll poke at it this weekend and send an update.

Ok, I might have to frame this comment. I'm a big fan.

After reading your wikipedia page, I didn't realize we were both at UWash CS at the same time. Small world.

My guess is that you're not in a project when you're opening claude? Easiest way for it to detect a project would be having a file or dired buffer open in something managed by git.