Latest commit d9edbbc seems broken "gptel--stream-convert-markdown->org is void"

[wlauppe]

Bug Description

While running commit d9edbbc i get the following message in the messages bufffer

gptel-curl-get-response: Symbol’s function definition is void: gptel--stream-convert-markdown->org

the last commit i was on 8889e27, works fine

Steps to Reproduce

execute gptel in an orgmode buffer

[pabl0]

Can't reproduce here, but 7400df6 does indeed drop loading gptel-org.el using with-eval-after-load ("since we require it anyway when sending commands").

Can you provide more details how to reproduce (emacs version, etc)?

[wlauppe]

Hello:
i use the master branch, from the emacs source
https://git.savannah.gnu.org/cgit/emacs.git/

Emacs version: "31.0.50"
OS: ubuntu linux

[wlauppe]

@pabl0 thanks for triaging the commits. I can confirm that the problem started with commit:
7400df6
the parent commit
aef57c2
works fine

[pabl0]

Can you provide the exact steps how to reproduce? Can you try with emacs -q?

If I run a new fresh emacs session with emacs foo.org and run M-x gptel-send, with d9edbbc it works fine for me.

[karthink]

@wlauppe do you have specific instructions on reproducing this?

After 7400df6 this can indeed happen, but under very special conditions. (By calling gptel-request directly with a string as the prompt while you're in an Org mode buffer, for example.)

I'm curious about how you triggered them.

Alternatively, you might just need to rebuild/reinstall gptel if there are some byte-compilation order issues.

[wlauppe]

@wlauppe do you have specific instructions on reproducing this?

1. start emacs
2. open a new file: foo.org
3. ensure that you have a model with streaming chosen, for example

(gptel-make-anthropic "Claude"
  :stream t :key gptel-api-key)

in the .emacs config and
M-x gptel-menu -> -m -> Claude:claude-3-5-sonnet-20241

4. write a new line in foo.org
   * count from 1 to 10
5. select as region the text "count from 1 to 10"
6. press "M-x gptel-send"
7. watch the Messages Buffer

you will see the line

gptel-curl-get-response: Symbol’s function definition is void: gptel--stream-convert-markdown->org

[pabl0]

OK I am able to reproduce with Github:deepseek-r1 and Github:gpt-4o and I have a proposed fix.

[karthink]

To solve this, I first need to answer a question I could use your feedback on:

If I select a region in Org mode and send it, should it be subject to the same processing as regular non-region gptel-send? This includes respecting gptel-org-branching-context and stripping property drawers and other elements according to gptel-org-ignore-elements.

If sending regions does respect these settings, there is no way to send a literal region in Org mode without turning off these settings first. On the other hand, if it always sends the region literally, this might not be what you want when you select a portion of an Org buffer.

What is your expectation?

[karthink]

@wlauppe While I decide between the two possible fixes, you can avoid this error by running (require 'gptel-org).

[wlauppe]

To solve this, I first need to answer a question I could use your feedback on:

If I select a region in Org mode and send it, should it be subject to the same processing as regular non-region gptel-send? This includes respecting gptel-org-branching-context and stripping property drawers and other elements according to gptel-org-ignore-elements.

If sending regions does respect these settings, there is no way to send a literal region in Org mode without turning off these settings first. On the other hand, if it always sends the region literally, this might not be what you want when you select a portion of an Org buffer.

What is your expectation?

Simpler is better. I didnt even know there are 3 modes. Until now i assumed there is the chat mode called "gptel-mode" and normal mode.

Im not using gptel-branching, so im maybe im not qualified to answer.
in fact, i only use region-gptel and dedicated-buffer-chat-gptel-mode

You hesitate, so you see some arguments in favour of the distinction? What are they?

I think it is easier for the users, if there are not too many different behaviours. Otherwise the bugs increase, because the edge cases are not tested well enough, or gptel behaviour is simply confusing, especially for newer users.

if you decide on not unifying the behaviour this should be made explicit in the documentation

from the README:

* Usage 
...
** In Any buffer 
...
2. If a region is selected, the conversation will be limited to its contents.

If there is more happening it should be documented there.

[karthink]

Simpler is better. I didnt even know there are 3 modes. Until now i assumed there is the chat mode called "gptel-mode" and normal mode.

The question is what "simpler" means. In this screenshot with a selected region

Should the PROPERTIES block be removed when sending the region? It is removed when calling gptel-send without the region active.