GNU bug report logs -
#18504
24.3.93; posn-at-point intermittently returns wrong value for a valid buffer position
Previous Next
Reported by: Dmitry <dgutov <at> yandex.ru>
Date: Fri, 19 Sep 2014 01:02:02 UTC
Severity: normal
Found in version 24.3.93
Done: Dmitry Gutov <dgutov <at> yandex.ru>
Bug is archived. No further changes may be made.
Full log
Message #41 received at 18504 <at> debbugs.gnu.org (full text, mbox):
On 09/19/2014 06:21 PM, Eli Zaretskii wrote:
>> Yes. I'm not sure how we get there code-wise, though.
>
> So I'm asking again: why does it matter what happens after a C-g,
> i.e. after the user abandons the completion?
1. I'm not 100% sure yet if the problem happens after C-/ or C-g. Just
that both need to be pressed at least once.
2. Apparently, one of the last C-g presses (probably the last one) calls
`keyboard-quit' instead of `company-abort', which in the command, bound
in `company-active-map', that aborts completion.
So, I haven't wrapped my head around it yet, but on the odd chance I
won't manage to do that before Emacs 24.4 release and it's not actually
a bug in company-mode, maybe it's worth investigating whether
`posn-at-point' behaves improperly anyway, first.
>> Same as previously described, no change there. Just make sure to (setq
>> bidi-display-reordering nil).
>
> Can you show the full value of posn-at-point in that case?
With this code:
diff --git a/company.el b/company.el
index fdf09f7..5c901c6 100644
--- a/company.el
+++ b/company.el
@@ -782,7 +782,12 @@ means that `company-mode' is always turned on
except in `message-mode' buffers."
(cons (+ col (window-hscroll)) row)))
(defun company--col-row (&optional pos)
- (company--posn-col-row (posn-at-point pos)))
+ (message "foofoo\nfoo")
+ (let ((posn (posn-at-point pos)))
+ (when (zerop (car (posn-x-y posn)))
+ (message "posn at %s #1 %s" pos posn)
+ (message "posn at %s #2 %s" pos (posn-at-point pos)))
+ (company--posn-col-row posn)))
(defun company--row (&optional pos)
(cdr (company--col-row pos)))
I get the following output:
<...>
foofoo
foo
posn at nil #1 (#<window 16 on *scratch*> 206 (0 . 270) 0 nil 206 (0 .
15) nil (0 . 0) (9 . 18))
posn at nil #2 (#<window 16 on *scratch*> 206 (0 . 270) 0 nil 206 (0 .
15) nil (0 . 0) (0 . 0))
foofoo
foo
posn at 195 #1 (#<window 16 on *scratch*> 206 (0 . 270) 0 nil 206 (0 .
15) nil (0 . 0) (0 . 0))
posn at 195 #2 (#<window 16 on *scratch*> 206 (0 . 270) 0 nil 206 (0 .
15) nil (0 . 0) (0 . 0))
<...>
foofoo
foo
posn at nil #1 (#<window 16 on *scratch*> 206 (0 . 270) 0 nil 206 (0 .
15) nil (0 . 0) (0 . 0))
posn at nil #2 (#<window 16 on *scratch*> 206 (0 . 270) 0 nil 206 (0 .
15) nil (0 . 0) (0 . 0))
foofoo
foo
posn at 195 #1 (#<window 16 on *scratch*> 206 (0 . 270) 0 nil 206 (0 .
15) nil (0 . 0) (0 . 0))
posn at 195 #2 (#<window 16 on *scratch*> 206 (0 . 270) 0 nil 206 (0 .
15) nil (0 . 0) (0 . 0))
<...>
Point is indeed at 195. Note that the last element is sometimes
different between `posn-at-point' invocations ((9 . 18) vs (0 . 0)), but
sometimes not (both pairs of zeros)).
This bug report was last modified 10 years and 248 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.