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: Sun, 30 Jul 2023 07:51:09 +0000 Message-ID: <87tttlj0r6.fsf@localhost> References: <87fs5l3b3g.fsf@localhost> <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> <83cz0bm2hn.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19689"; 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 Sun Jul 30 10:10:08 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 1qQ1V9-0004w2-QE for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 30 Jul 2023 10:10:07 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qQ1Df-0005F3-N7; Sun, 30 Jul 2023 03: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 1qQ1De-0005Ev-Uo for bug-gnu-emacs@gnu.org; Sun, 30 Jul 2023 03: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 1qQ1De-00017U-MO for bug-gnu-emacs@gnu.org; Sun, 30 Jul 2023 03:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qQ1De-0001Tu-IJ for bug-gnu-emacs@gnu.org; Sun, 30 Jul 2023 03:52: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: Sun, 30 Jul 2023 07: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.16907034645626 (code B ref 64696); Sun, 30 Jul 2023 07:52:02 +0000 Original-Received: (at 64696) by debbugs.gnu.org; 30 Jul 2023 07:51:04 +0000 Original-Received: from localhost ([127.0.0.1]:49287 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qQ1Ch-0001Sg-GF for submit@debbugs.gnu.org; Sun, 30 Jul 2023 03:51:03 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:54507) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qQ1Cf-0001SB-6j for 64696@debbugs.gnu.org; Sun, 30 Jul 2023 03:51:02 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 5CE3D240103 for <64696@debbugs.gnu.org>; Sun, 30 Jul 2023 09:50:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1690703455; bh=Q7/G84JmIUca5+xbbOdC4CnxXxSDsRKgU0fKoe1Ze3Y=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:From; b=UoP7Nok3v/kyPPx0gj5OnG+SfbgpKnThI6nFfX7YjQzhLKslIdkupPBq/JBNXAkC/ LEYSPJf52GLiWv41HOO4VPaQ0MuvvHIkOxSiEeH5TCm9pdMPcWIo2+33ctpOOE3vnL x/ZYI5fv31YkqP+fl0I1KZivY7zhBVvFebW4nygUi94nC7V+hs7001I+qymu71XoXS mTie35zRHMbs5JZ3xsreBhm4Ic/2bI7dF++1f6l9GJTAjyi0+X0ILVgxbebBLeOmH7 udlYlxTztTfrt63A4AIzJhaGuh7QdFiVzJMBPqILpzOIJpIN+0/cONV49LIGEKLSdq fXb6bU5oHuybg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RDD7y1w0Yz6v3H; Sun, 30 Jul 2023 09:50:54 +0200 (CEST) In-Reply-To: <83cz0bm2hn.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:266356 Archived-At: Eli Zaretskii writes: >> 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. What about fill_up_glyph_row_area_with_spaces and fill_up_frame_row_with_spaces? They append extra space glyphs to build up to window/frame width. And what I propose would enlarge some existing space glyphs instead. >> > Why does Org need to take up all the available space of a window to >> > begin with, btw? >>=20 >> To produce right-aligned text columns: >>=20 >> * 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? That's what we do (org-tags-column). However, people often ask for auto-adjustment to right margin when frame/window is resized. The usual use-case for auto-adjustment is when Org/agenda window is first built as a sole window in the frame and then user splits the frame into two windows vertically: * Heading :tag1:tag2:tag3: * Another heading :tag4: * Heading =E2=86=92| Other text file here. * Another heading =E2=86=92| Tags on the left are not vis= ible. or * Heading =E2=A4=B6| Other text file here. :tag1:tag2:tag3: | Tags wrapped and look ugly. * Another heading =E2=A4=B6| :tag4: | > If that is the problem, you should use buffer-text-pixel-size or > window-text-pixel-size instead. Good point. Thanks! >> 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. >>=20 >> 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? I was referring to one step earlier in the discussion: >> A toggle: disable all visual contributors. > It will never be used. I would use it in Org instead of `org-current-text-column'. It currently relies upon `string-width' ignoring visuals, which may or may not hold in future (the docstring implies that `string-width' may as well consider visuals: "Return width of STRING when displayed in the current buffer.") You pointed that my docstring reference did not include the whole docstring and that the docstring, in fact, does say that visuals have "limited" effect. So, I proceeded with docstring suggestion to highlight that window settings have no effect. My suggestion turned out to be wrong: (1) variable pitch faces can affect the results for glyphs; (2) buffer-display-table can alter the results. And note that the full docstring of `string-width' does not mention the above 2 factors. It just mentions a small subset of visual settings that _do not_ affect the results. Which is deceiving. > 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? So, we coming back to the original discussion about a toggle to disable "visuals", there seems to be a need in it, at the end. `org-current-text-column' is clearly not 100% reliable when using `string-width'. > I don't understand why "ignore". But TBH, I don't think I understand > what are you trying to accomplish with this long discussion. We have discussed multiple topics in this thread. From my point point of view, things are mostly revolving around understanding how invisible/display/other visual settings are affecting `indent-to', and `current-column'. Because on Org mode side, we sometimes want and sometimes don't want to account for visuals. On Emacs side, I can see that full, partial, or limited subset of visual settings is accounted for in various functions, like `indent-to', `current-column', and `string-width'. Not everything is clearly documented for `string-width' and accounting for invisible text properties is not fully consistent in `indent-to'. >> 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. I'd prefer to use the existing API if possible. But to do it, I first want to understand its logic. Inconsistencies in this logic is what this report is about. --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at