From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Yuri D'Elia Newsgroups: gmane.emacs.devel Subject: Re: Getting column position accounting for overlays Date: Sat, 8 Aug 2015 17:19:02 +0200 Message-ID: <55C61DE6.7050706@thregr.org> References: <83a8u6tplx.fsf@gnu.org> <55C1D323.50505@thregr.org> <831tfhu5ge.fsf@gnu.org> <55C25983.5040702@thregr.org> <83vbctsgo6.fsf@gnu.org> <55C4E756.5020607@thregr.org> <83r3nfq7uq.fsf@gnu.org> <8337ztrg98.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1439047186 7529 80.91.229.3 (8 Aug 2015 15:19:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 8 Aug 2015 15:19:46 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 08 17:19:38 2015 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 1ZO5uK-0005GQ-NP for ged-emacs-devel@m.gmane.org; Sat, 08 Aug 2015 17:19:36 +0200 Original-Received: from localhost ([::1]:53084 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZO5uJ-0004V0-Vv for ged-emacs-devel@m.gmane.org; Sat, 08 Aug 2015 11:19:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33095) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZO5u6-0004Uk-OC for emacs-devel@gnu.org; Sat, 08 Aug 2015 11:19:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZO5u3-0002Ka-Iw for emacs-devel@gnu.org; Sat, 08 Aug 2015 11:19:22 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:42003) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZO5u3-0002KQ-Bv for emacs-devel@gnu.org; Sat, 08 Aug 2015 11:19:19 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZO5u0-00050H-4v for emacs-devel@gnu.org; Sat, 08 Aug 2015 17:19:16 +0200 Original-Received: from 151.34.138.232 ([151.34.138.232]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 08 Aug 2015 17:19:16 +0200 Original-Received: from wavexx by 151.34.138.232 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 08 Aug 2015 17:19:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 50 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 151.34.138.232 X-Enigmail-Draft-Status: N1110 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.1.0 In-Reply-To: <8337ztrg98.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:188614 Archived-At: On 08/08/15 16:45, Eli Zaretskii wrote: >> Ah yes, but that's precisely the problem: I need to calculate POS >> beforehand. > > Yes, of course. But you will have the same problem if you do get the > text dimensions: you need to compare that with something to do useful > things with the value. Right? Getting text dimensions was/is sort of a work-around. If I could get displayed text easily, the iteration over overlays wouldn't be needed: I could just take the string length. Again, it would have problems on its own as we discussed, so far none of the solutions work perfectly. >> It's not so trivial, considering that you basically have to handle all >> 'display cases manually to replicate what emacs does, you might have >> overlapping overlays, and so on. I also think that it's bound to break >> if 'display gets extended to support new properties. > > It's simply impossible, except in a few special cases. If we need > such a feature that should work everywhere, we will need to ask the > display engine to supply this information. > > But I still am unsure when would this be needed. To be more concrete, what about a (visual-column) function, that just gives what's currently needed? --- (visual-column &optional logical) Return the horizontal position of point. Beginning of the *visual* line is column 0. This is calculated by adding together the widths of all the displayed representations of the characters, *including 'display overlays*, between the start of the previous *visual* line and point (e.g., control characters will have a width of 2 or 4, tabs will have a variable width). If logical is non-nil, count displayed characters since the beginning of the current logical line. (visual-column t) is similar to (current-column), with the difference that overlays are taken into account. --- This would be the ideal basis for any visual-alignment function.