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.bugs Subject: bug#64696: 30.0.50; indent-to inherits preceding text properties, including 'invisible Date: Sat, 29 Jul 2023 13:33:08 +0300 Message-ID: <83cz0bm2hn.fsf@gnu.org> References: <87fs5l3b3g.fsf@localhost> <871qh52nlw.fsf@localhost> <83pm4p5er8.fsf@gnu.org> <874jm0mhgb.fsf@localhost> <831qh459sy.fsf@gnu.org> <87jzuvq785.fsf@localhost> <835y6ca1ah.fsf@gnu.org> <87zg3o8m2a.fsf@localhost> <83wmys8a2g.fsf@gnu.org> <87v8ecrqib.fsf@localhost> <83bkg481g5.fsf@gnu.org> <87bkg3rso5.fsf@localhost> <83wmyrt02d.fsf@gnu.org> <87edkx3eoh.fsf@localhost> <83bkg1sbg7.fsf@gnu.org> <87zg3kqtbl.fsf@localhost> <83zg3kp3of.fsf@gnu.org> <87fs597msx.fsf@localhost> <83a5vhn2ak.fsf@gnu.org> <877cqkfoip.fsf@localhost> <83jzukjlse.fsf@gnu.org> <87wmyjxfbt.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36094"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, 64696@debbugs.gnu.org To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 29 13:16:30 2023 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 1qPhvx-0009DW-Sy for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 Jul 2023 13:16:30 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qPhGu-0005co-N7; Sat, 29 Jul 2023 06:34:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qPhGs-0005cg-NV for bug-gnu-emacs@gnu.org; Sat, 29 Jul 2023 06:34:02 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qPhGs-0008GD-Fs for bug-gnu-emacs@gnu.org; Sat, 29 Jul 2023 06:34:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qPhGr-00066x-Tf for bug-gnu-emacs@gnu.org; Sat, 29 Jul 2023 06:34:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 Jul 2023 10:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64696 X-GNU-PR-Package: emacs Original-Received: via spool by 64696-submit@debbugs.gnu.org id=B64696.169062680223444 (code B ref 64696); Sat, 29 Jul 2023 10:34:01 +0000 Original-Received: (at 64696) by debbugs.gnu.org; 29 Jul 2023 10:33:22 +0000 Original-Received: from localhost ([127.0.0.1]:46470 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qPhGE-000661-0V for submit@debbugs.gnu.org; Sat, 29 Jul 2023 06:33:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52910) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qPhGB-00065m-8t for 64696@debbugs.gnu.org; Sat, 29 Jul 2023 06:33:20 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qPhG5-00088a-8y; Sat, 29 Jul 2023 06:33:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=FDbVNf/xQi/IKsodpaiVfPkGvIGWpawgcgch1scThAs=; b=apJlRLQeKJBj v85N1cjYjGTYyCPJ8wAiMHXl26PO3ZvtRLpN1/WuEEm4bdtcN4q3CqattInuEHFmO5K1UGcVWNueY 4As4vgnKSlMAyLHX83YDbd62nnInZx2fiz/dldlIZ25qQK4Ee2BWYRpx7iCKEEWdeMLj/hWCvuGUN /6sskfTip9Nvt90jO5j74XwGaIJthKhMhOMVd1iMtj4zmbFXMCaYwYZ3eyuuqWFYq0IbUMzmUkXxJ DnckVClilQ+er0RGQ/f5f8ALgEZFnso9y4HhO/tfGahmsUee2GHYDFg22Cy4D3Gl4hYW8XhCYZx6G JYszSwvkxZzX3eANRpYKDQ==; Original-Received: from [87.69.77.57] (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 1qPhG4-0000mO-P4; Sat, 29 Jul 2023 06:33:13 -0400 In-Reply-To: <87wmyjxfbt.fsf@localhost> (message from Ihor Radchenko on Sat, 29 Jul 2023 09:00:22 +0000) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:266326 Archived-At: > From: Ihor Radchenko > Cc: monnier@iro.umontreal.ca, 64696@debbugs.gnu.org > Date: Sat, 29 Jul 2023 09:00:22 +0000 > > Eli Zaretskii writes: > > >> The most robust way would be delegating offset calculation to the > >> redisplay of the actual line being displayed. > > > > That would require that the display engine scans the screen line > > twice. That's unacceptable, both for performance reasons and because > > it violates the basic design of how the Emacs display iteration works. > > Sorry, that won't fly. > > I do not think that double scan will be needed. Just space width > calculation is to be postponed until the line is processed. That's what I meant by "double scan". The Emacs display engine never looks back, once it processed some text property. Looking back is particularly unacceptable when the display engine is called to start in the middle of the line, because it would mean we need always go to the beginning of the line. > May you point me to the place in code where the line scan is performed? There are two places: display_line and move_it_in_display_line_to. > > Why does Org need to take up all the available space of a window to > > begin with, btw? > > To produce right-aligned text columns: > > * Heading :tag1:tag2:tag3: > * Another heading :tag4: I guessed that much, but my point is: why not set some reasonable fixed right position, and align to that? > >> One needs to use `string-pixel-width', which is not always reliable. > > > > string-pixel-width uses the display code, so if it is unreliable, so > > will be any other implementation in the display engine (barring any > > bugs). (Of course, you didn't reveal any details of this lack of > > reliability, so I don't really know what are we talking about here.) > > Because `string-pixel-width' does not account for display and > fontification settings in current-buffer. For example, buffer-local > invisibility specs will be ignored; display tables will be ignored; face > remapping will be ignored. If that is the problem, you should use buffer-text-pixel-size or window-text-pixel-size instead. > There is also a number of edge cases when `string-pixel-width' will > straight return wrong width. For example, when string has > line-prefix/wrap-prefix text property, its width will depend on whether > string is displayed at bol or not. `string-pixel-width' will always make > it as if string is displayed at bol, thus adding line-prefix width to > the string. Does window-text-pixel-size work better in those cases? > >> Return width of STRING when displayed using fixed width font. > > > > That loses information (the "current buffer" part: it's important). > > > Can you explain why "fixed width font" is important enough for you to > > want to see it there? After all, the function counts columns, so > > whether the font is fixed-pitch or variable-pitch shouldn't matter. > > My original concern was about `string-width' not producing reliable > results when Emacs visual settings are changed. And, indeed, some > visuals that are not detailed in the docstring are taken into account. > > The purpose of using `string-width' in `org-current-text-column' is to > produce reliable result for different users with different visual > settings and fonts. This is because indentation is used in Org syntax > and must not be broken if the Org file is unchanged and visual settings > are. How does your proposal for the change in the doc string serve these issues? I asked a specific question about your proposed change, and I don't think what you say above answers that specific question? > >> And glyphs appear to honor variable pitch font, if it is default. > > > > No, they don't. When the function finds characters that will be > > composed on display, it computes the pixel-width of the result of the > > composition, and then converts that into the units of the frame's > > default face's font. For that conversion, and for that conversion > > only, the function needs the parameter of the default face's font that > > tells us the width of its characters; if that font is variable-pitch > > (unlikely), then these parameters give only some kind of average > > width. > > I am concerned exactly about this unlikely scenario. > I have seen variable pitch creating one-off errors for width in the > past. If variable-pitch fonts are used for the _default_ face's font, then using string-width as the measure of width on display is clearly inadequate to begin with, isn't it? The function tries to do its best, but why do you expect it to do miracles? Using variable-pitch fonts for the default face in Emacs is asking for trouble, even if Org is not used at all. We currently don't support that well. > > But again, all this access to the font parameters is only done for > > composed characters, because character composition rules can produce > > glyphs that have no corresponding codepoints, and therefore we cannot > > look them up in char-width-table. > > So, it is something Org needs to ignore somehow. I don't understand why "ignore". But TBH, I don't think I understand what are you trying to accomplish with this long discussion. > Org syntax must not depend on Emacs visual settings. If that is what you are trying to do, I think you will have quite a few difficulties. Emacs does not cater to such applications, especially when you are using APIs whose purpose was to support display and layout calculations.