From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Mendler Newsgroups: gmane.emacs.bugs Subject: bug#47712: 27.1; Provide `string-display-width` function, which takes properties into account, `substring-width` Date: Mon, 12 Apr 2021 14:50:25 +0200 Message-ID: <1c8f7066-3da2-d960-11e7-a42f567432bd@daniel-mendler.de> References: <642c8a37-31c7-2723-12af-06cd7f120c2f@daniel-mendler.de> <83r1jg2q72.fsf@gnu.org> <83lf9n3d7x.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25340"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 47712@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 12 14:51:37 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1lVw2T-0006TW-7s for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 12 Apr 2021 14:51:37 +0200 Original-Received: from localhost ([::1]:54536 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lVw2R-0001d7-Vl for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 12 Apr 2021 08:51:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43684) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lVw1u-0001cL-CO for bug-gnu-emacs@gnu.org; Mon, 12 Apr 2021 08:51:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45260) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lVw1u-0006Ms-4P for bug-gnu-emacs@gnu.org; Mon, 12 Apr 2021 08:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lVw1u-0006FQ-1h for bug-gnu-emacs@gnu.org; Mon, 12 Apr 2021 08:51:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Apr 2021 12:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47712 X-GNU-PR-Package: emacs Original-Received: via spool by 47712-submit@debbugs.gnu.org id=B47712.161823183623965 (code B ref 47712); Mon, 12 Apr 2021 12:51:02 +0000 Original-Received: (at 47712) by debbugs.gnu.org; 12 Apr 2021 12:50:36 +0000 Original-Received: from localhost ([127.0.0.1]:56804 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVw1T-0006ET-Qc for submit@debbugs.gnu.org; Mon, 12 Apr 2021 08:50:36 -0400 Original-Received: from server.qxqx.de ([178.63.65.180]:47231 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVw1R-0006ED-LW for 47712@debbugs.gnu.org; Mon, 12 Apr 2021 08:50:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=p5PDg2yPlO4WqJMmcVNI16Oyp8YIylC/DDcP3ckC5iM=; b=kNOMnra7a7TvtOdYmojJu9hoXL NCUJFoK73PaWBH2Rx1qqHiOBKeRSzfDrfzU/8Xbr8fa7zYTnhyvBf3sUAPL3ww6HCeqcg+qxYZWAx A0HJ7+Z0XnDaHy8bxrGBU0yiRHsMsjvNkVdDteZTBcKwLbXvAa29hwo8fPdTwvNCwrjc=; In-Reply-To: <83lf9n3d7x.fsf@gnu.org> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:203895 Archived-At: On 4/12/21 2:21 PM, Eli Zaretskii wrote: > That is easy to work around, right? Just insert the string into a > temporary buffer and say with-current-buffer (and/or > with-selected-window, if needed). I have not tested this but I suspect this to be slow for a few thousand strings. >> The function `string-width` instead takes a string argument >> returning the number of columns needed to display this string. This >> function is needed to compute widths of strings which are not yet >> displayed. > > But you compute the width because you are going to display that string > soon enough, right? Or did I misunderstand the purpose? I am using it to generate candidate strings for `completing-read` and Org is using it to format tables. So no, I don't think that's soon enough. > In general, calculating a string's width out of display context is > meaningless in Emacs. More about that below. I know about the context dependence. But there is the `string-width` function which is also computed in the current context. I am only asking for an improved version of already existing functionality. My most minimal feature request is just a function `substring-width`. > That's exactly my point: by not using the display code, you allow up > front inaccurate results. There's no practical way to implement this > in Lisp without yielding inaccurate and even grossly incorrect results > in some cases (see below), so any such implementation will be limited > from the get-go, in ways that are hard to even document precisely, let > alone use reliably. Thus, users of such an implementation are bound > to be unpleasantly surprised if they try using it in a situation > different from yours. I agree that it would not work in all case. But why does `string-width` exist then? Is it deprecated? >> Instead it computes the `string-width` of a flattened string, where >> the invisible parts have been removed and the displayed parts have >> been replaced. > > Yes, I understood what the code does. But it only handles some of the > possible use cases, and will fail in others. For example, it ignores > faces (which could change the metrics of characters); it assumes that > all the characters of the string can be displayed by the buffer's > fonts (because "tofu" has very different dimensions); it uses > char-width to measure a character's width (which is only accurate for > text-mode frames); it doesn't handle display properties that aren't > strings, such as (space :align-to N); etc. That's right. In particular not supporting the :space alignment property is a serious limitation. But in text-mode frames the computation will return a correct result if it considers 'invisible and 'display recursively. > So I urge you to try to use window-text-pixel-size for org-table and > elsewhere, because that's what that function is for. If it lacks some > feature or has bugs, we will improve it. It is fair to reject the feature request for a `string-display/property-width` function, because it would be hard to implement a generally useful function. However if you attack `string-width` for not computing something correct, then one may want to consider deprecating `string-width` altogether or at least make it clear in the documentation that this function should not be used and something else based on the window function should be used instead. Note that `gnus-correct-length` has been replaced by `string-width`, so maybe Lars can say something about the justification for `string-width`?