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#52676: 28.0.50; [PATCH] Rationalize window-text-pixel-size Date: Mon, 20 Dec 2021 17:19:43 +0200 Message-ID: <83zgov1ey8.fsf@gnu.org> References: <87wnk0xaz4.fsf@dick> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5052"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 52676@debbugs.gnu.org To: dick Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Dec 20 17:59:18 2021 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 1mzM0M-00017o-2Y for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 20 Dec 2021 17:59:18 +0100 Original-Received: from localhost ([::1]:59338 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mzM0L-0001zW-0D for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 20 Dec 2021 11:59:17 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:41676) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mzKTa-0002hM-NP for bug-gnu-emacs@gnu.org; Mon, 20 Dec 2021 10:21:29 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39577) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mzKTF-0007ly-Qf for bug-gnu-emacs@gnu.org; Mon, 20 Dec 2021 10:21:06 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mzKTF-0003BA-MH for bug-gnu-emacs@gnu.org; Mon, 20 Dec 2021 10:21:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Dec 2021 15:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52676 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 52676-submit@debbugs.gnu.org id=B52676.164001360312090 (code B ref 52676); Mon, 20 Dec 2021 15:21:01 +0000 Original-Received: (at 52676) by debbugs.gnu.org; 20 Dec 2021 15:20:03 +0000 Original-Received: from localhost ([127.0.0.1]:51116 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzKSI-00038p-Ep for submit@debbugs.gnu.org; Mon, 20 Dec 2021 10:20:03 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:38850) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzKSH-00038I-94 for 52676@debbugs.gnu.org; Mon, 20 Dec 2021 10:20:01 -0500 Original-Received: from fencepost.gnu.org ([209.51.188.10]:53308) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mzKS1-00079v-5w; Mon, 20 Dec 2021 10:19:51 -0500 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=Gm7YriUUqlIwVpNQkqIfC2bccc4f0K+4QORg3qNiMAw=; b=S9QvcGbAmMyG rG1gkdMmzl4LSDpjosQqXwWAM9D8UnVa7vCdq58z+IKSIrSMBpJCmhanYmQGp0FA8lWp9vEAbU6CJ gKqjIBLsOW6YZwMg7ttFSeacaZVycpPk9F8xEMuPlFK/xCpFqHS6SSWaSUT9g1mHXtr0C9HeQ0f3X HBlUcRhaQp+ueiowWkcoUFBr1FP8SNfWPqJwdBXuw6vOvozM38WUyjHGAgAd3gPOmSPzqCsx5oicJ PNWQ5wjmhbgdD30hNO3jeJL1+cGHLBJu/5n2qr9vMLs59sccXeyv/Uee4qejSuXVRTXgreq/dUbvO c7KXyDpQuKjm4JvPCH9n+w==; Original-Received: from [87.69.77.57] (port=2852 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 1mzKS0-0002OS-Ki; Mon, 20 Dec 2021 10:19:45 -0500 In-Reply-To: <87wnk0xaz4.fsf@dick> (message from dick on Sun, 19 Dec 2021 21:32:15 -0500) 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" Xref: news.gmane.io gmane.emacs.bugs:222783 Archived-At: > From: dick > Date: Sun, 19 Dec 2021 21:32:15 -0500 > > Even if 43c4cc2 did anything (it doesn't), it was obviously > the wrong way to go about it. It's WIP. It's too early IMNSHO to judge it, because alone it does very little. > start_display (&it, w, startp); > - int start_y = it.current_y; > - /* It makes no sense to measure dimensions of region of text that > - crosses the point where bidi reordering changes scan direction. > - By using unidirectional movement here we at least support the use > - case of measuring regions of text that have a uniformly R2L > - directionality, and regions that begin and end in text of the > - same directionality. */ > - it.bidi_p = false; Why was this removed? what's the rationale? Did you understand the underlying problem about which the comment hints? > - /* If FROM is on a newline, pretend that we start at the beginning > - of the next line, because the newline takes no place on display. */ > - if (FETCH_BYTE (start) == '\n') > - it.current_x = 0; And why was this removed? > - if (!NILP (x_limit)) > - { > - it.last_visible_x = max_x; > - /* Actually, we never want move_it_to stop at to_x. But to make > - sure that move_it_in_display_line_to always moves far enough, > - we set to_x to INT_MAX and specify MOVE_TO_X. */ > - move_op |= MOVE_TO_X; > - to_x = INT_MAX; > - } And this? > - /* We could have a display property at END, in which case asking > - move_it_to to stop at END will overshoot and stop at position > - after END. So we try again, stopping before END, and account for > - the width of the last buffer position manually. */ > - if (IT_CHARPOS (it) > end) > - { > - end--; > - RESTORE_IT (&it, &it2, it2data); > - x = move_it_to (&it, end, to_x, max_y, -1, move_op); > - /* Add the width of the thing at TO, but only if we didn't > - overshoot it; if we did, it is already accounted for. Also, > - account for the height of the thing at TO. */ And this? So basically, you removed code which was there to handle real problems, with no explanations and with log messages whose content includes no useful information. The Git history should have pointed you to the bug reports and discussions which caused us to add those code fragments you removed, with recipes to create those problematic situation; did you try those recipes? did you find them not reproducible, or thought that the fixes are no longer needed, or have better ideas for how to fix them? If so, how about including all that information in your patch submissions? Without all this information, how can you expect us to use your patches? All I see is that you delete code that is there for a reason.