Closed hieutkt closed 7 months 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?
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.
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.
The transient menu has this option now. You could do it in two ways:
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.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)Hmm... I can't hit return to send from gptel-menu
? Sorry I'm not very familiar with transient menus.
Wow that's odd. Not sure what the issue is. Does C-m
instead of RET
work?
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 😅
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).
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.
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)
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!
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.
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.
Should be fixed now.
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: