Closed wusticality closed 1 year ago
Both hl-line and copilot.el uses overlays, which is the most common cause of compatibility problems.
The problems you showed are caused by after-string
.
You can make the following changes to disable after-string
, but there will be other undesired side effects.
--- a/copilot.el
+++ b/copilot.el
@@ -413,14 +413,7 @@ USER-POS is the cursor position (for verification only)."
(make-overlay (point) (line-end-position) nil nil t)
(move-overlay copilot--overlay (point) (line-end-position))
copilot--overlay)))
- (if (= (overlay-start ov) (overlay-end ov)) ; end of line
- (progn
- (setq copilot--real-posn (cons (point) (posn-at-point)))
- (put-text-property 0 1 'cursor t p-completion)
- (overlay-put ov 'display "")
- (overlay-put ov 'after-string p-completion))
- (overlay-put ov 'display (substring p-completion 0 1))
- (overlay-put ov 'after-string (substring p-completion 1)))
+ (overlay-put ov 'display p-completion)
(overlay-put ov 'completion completion)
(overlay-put ov 'start (point))
(overlay-put ov 'uuid uuid)
@@ -567,7 +560,7 @@ Use this for custom bindings in `copilot-mode'.")
(or
(s-starts-with-p "copilot-" (symbol-name this-command))
(member this-command copilot-clear-overlay-ignore-commands)
- (copilot--self-insert this-command)))))
+ ))))
(copilot-clear-overlay)
(when copilot--post-command-timer
(cancel-timer copilot--post-command-timer))
Hmm, I'd rather not diverge from main
if I can help it. What about partitioning how candidates are displayed to make it customizable? That is, allow it to be an overlay, or a box (like company-box
), or the minibuffer, or what have you. Thoughts?
Hmm, I'd rather not diverge from
main
if I can help it. What about partitioning how candidates are displayed to make it customizable? That is, allow it to be an overlay, or a box (likecompany-box
), or the minibuffer, or what have you. Thoughts?
What I like about the current UI is that I can have the Corfu completion popup open while simultaneously having the Copilot overlay showing a completion in the buffer. The two completion interfaces do not interfere with each other.
Also, with these keybindings
(map! (:map copilot-completion-map
"<right>" #'copilot-accept-completion
"C-f" #'copilot-accept-completion
"M-<right>" #'copilot-accept-completion-by-word
"M-f" #'copilot-accept-completion-by-word
"C-e" #'copilot-accept-completion-by-line
"<end>" #'copilot-accept-completion-by-line
"M-n" #'copilot-next-completion
"M-p" #'copilot-previous-completion))
completion is feels very natural. Like you're "moving over" the text being completed to select it.
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.
This issue was closed because it has been stalled for 5 days with no activity.
Hey there, loving the package so far! :)
I'm running into a few snags with the way
copilot.el
deals with faces. I usehl-mode
to render a solid background color across the current line. Withcopilot.el
enabled, things look like this:A few things of note here:
hl-mode
line is broken up into two pieces spread across multiple lines which is strange behavior.hl-line
face. It also doesn't seem to use the background color of thecopilot-overlay-face
.I'm not wholly sure what the solution is here, but having more control over the face, the overlay and its properties would be extremely helpful. What I'd love more than anything is for the
hl-mode
line to be respected, and to default to the regular background color for the rest of the lines in the completion.