issue with narrowing

[ultronozm]

copilot often stops working in narrowed buffers. It also sometimes enters a broken state, occasionally requiring a restart of emacs. Here's a simple (non-artificial) example that disables it:

1. Put the following in *scratch* or some elisp file:

(defun add (a b)
  (+ a b))
(defun sub (a b)
  (- a b))
; 2+2
(defun mul (a b)
  (* a b))
(defun div (a b)
  (/ a b))

2. Mark the region containing the sub and mul definitions, and M-x narrow-to-region (so that add and div are now hidden).
3. Put point after the second 2 and insert "=". copilot fails to suggest any completion. (But if you try the same completion in a buffer containing the same contents as this narrowed buffer, it will consistently suggest the completion "4".)
4. After M-x widen, the buffer is occasionally in a semi-broken state as far as copilot is concerned -- sometimes completion overlays appear a few lines away from point, sometimes they don't appear at all, sometimes it won't work anywhere until I restart emacs, etc. I haven't been able to make this step repeatable.

[raymond-w-ko]

Hmm, one think that has to be figured out is whether this is related to PR #164, my lisp balancer code, or something that is part of core.

If you set copilot-balancer-lisp-modes to be empty list, does the issue still occur?

[ultronozm]

Yes, the issue persists after (setq copilot-balancer-lisp-modes nil). To give further evidence, I notice it while editing LaTeX in narrowed buffers.

[emil-vdw]

It makes sense that narrowing would break completions (and garble the internal state) because it changes the line and column number in the requests.

Insert an "a" before (defun sub ... before narrowing:

(:jsonrpc "2.0" :method "textDocument/didChange" :params
		  (:textDocument
		   (:uri "buffer://*scratch*" :version 158)
		   :contentChanges
		   [(:range
			 (:start
			  (:line 2 :character 0)
			  :end
			  (:line 2 :character 0))
			 :text "a")]))

and after narrowing:

(:jsonrpc "2.0" :method "textDocument/didChange" :params
		  (:textDocument
		   (:uri "buffer://*scratch*" :version 160)
		   :contentChanges
		   [(:range
			 (:start
			  (:line 0 :character 0)
			  :end
			  (:line 0 :character 0))
			 :text "a")]))

As far as I can tell there are 2 options:

1. Implement a mapping function to translate positions of ops in the narrowed region to their widened equivalent. Adds a bit of complexity and I'm not sure how worth it the complexity would be just to support narrowing?
2. Reload the whole buffer with just the narrowed area. Less complex but loses context of rest of buffer for completions.

[ultronozm]

My vote would be for (1), since I constantly use narrowing.

After seeing your comment, I looked at the code a bit, and it seems that there's a simple fix: add save-restriction and widen before computing line/column numbers in copilot--on-doc-change. Will send PR for review in just a sec