Re: wrong cursor position reported when window margins are wide

[Joost Kremers]

On Tue, Feb 28 2017, Eli Zaretskii wrote:
> > From: Joost Kremers <address@hidden>
> > Date: Tue, 28 Feb 2017 15:01:22 +0100
> > It seems that when the window margins of an Emacs window are 
> > non-nil, the cursor position is reported incorrectly, resulting 
> > in 
> > the input box being displayed in the wrong place.
> >
> > The original bug report is here:
> >
> > <https://github.com/joostkremers/visual-fill-column/issues/25#issuecomment-281844388>
> >
> > There are screen shots that illustrate the problem. (Scroll 
> > down a 
> > bit for screen shots with `emacs -Q'.)
>
> Sorry, I couldn't understand what is meant by "cursor position
> reporting".  Could you clarify, 

Honestly, I'm in way over my head here, so I'm mainly going by 
this FAQ on the Fcitx site:

https://fcitx-im.org/wiki/FAQ#Cursor_Following_problem

which admittedly doesn't provide much info, either. Basically, 
from what I gather, Fcitx and ibus and similar input methods pop 
up an input box that follows the text cursor as you type. In order 
to do so, they need to know the absolute position of the text 
cursor on the screen. And in order to be able to determine 
(calculate?) this position, they need some info from the windowing 
system, which in turn receives this info from the active 
application.

I'm sorry I can't be more specific, but I know nothing about the 
internals of the X Window System, nor am I well-versed enough in C 
to go through the Fcitx source and figure out what information it 
is exactly that Fcitx requires from X. I was kinda hoping that 
someone here has more clue than I do and could help out.

> and perhaps show an example of how
> that reported position changes when a window has display 
> margins?

Apparently, judging by the screen shots posted in the Github 
thread, the reported position does *not* change, even though it 
should.


--
Joost Kremers
Life has its moments