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: Fri, 28 Jul 2023 14:52:17 +0300 Message-ID: <83jzukjlse.fsf@gnu.org> References: <87fs5l3b3g.fsf@localhost> <87a5vt2vx8.fsf@localhost> <831qh56vvz.fsf@gnu.org> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34166"; 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 Fri Jul 28 14:15:12 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 1qPMND-0008cQ-N4 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 28 Jul 2023 14:15:11 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qPM0p-0001h8-Nd; Fri, 28 Jul 2023 07:52:03 -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 1qPM0o-0001gw-QA for bug-gnu-emacs@gnu.org; Fri, 28 Jul 2023 07:52: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 1qPM0o-0004uB-IW for bug-gnu-emacs@gnu.org; Fri, 28 Jul 2023 07:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qPM0o-0003om-F0 for bug-gnu-emacs@gnu.org; Fri, 28 Jul 2023 07:52:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 28 Jul 2023 11:52: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.169054510514654 (code B ref 64696); Fri, 28 Jul 2023 11:52:02 +0000 Original-Received: (at 64696) by debbugs.gnu.org; 28 Jul 2023 11:51:45 +0000 Original-Received: from localhost ([127.0.0.1]:43918 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qPM0X-0003oI-0z for submit@debbugs.gnu.org; Fri, 28 Jul 2023 07:51:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55574) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qPM0U-0003o4-HQ for 64696@debbugs.gnu.org; Fri, 28 Jul 2023 07:51:43 -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 1qPM0O-0004o8-8o; Fri, 28 Jul 2023 07:51:36 -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=8NsXPv6jl+mw4D1bNPFbicfm3SmA+IqcezoGqEaOLAg=; b=C6cDnXAxmXsm hpwq5WnNIfcalx3PMEww7tuDkTvYB9UBhlNP067YX+EkI763F0QoZkXEit64YLNKmrvWerRqc5Z2P xxSPBTn2NkdZ4o4u2ZgoyMKVdW4jNhc0bhOpJX8CDQqQ4WWe8S0yXCNHMo5l7TYuJK4/9vaMYoQiu AC0hBTG5mHG24zRL8UCwp6xxfWoBeOlGJJN8VBfPlsFrqfU1gATaYskfsQtIKi3LFeWLvb4i7Nk11 V49Qa070xT6HHJnIoK4cqtDDx+0XO3vbA6uP5VIgTfmZhVHbSOL15Vd437RywsFjjb+5hRzF5SqNq uU7D72Fcmel/COiAOlkgAA==; 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 1qPM0C-0002Dx-PD; Fri, 28 Jul 2023 07:51:35 -0400 In-Reply-To: <877cqkfoip.fsf@localhost> (message from Ihor Radchenko on Fri, 28 Jul 2023 08:06:54 +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:266263 Archived-At: > From: Ihor Radchenko > Cc: monnier@iro.umontreal.ca, 64696@debbugs.gnu.org > Date: Fri, 28 Jul 2023 08:06:54 +0000 > > Eli Zaretskii writes: > > >> Using :align-to space spec and font-lock-keywords. > >> This can work, although it is unfortunate that there is no "stretch" > >> space that will automatically occupy as much space as possible without > >> pushing the line across right fringe. > > > > 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? > 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. Why does Org need to take up all the available space of a window to begin with, btw? > 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.) > >> I think that the main source of the confusion is the first line "Return > >> width of STRING when displayed in the current buffer", which sounds like > >> certain buffer-specific display things are affecting the result. > > > > Feel free to suggest a single short enough sentence which doesn't have > > this issue, and yet does explain that the value is not just the count > > of characters in 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. > However, if I look into the code, it looks like buffer-display-table is > also taking into account. Yes. Also character compositions. > And string_char_and_length, which I do not fully understand. That's unrelated. string_char_and_length is just a convenient way of walking multibyte text one character at a time. It returns the codepoint of the current character, and also returns the length of its multibyte sequence, so it is easy to get to the next character in one jump. (Keep in mind that the basic movement across buffer text is always by bytes, and a character can be represented by 1 to 5 bytes.) > 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. 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.