karthink / gptel

A simple LLM client for Emacs
GNU General Public License v3.0
1.14k stars 119 forks source link

Underscores `_` in responses are replaced by `/` #40

Closed hieutkt closed 7 months ago

hieutkt commented 1 year ago

Great package, and I enjoy its integration ootb with the new preview system in Org-mode that you are developing.

This issue is just a small annoyance: The underscores _ in responses are replaced by /, this messes up some of the latex equation outputs:

Screenshot from 2023-04-09 23-15-13

karthink commented 1 year ago

Ah, I should have expected this bug. I'll fix it soon.

This is unrelated but: May I ask how you moved the prompt from your main org buffer into the gptel buffer? Did you copy the selection, open a gptel buffer, then yank it and type out the rest of the prompt?

hieutkt commented 1 year ago

Yeah I yanked it over and typed out the rest of the prompt. It would be nice (for me at least) if gptel-send can send the selected text to the dedicated *ChatGPT* buffer, instead of flooding output into the current buffer.

karthink commented 1 year ago

Yeah I yanked it over and typed out the rest of the prompt. It would be nice (for me at least) if gptel-send can send the selected text to the dedicated *ChatGPT* buffer, instead of flooding output into the current buffer.

2023-04-09-042930_918x376_scrot

The transient menu has this option now. You could do it in two ways:

  1. Select a region, use C-u C-c RET (gptel-send with prefix-arg, or just gptel-menu), then set the flag to run in an existing (-e) or new (-n) session. But you'll have to type the extra bits ("What is the intuition for this?") before you call gptel-send, or type it into the directive (h) in the menu.
  2. Select a region, use C-u C-c RET but use the "Read input from minibuffer" flag (-r) along with the -e or -n flag. The minibuffer will be populated with the region contents, which you can edit before sending. (It's easer to try than it is to explain)
hieutkt commented 1 year ago

Hmm... I can't hit return to send from gptel-menu? Sorry I'm not very familiar with transient menus.

image

karthink commented 1 year ago

Wow that's odd. Not sure what the issue is. Does C-m instead of RET work?

hieutkt commented 1 year ago

C-m worked, though I have to manually C-x b to the *Chat GPT* buffer afterward. I think a good behavior would be to jump to the session buffer where the text was sent to.

This RET problem probably has some thing to do with how evil-org-mode keybinding works, or the shenanigans that Doom brings for +org/dwim-at-point. I never understood how these work 😅

karthink commented 1 year ago

I think a good behavior would be to jump to the session buffer where the text was sent to.

Hmm, I'm not sure jumping to the buffer is a good idea for async processes -- it can happen without warning seconds later while you're doing something else. The alternative is to jump immediately, but then it's no longer async and you're left waiting for the response to finish (if streaming) or arrive (if batched).

hieutkt commented 1 year ago

Hmm I guess from the user perspective I want visual feedback that the function is indeed working. Seeing the transient menu simply disappear after C-m doesn't feel good for me ("Did I do it wrong?" moment). May be add a minibuffer notification? E.g. The selected text was sent to *ChatGPT* as promt.

For clarification: My *ChatGPT* buffer was buried, hidden from view, so I won't see new prompts there right away if I haven't switch to it.

karthink commented 1 year ago

I'm pushing a fix in a few minutes.

BTW, if you want a workflow not easily supported by gptel, you might also be interested in gptel-request. (See the wiki)

hieutkt commented 1 year ago

I'll look into it later. For now the switch-to-session-buffer-and-type has been mostly satisfactory for me.

Thanks for the fast reponse to this issue!

karthink commented 1 year ago

Added more visual feedback when redirecting the response in 00abbf75. The gptel buffer now pops up but isn't automatically selected.

I'll fix the parsing issue _ --> / when I can, it's a little trickier than expected.

karthink commented 1 year ago

I'll fix the parsing issue _ --> / when I can, it's a little trickier than expected.

I've fixed this for the specific examples you mention -- i.e. text between \( ... \) or \[ ... \] delimiters). I'm afraid there's no simple way of fixing this in general, for example with text inside $...$ or \begin{env} ... \end{env}, short of implementing a full markdown parser.

I haven't pushed this change yet, still looking for a better solution.

karthink commented 7 months ago

Should be fixed now.