Weird interplay with purpose mode

[xuan-w]

When I invoke (gptel) directly, I got the following error:

It seems that this has something to do with purpose mode (I use Spacemacs, it includes purpose mode). Since purpose mode hasn't been updated for 3 years and the only thing I updated was gptel, I guess gptel introduced some changes?

Here is the error I encountered:

Debugger entered--Lisp error: (void-function user-action-sequence)
  user-action-sequence(#<buffer *ChatGPT*> ((user-action-sequence user-action-sequence pop-to-buffer)))
  purpose--action-function(#<buffer *ChatGPT*> nil)
  #<subr display-buffer>(#<buffer *ChatGPT*> ((user-action-sequence pop-to-buffer)) nil)
  purpose-display-buffer-advice(#<subr display-buffer> #<buffer *ChatGPT*> ((user-action-sequence pop-to-buffer)) nil)
  apply(purpose-display-buffer-advice #<subr display-buffer> (#<buffer *ChatGPT*> ((user-action-sequence pop-to-buffer))))
  display-buffer(#<buffer *ChatGPT*> ((user-action-sequence pop-to-buffer)))
  #<subr pop-to-buffer>(#<buffer *ChatGPT*> ((user-action-sequence pop-to-buffer)) nil)
  purpose-pop-to-buffer-advice(#<subr pop-to-buffer> #<buffer *ChatGPT*> ((user-action-sequence pop-to-buffer)) nil)
  apply(purpose-pop-to-buffer-advice #<subr pop-to-buffer> (#<buffer *ChatGPT*> ((user-action-sequence pop-to-buffer))))
  pop-to-buffer(#<buffer *ChatGPT*> ((user-action-sequence pop-to-buffer)))
  purpose--action-function(#<buffer *ChatGPT*> nil)
  #<subr display-buffer>(#<buffer *ChatGPT*> (pop-to-buffer) nil)
  purpose-display-buffer-advice(#<subr display-buffer> #<buffer *ChatGPT*> (pop-to-buffer) nil)
  apply(purpose-display-buffer-advice #<subr display-buffer> (#<buffer *ChatGPT*> (pop-to-buffer)))
  display-buffer(#<buffer *ChatGPT*> (pop-to-buffer))
  gptel("*ChatGPT*" "sk-***********************************************..." nil t)
  funcall-interactively(gptel "*ChatGPT*" "sk-***********************************************..." nil t)
  command-execute(gptel record)
  helm-M-x-execute-command(gptel)

I went back and checked, it seems that gptel Feb 09 version was OK (at least in my memory) and on Feb 10 gptel add a variable to customize the pop up window behavior.

So the old code was

      (pop-to-buffer (current-buffer))

Now it is

      (display-buffer (current-buffer) gptel-display-buffer-action)

Actually got called was (display-buffer (current-buffer) '(pop-to-buffer)) with default value of gptel-display-buffer-action.

It seems that pop-to-buffer actually call display-buffer to do the work (got this from pop-to-buffer doc) so display-buffer is called again (my understanding could be wrong). Somehow with purpose's advice, when display-buffer got called again, an error was throwed.

First time display-buffer got called, it is display-buffer(#<buffer *ChatGPT*> (pop-to-buffer)), which is fine. Second time, it is #<subr display-buffer>(#<buffer *ChatGPT*> ((user-action-sequence pop-to-buffer)) nil), which doesn't match display-buffer's args.

This is the furthest I can dig, any suggestions? I am not sure if it is purpose mode too old to be compatible with latest Emacs or there is something can make gptel works happily with purpose mode.

Personally, I wrote a custom function in my .emacs to create a chat buffer and call gptel-send so I wasn't affected much. (That is why I only found it out after a month).

[BenedictHW]

I use Spacemacs, and I can confirm that I have the same bug. However the ChatGPT markdown buffer is created, I can see it when call "list-buffers". It is when I call M-x "gptel" for the second consecutive time that the "user-action-sequence" error pops up.

Great package Karthink, it's been a real pleasure to use.

[mch]

I also have this problem with spacemacs. I don't use the purpose layer, and was able to solve this by excluding the window-purpose package in my .spacemacs file:

   ;; A list of packages that will not be installed and loaded.
   dotspacemacs-excluded-packages '(window-purpose)

It is strange that this package specifically has this problem though.

[karthink]

Thank you for the reports. I'll take a look at what purpose-mode is doing when I have time.

[mijoharas]

One thing to note @mch, is that while your solution fixes gptel it'll cause some issues with spacemacs. For instance if you do C-h f and then select something you'll get an error. Instead for spacemacs using (purpose-mode -1) seems to work well (it just disables the mode, and allows both C-h f to work, and for gptel to work.)

I tried to debug it a little bit, but hooking the failing purpose function messes with edebug too, so I gave up when finding this workaround.

[karthink]

This should be handled by the update Spacemacs configuration in #412, which disables purpose-mode.