Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error when trying to pop up the completion window over a sufficiently long after-string overlay at the end of buffer #274

Closed
jmickelin opened this issue Jan 8, 2015 · 4 comments

Comments

@jmickelin
Copy link

I'm getting the following error when company-mode tries to show the completion window right before an overlay on (point-max) that has the after-string property containing more than one line:

Company: Front-end company-pseudo-tooltip-unless-just-one-frontend error "Invalid search bound (wrong side of point)" on command post-command

Steps to reproduce:

  1. Run

    (setq my-ov (make-overlay (point-max) (point-max) nil t t))
    (overlay-put my-ov 'after-string "~\n~\n~")
  2. Put cursor on any line at most 10 lines before the end of buffer.

  3. Try to type a prefix to a completion.

The error seems to be caused by the call to (vertical-motion 1) in company-buffer-lines reporting that it has moved more than 1 line forward, when the point actually only moved at most one line. This seems to be fixed by replacing vertical-motion with the functionally equivalent (?) function (lambda (n) (- n (forward-line n))).

@jmickelin jmickelin changed the title Error when trying to pop up the completion window over an after-string overlay at the end of buffer Error when trying to pop up the completion window over a sufficiently long after-string overlay at the end of buffer Jan 8, 2015
@dgutov
Copy link
Member

dgutov commented Jan 9, 2015

Thanks, I see the error.

replacing vertical-motion with the functionally equivalent (?) function (lambda (n) (- n (forward-line n)))

Alas, not equivalent: forward-line moves by physical lines, whereas vertical-motion uses the visual lines. And we want the latter.

@dgutov dgutov closed this as completed in 770d0d8 Jan 10, 2015
@dgutov
Copy link
Member

dgutov commented Jan 10, 2015

@jmickelin I've pushed a workaround. Please see if it helps with your package.

@dgutov
Copy link
Member

dgutov commented Jan 10, 2015

Anyway, I can see it does.

The recent commit in emacs-24 Emacs branch also fixed a smaller glitch with the last buffer character being hidden in certain similar circumstances.

@jmickelin
Copy link
Author

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants