bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#18504: 24.3.93; posn-at-point intermittently returns wrong value for


From: Dmitry Gutov
Subject: bug#18504: 24.3.93; posn-at-point intermittently returns wrong value for a valid buffer position
Date: Fri, 19 Sep 2014 23:33:58 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1

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)).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]