Closed LemonBreezes closed 4 months ago
I had considered this before, but I am not sure if (1- (point)) is generally better. I think the problem is a little more difficult. One should try to detect if point is at the edge of a region with a given face. Then maybe a certain distance should be required. For example a docstring in Python uses triple quotes, so only if point has a distance of three from the edge, we can actually be sure that we are inside the docstring, where completion should happen.
For now I've committed your change with a minor reformatting, see https://github.com/minad/cape/commit/ebace83837a7758dd331dad04878074382ea3dd7. If you stumble over more problems we should try to solve this more rigorously.
This addresses #109 where we weren't picking up
tree-sitter-hl-face:comment
. The problem is that when you use(text-properties-at (point))
, it returns the properties of the character after the point, not the character before the point. To illustrate, running(describe-char (point-max))
errors out with "No character follows specified position". When we are completing based on face, we always mean the face of the character immediately before the point.To give a few examples of running
(list (get-text-property (1- (point)) 'face) (get-text-property (point) 'face))
: ^ Running that here produces(font-lock-variable-name-face nil)
, and the left output makes more sense in the context that you are typing out a variable name. ^ Running that here gives(font-lock-comment-face font-lock-comment-face)
because Elisp font-locking applies the comment face to the newline character, ^ Whereas running it here gives(tree-sitter-hl-face:comment nil)
becausetree-sitter-hl
does not highlight the newline character.