Add customization option to disable max-char warning message

[jhdavis8]

This is just a really simple option I added for my own use, thought other might find it useful. I often open very large files that I don't necessarily care about getting copilot suggestions on and disabling this warning is simpler and more general than setting up emacs configurations to disable the copilot mode for those specific files and file types.

Just set copilot-max-char-warning-disable to t to disable the warning message that appears when opening a file that exceeds copilot-max-char.

[jcs090218]

This may not be an elegant way to work around this issue, but I don't have any objections on this. 🤔

cc @emil-vdw WDYT?

[emil-vdw]

I don't think this is a good feature. When this happens, the agent's state for that buffer is messed up so it breaks copilot for that buffer. It would be misleading to treat this as just a warning one can ignore. Best course of action is to increase this max or prevent copilot from activating in these large buffers like so:

(defun my/activate-copilot ()
  (if (> (buffer-size) copilot-max-char)
      ;; Or don't even warn to get rid of it.
      (warn "Buffer size exceeds copilot max char limit. Copilot will not be activated.")
    (copilot-mode)))

[emil-vdw]

What I mean is that the problem is activating copilot on an unsuitable buffer, and the solution is to to avoid activating it and not instead of silencing the warning. The other option is, of course, to extend the plugin to send large buffers in chunks initially. It might be worthwhile to look at how copilot.vim solves the problem of large buffers.

[emil-vdw]

@jhdavis8 didn't mean to be negative :sweat_smile: . Thanks for taking the time!

[Gleek]

Hello @emil-vdw,

It might be worthwhile to look at how copilot.vim solves the problem of large buffers.

Did you get a chance to look at this? I do see an issue open about handling large files in vscode copilot, here, so have little hope that copilot.vim handles this correctly as well.

the agent's state for that buffer is messed up so it breaks copilot for that buffer

It does provide slightly degraded completions, but they are still pretty good, in my experience of using it. Disabling it altogether seems a bit excessive

I think copilot.el takes the correct default approach of warning the user of potentially bad responses because of the limit while still keeping it enabled. In my opinion, we should maintain this behavior while still providing the customization to disable this warning.

In my use case, for example, I've an org file which I frequently open and it is slightly over the max char limit. I still use copilot in it with decent results. Getting a warning popup every time I open it becomes slightly annoying specially if I'm doing this multiple times an hour. I'm aware that the results will be degraded, but I don't want to be reminded about it all the time.

I suppose having some variable that I can set buffer locally using .dir-locals.el or some hook will make this very simple for me to handle.

How else do you suggest I could handle this case? If not for a single variable that I could easily toggle, I think I'm left with:

• either increasing the max-char-limit to cover the whole file, which I don't want to and would prefer to stick to the defaults as the file might get too large to send over to github causing other issues.
• wrap an advice over the copilot function to disable the warning popups, which is still painful.

Do you suggest there's another way to approach this?

Anyway, thanks for helping bring copilot to Emacs and continued effort to improve it's functionality 😄

Regards.