minad / cape

🦸cape.el - Completion At Point Extensions
GNU General Public License v3.0
573 stars 20 forks source link

cape-wrap-inside-faces: use (1- (point)) instead of (point) #111

Closed LemonBreezes closed 4 months ago

LemonBreezes commented 4 months ago

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)) : image ^ 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. image ^ Running that here gives (font-lock-comment-face font-lock-comment-face) because Elisp font-locking applies the comment face to the newline character, image ^ Whereas running it here gives (tree-sitter-hl-face:comment nil) because tree-sitter-hl does not highlight the newline character.

minad commented 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.

minad commented 4 months ago

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.