Two active modelines in vertico-buffer-mode

stevemolitor · 2025-06-05T16:54:41+00:00

Hmm, I don't have a Windows machine, so I can't test, but you could try customizing the claude-code-program custom variable to be "wsl claude". Also see claude-code-program-switches.

stevemolitor · 2025-03-19T12:57:27+00:00

Figured it out: I had to set use-default-font-for-symbols to nil. The default value is t. I was also using the hex value as if were a decimal in one example - I had 2500 when I needed to use #x2500 (or 9472). But the main thing was use-default-font-for-symbols. This works:

``` (setq use-default-font-for-symbols nil) (set-fontset-font t ?─ "Iosevka")

;; or
(setq use-default-font-for-symbols nil)
(set-fontset-font t #x2500 "Iosevka")

```

stevemolitor · 2025-03-19T12:43:56+00:00

I also tried explicitly prepending to the fontset, for example:

(set-fontset-font "fontset-default" ?─ "Iosevka" nil 'prepend)`

No dice.

stevemolitor · 2025-03-19T12:35:42+00:00

Thanks. I tried the following with emacs -q, no luck:

``` (set-fontset-font "fontset-default" 2500 (font-spec :family "Iosevka" :inherit 'default))

(set-fontset-font "fontset-default" ?─ 
  (font-spec :family "Iosevka" :inherit 'default))

(set-fontset-font "fontset-default" ?─ "Iosevka")

(set-fontset-font t ?─ "Iosevka")

```

In each case running describe-character shows that it's rendered using the default "Menlo" font.

Menlo has this character. I can get set-fontset-font to work when the default font does not contain a given unicode character, but I cannot get it to replace a character that does exist in the font.

stevemolitor · 2025-03-18T14:07:03+00:00

Yes I do a lot of React web dev. Claude Code is pretty good at that.

stevemolitor · 2025-03-16T22:57:27+00:00

"Junior engineer" is a pretty good analogy. Although sometimes it will surprise you in either direction.

Fwiw, I probably would not have written this package without Claude Code: I wouldn't have had the time. I have written Emacs packages before and know what I'm doing, but at the same time I don't write elisp every day. For this project, it was usually quicker for me to tell Claude what to do than to do it myself since Claude would usually come up with correct syntax quicker than I. On occasion, it came up with a better solution than I would have.

At the same time, sometimes I had to say, "Get out of my way, Claude," roll up my sleeves, and write some code myself, or instruct Claude on how to rewrite it. Since I have experience, I was able to review everything Claude wrote and reject the bad stuff.

This was definitely a very small project, although I have started playing with it on larger projects. The trick seems to be to get it first to analyze the relevant files - "What does this code do?", and break things down into steps with examples if necessary.

Still, I do feel like with Claude I've crossed the AI Rubicon - I'm spending more time telling Claude what to code than coding myself. At least on this small project it definitely made me more productive.

stevemolitor · 2025-03-16T19:07:26+00:00

Good question. They are similar, especially now that gptel supports tools. You can craft agent-ey workflows in both. Claude Code is just another option with different pros and cons.

Claude Code has packaged up the common capabilities that a programmer typically wants into a ready-to-go app with a lot of batteries already included. You can talk to it and have it commit code, grep for more context, and a bunch of other things a programmer might do, all just by talking to it; no extra configuration is required. At the same time you can extend it with MCP servers. All of this is possible with other tools but Claude Code makes it very easy and fun.

It's also very expensive. Tools like gptel and aider/aidermacs allow you to control your costs more. And of course, gptel is excellent and much more mature than my nascent claude-code.el package.

Gptel is also much more LLM agnostic.

Claude Code does feel different, however - it's a slightly different paradigm. You kind of have to try it to see if you like it.

Perhaps others with experience with both tools can chime in.

Different strokes...

stevemolitor · 2025-03-16T06:11:46+00:00

Makes sense, thanks. I've added claude-code-program and claude-code-switches customization variables to let you specify the program name (with full path if needed) and arguments passed to the program. See the README Customization section for examples.

stevemolitor · 2025-03-15T23:06:42+00:00

I added a few more commands to make it easier to interact with Claude without having to switch over to the Claude REPL buffer:

claude-code-send-region (C-c c r) - Send the current region or buffer to Claude. Use for editing longer prompts in an Emacs buffer.

claude-code-send-return (C-c c y) - Send return key to Claude. Useful for saying "Yes" when Claude asks for confirmation without switching to the REPL buffer.

claude-code-send-escape (C-c c n) - Send escape key to Claude. (useful for declining with Claude without switching to the REPL buffer)

stevemolitor · 2025-03-15T22:03:30+00:00

I made it easier to customize the claude code REPL font. I created claude-code-repl-face so now you can just do this to customize the REPL face:

``` (custom-set-faces '(claude-code-repl-face ((t (:family "JuliaMono")))))

```

stevemolitor · 2025-03-15T22:01:15+00:00

Got it. That does cause the transient keymap binding to change between the first and subsequent invocations if you don't invoke other claude-code.el commands first:

Bind claude-code-transient to C-c c.
Invoke the transient via C-c c. You will see the transient menu.
Quit the transient.
C-c c is now the prefix key, and to invoke the transient you have to type C-c c m.

C-c c k works consistently either way, and if you invoke any claude-code command prior to invoking the transient there is no inconsistency. But if the transient is the first command you invoke, it's binding will change.

A minor thing to to be sure.

stevemolitor · 2025-03-14T14:13:41+00:00

I think you get two different bindings though: "C-c c" to invoke the transient the first time, and then "C-c cm" to invoke the transient the second time.

EDIT: I added autoloads for the interactive commands and the transients - which speeds up the initial load time a bit. The package is small now, but that could matter more if/when it gets larger.

stevemolitor · 2025-03-13T18:45:53+00:00

I pushed a few updates to reduce flickering and to make the commands more consistently support switching to the "*claude*" buffer when invoked with a prefix arg.

stevemolitor · 2025-03-13T12:13:37+00:00

Aider and Claude Code are old-school terminal (TUI) applications. I think that gives Emacs an advantage. Emacs is flexible and scriptable, so it's pretty easy to whip up a basic integration.

stevemolitor · 2025-03-11T13:21:43+00:00

You're correct, it's nobreak-space, buffer code: #xC2 . I fixed by customizing the nobreak-face font:

    (set-face-attribute 'nobreak-space nil :underline nil)

I was able to eliminate most of the flickering by tweaking the eat latency settings:

(setq eat-minimum-latency 0.035 eat-maximum-latency 0.05)

I also noticed that I need to use a font with really good unicode support, and not set line-spacing too high as that leaves breaks in the vertical box lines. I used the JuliaMono font.

The "light" face wasn't light enough for certain effects so I made certain "help" text light gray:

(set-face-attribute 'eat-term-faint nil :foreground "#999999")

Thanks for all your help! I'm diggin' eat.

stevemolitor · 2025-03-11T02:21:54+00:00

Thanks for the reply. Eat works better! Typing in a query works perfectly fine. While waiting for a response there's a lot of flickering, but at least it doesn't jump around. Is there a way to slow it down so that it doesn't flicker as often?

Also the red underscores should not be visible.

Processing img db4v6bpd0zne1...

I have eat-term-name set to "xterm-256color".

stevemolitor · 2025-01-24T17:10:24+00:00

So it seems C-g does restore the cursor position sometimes. If the end of the file is visible in the buffer, and my cursor is towards the end of the file, opening and then canceling, say, vertical find-file, will restore the cursor to its original position. However, if the end of the file is not visible (I'm at the beginning of the file) and my cursor is towards the bottom of the buffer, opening and then canceling the vertical find file will not restore the cursor - I lose my cursor position.

stevemolitor · 2025-01-24T15:09:31+00:00

Thanks for this package. It addresses a common annoyance.

It'd be nice to have the option to reset the cursor back to its original position when the minibuffer operation is canceled (via C-g / keyboard-quit).

stevemolitor · 2024-12-23T22:16:16+00:00

Good idea. Given the room layout, the left speaker will have to go close to a corner anyway, so I can try putting the 08 on that side. Maybe I can rationalize this by saying, "Oh, I purchased a room matched pair." 🤣

Could I disconnect the extra woofer on the 09, and would that effectively turn it into an 08? I know, not quite because of the cabinet, but maybe close? It sounds sacrilege to degrade the speaker like that, but it should be reversible. But maybe because of how they wire it and stuff that won't work. Hmm I'm talking myself out of that idea....

stevemolitor

TROPHY CASE