From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: How to obtain x/y/hpos/vpos at eol -- excluding overlay 'after-string. Date: Tue, 05 Apr 2016 18:08:09 +0300 Message-ID: <83shz0m6ue.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1459868934 19762 80.91.229.3 (5 Apr 2016 15:08:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Apr 2016 15:08:54 +0000 (UTC) Cc: emacs-devel@gnu.org To: Keith David Bershatsky Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 05 17:08:47 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1anSax-0005M1-SJ for ged-emacs-devel@m.gmane.org; Tue, 05 Apr 2016 17:08:43 +0200 Original-Received: from localhost ([::1]:37602 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anSax-0002We-1K for ged-emacs-devel@m.gmane.org; Tue, 05 Apr 2016 11:08:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46337) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anSaq-0002Ur-FV for emacs-devel@gnu.org; Tue, 05 Apr 2016 11:08:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1anSam-00085N-BC for emacs-devel@gnu.org; Tue, 05 Apr 2016 11:08:36 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50260) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anSam-000852-7C; Tue, 05 Apr 2016 11:08:32 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4267 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1anSal-0003He-Hx; Tue, 05 Apr 2016 11:08:31 -0400 In-reply-to: (message from Keith David Bershatsky on Mon, 04 Apr 2016 14:06:08 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:202739 Archived-At: > Date: Mon, 04 Apr 2016 14:06:08 -0700 > From: Keith David Bershatsky > > There are a couple of applications where this would be useful. > > The first application is a common function available interactively called `posn-at-point` which cannot return the desired `x` and `hpos` when an 'after-string is present at point. For example, line-move-visual in simple.el has never worked correctly when I have overlay 'after-string at the end of the line. So, I have been using a workaround with `vertical-motion` to calculate the desired `temporary-goal-column`. Here is the link to a thread on emacs.stackexchange.com from about a year ago relating to this issue: > > http://emacs.stackexchange.com/questions/7957/calculating-cursor-position-excluding-the-overlay-after-string Your original request was about doing this on the C level, so the above use case is not really related: line-move-visual is implemented in Lisp. > The second application is related to feature request 22873 (multiple fake cursors) and a dormant (yet related) feature request 17684 (drawing a vertical line the length of the window). I have not been able to accurately predict programmatically where the fake cursors are located subsequent to the screen scrolling when overlay 'after-string are present. [I spent a day writing up a function to calculate the differential of `y` and `vpos` based on previous and current window-start/end, only to discover that the Little Rascals (fake cursors) were still somewhere else when scrolling.] The function `erase_phys_cursor` redraws the character (where the cursor was) based upon (in part) the values of x/y/hpos/vpos. Until I can figure out how to accurately predict where those Little Rascals (fa ke cursors) have gone to when scrolling occurs, the easiest thing to do is erase/redraw everything along the `x` axis. `erase_phys_cursor` should not be used, however, when there is no TEXT along the `x` axis - because that yields strange looking glyphs along the right side of the screen. Before calling `erase_phys_cursor` (or my custom function `mc_erase`), I want to check to see where the end of the visual line is -- i.e., x/y/hpos/vpos at the end of each visual line -- and only erase/redraw characters when the `x` axis is less than the end of the visual line This is indeed about something you do in C. However, I don't understand why you try using posn-at-point, which is a Lisp API, for a job you need to do in C. On the C level, you have access to a more elaborate information, e.g. you can examine the object at point and do something when it is an overlay string. I must admit I still don't see clearly why you need screen coordinates corresponding to a buffer position, in the multiple-curses scenario. Isn't it your code that positions those cursors in the first place? If so, why do you need to find out where those cursors are, if your code did the positioning?