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: Sun, 30 Jul 2023 12:59:31 +0300 Message-ID: <83leexlny4.fsf@gnu.org> 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> <87tttlj0r6.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="412"; 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 Sun Jul 30 12:24:33 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 1qQ3bF-000AVn-DQ for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 30 Jul 2023 12:24:33 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qQ3DZ-0000Vz-11; Sun, 30 Jul 2023 06:00: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 1qQ3DX-0000Vo-II for bug-gnu-emacs@gnu.org; Sun, 30 Jul 2023 06:00: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 1qQ3DX-0001ev-9N for bug-gnu-emacs@gnu.org; Sun, 30 Jul 2023 06:00:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qQ3DW-0004c8-JS for bug-gnu-emacs@gnu.org; Sun, 30 Jul 2023 06:00: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: Sun, 30 Jul 2023 10:00: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.169071118117686 (code B ref 64696); Sun, 30 Jul 2023 10:00:02 +0000 Original-Received: (at 64696) by debbugs.gnu.org; 30 Jul 2023 09:59:41 +0000 Original-Received: from localhost ([127.0.0.1]:49407 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qQ3DB-0004bB-3Z for submit@debbugs.gnu.org; Sun, 30 Jul 2023 05:59:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52554) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qQ3D8-0004ax-Iv for 64696@debbugs.gnu.org; Sun, 30 Jul 2023 05:59:39 -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 1qQ3D3-0001Yv-2F; Sun, 30 Jul 2023 05:59:33 -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=iIEQ8LzhtD+M6VwZrsqnWNFuIav/y1WHue5fnIjIh/g=; b=EMrAF7FHiuYx Z0YaPdmfFr/M20sF7mVD8e7SHHa7ZAAoBDokjaE0Lf2tbftiHsQBQGktc8B1J6uHoe5fmuMj9dLfL dIDqQbbLQMVMr0cjHk9hdmTvctVr+fV+Ii+TkbnHxW0+tylotqKYz6zzRMigGYWnO+/7ZlxZRD18i XvQvz0iFspESzg0H2O/DJEiw/EFQR/K75hMmFWSw51/enY5sk+EADxmrYPdExzbAbxEfJ81uUlwLo F3GFqDEVYj3zLrXw6C0PVdJ8xRxto9hfVUrJeWFiJyZxhaUkvY9jQruIsGrM2WvhXVOd1KaPzzBQB R2SwFHTkp3iMoIGJkEUE5Q==; 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 1qQ3D2-0005e3-Hv; Sun, 30 Jul 2023 05:59:32 -0400 In-Reply-To: <87tttlj0r6.fsf@localhost> (message from Ihor Radchenko on Sun, 30 Jul 2023 07:51:09 +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:266363 Archived-At: > From: Ihor Radchenko > Cc: monnier@iro.umontreal.ca, 64696@debbugs.gnu.org > Date: Sun, 30 Jul 2023 07:51:09 +0000 > > 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. First, these are for TTY frames only (that's the meaning of "frame-based redisplay" in Emacs display parlance). And more importantly, these fill _the_rest_ of a screen line with space glyphs. We already know how to do that, on both TTY and GUI frames, see extend_face_to_end_of_line, where it calls append_stretch_glyph. The problem is that when these functions are called, we need to be able to calculate the width of the stretch glyph to produce. That is possible if the stretch is the last element of a screen line and ends at the right edge of the window's text area, but not possible if some text is yet to follow, because the width of the following text on display is not yet known -- it was not calculated. The basic design of the Emacs display engine is that layout calculations proceed in strict left-to-right visual order, one buffer or string position at a time, and each position is completely processed before we proceed to the next. What you are asking for will violate this basic design, so it is something I very much would like to avoid, because it will definitely cause complications and bugs. > And what I propose would enlarge some existing space glyphs instead. What do you mean by "enlarge existing space glyphs"? In the functions to which you pointed, each space glyph is just the SPC character (which is eventually sent to the text-mode terminal); those cannot be enlarged, because this is a text-mode terminal. > >> > 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? > > That's what we do (org-tags-column). However, people often ask for > auto-adjustment to right margin when frame/window is resized. And you must honor each and every request? Why? There's nothing wrong with telling users "this is too complicated to implement, sorry". > 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: When a window is split, the alignment could be re-done, no? > 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. "Deceiving" is a harsh word, please reconsider. There's a limit to which a doc string can describe every single subtlety of a non-trivial implementation, and still remain useful. If someone needs to know about these aspects (presumably because their Lisp program does something very special, because otherwise these things "just work"), they should either read the source or ask here, because they basically use string-width outside of its main usage domain. > > 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. I don't see how this follows. And I thought I already explained why "visuals" is not well defined in general: each application needs to disable some parts of it, but never all of them, and which parts depends on the application. Why do we have to reiterate this over and over again? > `org-current-text-column' is clearly not 100% reliable when using > `string-width'. Then don't use string-width. I don't know what you should use instead, because I don't understand well enough what org-current-text-column wants to do and for what purpose. It could be that the functionality you want doesn't exist, or maybe it can be had by some tweaking of the existing APIs, I don't know. But if that is the issue here, we should restart the discussion from a very different point: by your describing what you need to do win org-current-text-column and why. What current-column and indent-to do or don't do is almost irrelevant, it seems. > 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. There are no inconsistencies, not from where I stand. Each API was written for a specific purpose and does a specific job; if your purpose is very different, you need to describe it first, and do that with all the details. Then we can see if we already support your purpose or need new APIs.