1

I use the ace-window package to move focus from one Emacs window to another. It uses the built-in function window-start to decide where to place an overlay that contains a number I would type to jump to that window. That is, to make that window (and the frame containing it) the focus of input.

Sometimes, a window will not display a number, making me guess how to get to it.

The window-start function is supposed to return the character position in the buffer that is the top-left visible position in that window.

It seems that window-start sometimes returns the position in that window's buffer that is one line above the actual first-displayed position. So, ace-window dutifully displays the number in a place that is not visible.

Has anyone else experienced this? Does anyone have suggestions on how I could fix it?

Speculation: - Could it be thrown off by lines with unusual line-height such as those containing special glyphs like HEAVY CHECK MARK? - Could it be caused by unusual fringes or a header-line? [One buffer where I experienced this, had some lines with extra-tall characters. Another was an info buffer that had a header-line.]

  • More speculation: Perhaps window-start is called before redisplay has updated it? (re: (elisp) Window Start and End) – Basil Mar 18 at 20:37
  • 1
    Unfortunately, window-start and window-end can never be 100% entirely accurate even when using the optional argument to latter; i.e., UPDATE. It is sad, but true ... Only by going inside the C source code and creating new features that work with redisplay can these values be obtained with 100% accuracy. Why? Because redisplay does not know the values 100% of the time until it has finished and there are numerous settings and stuff that affect where the bouncing ball will finally land. stackoverflow.com/questions/23923371/… – lawlist Mar 19 at 1:36
  • 1
    In order to fix this, I think one would have to first figure out what is happening. Maybe window-start is actually correct (that would be my guess) but the corresponding buffer text is made invisible and that ends hiding the overlay as well? – Stefan Mar 19 at 1:58
  • Please consider filing and Emacs bug/enhancement-request report: M-x report-emacs-bug. – Drew Mar 19 at 2:33
  • @Stefan I ran it under edebug and saved the value returned for the relevant window. Then I used goto-char and saw that it was the BOL position of the line before what should be the value of (window-start). It happened for two windows in two distinct frames. That’s why I think the value is wrong. – Colin Fraizer Mar 19 at 2:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.