mode-line-process instead of header-line-format about gptel HOT 9 CLOSED

Which one do you think should be the default?

I don't care much, but personally I would for sure disable the header line.

The reason I picked the header-line is because there are too many mode-line packages out there that transform/hide mode-line elements and minor-mode lighter info.

I agree. In my setup I only use minions and made a few simple adjustments to the mode line myself. But besides that my mode-line is mostly vanilla.

Since the header-line is only intended for dedicated gptel buffers, it seemed like a safe bet.

Indeed, it is. The mode-line-process variable should be a reasonable safe alternative.

from gptel.

@minad Streaming responses is now added, and is turned on by default.

from gptel.

Done, finally! Set gptel-use-header-line to nil for less obtrusive status display/messaging when using gptel-mode.

from gptel.

Sure, the header-line is just a stopgap solution. I'm sure there are better alternatives.

To get more progress updates, there are a couple of possibilities:

1. The API has a stream option that sends chunks of data. It is possible to write a process filter that updates the buffer live as these come in, like in the browser. This is the correct solution, but I've been working on other aspects. (PRs are welcome!)
2. There is a gptel-playback option in the package that plays back data in chunks. This doesn't save you any time, it waits until it receives the full response, then plays it back continuously so it's actually slower! It's silly but it does make the process feel somewaht interactive.
3. Another cheap trick I've tried is to pulse-momentary-highlight-region when the response comes in. It's still slow, but like the previous option it feels a little more interactive.

from gptel.

The API has a stream option that sends chunks of data. It is possible to write a process filter that updates the buffer live as these come in, like in the browser. This is the correct solution, but I've been working on other aspects. (PRs are welcome!)

This is the approach I favor. I am happy to help out if I find time, but I just started experimenting with this. The overall approach of your package seems good with the list of prompts in a plain text document, but I haven't checked out the other solutions.

from gptel.

Would you accept a quick PR which replaces the header-line with a mode-line indicator? I would add a gptel-status-function which can be either set to a function for the header-line and a function for the mode-line.

from gptel.

Sure, that would be a welcome addition! Which one do you think should be the default?

The reason I picked the header-line is because there are too many mode-line packages out there that transform/hide mode-line elements and minor-mode lighter info. doom-modeline is a popular example of this -- no Doom users would see any status messages until someone adds explicit support for doom-modeline. This makes my job of reporting errors/readiness etc harder.

Since the header-line is only intended for dedicated gptel buffers, it seemed like a safe bet.

from gptel.

Indeed, it is. The mode-line-process variable should be a reasonable safe alternative.

Sounds good to me.

from gptel.

This is the approach I favor. I am happy to help out if I find time, but I just started experimenting with this. The overall approach of your package seems good with the list of prompts in a plain text document, but I haven't checked out the other solutions.

@minad I added continuous response streaming -- it's now much faster (and continues to be async):

I haven't merged it yet (it's in the streaming branch) since the markdown -> Org conversion from an incomplete parse state is proving tricky.

from gptel.