From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.bugs Subject: bug#64696: 30.0.50; indent-to inherits preceding text properties, including 'invisible Date: Sat, 29 Jul 2023 09:00:22 +0000 Message-ID: <87wmyjxfbt.fsf@localhost> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6565"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, 64696@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 29 11:03:06 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 1qPfqs-0001TP-5j for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 Jul 2023 11:03:06 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qPfov-0008Cg-Iv; Sat, 29 Jul 2023 05:01:05 -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 1qPfos-0008BS-WC for bug-gnu-emacs@gnu.org; Sat, 29 Jul 2023 05:01:03 -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 1qPfos-0001nN-Ox for bug-gnu-emacs@gnu.org; Sat, 29 Jul 2023 05:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qPfos-0003Y2-36 for bug-gnu-emacs@gnu.org; Sat, 29 Jul 2023 05:01:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 Jul 2023 09:01:02 +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.169062121713582 (code B ref 64696); Sat, 29 Jul 2023 09:01:02 +0000 Original-Received: (at 64696) by debbugs.gnu.org; 29 Jul 2023 09:00:17 +0000 Original-Received: from localhost ([127.0.0.1]:46427 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qPfo8-0003X0-UU for submit@debbugs.gnu.org; Sat, 29 Jul 2023 05:00:17 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]:49375) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qPfo7-0003Wk-4a for 64696@debbugs.gnu.org; Sat, 29 Jul 2023 05:00:15 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id B2204240027 for <64696@debbugs.gnu.org>; Sat, 29 Jul 2023 11:00:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1690621208; bh=UNFTSw3t3ZDykxnnZNwadDoEFYkAyjTDjzGKtaN8dJo=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=JN0dxk6mL0JHmMEWmRsKwgBU9Itb6oDS2xnmU8sPUFgANmpr5hEJSxxllvmJeuzB8 SVxDyJmd8BoHTmq2dwQC6HchMjjzhUespcISJerJNv5RPfYVDf68t28FOSdAis0G2s 6oyo5p/rznl+iw/50qmzmWUYuxLgvqAXS1NwZt1vFFAsKVhU+D7wUza4gcoyYfHkKF zNSA+1Q9Iy8l/P92ozFsoQ6EzlnTORtKSDsJUlj8COkLw/uQEnwug1ceKTbop1IRBb EQlEKjVe12eXB4HepLiz4O1ivRZ0gKKX5N0UgJ9Gl5XnKjalDSUaYZPdZGZkDPIKpv Wtttx/m68vnrg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RCdkH40Zrz6v0D; Sat, 29 Jul 2023 11:00:07 +0200 (CEST) In-Reply-To: <83jzukjlse.fsf@gnu.org> 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:266317 Archived-At: Eli Zaretskii writes: >> > Of course, there is: use the 'right' position with a negative offset. >> >> This indeed works, but the annoying part is calculating the offset. > > What offset? You said "occupy as much space as possible", which means > the offset from the right edge is zero, right? I meant: ^some textsome more text$ With adjusting its width in such a way that the whole line occupies exactly buffer width. Now, I have to use ^some text<:align-to `(- right-fringe ,(string-pixel-width "some more text"))>some more text$ >> 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. May you point me to the place in code where the line scan is performed? > 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: >> 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. 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. >> 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. >> 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. > 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. Org syntax must not depend on Emacs visual settings. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at