From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= Newsgroups: gmane.emacs.devel Subject: Re: Unicode combining characters Date: Tue, 25 May 2021 15:30:21 -0400 Message-ID: <3e40bcd1-3d04-23c0-37a7-6a283ca4e3e4@gmail.com> References: <83k0nmbubk.fsf@gnu.org> <2437db42-62fc-ea3c-279b-170152defc62@gmail.com> <83cztebqtl.fsf@gnu.org> 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="9826"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 25 21:31:57 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 1llcmT-0002Qy-3p for ged-emacs-devel@m.gmane-mx.org; Tue, 25 May 2021 21:31:57 +0200 Original-Received: from localhost ([::1]:35542 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1llcmR-0001D3-Vp for ged-emacs-devel@m.gmane-mx.org; Tue, 25 May 2021 15:31:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34806) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1llcl2-0000Df-Ax for emacs-devel@gnu.org; Tue, 25 May 2021 15:30:28 -0400 Original-Received: from mail-qk1-x72f.google.com ([2607:f8b0:4864:20::72f]:42850) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1llcl0-0006Yd-Kb; Tue, 25 May 2021 15:30:28 -0400 Original-Received: by mail-qk1-x72f.google.com with SMTP id o27so31582250qkj.9; Tue, 25 May 2021 12:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=3yjWy6efq5z3q+cnG57MXaPKpZ6wjU5SH6V3QBb8BW0=; b=EKLiw3m0seEny3iPZLFmSOj1ZLDiYh4JXWhXkNGOgnYn3n0tf2WMzBzSXdnqUB0jFc 30onLyAAbp1UDcEk0MuHc1LxJaS+d3ZV+yIpJJpmn0yuOQjEmbk3L3xrCr8NywRqZkys ClU4jfXOGABhtsgYKx/U8It9qVbfYjvzfIY37W/Y7+CsPI56kaN1XIz0LYSZ0nyj68rp XA5fyakab3iCiF3ffey4jTRDUr3JRyJaaHvhblw0n/jdOZ1WT0dsLf7j9wHOcqVv7iL4 3hw0I3gOIP5hH+6nZeVu6GkHS4kROKgkxbStqGYHWI3syIZbxu2N+wx93u2ewx//2pNw 6vqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3yjWy6efq5z3q+cnG57MXaPKpZ6wjU5SH6V3QBb8BW0=; b=FNFRdvRxSC4nCNAd0+5epWAlW1mzinbvNmKpngOeUOnlvmPjF7ECl4ljae4dv9HSiq HtYYzFyQJjvXfN+CwAMxjjUKH5dlBGnu2XFUs5xpm05N9IZgnd7JjlZ40OK35pAdgDpi Zk9gcdFTQPdvcmo7odd3izmGZowqSAOLIDbLxx1RuIhQYw6rfoLo7X2DG7porDqhUCdV ckJscJQ3Oa9cqJr1c+Dks/9A6LTW/Wqzar2N1fWisY6887ead/ngnSUsg5Sv0bDOSzHH chSlqixRx3JKe9el0SmXktBJ1BO+lAs1eg1yISxMzYWA04KVzkbKRKRrAN2PtsrLZn8G kspA== X-Gm-Message-State: AOAM530cK9i90ACJr8C8JWkD04gDNuPdRDtou8mBpiMZNkgN/iUbv0HS aAlDzLOsxkE9HT0NvUHwuBFp84Stke8= X-Google-Smtp-Source: ABdhPJzOM6ywFom4mlRJncoTeQAR1pV5CSFcPQYzpr4IRswvEUfw6d0ObR6BsbZIimAEyB25j6RSjA== X-Received: by 2002:a37:9fc1:: with SMTP id i184mr37649622qke.334.1621971024520; Tue, 25 May 2021 12:30:24 -0700 (PDT) Original-Received: from [192.168.1.11] (c-24-61-240-80.hsd1.ma.comcast.net. [24.61.240.80]) by smtp.googlemail.com with ESMTPSA id c26sm75107qtj.41.2021.05.25.12.30.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 May 2021 12:30:22 -0700 (PDT) In-Reply-To: <83cztebqtl.fsf@gnu.org> Content-Language: en-GB Received-SPF: pass client-ip=2607:f8b0:4864:20::72f; envelope-from=cpitclaudel@gmail.com; helo=mail-qk1-x72f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:269885 Archived-At: On 5/25/21 2:39 PM, Eli Zaretskii wrote: >> From: Clément Pit-Claudel >> Date: Tue, 25 May 2021 14:15:33 -0400 >> >> On 5/25/21 1:24 PM, Eli Zaretskii wrote: >>>> From: Anand Tamariya >>>> Date: Tue, 25 May 2021 21:26:44 +0530 >>>> >>>> Hindi Devanagari script has lot of unicode combining characters which results in misalignment in a >>>> rectangular overlay for constant number of characters (screenshot ) >>>> What would be a recommended way to tackle this in Emacs? >>> >>> Use align-to 'space' display spec and/or the window-text-pixel-size >>> function, which will account for the actual size of the text on >>> display. >> >> Will this work? The misaligned specs are already part of a replacing dipsplay spec, so the additional align-to would be ignored, no? > > I don't understand, but maybe you know about the particular use case > more than I do. I just mentioned two devices that can be accurate to > 1 pixel wrt to the X coordinate. > >> (IIRC, there is no way to say "replace this text by this string followed by this specified space; it's one or the other, right?) > > Again, I don't think I follow. If you have "this text", you can > calculate its width on display, and then know how many pixels of white > space you will need after "this string" replaces that text. So, > unless I'm missing something, specifying the space width is redundant, > and actually makes a solvable problem unsolvable. 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. Clément.