From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Unicode combining characters Date: Tue, 25 May 2021 22:44:29 +0300 Message-ID: <83a6oibntu.fsf@gnu.org> References: <83k0nmbubk.fsf@gnu.org> <2437db42-62fc-ea3c-279b-170152defc62@gmail.com> <83cztebqtl.fsf@gnu.org> <3e40bcd1-3d04-23c0-37a7-6a283ca4e3e4@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40669"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 25 21:45:45 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1llczp-000ARh-KM for ged-emacs-devel@m.gmane-mx.org; Tue, 25 May 2021 21:45:45 +0200 Original-Received: from localhost ([::1]:53234 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1llczo-0005RF-Ip for ged-emacs-devel@m.gmane-mx.org; Tue, 25 May 2021 15:45:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37620) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1llcyd-00046t-Uf for emacs-devel@gnu.org; Tue, 25 May 2021 15:44:32 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60926) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1llcyd-0005vD-Mf; Tue, 25 May 2021 15:44:31 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3867 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1llcyd-00081e-7z; Tue, 25 May 2021 15:44:31 -0400 In-Reply-To: <3e40bcd1-3d04-23c0-37a7-6a283ca4e3e4@gmail.com> (message from =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel on Tue, 25 May 2021 15:30:21 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:269888 Archived-At: > Cc: emacs-devel@gnu.org > From: Clément Pit-Claudel > Date: Tue, 25 May 2021 15:30:21 -0400 > > Based on the screenshot this is an issue with Company. Company displays its "pop-ups" by putting a replacing 'display property on the text following the point (and on the next few lines). So if the buffer contains > > ABC XYZ DEF GHI > JKL MNO PQR STU > > and the point is after XYZ, then company puts a replacing display spec from " DEF" to "STU". > To display completions "XYZ1233" and "XYZ456", the replacing display spec contains "123| GHI\nJKL XYZ456| STU", so the final display is > > ABC XYZ123| GHI > JKL XYZ456| STU > > The OP's issue is that "123" and "456" don't have the same length. As far as I know, there is no way to add extra space after 123 or 456 so that they reach the same X coordinate, given that they are already part of a display spec. First, the OP said "overlay", and overlay strings can have display properties. And second, I'd expect the current code to use string-width to compute how much whitespace will be needed after each completion candidate, and string-width already accounts for composed (a.k.a "combined") characters. Yes, string-width provides only an approximation for the true pixel width of the string, but that's not specific to compositions, and the whole technique is somewhat of a kludge anyway, for this reason and others.