Can superchat be added to the packages use gptel section in the README?

[yibie]

Check out: https://github.com/yibie/superchat

[karthink]

Sure. Do you have a line of text I should use to describe Superchat?

…

On Sat, Nov 1, 2025, 8:43 PM yibie ***@***.***> wrote: Check out: https://github.com/yibie/superchat — Reply to this email directly, view it on GitHub <#1130>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBVOLCTITYB2SDKJSH4TET32V4ULAVCNFSM6AAAAACK4JVBHKVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZZGA4TOMBVGM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[yibie]

Thank you, here:

Provide a simpler and more user-friendly GPTel conversation interface.

[karthink]

Thank you, here: Provide a simpler and more user-friendly GPTel conversation interface.

I don't know that it's more user-friendly! This is a matter of opinion. Could you give me some text that explains what it does instead of how it compares to gptel? From the project page I see "A friendly, Claude Code–style chat UI for gptel in Emacs. Superchat makes structured prompts and file‑grounded conversations effortless." Can I use this instead?

[yibie]

OK. It's better.

[karthink]

OK. It's better.

It's done. Superchat looks great, BTW!

[yibie]

@ is used for swtich models, / is used for switch prompts (in superchat, it calls commands, keeps it the same as Claude Code).

And / can call out built-in commands, like /clear, it means clear all the coversation at the right now, and start a new conversation.

[karthink]

@ is used in gptel to apply presets to prompts, which can change the model or do absolutely anything. The entire gptel-agent package I'm working on can be used by including @gptel-agent in a prompt in gptel.

Commands like /clear don't make sense for gptel's buffer-oriented workflow. It's not a shell, and the "conversation history" is just the contents of the buffer before point. So you can simply run M-x erase-buffer if you want to clear the context, or edit the buffer to clear parts of it.

More generally, I don't understand what "commands" are in Claude Code. If they are just prompts, Emacs has many ways to expand /command into a prompt.

[yibie]

What specific prefix symbol is not important; I'm glad you're already using @ to call Prompt. In general, the interaction pattern is to use specific prefix symbols to call different options, such as @ for calling models, / for calling prompts, and # for calling files. But what is called is not important.

However, it can conveniently bring up a dropdown menu and let the user select directly through prefix symbols. This interaction pattern is quite important. I don't think it's necessary to be rigid about any specific implementation.

[karthink]

What specific prefix symbol is not important

I understand.

However, it can conveniently bring up a dropdown menu and let the user select directly through prefix symbols. This interaction pattern is quite important.

If Emacs provides a metaphor that maps well to gptel's requirements, I prefer to reuse it instead of defining new interaction patterns. For example, including files in the prompt is done using Org or Markdown links. Then the user can use whatever method they are used to for inserting links. In my case completion-at-point completes file paths automatically when I start to type them, but there are several.

I don't see the point of making gptel's completely free-form, buffer-centric usage paradigm more like a shell prompt. There already are many shell-style LLM client UIs and interfaces to Claude Code for Emacs.

I made an exception for presets (with the explicit @preset-name syntax) because although Org provides keywords like #+preset:, Markdown does not, and I needed something that works with prompts in any major mode and in the minibuffer. Moreover, presets are way more powerful than most users realize, as they can do arbitrary prompt and response transformations, including calling models, prompts and files.

Alternative UIs like Superchat might work better for some users -- I'm happy to see more experimentation. I recently finished decoupling gptel-request from gptel's UI so that it's easier to use it as a library for new UI designs. (Using (require 'gptel-request) instead of (require 'gptel) will keep most of gptel's UI code from ever being loaded.)

[yibie]

If Emacs provides a metaphor that maps well to gptel's requirements, I prefer to reuse it instead of defining new interaction patterns.

I also agree with this point. However, my idea still remains "interaction-first." As long as the fundamental features of Emacs can be achieved using third-party packages, I will take action to implement them. Superchat was initially just an experimental idea, but I found that Emacs's own ecosystem can satisfy this kind of "prefix symbol" interaction method, so that's what I did.

Personally, I still think command methods are more cognitively taxing, but I believe your point itself is not wrong—it's purely a gap in our perspectives. I'm very happy that in this conversation, we were able to interact openly and exchange views.