Received: (at 80025) by debbugs.gnu.org; 5 Jan 2026 08:00:50 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 05 03:00:50 2026 Received: from localhost ([127.0.0.1]:49528 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vcfWE-0005jO-07 for submit <at> debbugs.gnu.org; Mon, 05 Jan 2026 03:00:50 -0500 Received: from mout-p-102.mailbox.org ([80.241.56.152]:47710) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1vcfWB-0005OL-Oz for 80025 <at> debbugs.gnu.org; Mon, 05 Jan 2026 03:00:48 -0500 Received: from smtp1.mailbox.org (smtp1.mailbox.org [10.196.197.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4dl6DP6hJYz9tpP; Mon, 5 Jan 2026 09:00:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkov.net; s=MBO0001; t=1767600038; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+aRX1gHxv3cAUV4vZKtroeCoS+rSXk8vMVw9w9A9g7I=; b=uaOiYuZg7yKnmVWQ8ekOGJIWbmSgRQaqDiBL1hyvVEcNdYBOMmDqsZXaSSMC2+Pxl0H+XL E0J2YvxYQHzRisxPkmzxdM7YDpFVBw5kZjZCH5VhnnahBaDmGxIqxjhDL5dZpH4GEmuBdL wFKW6+vKfYUtZWLYDbiIAXDhLnT16TynJowKv1gtsrUMtkN0oe3/limriaR9SA6PXEmovx QVDKiAsHqYsYqN6CSX/hKylIqSHGZC3nwgjEPfGlbINavCPOdChqWbHuSJ8pEOI0LuACvw gtkxiY/LU/BPJCYEFP3DXs0urkenrJbfKfKgtoUdNk50LO7vjOLK3bLz7e9bXw== From: Juri Linkov <juri@HIDDEN> To: Gerd =?iso-8859-1?Q?M=F6llmann?= <gerd.moellmann@HIDDEN> Subject: Re: bug#80025: Margin columns In-Reply-To: <m2tsx16uez.fsf@HIDDEN> Organization: LINKOV.NET References: <87h5tpj7ch.fsf_-_@HIDDEN> <861pkt3q8e.fsf@HIDDEN> <87cy48nv4o.fsf@HIDDEN> <86ldiwxm9m.fsf@HIDDEN> <87qzsn9dgm.fsf@HIDDEN> <87y0mlkx31.fsf@HIDDEN> <86qzsdqhyi.fsf@HIDDEN> <m2344ssf8p.fsf@HIDDEN> <87y0mkju8d.fsf@HIDDEN> <m2v7hoqtcr.fsf@HIDDEN> <87ecob4zbz.fsf@HIDDEN> <m2qzsbrcug.fsf@HIDDEN> <m2ikdnqhdn.fsf@HIDDEN> <m2ecobqftp.fsf@HIDDEN> <87y0mjyu0c.fsf@HIDDEN> <m2a4yzqbli.fsf@HIDDEN> <m2ms2y2dz0.fsf@HIDDEN> <87cy3pmeu5.fsf@HIDDEN> <m2tsx16uez.fsf@HIDDEN> Date: Mon, 05 Jan 2026 09:57:46 +0200 Message-ID: <87v7hgjxtx.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 80025 Cc: Eli Zaretskii <eliz@HIDDEN>, 80025 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) > Another idea: Could one give "column" a different meaning, maybe? I wanted to suggest to use the same definition of column as in normal buffers, and to handle columns of wide chars the same way. But when I tried to replace wide chars of different widths using 'subst-char-in-region', it failed with the error: "Characters in ‘subst-char-in-region’ have different byte-lengths" So it seems there is no precedent of using columns of wide chars in non-margin text area?
bug-gnu-emacs@HIDDEN:bug#80025; Package emacs.
Full text available.Received: (at 80025) by debbugs.gnu.org; 5 Jan 2026 04:09:06 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 04 23:09:06 2026 Received: from localhost ([127.0.0.1]:48634 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vcbtx-0005ic-QW for submit <at> debbugs.gnu.org; Sun, 04 Jan 2026 23:09:06 -0500 Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]:57439) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1vcbtv-0005iS-2j for 80025 <at> debbugs.gnu.org; Sun, 04 Jan 2026 23:09:04 -0500 Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-42fb2314eb0so10837615f8f.2 for <80025 <at> debbugs.gnu.org>; Sun, 04 Jan 2026 20:09:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767586141; x=1768190941; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=0qVG1fVPhLrk34XFXTbJ0Gf6/s5TppXHfPPBRHCdB6I=; b=atQDfCx22+hMxBRPYani9jsr2EHxOT04YiU13UGGsrdBs/Wqo2GBJ67xJGlS6earHf ul5abtM7GNqJguz0Z3Cyt/45zaYfaL5XkX/weEhWIYbRdnMlFmrLhd544KPdn47KLVrR BOzZrZm8VIWGnTwMPGE1X6WMuJHZPmrfLrVHRhBRrTE8jrV9HSWYBDNVwt1d3AKF0/Np mABEsP9WpIhIt8BMJelb8FIATDimySnJuydBvt+WM0tU4QQhwJVC4EG5+o0FdTcKRF4T Yv/gUYXWuGqpKQiQiFwx1xYpnkJwn+dRmSyhinOBO8uk5XiFWix1toj90GgzHS7NmOEL UpjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767586141; x=1768190941; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0qVG1fVPhLrk34XFXTbJ0Gf6/s5TppXHfPPBRHCdB6I=; b=Zbi8aNH0W7SSjz0X+HEo/UN80F1GYR1vxdtd73IdaA+Qbr2DeOux8hJrS/fKMZq8GE Vrcfs4n/mnRVqrtED7bZerMT/kKVVVybYax9Oii2nKjwc28neECDrwI1oxfhZcypj8gR DLpc0X3UKb4krYvdotKbD532S/mehCVAj8M7qny0chZ5aSys2GqsN2njrjrcrOUXb5Li jE4YU4q0e5DyXDPMc+KZSXPFizfGcTPyZ2QkN1H132qTRP2OYV9IIU4d/4fTUX5SkI/L asLYybkEfdAmrYSrXqmGqAXkmzIv2qwljAbrDaad4GgPZw7g1X2qVAcIssN9aufBmANL ZSvg== X-Forwarded-Encrypted: i=1; AJvYcCX0zlWrM/0Rboit0ywg+/tKvzMcG62Bxzw5zuUPB1dcYMKTgCdNm/Kv1kRt9E4moQAypv7hbQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyiddR/6o6oRP266tHPyjxKZApuVvybCEshVonPFeDlfGwcCAjc QrrJv8o6hcEjVZK13wZV52yt96WXyE9DKsCO8CMGJN+xlq4UpLZor0/zlNyg5w== X-Gm-Gg: AY/fxX6bPoejfed981TPveXJPTHkH8wm/YSxXd3JScoSLDo/4pwPa6Ir6I0AjASnZnF d8X6DDo9XQZIFaFBFDVbDnvv8dWLCkC2hBVb04WPJZGFuwSiYgDjFTzPfxxmTdcI+vlAEi2+olx e3CCxwI8LJRwdWWzlpiGXRaDMjlxlIqcyqKLbNd8qL9Lk1nsKM3NZro9w+E1oc/WoADrlsPVqXB X+lMe6Pf285sG69u73ISqjCBdhwtP753TX5yyJBDijmd69Zd0bRXWTSh2pCTSkHJ1rJP75UBNJj HwQAp+ismk26Pv+cRhz5IGb9yxL36MRmglFjVkCoAvqe4Y+70P+/RNNxO/PyQJJV1PHnqxu63zs +URDdjHRVLL7sHGSXHR3VqlzRaBA7YRsUY/eixGK/hHgkVNKwOxnhfNA2bI0R3SMK0cRn14aj9x 1TLTCYLYfgpubZqYHnjLuSs2/ABBt05EyU8LlBS4I14sqvm4l45AS0yryDUvMkgj+u394gp+jeT wgqo3QpuBImOVVvh/El4s4= X-Google-Smtp-Source: AGHT+IFaqEy0pnqoEMJEQLMkdqHhSwQtrTzi3r00XwN2u5KJ90H0P/HO73Wmp62pMP272NEl5L+MzQ== X-Received: by 2002:a05:6000:2285:b0:430:f494:6abb with SMTP id ffacd0b85a97d-4324e4c63f9mr52108929f8f.8.1767586141353; Sun, 04 Jan 2026 20:09:01 -0800 (PST) Received: from pro4 (p200300e0b73b740065792d4775ce83d7.dip0.t-ipconnect.de. [2003:e0:b73b:7400:6579:2d47:75ce:83d7]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4324ea1b36fsm97755345f8f.5.2026.01.04.20.08.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 04 Jan 2026 20:08:59 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80025: Margin columns In-Reply-To: <86eco5gmwg.fsf@HIDDEN> References: <87h5tpj7ch.fsf_-_@HIDDEN> <861pkt3q8e.fsf@HIDDEN> <87cy48nv4o.fsf@HIDDEN> <86ldiwxm9m.fsf@HIDDEN> <87qzsn9dgm.fsf@HIDDEN> <87y0mlkx31.fsf@HIDDEN> <86qzsdqhyi.fsf@HIDDEN> <m2344ssf8p.fsf@HIDDEN> <87y0mkju8d.fsf@HIDDEN> <m2v7hoqtcr.fsf@HIDDEN> <87ecob4zbz.fsf@HIDDEN> <m2qzsbrcug.fsf@HIDDEN> <m2ikdnqhdn.fsf@HIDDEN> <m2ecobqftp.fsf@HIDDEN> <87y0mjyu0c.fsf@HIDDEN> <m2a4yzqbli.fsf@HIDDEN> <m2ms2y2dz0.fsf@HIDDEN> <87cy3pmeu5.fsf@HIDDEN> <m2tsx16uez.fsf@HIDDEN> <86eco5gmwg.fsf@HIDDEN> Date: Mon, 05 Jan 2026 05:08:58 +0100 Message-ID: <m2ms2s7lb9.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 80025 Cc: 80025 <at> debbugs.gnu.org, juri@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> >> Cc: Eli Zaretskii <eliz@HIDDEN>, 80025 <at> debbugs.gnu.org >> Date: Sun, 04 Jan 2026 20:37:40 +0100 >>=20 >> Juri Linkov <juri@HIDDEN> writes: >>=20 >> > What significantly complicates the logic are wide chars with padding >> > when a wide char for column < N overlaps with the previous wide char. >> > For example, the first wide char AAA is in the column 3, then comes >> > the second wide char BB in the column 2: >> > >> > 12345 >> > AAA >> > BB >>=20 >> Yes, exactly, that's what I was afraid of. >>=20 >> > We need to clear glyph->padding_p from all subsequent glyphs >> > that remain from the previous wide char AAA. >>=20 >> Just clearing the padding_p flag would not work I'm afraid. >> Consider the case=20 >>=20 >> 1234567890 >> Aaa >> Bb >>=20 >> i.e. we have a glyph row containing char A starting at 3 with 2 padding >> glyphs "aa". Now we want to write character B startign at 2 with 1 >> padding glyph "b". >>=20 >> When we just remove the padding_p flag from the first "a", we get a >> result glyph row of=20 >>=20 >> 1234567890 >> BbAa > > That's not what should be done. What should be done is move all the 3 > glyphs of A two places to the right. And if there's not enough margin > space to do that, then A will need to be completely removed (replaced > by space glyphs). > >> Another idea: Could one give "column" a different meaning, maybe? >>=20 >> At the moment, on ttys, it means an index of a glyph in an glyph_row >> area. What if we made it mean a character index? For example, say A had >> column 3 and B column 2, and in column 1 and 2 where something 1 pixel >> wide. Initially the glyph index for A would be 3 >>=20 >> 1234567890 glyph index >> __Aaa >>=20 >> and when B is inserted at "character column" 2, we make that >>=20 >> 1234567890 glyph index >> __BbAaa >>=20 >> i.e. we shift A to the right and column 3 for A becomes glyph index 5. A >> lot of work of course. One would have to translate a character column to >> a glyph index first, for example, and so on. But it would be equivalent >> to the GUI case which has not padding glyphs so there it's always >> character column =3D=3D glyph index.=20 > > I don't understand why we need this complication. The width of each > character on display is known in advance, both on TTY frames and on > GUI frames. So it is easy to calculate the column for a character. > Moreover, using columns means that glyphs don't shift on display > horizontally when a wide character is replaced by a narrower one. Not sure if I understand what you write correctly. What I tried to describe is exactly that visual aspect of column-alignment. Could you give an example how you'd do it?
bug-gnu-emacs@HIDDEN:bug#80025; Package emacs.
Full text available.Received: (at 80025) by debbugs.gnu.org; 4 Jan 2026 20:10:06 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 04 15:10:06 2026 Received: from localhost ([127.0.0.1]:46840 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vcUQP-0005H3-5P for submit <at> debbugs.gnu.org; Sun, 04 Jan 2026 15:10:05 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:34938) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vcUQL-0005G4-Vd for 80025 <at> debbugs.gnu.org; Sun, 04 Jan 2026 15:10:02 -0500 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 <eliz@HIDDEN>) id 1vcUQF-0000Br-Vy; Sun, 04 Jan 2026 15:09:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=t6j/u5xEfp4RgxwSsdoOx+wA+On5OMrANKrCoEigbDI=; b=pngHidDiFAqiP65bfsIu eirxKpejfhEm1ug10dDVQXwgAGAXY4JGA8X8Lk5b/5J1bsQVApdOSMajfwi1cJKOwNheD28NijhgS ijkqLBExymd4jv47coBvFOxFJGV0UELtvDPOxL6zlJxySBtN5Cp3seR8tY0oWV57gOMAHzfP3EVjS QqLO+avmIn5ORDbzroN8FNsR1AL+jLPVALuiqoyS4IZ6tpYuXx4j1p0bBsf56hQ9a3j138RKTOzNT NR3PQcUIepwxryn4ItUypBLAYOJAXzpdfH0kbPtb3qnMBTjo9WJAcQBdIF4ANYCpipp+uJU4UrOAT vzkS+3WYIcYO9Q==; Date: Sun, 04 Jan 2026 22:09:51 +0200 Message-Id: <86eco5gmwg.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> In-Reply-To: <m2tsx16uez.fsf@HIDDEN> (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Sun, 04 Jan 2026 20:37:40 +0100) Subject: Re: bug#80025: Margin columns References: <87h5tpj7ch.fsf_-_@HIDDEN> <861pkt3q8e.fsf@HIDDEN> <87cy48nv4o.fsf@HIDDEN> <86ldiwxm9m.fsf@HIDDEN> <87qzsn9dgm.fsf@HIDDEN> <87y0mlkx31.fsf@HIDDEN> <86qzsdqhyi.fsf@HIDDEN> <m2344ssf8p.fsf@HIDDEN> <87y0mkju8d.fsf@HIDDEN> <m2v7hoqtcr.fsf@HIDDEN> <87ecob4zbz.fsf@HIDDEN> <m2qzsbrcug.fsf@HIDDEN> <m2ikdnqhdn.fsf@HIDDEN> <m2ecobqftp.fsf@HIDDEN> <87y0mjyu0c.fsf@HIDDEN> <m2a4yzqbli.fsf@HIDDEN> <m2ms2y2dz0.fsf@HIDDEN> <87cy3pmeu5.fsf@HIDDEN> <m2tsx16uez.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80025 Cc: 80025 <at> debbugs.gnu.org, juri@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Gerd Möllmann <gerd.moellmann@HIDDEN> > Cc: Eli Zaretskii <eliz@HIDDEN>, 80025 <at> debbugs.gnu.org > Date: Sun, 04 Jan 2026 20:37:40 +0100 > > Juri Linkov <juri@HIDDEN> writes: > > > What significantly complicates the logic are wide chars with padding > > when a wide char for column < N overlaps with the previous wide char. > > For example, the first wide char AAA is in the column 3, then comes > > the second wide char BB in the column 2: > > > > 12345 > > AAA > > BB > > Yes, exactly, that's what I was afraid of. > > > We need to clear glyph->padding_p from all subsequent glyphs > > that remain from the previous wide char AAA. > > Just clearing the padding_p flag would not work I'm afraid. > Consider the case > > 1234567890 > Aaa > Bb > > i.e. we have a glyph row containing char A starting at 3 with 2 padding > glyphs "aa". Now we want to write character B startign at 2 with 1 > padding glyph "b". > > When we just remove the padding_p flag from the first "a", we get a > result glyph row of > > 1234567890 > BbAa That's not what should be done. What should be done is move all the 3 glyphs of A two places to the right. And if there's not enough margin space to do that, then A will need to be completely removed (replaced by space glyphs). > Another idea: Could one give "column" a different meaning, maybe? > > At the moment, on ttys, it means an index of a glyph in an glyph_row > area. What if we made it mean a character index? For example, say A had > column 3 and B column 2, and in column 1 and 2 where something 1 pixel > wide. Initially the glyph index for A would be 3 > > 1234567890 glyph index > __Aaa > > and when B is inserted at "character column" 2, we make that > > 1234567890 glyph index > __BbAaa > > i.e. we shift A to the right and column 3 for A becomes glyph index 5. A > lot of work of course. One would have to translate a character column to > a glyph index first, for example, and so on. But it would be equivalent > to the GUI case which has not padding glyphs so there it's always > character column == glyph index. I don't understand why we need this complication. The width of each character on display is known in advance, both on TTY frames and on GUI frames. So it is easy to calculate the column for a character. Moreover, using columns means that glyphs don't shift on display horizontally when a wide character is replaced by a narrower one.
bug-gnu-emacs@HIDDEN:bug#80025; Package emacs.
Full text available.Received: (at 80025) by debbugs.gnu.org; 4 Jan 2026 19:37:46 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 04 14:37:46 2026 Received: from localhost ([127.0.0.1]:46711 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vcTv7-00037W-Km for submit <at> debbugs.gnu.org; Sun, 04 Jan 2026 14:37:46 -0500 Received: from mail-ed1-x529.google.com ([2a00:1450:4864:20::529]:53415) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1vcTv5-00037J-Me for 80025 <at> debbugs.gnu.org; Sun, 04 Jan 2026 14:37:44 -0500 Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-64b7318f1b0so15989058a12.2 for <80025 <at> debbugs.gnu.org>; Sun, 04 Jan 2026 11:37:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767555462; x=1768160262; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=9Yk2RMeWVy7AMdI/FBnP71OqQzW+KY/kQwtCpe2FTiI=; b=J5YpFNh0fsLA9FynwlR9f1NXn5JnYR8B4pd1huM6IkzdDwUvZ72K2D/jaMuFDKIJDw qp01V5x5M5Gl9mfFRmckhw5NEobSjogjh8c42Sze8NWeFMmDlQhzYipwupjYFfC1PZuT Sv5ICSTHlE14nTMW6tz0n0BCHpq2hQtKVWJFLX/br01xmjuHl8Usn4s/+A0a9uMB3/2U YI79O6RNCSA1W8wOk8Ckhp+1px/W8/4UcuDytyl0HyHneh8IF/uJzDEorNnbLI4VCydZ UGOwlo1NBAYO9XN5ZHzWLUT8+rehxXWCZ51WDwH+bc/yrxlDpWHEMSuVnuOj4Gygrr0T Q33Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767555462; x=1768160262; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=9Yk2RMeWVy7AMdI/FBnP71OqQzW+KY/kQwtCpe2FTiI=; b=j8w9RMxzo9vJAF7DM6eH36M4kM506wU5ypP+oysuWgLpcm5XAh3owshBnLa7N+8nmY gtY5+ubc42pKnTHVskCLYJowlbk2UsGW6m9JzvxmxWdM/cHd868uh7fFqeUAdGiKS4yl pzYbuMWona8Bl3jaWR71NSrH9V4FnOrHyq+lM2hgijRsDsbUkQzMC8xkZsjkBh2pkCmO Ghbt5XrufVG0vpjpzu0oR7PQXz4G2XFkXZ1+LS9DR5unLy6zluNHDdu9DFto6Z4RoNyQ SbJDTDT1+zh/aoZSBAKAhoInDIVWCG4YHAvovv4OKeJYO8cZ4OrzgtR0mNv4gKpEPTBZ VTmg== X-Forwarded-Encrypted: i=1; AJvYcCWUSc6ky1b+ve44lAbbDyQXL+5rFt/+cyFJtbE86YYu+mP+4uFV7Gk9Hd0Pga8WSWOslqCVcg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YytnBn4ZypPj9j24JEF50q/6/tvWnX4Tyjmkfk5VF1RRsmMugQE XHWE12ARtr8Y+FtxB+Y7WXAqmIsF+KfFb8D8nzKAU4GqcVcbL++6yDv1t5hjlCJ9 X-Gm-Gg: AY/fxX6glAlndUCqZzZHYgWbc8WbIJzqF7QSwT2yrYWsibw3BcIrQpgSVQR7q7rtHP9 fG7Fxb35XzKCImXRAUCjYRpfYiZw3jrc8INihvRzihBLjgWj5gxCX9dQPpkNDcoifiCfrOFZzg1 PMqyBk0obOjTylK3AF17xWhLGgfhwj+jCOOMMC9eXiNDRhMPsBUTFp4gZoaSqwMS9QeZq3byK5r vtT33kzMBWlVJKDhUMEphFisn5idz7iOkQV5ZUjoxU9zFyDKyPphwRUwdhE45T7yyhOQAN+B6Uw nNJ2ALAL4MawGKClFEllC4cPhKDJeyZJf2GgO0JTJXw+4eBrHAnrlAiS+CHsLU8NMePj4p1/WKw +ZXFTjgZsY1nklE9wJJDSKKvbD8XT2YAMkJoU7HGptRquqyH+Yh+jw00AKO63B4SI+nfL6wsWC+ wW/ythZ19s0/86jCuJkTUe2miQ+PuFHGIBIw1AjZVVQ8G1cciVv13Tw/KmC950PeyYenmthxkoe PL1GOU1l0Ic3B/J6wdmdds= X-Google-Smtp-Source: AGHT+IFDM3eWEsYSkxJdEP06NwMn2y935K8VFumW0o4YkckeNQMTV2RPBkC0xyK1EY7hv5R1KmpdIQ== X-Received: by 2002:a17:907:72ca:b0:b7a:18ba:a63 with SMTP id a640c23a62f3a-b8036f2ab43mr4603904566b.19.1767555461843; Sun, 04 Jan 2026 11:37:41 -0800 (PST) Received: from pro4 (p200300e0b73d3d00c1125116e5964143.dip0.t-ipconnect.de. [2003:e0:b73d:3d00:c112:5116:e596:4143]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b803d3cea32sm5159494566b.34.2026.01.04.11.37.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 04 Jan 2026 11:37:41 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Juri Linkov <juri@HIDDEN> Subject: Re: bug#80025: Margin columns In-Reply-To: <87cy3pmeu5.fsf@HIDDEN> References: <87h5tpj7ch.fsf_-_@HIDDEN> <861pkt3q8e.fsf@HIDDEN> <87cy48nv4o.fsf@HIDDEN> <86ldiwxm9m.fsf@HIDDEN> <87qzsn9dgm.fsf@HIDDEN> <87y0mlkx31.fsf@HIDDEN> <86qzsdqhyi.fsf@HIDDEN> <m2344ssf8p.fsf@HIDDEN> <87y0mkju8d.fsf@HIDDEN> <m2v7hoqtcr.fsf@HIDDEN> <87ecob4zbz.fsf@HIDDEN> <m2qzsbrcug.fsf@HIDDEN> <m2ikdnqhdn.fsf@HIDDEN> <m2ecobqftp.fsf@HIDDEN> <87y0mjyu0c.fsf@HIDDEN> <m2a4yzqbli.fsf@HIDDEN> <m2ms2y2dz0.fsf@HIDDEN> <87cy3pmeu5.fsf@HIDDEN> Date: Sun, 04 Jan 2026 20:37:40 +0100 Message-ID: <m2tsx16uez.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 80025 Cc: Eli Zaretskii <eliz@HIDDEN>, 80025 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Juri Linkov <juri@HIDDEN> writes: >>> Thanks, I think that should work. If you're not yet tired of it - I'd >>> have some suggestions, though :-). >>> >>> - Can we please remove nglyphs? It's always it->pixel_width. >>> >>> - "end" is always it->glyph_row->glyphs[1 + area];, except if the row is >>> revered_p, in which case it is set to a different value. So we could >>> set that once and spare an else. >>> >>> - glyph is similar. I wonder why/when >>> >>> term.c<feature-margin-columns>: >>> 1579 >>> 1580 glyph = it->glyph_row->glyphs[area] + margin_column; >>> 1581 >>> >>> is different from >>> >>> term.c<feature-margin-columns>: >>> 1597 glyph = it->glyph_row->glyphs[area] >>> 1598 + it->glyph_row->used[area]; >>> >>> for the code that is following. When we add spaces, we increment >>> row->used[area] already, as far as the area has room, so I think no harm >>> is done when we use "used" like in the normal case. >>> >>> So glyph and end could be set in one place. >>> >>> - And if we remove >>> >>> term.c<feature-margin-columns>: >>> 1582 /* Increment used counter only after filling with spaces, >>> 1583 but not when changing existing column value. */ >>> 1584 if (margin_column >= it->glyph_row->used[area]) >>> 1585 it->glyph_row->used[area] = margin_column + 1; >>> >>> I think we can remove the special handling >>> >>> term.c<feature-margin-columns>: >>> 1651 if (!handled_column) >>> 1652 ++it->glyph_row->used[area]; >>> >>> and let that just run increment, or not? >>> >>> - And finally handled_column could go, if the above is done. I think. >> >> It just appeared to me - is it true that append_glyph can run first for >> a margin_column N and later for a column < N? IOW, is append_glyphs >> intended tg overwrite glyphs that were previously appended? > > Yes, this requirement is the reason why the second part of your > suggestions above can't be applied (I applied only the first part). > > When changing an existing margin indicator, we need to overwrite > the previous column value. > > What significantly complicates the logic are wide chars with padding > when a wide char for column < N overlaps with the previous wide char. > For example, the first wide char AAA is in the column 3, then comes > the second wide char BB in the column 2: > > 12345 > AAA > BB Yes, exactly, that's what I was afraid of. > We need to clear glyph->padding_p from all subsequent glyphs > that remain from the previous wide char AAA. Just clearing the padding_p flag would not work I'm afraid. Consider the case 1234567890 Aaa Bb i.e. we have a glyph row containing char A starting at 3 with 2 padding glyphs "aa". Now we want to write character B startign at 2 with 1 padding glyph "b". When we just remove the padding_p flag from the first "a", we get a result glyph row of 1234567890 BbAa and when we process such a glyph row, the actual display would end up looking like 1234567890 BBAAA where each AAA and BB are a single wide character. But Emacs' understanding of where the cursor is in the end is different from the understanding of the tty, because Emacs is missing the second "a" padding glyph. Something similar also happens for, say 12345 Aaa Bb where B is written into padding glyphs of A. In this case the display would end up as 1234567890 AAABB And what if we reverse that 12345 Aa Bbb Another idea: Could one give "column" a different meaning, maybe? At the moment, on ttys, it means an index of a glyph in an glyph_row area. What if we made it mean a character index? For example, say A had column 3 and B column 2, and in column 1 and 2 where something 1 pixel wide. Initially the glyph index for A would be 3 1234567890 glyph index __Aaa and when B is inserted at "character column" 2, we make that 1234567890 glyph index __BbAaa i.e. we shift A to the right and column 3 for A becomes glyph index 5. A lot of work of course. One would have to translate a character column to a glyph index first, for example, and so on. But it would be equivalent to the GUI case which has not padding glyphs so there it's always character column == glyph index.
bug-gnu-emacs@HIDDEN:bug#80025; Package emacs.
Full text available.
Received: (at 80025) by debbugs.gnu.org; 4 Jan 2026 18:11:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 04 13:11:35 2026
Received: from localhost ([127.0.0.1]:45222 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vcSZi-0001mF-Rc
for submit <at> debbugs.gnu.org; Sun, 04 Jan 2026 13:11:35 -0500
Received: from mout-p-101.mailbox.org ([80.241.56.151]:53146)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1vcSZg-0001kv-8b
for 80025 <at> debbugs.gnu.org; Sun, 04 Jan 2026 13:11:33 -0500
Received: from smtp2.mailbox.org (smtp2.mailbox.org
[IPv6:2001:67c:2050:b231:465::2])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(No client certificate requested)
by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4dklqb3v6jz9shs;
Sun, 4 Jan 2026 19:11:23 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkov.net; s=MBO0001;
t=1767550283;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
in-reply-to:in-reply-to:references:references;
bh=MbS6KPP+XE5Qh36Rt5wRBReY9luyW2zYSII9ZDrbdzc=;
b=DRxZ5b/YdbewX0ZX6YHS08uVP/U1k0Qh5wjg741M3f+RPIBCaf4MFLdB/H2J/s7xvoIy2f
WqSLCkSiIltNsSe2Eo+cPK9k5hXjozTxOuYtgY1mtZT2OJxrfFEeRr0/ggLFaBBG9vQcvr
06Ibzs4/Rd/j3Ax+Po7lZKe29oXHGTsVXA28DHPG1h68cnuhxeHdgveyQMvubvVgqyg9TX
P+NuDgV7sU44vems0TT9WmtjtC3t+PqqAS2w+tWd/ma3xn/Xgb53J4nZiyXvfB/3OexXAj
Ji1TZ8Eg696OMoHUD0atct132bXFwBPqYL0xM2MpuqKvEYSFAwxceZrLKEWRCA==
Authentication-Results: outgoing_mbo_mout; dkim=none;
spf=pass (outgoing_mbo_mout: domain of juri@HIDDEN designates
2001:67c:2050:b231:465::2 as permitted sender) smtp.mailfrom=juri@HIDDEN
From: Juri Linkov <juri@HIDDEN>
To: Gerd =?iso-8859-1?Q?M=F6llmann?= <gerd.moellmann@HIDDEN>
Subject: Re: bug#80025: Margin columns
In-Reply-To: <m2ms2y2dz0.fsf@HIDDEN>
Organization: LINKOV.NET
References: <87h5tpj7ch.fsf_-_@HIDDEN> <861pkt3q8e.fsf@HIDDEN>
<87cy48nv4o.fsf@HIDDEN> <86ldiwxm9m.fsf@HIDDEN>
<87qzsn9dgm.fsf@HIDDEN> <87y0mlkx31.fsf@HIDDEN>
<86qzsdqhyi.fsf@HIDDEN> <m2344ssf8p.fsf@HIDDEN>
<87y0mkju8d.fsf@HIDDEN> <m2v7hoqtcr.fsf@HIDDEN>
<87ecob4zbz.fsf@HIDDEN> <m2qzsbrcug.fsf@HIDDEN>
<m2ikdnqhdn.fsf@HIDDEN> <m2ecobqftp.fsf@HIDDEN>
<87y0mjyu0c.fsf@HIDDEN> <m2a4yzqbli.fsf@HIDDEN>
<m2ms2y2dz0.fsf@HIDDEN>
Date: Sun, 04 Jan 2026 20:07:30 +0200
Message-ID: <87cy3pmeu5.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Rspamd-Queue-Id: 4dklqb3v6jz9shs
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 80025
Cc: Eli Zaretskii <eliz@HIDDEN>, 80025 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
--=-=-=
Content-Type: text/plain
>> Thanks, I think that should work. If you're not yet tired of it - I'd
>> have some suggestions, though :-).
>>
>> - Can we please remove nglyphs? It's always it->pixel_width.
>>
>> - "end" is always it->glyph_row->glyphs[1 + area];, except if the row is
>> revered_p, in which case it is set to a different value. So we could
>> set that once and spare an else.
>>
>> - glyph is similar. I wonder why/when
>>
>> term.c<feature-margin-columns>:
>> 1579
>> 1580 glyph = it->glyph_row->glyphs[area] + margin_column;
>> 1581
>>
>> is different from
>>
>> term.c<feature-margin-columns>:
>> 1597 glyph = it->glyph_row->glyphs[area]
>> 1598 + it->glyph_row->used[area];
>>
>> for the code that is following. When we add spaces, we increment
>> row->used[area] already, as far as the area has room, so I think no harm
>> is done when we use "used" like in the normal case.
>>
>> So glyph and end could be set in one place.
>>
>> - And if we remove
>>
>> term.c<feature-margin-columns>:
>> 1582 /* Increment used counter only after filling with spaces,
>> 1583 but not when changing existing column value. */
>> 1584 if (margin_column >= it->glyph_row->used[area])
>> 1585 it->glyph_row->used[area] = margin_column + 1;
>>
>> I think we can remove the special handling
>>
>> term.c<feature-margin-columns>:
>> 1651 if (!handled_column)
>> 1652 ++it->glyph_row->used[area];
>>
>> and let that just run increment, or not?
>>
>> - And finally handled_column could go, if the above is done. I think.
>
> It just appeared to me - is it true that append_glyph can run first for
> a margin_column N and later for a column < N? IOW, is append_glyphs
> intended tg overwrite glyphs that were previously appended?
Yes, this requirement is the reason why the second part of your
suggestions above can't be applied (I applied only the first part).
When changing an existing margin indicator, we need to overwrite
the previous column value.
What significantly complicates the logic are wide chars with padding
when a wide char for column < N overlaps with the previous wide char.
For example, the first wide char AAA is in the column 3, then comes
the second wide char BB in the column 2:
12345
AAA
BB
We need to clear glyph->padding_p from all subsequent glyphs
that remain from the previous wide char AAA.
Here is an unfinished patch that demonstrates the idea
(at least, it avoids crashes in case of 2-char wide chars):
--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline; filename=changed_existing.patch
diff --git a/src/term.c b/src/term.c
index b4642e76c1e..f1f894e9abc 100644
--- a/src/term.c
+++ b/src/term.c
@@ -1545,8 +1545,7 @@ append_glyph (struct it *it)
struct glyph *glyph, *end;
enum glyph_row_area area = it->area;
int margin_column = -1;
- bool handled_column = false;
- int nglyphs;
+ bool changed_existing = false;
int i;
eassert (it->glyph_row);
@@ -1562,41 +1561,40 @@ append_glyph (struct it *it)
? WINDOW_LEFT_MARGIN_WIDTH (it->w)
: WINDOW_RIGHT_MARGIN_WIDTH (it->w)))
{
- /* Fill gaps between current position and target column with spaces. */
- int face_id = lookup_basic_face (it->w, it->f, DEFAULT_FACE_ID);
- while (it->glyph_row->used[area] < margin_column
- && it->glyph_row->glyphs[area] + it->glyph_row->used[area]
- < it->glyph_row->glyphs[area + 1])
- {
- struct glyph *fill_glyph =
- it->glyph_row->glyphs[area] + it->glyph_row->used[area];
- *fill_glyph = space_glyph;
- fill_glyph->pixel_width = 1;
- fill_glyph->face_id = face_id;
- fill_glyph->frame = it->f;
- ++it->glyph_row->used[area];
- }
-
- glyph = it->glyph_row->glyphs[area] + margin_column;
-
- /* Increment used counter only after filling with spaces,
- but not when changing existing column value. */
- if (margin_column >= it->glyph_row->used[area])
- it->glyph_row->used[area] = margin_column + 1;
-
/* Increment the margin column for the next character
in a possibly multiple wide chars string. */
it->margin_column += it->pixel_width;
- handled_column = true;
- nglyphs = it->pixel_width;
+ if (margin_column < it->glyph_row->used[area])
+ {
+ glyph = it->glyph_row->glyphs[area] + margin_column;
+ changed_existing = true;
+ }
+ else
+ {
+ /* Fill gaps between current position and target column with spaces. */
+ int face_id = lookup_basic_face (it->w, it->f, DEFAULT_FACE_ID);
+ while (it->glyph_row->used[area] < margin_column
+ && it->glyph_row->glyphs[area] + it->glyph_row->used[area]
+ < it->glyph_row->glyphs[area + 1])
+ {
+ struct glyph *fill_glyph =
+ it->glyph_row->glyphs[area] + it->glyph_row->used[area];
+ *fill_glyph = space_glyph;
+ fill_glyph->pixel_width = 1;
+ fill_glyph->face_id = face_id;
+ fill_glyph->frame = it->f;
+ ++it->glyph_row->used[area];
+ }
+ }
}
- if (!handled_column)
+ end = it->glyph_row->glyphs[1 + area];
+
+ if (!changed_existing)
{
glyph = it->glyph_row->glyphs[area]
+ it->glyph_row->used[area];
- end = it->glyph_row->glyphs[1 + area];
/* If the glyph row is reversed, we need to prepend the glyph rather
than append it. */
@@ -1613,17 +1611,14 @@ append_glyph (struct it *it)
glyph = it->glyph_row->glyphs[area];
end = glyph + move_by;
}
- nglyphs = it->pixel_width;
}
- else
- end = it->glyph_row->glyphs[1 + area];
/* BIDI Note: we put the glyphs of a "multi-pixel" character left to
right, even in the REVERSED_P case, since (a) all of its u.ch are
identical, and (b) the PADDING_P flag needs to be set for the
leftmost one, because we write to the terminal left-to-right. */
for (i = 0;
- i < nglyphs && glyph < end;
+ i < it->pixel_width && glyph < end;
++i)
{
glyph->type = CHAR_GLYPH;
@@ -1648,10 +1643,13 @@ append_glyph (struct it *it)
glyph->bidi_type = UNKNOWN_BT;
}
- if (!handled_column)
+ if (!changed_existing)
++it->glyph_row->used[area];
++glyph;
}
+
+ if (changed_existing && glyph->padding_p)
+ glyph->padding_p = false;
}
/* For external use. */
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#80025; Package emacs.
Full text available.Received: (at 80025) by debbugs.gnu.org; 1 Jan 2026 03:45:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 31 22:45:21 2025 Received: from localhost ([127.0.0.1]:52318 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vb9cm-0003iv-Rv for submit <at> debbugs.gnu.org; Wed, 31 Dec 2025 22:45:21 -0500 Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]:53591) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1vb9ci-0003gk-NV for 80025 <at> debbugs.gnu.org; Wed, 31 Dec 2025 22:45:18 -0500 Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-477a2ab455fso106274795e9.3 for <80025 <at> debbugs.gnu.org>; Wed, 31 Dec 2025 19:45:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767239110; x=1767843910; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=9xKDi5YgeFyUEIx+n/yDZ18gdSt8pTFwPmhw64bx828=; b=BgN/6xbzWCQNcRSNDyIpJKxV6lI2fKSJR/ZBZb60y7f/ND3gWZ2To5K/HAzn7ti98t 4ryVYDiwjqUEWgRtAZK5Ybk3N6tbXuMLVMuJqHBG1EO9eyDhjGRva464mWze7dSAzBeP 0rkchZEhwUT0aPHEveImsxnZ/d8wuWePJWNCRwMAyNoo0IvQLFbfnkEa3es1xIMwiQCB 9vTVmB6wnr2vrpZClS1xXClTFRfr5MiJhFduKRkjYfFs9QOaLZIg9cHM9LkPZbGcK8jX 8muc0SY/WQCicSR9eCMouVcO6TQHX8rCYje75oZSIlbmOVzPI+dF0AmLclq4OkBrldyi lDdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767239110; x=1767843910; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9xKDi5YgeFyUEIx+n/yDZ18gdSt8pTFwPmhw64bx828=; b=wNr5evMP8DzMd15JVvTvqPxsn2CMTv3HVy2HUR+C1YVg7BstScgGJHJ/9HlSSSQzzd UY0RPMflukdTnlARNr3nkr55pPJ0Rl0e3/BLWda/CBxgXNgmlXC/D02NJBkxBg3MLngw bzuK6ki7RztVYCJzjcOVNUb/NfvEP++xY47LEXicQgLwmcoTpB3Z4/Vkr1hK4YEjt3eK ZFrfumvWqNtNztcsNgKMwWAFROQEywDIsdAcvY+Nq4JNFfDahaqRVz1eaDUSD5xTRvxF kDX26SII7eC3VCsUD9uyiXABmdlzg7H2jqbIIkSWZDMy9Xfxx1HlvD2ptYlb1jxMR7fo Vyyg== X-Forwarded-Encrypted: i=1; AJvYcCUNZODcmtviYfaNGBUpY5wnJHA4hqVeLK/pbZG52XQNMRCeUMrO7pBqxiYeB0sgaw5Yht9BvA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyDMfod1CdPHUkm+vYS1bo1ngRgmG/fPSkqGUPu6iyfqChOrRre vsYe5mZ8izMq9gisgyEaLsNaqW+4QU92DThkB5PsT4ipDW7lE/0X4wfS0Vk70A== X-Gm-Gg: AY/fxX5Pk+S0nzJGzVcPEQh0SFWreZHlaoL9smP7roXvyKt/fkaeOL4rBVLs92uYZZd s9XOgW/khGmQw9sB1JqHATBxboxoYsp9Pe3bJfgBdn5cdT2+9ACaJz8CBMDHkI8Rxvf98muOvze j2upe1yYc9KuH73psRmInndGcFtIqQea23cYEe6FrXQKYHTgskMRCpxIHO87BY3iDzbqUi/bpVn YYW9Vf9Hk1O/o3qt1ryOU6g6xjg5ltonPmtE5wpaJB1K3r3FX6wk8EzSwXJ9OvROwW3ry9rSd2V K3nA1fXl4MjFcJBwVhJMPuckaY2ysSgU8H634jJWzF2l5/OveH7r+pcVH1iegBOVRFwoQy/MDkk 7d7k2wDvJbmYV2i8Uo2OnAi2cADCdHmsIwgzIUUpJ37HI0pUYDbxshaUAMaaNq7KLc4v4WDTbrB KQxaPEQPvxc47cHJ1hldLkpGZ062aAWsbQxLkTZnFXzrWA/05+fwO4Yjii4CPGndseOmST8tpsM 4MGX996a2bOcEv/355LOAI= X-Google-Smtp-Source: AGHT+IGuJkfjliankgPymJ744w5vM6o3UI2QaBOiKm+uP1QF4CLlrutyQcl+8ZqIm+WdNIuNuWDnGQ== X-Received: by 2002:a05:600c:348a:b0:477:95a0:fe95 with SMTP id 5b1f17b1804b1-47d195ab61fmr480142805e9.24.1767239110109; Wed, 31 Dec 2025 19:45:10 -0800 (PST) Received: from pro4 (p200300e0b72a5800b5f4f6c74a962586.dip0.t-ipconnect.de. [2003:e0:b72a:5800:b5f4:f6c7:4a96:2586]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47be27b28a7sm731028855e9.12.2025.12.31.19.45.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 31 Dec 2025 19:45:08 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Juri Linkov <juri@HIDDEN> Subject: Re: bug#80025: Margin columns In-Reply-To: <m2a4yzqbli.fsf@HIDDEN> References: <87h5tpj7ch.fsf_-_@HIDDEN> <861pkt3q8e.fsf@HIDDEN> <87cy48nv4o.fsf@HIDDEN> <86ldiwxm9m.fsf@HIDDEN> <87qzsn9dgm.fsf@HIDDEN> <87y0mlkx31.fsf@HIDDEN> <86qzsdqhyi.fsf@HIDDEN> <m2344ssf8p.fsf@HIDDEN> <87y0mkju8d.fsf@HIDDEN> <m2v7hoqtcr.fsf@HIDDEN> <87ecob4zbz.fsf@HIDDEN> <m2qzsbrcug.fsf@HIDDEN> <m2ikdnqhdn.fsf@HIDDEN> <m2ecobqftp.fsf@HIDDEN> <87y0mjyu0c.fsf@HIDDEN> <m2a4yzqbli.fsf@HIDDEN> Date: Thu, 01 Jan 2026 04:45:07 +0100 Message-ID: <m2ms2y2dz0.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 80025 Cc: Eli Zaretskii <eliz@HIDDEN>, 80025 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: > Juri Linkov <juri@HIDDEN> writes: > >>>>>> Please take a look. >>>>> >>>>> Hm, regarding append_glyph, I don't understand this: >>>>> >>>>> term.c: >>>>> 1591 handled_column =3D true; >>>>> 1592 nglyphs =3D 1; >>>>> ^^^^^^^^^^^ >>>>> >>>>> It->pixel_width here shojld be the number of glyphs we must append he= re, >>>>> for it->c, and it is > 1 for wide characters. If it is > 1, this means >>>>> the tty will output something that is that number of character cells = (=3D >>>>> pixels) wide and then move the cursor to the end of the character. If= we >>>>> always append just 1 glyph, Emacs' idea where the cursor is might dif= fer >>>>> from tty's idea when wide characters are involved. >>> >>> There is another thing which assumes that one character in a glyph row >>> occupies 1 glyph: >>> >>> /* Increment the margin column for the next character >>> in a possibly multi-char string. */ >>> it->margin_column++; >>> >>> and it fits with nglyphs being set to 1. >>> >>> That can't be done on ttys. append_glyph has to produce it->pixel_width >>> glyphs for it->c. >> >> I tried to fix these now. >> >>>>> 1593 } >>>>> 1594=20 >>>>> 1595 if (!handled_column) >>>>> >>>>> The if above I'd find easier to follow if it were an else, which it i= s. >>>>> >>>>> term.c: >>>>> 1617 } >>>>> 1618 else >>>>> 1619 end =3D it->glyph_row->glyphs[1 + area]; >>>>> >>>>> and the else here would be in the other arm of the if.=20 >>>> >>>> Just appeared to me that what I said is wrong because of >>>> >>>> && margin_column < (area =3D=3D LEFT_MARGIN_AREA >>>> ? WINDOW_LEFT_MARGIN_WIDTH (it->w) >>>> : WINDOW_RIGHT_MARGIN_WIDTH (it->w))) >> >> This line >> >> end =3D it->glyph_row->glyphs[1 + area]; >> >> was inside this condition >> >> && margin_column < (area =3D=3D LEFT_MARGIN_AREA >> >> before my previous change. I moved it to improve readability >> as I believed, but maybe it worsened readability. >> >>>> Anyway - maybe an indicator that the function could be a bit clearer. >> >> A function would be justified if it was called at least from two places, >> but not sure about a function only for readability. > > (I'm so tired of deciphering code that I'd prefer readability every time > and let the compiler do the work. But I'm old :-)). > > Thanks, I think that should work. If you're not yet tired of it - I'd > have some suggestions, though :-). > > - Can we please remove nglyphs? It's always it->pixel_width. > > - "end" is always it->glyph_row->glyphs[1 + area];, except if the row is > revered_p, in which case it is set to a different value. So we could > set that once and spare an else. > > - glyph is similar. I wonder why/when > > term.c<feature-margin-columns>: > 1579=20 > 1580 glyph =3D it->glyph_row->glyphs[area] + margin_column; > 1581=20 > > is different from > > term.c<feature-margin-columns>: > 1597 glyph =3D it->glyph_row->glyphs[area] > 1598 + it->glyph_row->used[area]; > > for the code that is following. When we add spaces, we increment > row->used[area] already, as far as the area has room, so I think no harm > is done when we use "used" like in the normal case. > > So glyph and end could be set in one place. > > - And if we remove > > term.c<feature-margin-columns>: > 1582 /* Increment used counter only after filling with spaces, > 1583 but not when changing existing column value. */ > 1584 if (margin_column >=3D it->glyph_row->used[area]) > 1585 it->glyph_row->used[area] =3D margin_column + 1; > > I think we can remove the special handling > > term.c<feature-margin-columns>: > 1651 if (!handled_column) > 1652 ++it->glyph_row->used[area]; > > and let that just run increment, or not? > > - And finally handled_column could go, if the above is done. I think. It just appeared to me - is it true that append_glyph can run first for a margin_column N and later for a column < N? IOW, is append_glyphs intended tg overwrite glyphs that were previously appended?
bug-gnu-emacs@HIDDEN:bug#80025; Package emacs.
Full text available.Received: (at 80025) by debbugs.gnu.org; 31 Dec 2025 08:50:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 31 03:50:30 2025 Received: from localhost ([127.0.0.1]:49212 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1varuX-00059l-HQ for submit <at> debbugs.gnu.org; Wed, 31 Dec 2025 03:50:30 -0500 Received: from mail-ed1-x531.google.com ([2a00:1450:4864:20::531]:50279) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1varuU-00059U-FG for 80025 <at> debbugs.gnu.org; Wed, 31 Dec 2025 03:50:27 -0500 Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-64b4b35c812so14695423a12.0 for <80025 <at> debbugs.gnu.org>; Wed, 31 Dec 2025 00:50:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767171020; x=1767775820; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=NJUnyfvvsLMLvUjU3fqoLiqsmhr9lfcRGxo1+7KroPE=; b=eAcLeaMbXkTd4vfk9sfeQk/8cLkD7isdi7FO9sptYTjJa89Wmj8lNV7pKcvXdgTdG4 zrQB5cRQmKPP2hYeP9X0H2nZuphvR4KAWUzozaG5+HHFhTUScVIxuzNd/PorLGbi3qJ4 jyps/IXeZiqkXL/YbMVt8S2jS5fn/WOm+xVOMKRovP0RlXoDs4xkn3v0xogEQBP7p3aP Tc6yk4k/ft34z/JMPxlip8FW+O6seIjsLh6GGlCCZ6JvJcK5E6tnDP0YAdylYyHajR04 6EF3aBG758Fv6B8pBWWn4HaZz7E079OrGLEKtIRi3KDb3ubqMxLoRfgTfXmRK8gp+5p6 uaMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767171020; x=1767775820; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=NJUnyfvvsLMLvUjU3fqoLiqsmhr9lfcRGxo1+7KroPE=; b=ttXDw6DdTumFpfaYTq010PS/nyUgv0N6ugT7AtK2IKUQJYWlBS6n9KVqTmBxmH+6ir v8GxzsTZrUJvHbBf5RWefu+552gzN0z4BQbjJaaMhvXjjr0GCfY8wHqD096JkITwZA91 KcFIWQFhycF0z9+thnVzpjnmoX4spmHko2wE7plVbgi4TxGhFd8Es8uxZkI+/35tzdxH GGK33qHeQg+xEzWTb2HRO+0ofOtrUWikexn10ex4FFXw8VNsKBSuw2NPRrgB9e3+hhEE qgqbgAiCO8PGIW3zzoniULbpl/7PVK1SNd1rtVU93u22X8Qj74aT4LloBeBcGH5tTzaD KvKg== X-Forwarded-Encrypted: i=1; AJvYcCWCjcGiac21P8KRVGE7t/o8hF+vSg/Mm/h1P3jSUXClMN+JzF8PD3IPoJqtnkN/OJf2Mz0i0A==@debbugs.gnu.org X-Gm-Message-State: AOJu0YziZJASmNdQTK3bZh3LRMFIMJjWhtvpnqMzKJAYtcH1LSRICJyj 0i1KaEOJumlzrSyO98re+BlIHA/MkPk+cO/MdUNpgXDZWmQ1VcOf216ETpWOCkDu X-Gm-Gg: AY/fxX6RKwbRuYtXVJc/i6xEjDFni+eEw+j+m/zHUjGUaIGNnK853fJ0PsgP7wOW4iF pBEUx8jg4ZYoGwbM6fYDB++kt/qj7iWvCzmx6xj9ppwNcq0QhqayHSvHNwcTH5qMWstqas9fWxx Zpp3rUJ9LMBTLlaLrBAp2B5vnBuppAq1sSqjjIVi4bNwvhQ735WwByCE5Hmu3GYFhm4bVZKJcIy z4Hre50lhwPo58NnnGvrrPx1ccCFUqwEeH0EqSZYpPAaaoMXYQv4g/RBNOm3yf1qHAmi6Z0sSal jdUSOLyyxbhEYOCUbKSs+mo2fw4xoIxJqlcbRLPINs6h5NJVlMCbUNVlO4VhpJouraPZi6iNIk3 7/dsEc5+X6vVYBxQs3qB68Lv3WjCVw9jZgUPVV/s3ryCq71sfdmgWdkv4IGB0h+WwpUEL4uUTpT bey/qPOhL4J0Mo5Jc9oVAgZo8ivlRPTr5dH5486X+t9TNISSghYKPE6QhxVkdbORchEBK1iMeaW 9dt+fKsSkcIj1Mc2DUC5zw= X-Google-Smtp-Source: AGHT+IH+TOpXKRFXrk56Z7u4bHTkie2Ox0ZPnhzQzxhyawBAfrRFy0RqUzTg5po1Rjge7lqGjlWq/Q== X-Received: by 2002:a05:6402:5188:b0:649:9251:1115 with SMTP id 4fb4d7f45d1cf-64b8ec9eb4bmr29316007a12.29.1767171019805; Wed, 31 Dec 2025 00:50:19 -0800 (PST) Received: from pro4 (p200300e0b72377007c71977acab91cbc.dip0.t-ipconnect.de. [2003:e0:b723:7700:7c71:977a:cab9:1cbc]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-64b916b66e2sm38014832a12.34.2025.12.31.00.50.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 31 Dec 2025 00:50:19 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Juri Linkov <juri@HIDDEN> Subject: Re: bug#80025: Margin columns In-Reply-To: <87y0mjyu0c.fsf@HIDDEN> References: <87h5tpj7ch.fsf_-_@HIDDEN> <861pkt3q8e.fsf@HIDDEN> <87cy48nv4o.fsf@HIDDEN> <86ldiwxm9m.fsf@HIDDEN> <87qzsn9dgm.fsf@HIDDEN> <87y0mlkx31.fsf@HIDDEN> <86qzsdqhyi.fsf@HIDDEN> <m2344ssf8p.fsf@HIDDEN> <87y0mkju8d.fsf@HIDDEN> <m2v7hoqtcr.fsf@HIDDEN> <87ecob4zbz.fsf@HIDDEN> <m2qzsbrcug.fsf@HIDDEN> <m2ikdnqhdn.fsf@HIDDEN> <m2ecobqftp.fsf@HIDDEN> <87y0mjyu0c.fsf@HIDDEN> Date: Wed, 31 Dec 2025 09:50:17 +0100 Message-ID: <m2a4yzqbli.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 80025 Cc: Eli Zaretskii <eliz@HIDDEN>, 80025 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Juri Linkov <juri@HIDDEN> writes: >>>>> Please take a look. >>>> >>>> Hm, regarding append_glyph, I don't understand this: >>>> >>>> term.c: >>>> 1591 handled_column = true; >>>> 1592 nglyphs = 1; >>>> ^^^^^^^^^^^ >>>> >>>> It->pixel_width here shojld be the number of glyphs we must append here, >>>> for it->c, and it is > 1 for wide characters. If it is > 1, this means >>>> the tty will output something that is that number of character cells (= >>>> pixels) wide and then move the cursor to the end of the character. If we >>>> always append just 1 glyph, Emacs' idea where the cursor is might differ >>>> from tty's idea when wide characters are involved. >> >> There is another thing which assumes that one character in a glyph row >> occupies 1 glyph: >> >> /* Increment the margin column for the next character >> in a possibly multi-char string. */ >> it->margin_column++; >> >> and it fits with nglyphs being set to 1. >> >> That can't be done on ttys. append_glyph has to produce it->pixel_width >> glyphs for it->c. > > I tried to fix these now. > >>>> 1593 } >>>> 1594 >>>> 1595 if (!handled_column) >>>> >>>> The if above I'd find easier to follow if it were an else, which it is. >>>> >>>> term.c: >>>> 1617 } >>>> 1618 else >>>> 1619 end = it->glyph_row->glyphs[1 + area]; >>>> >>>> and the else here would be in the other arm of the if. >>> >>> Just appeared to me that what I said is wrong because of >>> >>> && margin_column < (area == LEFT_MARGIN_AREA >>> ? WINDOW_LEFT_MARGIN_WIDTH (it->w) >>> : WINDOW_RIGHT_MARGIN_WIDTH (it->w))) > > This line > > end = it->glyph_row->glyphs[1 + area]; > > was inside this condition > > && margin_column < (area == LEFT_MARGIN_AREA > > before my previous change. I moved it to improve readability > as I believed, but maybe it worsened readability. > >>> Anyway - maybe an indicator that the function could be a bit clearer. > > A function would be justified if it was called at least from two places, > but not sure about a function only for readability. (I'm so tired of deciphering code that I'd prefer readability every time and let the compiler do the work. But I'm old :-)). Thanks, I think that should work. If you're not yet tired of it - I'd have some suggestions, though :-). - Can we please remove nglyphs? It's always it->pixel_width. - "end" is always it->glyph_row->glyphs[1 + area];, except if the row is revered_p, in which case it is set to a different value. So we could set that once and spare an else. - glyph is similar. I wonder why/when term.c<feature-margin-columns>: 1579 1580 glyph = it->glyph_row->glyphs[area] + margin_column; 1581 is different from term.c<feature-margin-columns>: 1597 glyph = it->glyph_row->glyphs[area] 1598 + it->glyph_row->used[area]; for the code that is following. When we add spaces, we increment row->used[area] already, as far as the area has room, so I think no harm is done when we use "used" like in the normal case. So glyph and end could be set in one place. - And if we remove term.c<feature-margin-columns>: 1582 /* Increment used counter only after filling with spaces, 1583 but not when changing existing column value. */ 1584 if (margin_column >= it->glyph_row->used[area]) 1585 it->glyph_row->used[area] = margin_column + 1; I think we can remove the special handling term.c<feature-margin-columns>: 1651 if (!handled_column) 1652 ++it->glyph_row->used[area]; and let that just run increment, or not? - And finally handled_column could go, if the above is done. I think.
bug-gnu-emacs@HIDDEN:bug#80025; Package emacs.
Full text available.Received: (at 80025) by debbugs.gnu.org; 31 Dec 2025 07:46:47 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 31 02:46:46 2025 Received: from localhost ([127.0.0.1]:48949 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vaqus-0001D4-JB for submit <at> debbugs.gnu.org; Wed, 31 Dec 2025 02:46:46 -0500 Received: from mout-p-102.mailbox.org ([80.241.56.152]:46894) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1vaqup-0001C4-QV for 80025 <at> debbugs.gnu.org; Wed, 31 Dec 2025 02:46:45 -0500 Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4dh28R1B7Gz9t2T; Wed, 31 Dec 2025 08:46:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkov.net; s=MBO0001; t=1767167191; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dMRsW+oy4X3xR9KlegBh4rXo4kKeRgrQ68WiVRViCv8=; b=u9IUdM0XzfrE5pBZB4dB0z/vgDBFUSU04P5uW2qAxWl98SBcKE4XLdLVRUF7II+HIqXhsV xT6YQLQOuGFVN+6+riYzFftgE50ySOW4QoLAu8CNhkus7HY+aPpkE4RFp+lE9ibKF3fzkI VzK7YdTE2LrrpD+2397NWdm2KbLaKIeOdxcl+o/c6PKn9m3e+TnW1zmaHoSuzf0IXgx+cO 9QjM1W9o2o60wJlYd3eBVu33nx5U27fzMyzvPvZr4mATztWMxznFiwCdAspVNVsSBP8+88 /pmmxX/r36ksN866bmTbM4tr0pq4dyg+K9MPe3MeOeE2DGG7HSr1Eovg1JU68g== From: Juri Linkov <juri@HIDDEN> To: Gerd =?iso-8859-1?Q?M=F6llmann?= <gerd.moellmann@HIDDEN> Subject: Re: bug#80025: Margin columns In-Reply-To: <m2ecobqftp.fsf@HIDDEN> Organization: LINKOV.NET References: <87h5tpj7ch.fsf_-_@HIDDEN> <861pkt3q8e.fsf@HIDDEN> <87cy48nv4o.fsf@HIDDEN> <86ldiwxm9m.fsf@HIDDEN> <87qzsn9dgm.fsf@HIDDEN> <87y0mlkx31.fsf@HIDDEN> <86qzsdqhyi.fsf@HIDDEN> <m2344ssf8p.fsf@HIDDEN> <87y0mkju8d.fsf@HIDDEN> <m2v7hoqtcr.fsf@HIDDEN> <87ecob4zbz.fsf@HIDDEN> <m2qzsbrcug.fsf@HIDDEN> <m2ikdnqhdn.fsf@HIDDEN> <m2ecobqftp.fsf@HIDDEN> Date: Wed, 31 Dec 2025 09:45:23 +0200 Message-ID: <87y0mjyu0c.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 80025 Cc: Eli Zaretskii <eliz@HIDDEN>, 80025 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) >>>> Please take a look. >>> >>> Hm, regarding append_glyph, I don't understand this: >>> >>> term.c: >>> 1591 handled_column = true; >>> 1592 nglyphs = 1; >>> ^^^^^^^^^^^ >>> >>> It->pixel_width here shojld be the number of glyphs we must append here, >>> for it->c, and it is > 1 for wide characters. If it is > 1, this means >>> the tty will output something that is that number of character cells (= >>> pixels) wide and then move the cursor to the end of the character. If we >>> always append just 1 glyph, Emacs' idea where the cursor is might differ >>> from tty's idea when wide characters are involved. > > There is another thing which assumes that one character in a glyph row > occupies 1 glyph: > > /* Increment the margin column for the next character > in a possibly multi-char string. */ > it->margin_column++; > > and it fits with nglyphs being set to 1. > > That can't be done on ttys. append_glyph has to produce it->pixel_width > glyphs for it->c. I tried to fix these now. >>> 1593 } >>> 1594 >>> 1595 if (!handled_column) >>> >>> The if above I'd find easier to follow if it were an else, which it is. >>> >>> term.c: >>> 1617 } >>> 1618 else >>> 1619 end = it->glyph_row->glyphs[1 + area]; >>> >>> and the else here would be in the other arm of the if. >> >> Just appeared to me that what I said is wrong because of >> >> && margin_column < (area == LEFT_MARGIN_AREA >> ? WINDOW_LEFT_MARGIN_WIDTH (it->w) >> : WINDOW_RIGHT_MARGIN_WIDTH (it->w))) This line end = it->glyph_row->glyphs[1 + area]; was inside this condition && margin_column < (area == LEFT_MARGIN_AREA before my previous change. I moved it to improve readability as I believed, but maybe it worsened readability. >> Anyway - maybe an indicator that the function could be a bit clearer. A function would be justified if it was called at least from two places, but not sure about a function only for readability.
bug-gnu-emacs@HIDDEN:bug#80025; Package emacs.
Full text available.
Received: (at 80025) by debbugs.gnu.org; 31 Dec 2025 07:19:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 31 02:19:10 2025
Received: from localhost ([127.0.0.1]:48864 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vaqU9-0008Hc-RG
for submit <at> debbugs.gnu.org; Wed, 31 Dec 2025 02:19:10 -0500
Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]:55595)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>)
id 1vaqU7-0008H1-4X
for 80025 <at> debbugs.gnu.org; Wed, 31 Dec 2025 02:19:08 -0500
Received: by mail-wm1-x32a.google.com with SMTP id
5b1f17b1804b1-4779cc419b2so83177675e9.3
for <80025 <at> debbugs.gnu.org>; Tue, 30 Dec 2025 23:19:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1767165541; x=1767770341; darn=debbugs.gnu.org;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=IZYBhwTEvo9Rmtc1+/U92rsENX0lb2tOUYyuE6GTd8E=;
b=IikglRwwL7IIFMesMpd+BJ5h7nmdUQ8e5fRld6rg5IdRg+RhwDx/S+j2Ja17d2qxT0
GpcZ/qaj/VBDW8bR8bCchP0pMG4HevS3Jmqn/oYj5FEDqRE+4Lxh69jPmrhbzbBQW6FH
727oyHZ7vLX+jomaKIBdp9aM46yCo9j6e5qrk/KwzjBvbw3eqqjm85bxwIWyaGo45mpL
foKCTXc4jW067RcpYC0lVHJs8gVQye0iWfXvnJbOgdsVo6455iyN+308pc0vL4e6tYXE
CRGoKSRXAhrErNIPT43EnhD7SlXfmr9yzi1d+263cN2Xgs8cl4AonXalP59mcl0Gdq57
q2ig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1767165541; x=1767770341;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:x-gm-gg
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=IZYBhwTEvo9Rmtc1+/U92rsENX0lb2tOUYyuE6GTd8E=;
b=C8yfVhvzB7iDPZ7BaXDHNPFF0iFGKYlnvQLcomhQTueCmnX+jlHHS8Ug1vRyn7BuTj
4tL71g3iy6iGHRh84UgSKf3zVhoWUo/z8Oo8B5VNsl8imGQx7bOoWt6tVw/yGMtG0hYE
qD3txqeiJ2GxCrVLOxPUzu1lISXfcFDvDl1QTQs35W63PFU1dgrHnmteat1pQ6+ffhRC
rMrEEF6Wnjk6qD50ZMz8qwKG7xs9wKdNKhYW6QY7hgXivBPMIxTsEAQztT2KFb27k+4I
Jgbw7RCOVDHCoi5FcbsIovpuEYUx0Li7tuBo11d8lU5321243Yebw8hM/EnP6/H/uK2r
8u5A==
X-Forwarded-Encrypted: i=1;
AJvYcCXdWJeArbAmjbRVHeqM+O34VdWeCz2+dKozb4sDplwMEz0D9UEJvJ7W073sn8/iLH6qvMD+ow==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YxcQNimLdweRxAb6prI2GrFSsDsoLOx8a7FVaBRvf3eVItc8NDc
IO9IcwcR1xAaLhFpZDRtOgpAxV+CdgAZvKTqEkV7GOC+cOBmz/YLkwnMqkExRP56
X-Gm-Gg: AY/fxX6fi8QYywElIJGlaq07m9IkCpwUtTqKO+Ix0zEnTqS9HIdoIkbYHHfr+MarZo6
cRreNzqvlJYMBPynMOtB71DH1KF/9fyKGUminxtVDp2wIf+mpt60KM0lCrGy6WIjvnFCGSNS1IT
8R3FLucpJsjhO7sFYc14BNei1ABEmSKlNVTSDv5cB2/yf9cQdGVvuwmIrykqWFwmUJIgYObu7mZ
QvhU5rSbox2zRutRIAszJCuvDCaL0svkvGnkF458Ffs5kIBJEuZV1rctaOL3CKB2ZzECzKXeB1M
WMOMXZFnfdlNTigaqWVhhk1Loeh9YpoNkCtIYt0tsWTyIkO6cJ3KdgL29mV9fIUDl1+cLlsupSZ
ldgNsmUcVTqPwetXgKl7RYVgFsJfr+nojmyx6gfZgnjwrzr4gmgIguFOFGZvrTBqZT/vMpg0Jcg
GstswL4pVian+TF2DTIGK7O+f1b3T5oUcfNtr2oUL/33TRobAIOpupTqsSdpK7eLPd+d7yAG1pG
u2WjeJPykf18DbD2S091a3TYwZZ/NkGbA==
X-Google-Smtp-Source: AGHT+IEfNLlFlmQ5KFit0Yo6vaUMQfI+Besi3/NMaUhaj5r8/baEC6Jjb7EWk1fNj4Ui8+aO7Sgymw==
X-Received: by 2002:a05:600c:8216:b0:477:97c7:9be7 with SMTP id
5b1f17b1804b1-47d19549a07mr427081725e9.1.1767165540572;
Tue, 30 Dec 2025 23:19:00 -0800 (PST)
Received: from pro4 (p200300e0b72377007c71977acab91cbc.dip0.t-ipconnect.de.
[2003:e0:b723:7700:7c71:977a:cab9:1cbc])
by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-47be3a9687dsm287796165e9.3.2025.12.30.23.18.59
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Tue, 30 Dec 2025 23:18:59 -0800 (PST)
From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: Juri Linkov <juri@HIDDEN>
Subject: Re: bug#80025: Margin columns
In-Reply-To: <m2ikdnqhdn.fsf@HIDDEN>
References: <87h5tpj7ch.fsf_-_@HIDDEN> <861pkt3q8e.fsf@HIDDEN>
<87cy48nv4o.fsf@HIDDEN> <86ldiwxm9m.fsf@HIDDEN>
<87qzsn9dgm.fsf@HIDDEN> <87y0mlkx31.fsf@HIDDEN>
<86qzsdqhyi.fsf@HIDDEN> <m2344ssf8p.fsf@HIDDEN>
<87y0mkju8d.fsf@HIDDEN> <m2v7hoqtcr.fsf@HIDDEN>
<87ecob4zbz.fsf@HIDDEN> <m2qzsbrcug.fsf@HIDDEN>
<m2ikdnqhdn.fsf@HIDDEN>
Date: Wed, 31 Dec 2025 08:18:58 +0100
Message-ID: <m2ecobqftp.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 80025
Cc: Eli Zaretskii <eliz@HIDDEN>, 80025 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes:
> Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes:
>
>> 1593 }
>> 1594=20
>> 1595 if (!handled_column)
>>
>> The if above I'd find easier to follow if it were an else, which it
>> is.
>
> Just appeared to me that what I said is wrong because of
>
> && margin_column < (area =3D=3D LEFT_MARGIN_AREA
> ? WINDOW_LEFT_MARGIN_WIDTH (it->w)
> : WINDOW_RIGHT_MARGIN_WIDTH (it->w)))
>
> Anyway - maybe an indicator that the function could be a bit clearer.
There is another thing which assumes that one character in a glyph row
occupies 1 glyph:
/* Increment the margin column for the next character
in a possibly multi-char string. */
it->margin_column++;
and it fits with nglyphs being set to 1.
That can't be done on ttys. append_glyph has to produce it->pixel_width
glyphs for it->c.
bug-gnu-emacs@HIDDEN:bug#80025; Package emacs.
Full text available.
Received: (at 80025) by debbugs.gnu.org; 31 Dec 2025 06:45:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 31 01:45:38 2025
Received: from localhost ([127.0.0.1]:48748 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vapxh-0006eL-RS
for submit <at> debbugs.gnu.org; Wed, 31 Dec 2025 01:45:38 -0500
Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]:43329)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>)
id 1vapxd-0006dx-6O
for 80025 <at> debbugs.gnu.org; Wed, 31 Dec 2025 01:45:36 -0500
Received: by mail-wm1-x32c.google.com with SMTP id
5b1f17b1804b1-4779a4fc95aso55587185e9.1
for <80025 <at> debbugs.gnu.org>; Tue, 30 Dec 2025 22:45:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1767163527; x=1767768327; darn=debbugs.gnu.org;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=dbj7fCaj/76EY1LaeAuhqFkSZi2uSc1pMWM43PwLjdY=;
b=AZESbOjj/NSj/36UC/Wm2w/T9Zb0QaUEywUn5aOAGJ0YgUuBKSm0YbP/QKA8tvTW32
yCypjfs9qZs/OrJtcnxtIf1ubWOBoMoCCk460zTKdX6gQvwuf1UE0xtEgZs9J6NZhKws
dAeVmsRTuPhq5dNMZCDoZhKmzbLxoKdQwzG53Os2zGDcK/xeDJPLTd8feZrBQUKFzT8G
PJ+VX997EMIqVwhB2MEM9eFgxcw2EVL45Nz21jLFyKLOwgqWs/7chn2pWDOB3H/qSglr
BU6GhqonyvkLIlKeOYt9DsK+vnT9DxKflQBbBnXoSo1gCSWBmCLyxM/AKQOEnRcc6KVA
VdTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1767163527; x=1767768327;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:x-gm-gg
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=dbj7fCaj/76EY1LaeAuhqFkSZi2uSc1pMWM43PwLjdY=;
b=TmludMko81Piw2K4peY8cIGKm0AOVbvrd45/P2DDEq4zAJgvJDDcBRswvlHdciPapX
1qbS+Th/2CV8osHqlRDUMUyKhyRIAFy5jBAzdsMRx1EngNOWqCtDLToS/Xn7Iu8KnVmX
CYIg8aH9AUbAN4Y2i9Uz12695KT+n14WTU/y9UFDSYTxyot+3fd0vcpR4YpmGscI/1yB
z28zFwIfT5xNl5navST2kz45LtV2LO+mog8QIgwqkspmWdkQ6xO0ia+/gyBDJnAuIYaU
oL5T8A7tLT0RX+EEALTeikzwkJ9SdW6kiHyjh9Dt7VeqYlhXLdYJTJWX7MMqJLvZqCwI
MJug==
X-Forwarded-Encrypted: i=1;
AJvYcCU3YqbWybtVeG+HpfNuJhPmsHpVhdiDFWDWna/H3eihyeMtc7muleNod4iYC7X7JuTTxlcpZg==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YxMLv6da/CGWdGDKhD6Zpeip8U3qTHwGhxSw/Gde6MZ2nvNZadh
gqAsYPVLuO6ydU4Cyv7omH9u274PR/qnvd/K1iFpGTVNdIwU3iTe7U0ccICP/ssM
X-Gm-Gg: AY/fxX5YTmM/Xab/92vf/8vsVwsy8/MwQae2kliPB/1zVq1+Jlgi5Y5tJgRBiH1YdyL
B/dnmDZAmgf3gyHvYFp/aMvc53WYJhHAm7zSf2pOhBav/zpApKduPtPzNlGhnK77mNjFXnJMRZu
jvrMbbJY3X3FeD3zWjbEfSLE6ZLzAbjKpHwxTMlW5tQGAOeEfyw511FuBN70MiHTQWzd5Cuf6WP
Pyh53uFIwNw10V35pbo+Vtli1gwKwzFxHGp3FH6oVBYLjG896+C/L4WvBRiLM6jPLvzG1v19TMZ
Vx8lVinW9qj1NHRua1BEBSdcQKd8HOf9k6k5PYuNyBMuXbmDBprmO8Ac8szWK5T9YP2Z8pjfeJP
ucnRxBbVXaGsqTdMq0bEdothQb2zBqLYQionr+8erTP/M/etdNLHgzyt9C2H2YlAk91DRcdKfFc
UT+bwDm1XKE2Uy7Y9VLuhU8Sdd5zuGYWqbPPxKtbVstXg/6tZ+EGOOCh7RIRokT2cdJMqKw8CAe
ZBU7bdH1pPSV240cqD72Zk=
X-Google-Smtp-Source: AGHT+IGl0Lic+FCqrYnrECaSE3Teave/cE+tz8k9P271HDU/O2t9vnlmMntJverDOUPdnTw1uDmKdQ==
X-Received: by 2002:a05:600c:19ca:b0:477:a289:d854 with SMTP id
5b1f17b1804b1-47d18b98f87mr441081945e9.5.1767163526468;
Tue, 30 Dec 2025 22:45:26 -0800 (PST)
Received: from pro4 (p200300e0b72377007c71977acab91cbc.dip0.t-ipconnect.de.
[2003:e0:b723:7700:7c71:977a:cab9:1cbc])
by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-47d193d4f09sm646131975e9.12.2025.12.30.22.45.24
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Tue, 30 Dec 2025 22:45:25 -0800 (PST)
From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: Juri Linkov <juri@HIDDEN>
Subject: Re: bug#80025: Margin columns
In-Reply-To: <m2qzsbrcug.fsf@HIDDEN>
References: <87h5tpj7ch.fsf_-_@HIDDEN> <861pkt3q8e.fsf@HIDDEN>
<87cy48nv4o.fsf@HIDDEN> <86ldiwxm9m.fsf@HIDDEN>
<87qzsn9dgm.fsf@HIDDEN> <87y0mlkx31.fsf@HIDDEN>
<86qzsdqhyi.fsf@HIDDEN> <m2344ssf8p.fsf@HIDDEN>
<87y0mkju8d.fsf@HIDDEN> <m2v7hoqtcr.fsf@HIDDEN>
<87ecob4zbz.fsf@HIDDEN> <m2qzsbrcug.fsf@HIDDEN>
Date: Wed, 31 Dec 2025 07:45:24 +0100
Message-ID: <m2ikdnqhdn.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 80025
Cc: Eli Zaretskii <eliz@HIDDEN>, 80025 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes:
> 1593 }
> 1594=20
> 1595 if (!handled_column)
>
> The if above I'd find easier to follow if it were an else, which it
> is.
Just appeared to me that what I said is wrong because of
&& margin_column < (area =3D=3D LEFT_MARGIN_AREA
? WINDOW_LEFT_MARGIN_WIDTH (it->w)
: WINDOW_RIGHT_MARGIN_WIDTH (it->w)))
Anyway - maybe an indicator that the function could be a bit clearer.
bug-gnu-emacs@HIDDEN:bug#80025; Package emacs.
Full text available.Received: (at 80025) by debbugs.gnu.org; 30 Dec 2025 19:27:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 30 14:27:42 2025 Received: from localhost ([127.0.0.1]:46956 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vafNd-0004Fx-Nx for submit <at> debbugs.gnu.org; Tue, 30 Dec 2025 14:27:42 -0500 Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]:44230) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1vafNb-0004Fb-Bm for 80025 <at> debbugs.gnu.org; Tue, 30 Dec 2025 14:27:40 -0500 Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-47796a837c7so66092795e9.0 for <80025 <at> debbugs.gnu.org>; Tue, 30 Dec 2025 11:27:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767122853; x=1767727653; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=5RRs2lbb3nyH8zf2XVYBUiqoSjNTuzY+n0/m6myDrnE=; b=JPqIyGdrC65LPuhxOKMQ5qai9elS9sGyoY6OrWDagilaJXlrCn2KywpJfGmT9tIwKy 34uzkQfch5ucSLgYQL16GcWqnL8y26WIfAEdMOU93tvF0VE61h4zImHh8VdiT5KctUPW w0r2nTXh95sMg7mG/wpYHl5pJHacRwqHTxvS+Le4yTsZUmv+a0HoOOtZg7E//z5sSRbC XrGRHU9S995mCISNTpk6RqV4PZK55wb6ox7N0HN0R0f3ES2BMTRgtImjRddIuEPALSll /5VmjPk8iuu5yVPkSSoH4LDfp9clH8ij4vVEUqc5ONE0lvsbTxwEKPV/ww+7C2oHV2kb irDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767122853; x=1767727653; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=5RRs2lbb3nyH8zf2XVYBUiqoSjNTuzY+n0/m6myDrnE=; b=vlI+kcIdmNV8w9d89NsgF1Ud5UZScOK3uws4HeatFxMmp6tqByTt/MVRKHOa2N5jP1 UsD3Yo+4vtK9ObG5HMRKYOMZhiJt0o8OQ1F0pFOeOAG7tnP3Bll1Fcv+ADfDeN72MFY7 CzlroGJ9ZsQCBt3NfQ4l4Z42CYHDHeX8Zis+A3FJqWfzUGBKpeMBDFQJSowW4/1Lrr17 9Uqri1FejXf6o4ZuMzb8v7Yi10pafZutZm/NXFY7PTQjns+ke1t/17nutNSa+cN+0oe/ u0k6+/KTbI3TnpHpVTD50a1g2Mby7/Dc/g8E1HispiIUXUnJYQe07C4M3CMKKR3Vkojp RxVQ== X-Forwarded-Encrypted: i=1; AJvYcCWjBd5lFnwaOpx0Icz0I6w3SJdNTkauUfQpkl8nwNbar8pTXPq6HEqmvIPTmTz0afOWpNsLFw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyCXu2CUIcd1qnFtEZgK7FbpVbXsftpUW2aqyUqa28vHhCR10qt 24vy5BlsIaLQECtRuXS7PFEdohtEsJkv0fIR7r0UNrJSmJCM1/50vesI2TAKFjei X-Gm-Gg: AY/fxX6JDVdCkCjE8wP9qh/j7Y6TTENegCbtfT+zrWC4Ox4TXXnzjYdtyDLbb3X+VLu ZGrnCoO4es1V5qAch3zhibq0tBrBSBrXBRlTcrEYWqDCM9vKh1cgRKqB6KO90ioZd5/PmOr+S/m EFPy0SULnnPHl0RtEkAh867jy4NFVgKkVx4DrfAbkTZLvSzQz9sc54Xm6MCXZiXSjmfM+dgMTTw oAk6ZIl9o7nHiOf39WL2gUTae0BP/jX6YAQrEnhK0SJvIXZeViJQ2u3WwN7LgeBqYO3beEDn20W 4yHmFDPKiHC6Y2ycE4IkNFKaATEcFPs3UQS52ukv/5WilAuDn4GnOO4geX/rSzI1bEL3+lFVsTv FeOzJgdZ0JNSVDyT2CZDmBRuKhJYR26ghQfqPQFcsjPh6x77vL22GoMEvGF+npgL3BYHADpslG0 jlDLmljAK/CxszYNRJ9e388CVNSjQMVceEgkeRfev8TfiXTpVyMvnZtLi9qZGvnbroYWitOzF+o UDQdPhyqjGpWEwptXl1NDY= X-Google-Smtp-Source: AGHT+IHL90Z9tKCPo7/WpJpRjbOHqk7h8eOL4aSjRhcQpRs2i8iXF5eQ4KVsY3h+xk1bE4KOyFZohg== X-Received: by 2002:a05:600c:8287:b0:479:3a89:121e with SMTP id 5b1f17b1804b1-47d1959d0cfmr344520755e9.37.1767122852870; Tue, 30 Dec 2025 11:27:32 -0800 (PST) Received: from pro4 (p200300e0b71c5800f5ab9ead2e2bd28f.dip0.t-ipconnect.de. [2003:e0:b71c:5800:f5ab:9ead:2e2b:d28f]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d19346e48sm594506885e9.2.2025.12.30.11.27.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Dec 2025 11:27:32 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Juri Linkov <juri@HIDDEN> Subject: Re: bug#80025: Margin columns In-Reply-To: <87ecob4zbz.fsf@HIDDEN> References: <87h5tpj7ch.fsf_-_@HIDDEN> <861pkt3q8e.fsf@HIDDEN> <87cy48nv4o.fsf@HIDDEN> <86ldiwxm9m.fsf@HIDDEN> <87qzsn9dgm.fsf@HIDDEN> <87y0mlkx31.fsf@HIDDEN> <86qzsdqhyi.fsf@HIDDEN> <m2344ssf8p.fsf@HIDDEN> <87y0mkju8d.fsf@HIDDEN> <m2v7hoqtcr.fsf@HIDDEN> <87ecob4zbz.fsf@HIDDEN> Date: Tue, 30 Dec 2025 20:27:31 +0100 Message-ID: <m2ms2zrcrg.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 80025 Cc: Eli Zaretskii <eliz@HIDDEN>, 80025 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Juri Linkov <juri@HIDDEN> writes: >>> Does V... in this code properly access buffer-local values? >> >> You could Fmake_variable_buffer_local these, for example. That's already >> the case for a number of other variables in xdisp.c. > > Thanks, I don't know why I missed this: I looked specially > for similar buffer-local variables, but didn't notice them =F0=9F=A4=B7= =E2=80=8D=E2=99=82=EF=B8=8F > > Now I recalled how we arrived to the current approach. > In https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D77313#179 > we tried to duplicate flymake overlays: one overlay for fringe, > and one separate overlay for margin. But flymake depends > on the 1:1 mapping between errors and overlays. > So needed to keep the existing design with one overlay per error. > > The same overlay duplication would be required for the shared overlay. > Simply deleting the text with an overlay won't remove the > margin indicator anymore, thus requiring adding after-change-functions > and manually updating the dedicated overlay with > concatenated indicators from all packages. > > So it seems there is no alternatives to the current approach. Thanks for the explanation. I'd still find the "first-class indicators" nicer, but it also doesn't matter that much, I guess.
bug-gnu-emacs@HIDDEN:bug#80025; Package emacs.
Full text available.
Received: (at 80025) by debbugs.gnu.org; 30 Dec 2025 19:25:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 30 14:25:58 2025
Received: from localhost ([127.0.0.1]:46952 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vafLx-0004Cf-UX
for submit <at> debbugs.gnu.org; Tue, 30 Dec 2025 14:25:58 -0500
Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]:54392)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>)
id 1vafLs-0004CK-VC
for 80025 <at> debbugs.gnu.org; Tue, 30 Dec 2025 14:25:55 -0500
Received: by mail-wr1-x42a.google.com with SMTP id
ffacd0b85a97d-430f57cd471so4980465f8f.0
for <80025 <at> debbugs.gnu.org>; Tue, 30 Dec 2025 11:25:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1767122746; x=1767727546; darn=debbugs.gnu.org;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=UpHSmmW64ZfgSYHY4WzAjmapycpr392yz48IR2Us2+U=;
b=QGt+iIr9ZXnxpzMZjNM5ei/OW0W/sBhpwAvKIt9eiNz5oawPb4MGnyOEM+yLTlOzz/
L30wJr6D/VdJ4He4mF5iCuHveZGhdVDECS//iYT3BCLOYd5xGk0wrLxzcuIPF/Q5ZBPC
FV353NIsQVovqYl6dBziwIYaAMsQKCxJQ45LUJebNo8O1oCNayhjgeS6UQQFUFpnDhuC
hOAk/6QoTRCNV5Ae+UUADLwxiQzCZPYIM1pHa6kRkMO9HGcMUoFQEc9NGfLi51dCzXwE
8h2k4YfbD/t3TI5BZ7RoMRMXijIzC0D16y9EIIFAzmzmvpU5YisYxe6s6cdgMRzMJ/ZT
PsAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1767122746; x=1767727546;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:x-gm-gg
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=UpHSmmW64ZfgSYHY4WzAjmapycpr392yz48IR2Us2+U=;
b=W8aoAh4UZcRLw3Mw3sVeB9NHgRI/lkXbWmY2CWjV4BMSIikg769Az7PguSlDBmjxQT
xwDLCINwmRA1Z/wHxtwpf6s1H/ajMgYRYVUlxPsmSzN5LDZuTxLeP05titjgFNWBvqJB
nheSbFr12+XsMlFcDau2QAbgOw3wXhsR2oeX2jpBKDeesb/c86dNLBh8gH91tUp4yLYa
NcEZlkQ6TOgZXPhIkYiKAkQ/s1qBsmJVdeYVUqHBcehyFnxVtpm9vpE0Oq2iphbTAcLm
QG9xwG5y0QgHoP8/F4jom93TgsN2IyR61nxvMnjQ691LsaD0Uvz6/mp8vtxZHmQxboXg
moGA==
X-Forwarded-Encrypted: i=1;
AJvYcCVYiak5nyXeMNKMIacEoRmJO/CT4+IALs2eRQvkXP/5PnXt1jBI5RYpvBAAOrjuLjBOnK5qPA==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yy8qAvR+W1Hw8wwhvzKaIj7pyYcna9MCAhjEo/XjXN5DWdpdKTd
MDJFqp/xObiykhf/cxqj1VcLLMfkNugdgPRQ9JPraaSLO21wptw+MWjACmjeVTpk
X-Gm-Gg: AY/fxX63q2IErXuH10CvJR8ez9vLukOZy82Zn3ZlD/rTx9BRZvjapal4sHpbx2PVbxv
8ma6ZK2KTCSjpH5+4XemJDLAaZ/1iWRm8NAxz/X2T6Vgp/wRy62PCGXBsmWZ/swwVhG6OE5wnXL
Vo1BJvVqU6lPxR6ILf1rGuyy1OOWiouAeiCPI8eUDRzpQPCx2mKX+aYl3+MKfUHymqsa7mKjtyC
t/27Rvf8NgYkrFSqQ+78+f+Ghp5WzrpyRCDpzbrI4AZHbBqW11MJJnbgELcNWYUyxUFeJH/Cl4e
Lt1wyZJF8lmAXEpVm/kSwIaN9NxD+nSswEzjHk381IhkT5Fn/4BRPhrAIq3gyGcCW5zKC5+U/9Q
nhIu6HiPzvC4u/Py2CmYgd/HnJWg9MPl9f1iZ70MXQD+0HjKUdc4mBn34YTtslwCNo1+a/DoL+x
s8+yCgkXBrQgHuVt6vQddw7RXT0HdehCAR1rMs/BPvbW6V30V2IyEX/6f3FDYqlLIp+Rug32vEM
E59vKFooBWrUL8N9OlLolA=
X-Google-Smtp-Source: AGHT+IGuvhbxh5EqTVgavoVjzHLrRnlFuJ+F/CNbIStqIhxcG3FnnQ0dsFOHRIuLXTRsN+ehM5OtWw==
X-Received: by 2002:a05:6000:601:b0:42f:bc61:d1e5 with SMTP id
ffacd0b85a97d-4324e4cbd6emr47784536f8f.15.1767122746050;
Tue, 30 Dec 2025 11:25:46 -0800 (PST)
Received: from pro4 (p200300e0b71c5800f5ab9ead2e2bd28f.dip0.t-ipconnect.de.
[2003:e0:b71c:5800:f5ab:9ead:2e2b:d28f])
by smtp.gmail.com with ESMTPSA id
ffacd0b85a97d-4324eab2a94sm70444588f8f.43.2025.12.30.11.25.44
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Tue, 30 Dec 2025 11:25:44 -0800 (PST)
From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: Juri Linkov <juri@HIDDEN>
Subject: Re: bug#80025: Margin columns
In-Reply-To: <87ecob4zbz.fsf@HIDDEN>
References: <87h5tpj7ch.fsf_-_@HIDDEN> <861pkt3q8e.fsf@HIDDEN>
<87cy48nv4o.fsf@HIDDEN> <86ldiwxm9m.fsf@HIDDEN>
<87qzsn9dgm.fsf@HIDDEN> <87y0mlkx31.fsf@HIDDEN>
<86qzsdqhyi.fsf@HIDDEN> <m2344ssf8p.fsf@HIDDEN>
<87y0mkju8d.fsf@HIDDEN> <m2v7hoqtcr.fsf@HIDDEN>
<87ecob4zbz.fsf@HIDDEN>
Date: Tue, 30 Dec 2025 20:25:43 +0100
Message-ID: <m2qzsbrcug.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 80025
Cc: Eli Zaretskii <eliz@HIDDEN>, 80025 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Juri Linkov <juri@HIDDEN> writes:
>>> Does V... in this code properly access buffer-local values?
>>
>> You could Fmake_variable_buffer_local these, for example. That's already
>> the case for a number of other variables in xdisp.c.
>
> Thanks, I don't know why I missed this: I looked specially
> for similar buffer-local variables, but didn't notice them =F0=9F=A4=B7=
=E2=80=8D=E2=99=82=EF=B8=8F
>
> Now I recalled how we arrived to the current approach.
> In https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D77313#179
> we tried to duplicate flymake overlays: one overlay for fringe,
> and one separate overlay for margin. But flymake depends
> on the 1:1 mapping between errors and overlays.
> So needed to keep the existing design with one overlay per error.
>
> The same overlay duplication would be required for the shared overlay.
> Simply deleting the text with an overlay won't remove the
> margin indicator anymore, thus requiring adding after-change-functions
> and manually updating the dedicated overlay with
> concatenated indicators from all packages.
>
> So it seems there is no alternatives to the current approach.
>
> In addition to the above fixes in commit 3ff8f30f838,
> I also tried to fix term.c in commit 996b2304e59.
>
> Please take a look.
Hm, regarding append_glyph, I don't understand this:
term.c:
1591 handled_column =3D true;
1592 nglyphs =3D 1;
^^^^^^^^^^^
It->pixel_width here shojld be the number of glyphs we must append here,
for it->c, and it is > 1 for wide characters. If it is > 1, this means
the tty will output something that is that number of character cells (=3D
pixels) wide and then move the cursor to the end of the character. If we
always append just 1 glyph, Emacs' idea where the cursor is might differ
from tty's idea when wide characters are involved.
That's at least my understanding.
1593 }
1594=20
1595 if (!handled_column)
The if above I'd find easier to follow if it were an else, which it is.
term.c:
1617 }
1618 else
1619 end =3D it->glyph_row->glyphs[1 + area];
and the else here would be in the other arm of the if.=20
bug-gnu-emacs@HIDDEN:bug#80025; Package emacs.
Full text available.Received: (at 80025) by debbugs.gnu.org; 30 Dec 2025 18:14:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 30 13:14:07 2025 Received: from localhost ([127.0.0.1]:46772 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vaeEP-0000UC-OO for submit <at> debbugs.gnu.org; Tue, 30 Dec 2025 13:14:07 -0500 Received: from mout-p-103.mailbox.org ([2001:67c:2050:0:465::103]:52808) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1vaeEA-0000RF-TD for 80025 <at> debbugs.gnu.org; Tue, 30 Dec 2025 13:13:55 -0500 Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:b231:465::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-103.mailbox.org (Postfix) with ESMTPS id 4dgh6Z6fnzz9scY; Tue, 30 Dec 2025 19:13:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkov.net; s=MBO0001; t=1767118423; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8wS/qCsK8PROj4elOEcJScvxa0RYwURTHRRUi2CWwII=; b=AY587GztwAGaDa48qhXPqFoP+4j/CLmZH7j9n6yiv1ofJ8CqmT4pM0nCPKpN3X106QOFJi 1ny7x4NqK2scFVZUDEOesXYPuV1IaY24AYobqR4LxMhWjycc2vRTCJ6EQJY98bwSeiKlkv EBFcZDJ02LOIH4VVpisEBsqYssF8piyFPjenRoOd9OgcAIVK7ScSxR3PfpdyaZyhPQTxYM hWJ5TxBKYRfl2znGgfapnt3/gvdYj5l2/LY0evlxNJpwyi7GB/2gDzfLh3FBUZPOkq1PNw fWa5xxkuiPUF2hlQ/x2xJO0rK1VVo1GaxoffPj+681BpWkpd3lOgS3GVGZUVBw== Authentication-Results: outgoing_mbo_mout; dkim=none; spf=pass (outgoing_mbo_mout: domain of juri@HIDDEN designates 2001:67c:2050:b231:465::1 as permitted sender) smtp.mailfrom=juri@HIDDEN From: Juri Linkov <juri@HIDDEN> To: Gerd =?iso-8859-1?Q?M=F6llmann?= <gerd.moellmann@HIDDEN> Subject: Re: bug#80025: Margin columns In-Reply-To: <m2v7hoqtcr.fsf@HIDDEN> Organization: LINKOV.NET References: <87h5tpj7ch.fsf_-_@HIDDEN> <861pkt3q8e.fsf@HIDDEN> <87cy48nv4o.fsf@HIDDEN> <86ldiwxm9m.fsf@HIDDEN> <87qzsn9dgm.fsf@HIDDEN> <87y0mlkx31.fsf@HIDDEN> <86qzsdqhyi.fsf@HIDDEN> <m2344ssf8p.fsf@HIDDEN> <87y0mkju8d.fsf@HIDDEN> <m2v7hoqtcr.fsf@HIDDEN> Date: Tue, 30 Dec 2025 20:08:32 +0200 Message-ID: <87ecob4zbz.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4dgh6Z6fnzz9scY X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 80025 Cc: Eli Zaretskii <eliz@HIDDEN>, 80025 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) >> Does V... in this code properly access buffer-local values? > > You could Fmake_variable_buffer_local these, for example. That's already > the case for a number of other variables in xdisp.c. Thanks, I don't know why I missed this: I looked specially for similar buffer-local variables, but didn't notice them 🤷♂️ Now I recalled how we arrived to the current approach. In https://debbugs.gnu.org/cgi/bugreport.cgi?bug=77313#179 we tried to duplicate flymake overlays: one overlay for fringe, and one separate overlay for margin. But flymake depends on the 1:1 mapping between errors and overlays. So needed to keep the existing design with one overlay per error. The same overlay duplication would be required for the shared overlay. Simply deleting the text with an overlay won't remove the margin indicator anymore, thus requiring adding after-change-functions and manually updating the dedicated overlay with concatenated indicators from all packages. So it seems there is no alternatives to the current approach. In addition to the above fixes in commit 3ff8f30f838, I also tried to fix term.c in commit 996b2304e59. Please take a look.
bug-gnu-emacs@HIDDEN:bug#80025; Package emacs.
Full text available.Received: (at 80025) by debbugs.gnu.org; 30 Dec 2025 08:14:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 30 03:14:39 2025 Received: from localhost ([127.0.0.1]:42516 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vaUsJ-0004o0-41 for submit <at> debbugs.gnu.org; Tue, 30 Dec 2025 03:14:39 -0500 Received: from mail-ed1-x529.google.com ([2a00:1450:4864:20::529]:56441) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1vaUsG-0004nL-3R for 80025 <at> debbugs.gnu.org; Tue, 30 Dec 2025 03:14:36 -0500 Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-64b61f82b5fso12993318a12.0 for <80025 <at> debbugs.gnu.org>; Tue, 30 Dec 2025 00:14:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767082470; x=1767687270; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=fVQor1qCyhU+c4S81lc3jB93PhHjTarIbN9hMjyt+gE=; b=aKZnJCs4dbM66blNRMH1Vj4RF2WU4IWx0FosUaLGAUqFPO+Y+gBE+qzYTK10lJ3oEb eSM8bnohCaSkrY2ceLvCyaCUZu2+4W/1OBftSOV2WiqXlrK2rYoqiiAj/CdTSW0wNsZP reauFqDeSkZrd2YLnHgtKmbVPGc7Xpp98MWDx3c6YS3gwquEcH40QufrkgrOlkOA+0pr KB46MG9Flj2oIJwUSVKcE/qO5ptsXlMEpIRuC66npyaxDd8iHXfL1RiyGyo4Q+/LBW9y D8VME9EPJSEiDzxZ7IKLbbe9Ezk6yi5o/LdjKAmXaOToohLnS5y6ndxrFIztB6+MInKb Q7cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767082470; x=1767687270; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=fVQor1qCyhU+c4S81lc3jB93PhHjTarIbN9hMjyt+gE=; b=fY1RtYznZXFiIXbmlpiMabenFP3DCQdnn/Pvffr7jNyjftPEyEvhEigQSLKdVpYl8A kg/iVn1pcETHvr2W/viiKhVY6OMEb0BgTm+MuU400SchLNo+a8o9fuSIXTS3vxqFPZRC 9nAM4Q1/J+VrsEnFCnAyyl3+RymA7cjVFh3KhDQBqfn9nWHZ/QRsNj7V7JAyY3bqJ89j rb6ChElcpQJLiSmN75sBhaoosjY/iQh6lINMXzeOUwY9lWNld9QgZ4GRHG1mNZg4z93d wATGPGmUzLeUijr/dogbRI67HWy5MBMPR/HS3t5g5ZpFfBkAatmKpN6MuLvHKzNCpfRi CGOQ== X-Forwarded-Encrypted: i=1; AJvYcCU/qs2WZJXepsdwBLglVBybYyT3qk8dGB3kyJer5iaAyjPI77VHVVr/vT9dkNaI6rPKqLSSmw==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yzd4avCZkThfwWTfUG1NHrMhO5ybruxcxivRs3PD1Tmow4Q+C86 RP0SlCTSIng19zGcMiMeGDsppZzxkKTMWan9ZuGMil2iKx8JQwH4xcfOA7JozFLC X-Gm-Gg: AY/fxX58iQ4AnsuHePK7QqrbfSVhFksYem8PV2eoaTkH/1GDkvOpQD6M4WtVS/nTvDD if/VDNoUBbdu6Xv4kV70exH7hUeWgs6pqTnSl2A03thh0gPucrC8DNmQtxMTJRSG3bbkwVCvx2N jmXpUus/epnAl/iPQYFz6PnVKvXxYNVZfIr8cw3j9PhAdhi1VH8zlDZDZArADTV53OeC+CBTI/h zYW/2STuZAMGBxoFCMIGbL7H6mZW+KpnClBw3ed6ZwKLAHJGNRJwXbwq9siDUHjNbm9wMxL7l+J dZfkMVFgXcpDWZUQzA/wLEvmrcO8gXYNGXXEsHWY3EEZN7Lwa1Fh0a17Ab6nrOg5XV0parRXbb8 /ZYEorXiRXNp4Z/K1ew4ZrQc8g3P26REuNVfnm09v1U1doxcfE22Ap5Zt3Jn1fH2pJq/kex0pbc vYkQLj8Bhy3CRC+Lkwh9Ncr//OfqPDEdQoioMIo2SzsgYdL4SXu+gfxsSClGdovribQxGucrdiA SykPN0zC/HFBtV6IcvN7os= X-Google-Smtp-Source: AGHT+IFSObmM0G4loaaEncUqBqG+haheXdjB4vKGgavLVuazmpl0KldKwqWbEyxfGQ54abxAHVQo6A== X-Received: by 2002:a05:6402:2806:b0:649:9159:243d with SMTP id 4fb4d7f45d1cf-64b8ec9cf53mr28631813a12.22.1767082469539; Tue, 30 Dec 2025 00:14:29 -0800 (PST) Received: from pro4 (p200300e0b71c5800f5ab9ead2e2bd28f.dip0.t-ipconnect.de. [2003:e0:b71c:5800:f5ab:9ead:2e2b:d28f]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-64b90f5400bsm33960753a12.4.2025.12.30.00.14.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Dec 2025 00:14:28 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Juri Linkov <juri@HIDDEN> Subject: Re: bug#80025: Margin columns In-Reply-To: <87y0mkju8d.fsf@HIDDEN> References: <87h5tpj7ch.fsf_-_@HIDDEN> <861pkt3q8e.fsf@HIDDEN> <87cy48nv4o.fsf@HIDDEN> <86ldiwxm9m.fsf@HIDDEN> <87qzsn9dgm.fsf@HIDDEN> <87y0mlkx31.fsf@HIDDEN> <86qzsdqhyi.fsf@HIDDEN> <m2344ssf8p.fsf@HIDDEN> <87y0mkju8d.fsf@HIDDEN> Date: Tue, 30 Dec 2025 09:14:28 +0100 Message-ID: <m2v7hoqtcr.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 80025 Cc: Eli Zaretskii <eliz@HIDDEN>, 80025 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Juri Linkov <juri@HIDDEN> writes: > Does V... in this code properly access buffer-local values? You could Fmake_variable_buffer_local these, for example. That's already the case for a number of other variables in xdisp.c.
bug-gnu-emacs@HIDDEN:bug#80025; Package emacs.
Full text available.
Received: (at 80025) by debbugs.gnu.org; 30 Dec 2025 07:55:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 30 02:55:14 2025
Received: from localhost ([127.0.0.1]:42407 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vaUZV-00039c-Q5
for submit <at> debbugs.gnu.org; Tue, 30 Dec 2025 02:55:14 -0500
Received: from mout-p-102.mailbox.org ([2001:67c:2050:0:465::102]:56640)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1vaUZR-00032Z-66
for 80025 <at> debbugs.gnu.org; Tue, 30 Dec 2025 02:55:09 -0500
Received: from smtp1.mailbox.org (smtp1.mailbox.org [10.196.197.1])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(No client certificate requested)
by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4dgQNg4XqQz9v83;
Tue, 30 Dec 2025 08:54:59 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkov.net; s=MBO0001;
t=1767081299;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
in-reply-to:in-reply-to:references:references;
bh=C0VLYjUzL5FU7HuvhU3VVq5StEn+Jvq+TJS74em7s7I=;
b=0QNL+f2D3qCN1GhzGYp25MAW8+KH9VjwDzhWo6n62Qtm5nECFId5dBZ2pfehjZC9Z0rZEg
tS1LisxCkK48ZSDx2WN6ILrUknWgOi/reBNvhuiWD87+hgW0Qyg6l+u34nnVLQ6ry+HzkI
3LFYr5aun4UeTEF7D2ohLa3apLBSIBQuvMb/3C9D0ayeSRaYFUeFuFRPljcrIus7J1rhvQ
mKgLg1HFw9vXc6zAN+thP1zolU0nLXBQXZotO8j0Fjtzec91EBvWRxU+m1i0CHntttLlvU
Hp7AK1QaholTBQ5+EvD4w/iktfuLaT8AXEoRLvUn5QasJ64AExIiF9Mz9ohnWw==
From: Juri Linkov <juri@HIDDEN>
To: Gerd =?iso-8859-1?Q?M=F6llmann?= <gerd.moellmann@HIDDEN>
Subject: Re: bug#80025: Margin columns
In-Reply-To: <m2344ssf8p.fsf@HIDDEN>
Organization: LINKOV.NET
References: <87h5tpj7ch.fsf_-_@HIDDEN> <861pkt3q8e.fsf@HIDDEN>
<87cy48nv4o.fsf@HIDDEN> <86ldiwxm9m.fsf@HIDDEN>
<87qzsn9dgm.fsf@HIDDEN> <87y0mlkx31.fsf@HIDDEN>
<86qzsdqhyi.fsf@HIDDEN> <m2344ssf8p.fsf@HIDDEN>
Date: Tue, 30 Dec 2025 09:47:22 +0200
Message-ID: <87y0mkju8d.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 80025
Cc: Eli Zaretskii <eliz@HIDDEN>, 80025 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
> First of all, TBH, I'm not a big fan of the approach.
>
> No doubt it can be made to work, and probably does work already in most
> cases, but I get the feeling that it is a bit ad-hoc, put at the lowest
> level possible, and pushes something into the display engine that is
> only useful for one use-case, indicators. It leaves me with the doubt if
> this couldn't have been done in Lisp somehow.
>
> Anyway, can I ask if other solutions have been considered? I'm thinking
> maybe something making "indicators" a first-class "thing" with an API,
> maybe managing one overlay per line used by multiple clients or
> whatever. I couldn't find anything on emacs-devel, as usual.
One overlay per line would require too much coordination between packages
to update the same overlay at the beginning of the line.
While the proposed approach requires minimal changes in existing packages.
So I'm not sure in what direction it should be balanced: more changes
in packages or more changes in core?
> Be that as it may, had to say that because once a feature is in it tends
> to stay there forever :-).
This feature is optional, so should not cause too much hassle.
> Here are the things I've seen while reading the code
>
> xdisp.c:
> 6413 if (FIXNUMP (tem) && XFIXNUM (tem) >= 0)
>
> FIXNATP?
Thanks, will fix.
> xdisp.c:
> 6415 else if (SYMBOLP (tem))
> 6416 {
> 6417 Lisp_Object columns_list = Fsymbol_value
> 6418 (EQ (location, Qleft_margin)
> 6419 ? Qleft_margin_columns : Qright_margin_columns);
>
> I think the Fsymbol_value is not needed. Just use the V... variables,
> and the Q... can then go.
Does V... in this code properly access buffer-local values?
Lisp_Object columns_list = EQ (location, Qleft_margin)
? Vleft_margin_columns : Vright_margin_columns;
> Another question is if a position in a list is the right thing. What if
> someone wants more then 1 column? One could also use a symbol property,
> maybe.
I've already thought about that: later a symbol in the list
could be turned into such format (SYMBOL . WIDTH).
> term.c<feature-margin-columns>:
> 1590 /* Do the same glyph filling as below and return. */
> 1591 if (glyph < end)
> 1592 {
> 1593 glyph->type = CHAR_GLYPH;
> 1594 glyph->pixel_width = 1;
> 1595 glyph->u.ch = it->char_to_display;
> 1596 glyph->frame = it->f;
> 1597 glyph->face_id = it->face_id;
> 1598 glyph->avoid_cursor_p = it->avoid_cursor_p;
> 1599 glyph->multibyte_p = it->multibyte_p;
> 1600 glyph->padding_p = false;
>
> The iterator may contain a wide character (it->pixel_width > 1), which
> means that printing that character will move the cursor by more than 1
> column (Chinese characters, for instance, or some Unicode symbols). In
> that case, N glyphs are produced where the first is for the character
> itself and the rest have padding_p set, and are placeholders for what
> the terminal does.
>
> This should be done like further down in the for-loop.
>
> term.c<feature-margin-columns>:
> 1643 for (i = 0;
> 1644 i < it->pixel_width && glyph < end;
> 1645 ++i)
> 1646 {
> ...
> 1654 glyph->padding_p = i > 0;
>
> Kudos if you extract that into a function somehow :-).
This is easy to do: instead of duplicating code above and returning,
it could continue to the loop above while using an if-condition
such as 'if (!handled_margin_column)' where necessary.
So could do this only after reconsidering other approaches.
bug-gnu-emacs@HIDDEN:bug#80025; Package emacs.
Full text available.Received: (at 80025) by debbugs.gnu.org; 30 Dec 2025 07:55:05 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 30 02:55:05 2025 Received: from localhost ([127.0.0.1]:42398 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vaUZM-00033d-He for submit <at> debbugs.gnu.org; Tue, 30 Dec 2025 02:55:05 -0500 Received: from mout-p-201.mailbox.org ([80.241.56.171]:51124) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1vaUZJ-000322-Sc for 80025 <at> debbugs.gnu.org; Tue, 30 Dec 2025 02:55:02 -0500 Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4dgQNZ2Vzcz9tKj; Tue, 30 Dec 2025 08:54:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkov.net; s=MBO0001; t=1767081294; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=vLgk43cshIANzH8Vje+NCRtc7jkeE+vNHtHgizl/AW8=; b=aWjhpJE2fCDtZxKVvaRTvgdlgRYfRcAqMsOi7PkAJAY5RYrEMYXWircfDaGxcGB8FDkuqb AXmIUE6fCARGR+6HIasMTbWNtn2erfhTHFUs57Y1dcxuQO5k27D55oncYmh5oAyTbN54kH jW1jLw8G3S9ZDpXT5KUNE2/IyZN8ZdavFnUKhGyaIkWNN20h7dTldhAhUjh+gxt3X+QbqJ cICSR5mIm/grEDIALZ+lCYMWrKh9xY0uCbszUF7rWZBike5ep5uNHIZyPlaHr5i81If8ce R/NM6LX9hNuEVisCA2HCtMyKibeMKiH+fcTGcOGYl6NVB6yAhv0rNFBwQ773rQ== From: Juri Linkov <juri@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80025: Margin columns In-Reply-To: <86qzsdqhyi.fsf@HIDDEN> Organization: LINKOV.NET References: <87h5tpj7ch.fsf_-_@HIDDEN> <861pkt3q8e.fsf@HIDDEN> <87cy48nv4o.fsf@HIDDEN> <86ldiwxm9m.fsf@HIDDEN> <87qzsn9dgm.fsf@HIDDEN> <87y0mlkx31.fsf@HIDDEN> <86qzsdqhyi.fsf@HIDDEN> Date: Tue, 30 Dec 2025 09:34:07 +0200 Message-ID: <87qzscmofu.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 80025 Cc: Gerd =?iso-8859-1?Q?M=F6llmann?= <gerd.moellmann@HIDDEN>, 80025 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) >> It seems the branch 'feature/margin-columns' is ready for merging to master >> (modulo the documentation). Everything works as designed. For example: >> >> - 'M-x flymake-mode' adds a margin column for flymake errors/warnings >> - 'M-x outline-minor-mode' adds a margin column for outline arrows >> - 'M-x hs-minor-mode' adds a margin column for hideshow indicators >> >> - 'M-x flymake-mode' again removes the first column >> - 'M-x hs-minor-mode' removes the third column >> - 'M-x outline-minor-mode' removes the remaining column >> >> The column order can be changed by the users using mode hooks >> by reordering the mode symbols in the new variables >> 'left-margin-columns' and 'right-margin-columns'. > > Thanks, but what about documenting this new feature of the 'display' > property? We cannot leave it undocumented, can we? Will add the documentation as well. > Finally, can you describe how you tested this and on what terminal > types? This was tested on X and tty. And here are complete settings for testing: (setopt flymake-indicator-type 'margins outline-minor-mode-use-buttons 'in-margins hs-show-indicators t hs-indicator-type 'margin)
bug-gnu-emacs@HIDDEN:bug#80025; Package emacs.
Full text available.
Received: (at 80025) by debbugs.gnu.org; 30 Dec 2025 05:36:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 30 00:36:33 2025
Received: from localhost ([127.0.0.1]:41647 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vaSPJ-0000eP-B7
for submit <at> debbugs.gnu.org; Tue, 30 Dec 2025 00:36:33 -0500
Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]:55597)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>)
id 1vaSPG-0000dy-5e
for 80025 <at> debbugs.gnu.org; Tue, 30 Dec 2025 00:36:31 -0500
Received: by mail-wm1-x32e.google.com with SMTP id
5b1f17b1804b1-4779cc419b2so75158155e9.3
for <80025 <at> debbugs.gnu.org>; Mon, 29 Dec 2025 21:36:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1767072984; x=1767677784; darn=debbugs.gnu.org;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
bh=hjhh18Asa5HqJhrDsl7Et4RByRuSJMTnBo9R7Ou9IG4=;
b=T1hCxI4qNYHJFBakb8QEzYSY61I/SmO8Vw6yILkgOeXaQrJsj9Pq5IRzhJZRtl/e7T
QVvftOX9cVHlp2AsNXTGWrvZOCqNMaB/ldU2o15rdzeao4AujF9hbRxwihuiEnpM4f+L
mZqSbpRKsqVumID9Cw/HGg+c/Nr0QHM5uvd3mq4+L3OEU4IVYl9V4VYNFCv+/UzOR1nk
Q4tkpvjiCQ5+Qe2wQG1FNvrQ0OxQeBAzxQ/2RQ+sPMmWWt0PzB9hx3E+9NPvMQTMoR5Q
anP2Xf2aqYIZIZvAkWwBkgepx5T8wWNxBrHIUZRDxrLkJC+0OBtVt/fqXW8eCs5mprG6
pNlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1767072984; x=1767677784;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject
:date:message-id:reply-to;
bh=hjhh18Asa5HqJhrDsl7Et4RByRuSJMTnBo9R7Ou9IG4=;
b=JF+P+2HbSxE8NOPfiNC9L9MhVwxsHJ6aS61vF1jSN0S9myD3fWOMrgknfR0PsOGSu9
sX5w87qZwjm1DSVB+8hiotycKifWWZ8Drt9o0txJ4Lom9+UFD7Qx+LWqu2sbDj+pZKwB
9pzbdTdfOujD3F+NSRODhd7EQOnl7MNEXbc9W/oOrxypd8TSvSqL1loBhZaamYunDshV
iexGKrGki0Ohp+Apr7R6EI9MQg+tgCCGU4cH8rQNmtQs3oWiugn7BWXB7xYnX1Hmerw0
zjI8EFJdPG0rzzMHHpTBWvCltYp7B9BeTl7oNXSJO8f2qdVwLuNDj5aS38SrF3cNYBOu
FjyQ==
X-Forwarded-Encrypted: i=1;
AJvYcCVApSAiBJIz2OSerXtl+7OjwLkKzhNw8qxo2xH7c3ZOeKAepoextddXYZ/Ht35Cey+P2vKBQw==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Ywj8zQ3MmoyfM29Thhr2ZHAZCzX4OsGhY/bHGH0nEM0u5k0wZsX
mN5Ym1Al7xkMn82CaeCQIQmn8686kYFB0LPnD1asgTktjz2On/4y9nM/jeV5Zg==
X-Gm-Gg: AY/fxX4xH527zaL/8cg3N4gJhv4r2SV68DWMOrGShFZY7Yy+RZVBgT9RFcwcJo43s7F
hsdyXxjuM0T77SEtcNWy39bAzCxK+yKQsxc7UqSEtKaORuvH1b9o+RDBdkuVUSK8ziBm/0BLuu1
2p+BpNiTWh35qiQyWANRSde+TfmODtfgzViEARd/cPbrF+N/XDh5Vg5ycui0FxXSzxSxX6Aielm
5l4OCkzTP9ZkoKBc3Fb9fjraJKK7kpWIkFbK9be5hfyplsrmRRGmAdgwV8GVBCDFGBFwsKtm5ED
kXJ6orBqpS+Un2SCxWviFrz1ntZAZR/SftL1K5uSEzuhcEnmbXQbUX+dmXCKVp0KbK8UxXXFW8f
Ppc9wgTmkSDx2HUDhQ6eYMLui4uE1yLA0OIumk79UwcxNuomlpVI4NXz6z5CYtl60Ll5Z30w/UO
mlwv1MHP8u7v0YkUL9dE0jcYdtKVAmLBvo07MlP6qU17KC7hKMOcaAOM1mMvupyn6CuWXEKRIsS
PgTwn34zehm4tKziNeKOzw=
X-Google-Smtp-Source: AGHT+IGK2FP/odQOfKqPD+lyS375nlsMtPzfWc1WE9+CCrQPmyRQHL6TFN7OQw+hC/hv8HafwL0gVQ==
X-Received: by 2002:a05:600c:348a:b0:46e:1a5e:211 with SMTP id
5b1f17b1804b1-47d1958a755mr404475855e9.21.1767072983565;
Mon, 29 Dec 2025 21:36:23 -0800 (PST)
Received: from pro4 (p200300e0b71c5800f5ab9ead2e2bd28f.dip0.t-ipconnect.de.
[2003:e0:b71c:5800:f5ab:9ead:2e2b:d28f])
by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-47d193d4e91sm559385175e9.13.2025.12.29.21.36.22
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 29 Dec 2025 21:36:22 -0800 (PST)
From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#80025: Margin columns
In-Reply-To: <86qzsdqhyi.fsf@HIDDEN>
References: <87h5tpj7ch.fsf_-_@HIDDEN> <861pkt3q8e.fsf@HIDDEN>
<87cy48nv4o.fsf@HIDDEN> <86ldiwxm9m.fsf@HIDDEN>
<87qzsn9dgm.fsf@HIDDEN> <87y0mlkx31.fsf@HIDDEN>
<86qzsdqhyi.fsf@HIDDEN>
Date: Tue, 30 Dec 2025 06:36:22 +0100
Message-ID: <m2344ssf8p.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 80025
Cc: 80025 <at> debbugs.gnu.org, Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Eli Zaretskii <eliz@HIDDEN> writes:
> I'd also like to ask Gerd to please review the changes and provide any
> comments, if he could spare the time.
I've read the messages in the bug, some messages on emacs-devel about
"shared margins", and at least some of the code. Not in every detail,
I trust that's not necessary.
First of all, TBH, I'm not a big fan of the approach.
No doubt it can be made to work, and probably does work already in most
cases, but I get the feeling that it is a bit ad-hoc, put at the lowest
level possible, and pushes something into the display engine that is
only useful for one use-case, indicators. It leaves me with the doubt if
this couldn't have been done in Lisp somehow.
Anyway, can I ask if other solutions have been considered? I'm thinking
maybe something making "indicators" a first-class "thing" with an API,
maybe managing one overlay per line used by multiple clients or
whatever. I couldn't find anything on emacs-devel, as usual.
Be that as it may, had to say that because once a feature is in it tends
to stay there forever :-). Here are the things I've seen while reading
the code
xdisp.c:
6413 if (FIXNUMP (tem) && XFIXNUM (tem) >= 0)
FIXNATP?
xdisp.c:
6415 else if (SYMBOLP (tem))
6416 {
6417 Lisp_Object columns_list = Fsymbol_value
6418 (EQ (location, Qleft_margin)
6419 ? Qleft_margin_columns : Qright_margin_columns);
I think the Fsymbol_value is not needed. Just use the V... variables,
and the Q... can then go.
Another question is if a position in a list is the right thing. What if
someone wants more then 1 column? One could also use a symbol property,
maybe.
term.c<feature-margin-columns>:
1590 /* Do the same glyph filling as below and return. */
1591 if (glyph < end)
1592 {
1593 glyph->type = CHAR_GLYPH;
1594 glyph->pixel_width = 1;
1595 glyph->u.ch = it->char_to_display;
1596 glyph->frame = it->f;
1597 glyph->face_id = it->face_id;
1598 glyph->avoid_cursor_p = it->avoid_cursor_p;
1599 glyph->multibyte_p = it->multibyte_p;
1600 glyph->padding_p = false;
The iterator may contain a wide character (it->pixel_width > 1), which
means that printing that character will move the cursor by more than 1
column (Chinese characters, for instance, or some Unicode symbols). In
that case, N glyphs are produced where the first is for the character
itself and the rest have padding_p set, and are placeholders for what
the terminal does.
This should be done like further down in the for-loop.
term.c<feature-margin-columns>:
1643 for (i = 0;
1644 i < it->pixel_width && glyph < end;
1645 ++i)
1646 {
...
1654 glyph->padding_p = i > 0;
Kudos if you extract that into a function somehow :-).
bug-gnu-emacs@HIDDEN:bug#80025; Package emacs.
Full text available.Received: (at 80025) by debbugs.gnu.org; 29 Dec 2025 18:08:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 29 13:08:44 2025 Received: from localhost ([127.0.0.1]:38730 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vaHff-0004Ig-PN for submit <at> debbugs.gnu.org; Mon, 29 Dec 2025 13:08:44 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:53986) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vaHfd-0004IS-Au for 80025 <at> debbugs.gnu.org; Mon, 29 Dec 2025 13:08:42 -0500 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 <eliz@HIDDEN>) id 1vaHfX-0008GW-BK; Mon, 29 Dec 2025 13:08:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=YcAUq+RXWDqFO4SebNrAeIq+acgSFkjbCaH3T9Ql2vY=; b=E3KUvLrM6T/UU4R8RYbu GQ3o/CKyjBTOCuIjlBgbgdPppN6OS64SA/UNmEVB8rWpPosR95V6+bACn2U3EMW460Ip6FyrEEldj Wa04sVq40RLIK5E6RIdyHp6QMDBuM7zyGSbcQ462kZK1tAPrc6xZQAEwfq6pIBIdEdJu5nmhThvEA O5CyaaM8HWSwiMGy9L/KRFgsOJeVPfluMPfisVHC17wjzFzs4cq03UH79EDZzn8wbqRpn+Yv0l838 dG8pXIffGEkluVsZvAZ0wjMDV4Y0LeEArjBJPAU1SkEMK/PrkQXABFk7urAG1/qXRRxrAGc3jtI4l Ch1sz8MCRa0R0w==; Date: Mon, 29 Dec 2025 20:08:21 +0200 Message-Id: <86qzsdqhyi.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Juri Linkov <juri@HIDDEN>, =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> In-Reply-To: <87y0mlkx31.fsf@HIDDEN> (message from Juri Linkov on Mon, 29 Dec 2025 19:38:10 +0200) Subject: Re: bug#80025: Margin columns References: <87h5tpj7ch.fsf_-_@HIDDEN> <861pkt3q8e.fsf@HIDDEN> <87cy48nv4o.fsf@HIDDEN> <86ldiwxm9m.fsf@HIDDEN> <87qzsn9dgm.fsf@HIDDEN> <87y0mlkx31.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80025 Cc: 80025 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Juri Linkov <juri@HIDDEN> > Cc: 80025 <at> debbugs.gnu.org > Date: Mon, 29 Dec 2025 19:38:10 +0200 > > It seems the branch 'feature/margin-columns' is ready for merging to master > (modulo the documentation). Everything works as designed. For example: > > - 'M-x flymake-mode' adds a margin column for flymake errors/warnings > - 'M-x outline-minor-mode' adds a margin column for outline arrows > - 'M-x hs-minor-mode' adds a margin column for hideshow indicators > > - 'M-x flymake-mode' again removes the first column > - 'M-x hs-minor-mode' removes the third column > - 'M-x outline-minor-mode' removes the remaining column > > The column order can be changed by the users using mode hooks > by reordering the mode symbols in the new variables > 'left-margin-columns' and 'right-margin-columns'. Thanks, but what about documenting this new feature of the 'display' property? We cannot leave it undocumented, can we? I'd also like to ask Gerd to please review the changes and provide any comments, if he could spare the time. (I myself will also try to do that, but I'm afraid I won't have time for this soon enough, and I don't want to hold the merge due to my personal problems.) Finally, can you describe how you tested this and on what terminal types? Thanks for working on this feature.
bug-gnu-emacs@HIDDEN:bug#80025; Package emacs.
Full text available.Received: (at 80025) by debbugs.gnu.org; 29 Dec 2025 17:39:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 29 12:39:23 2025 Received: from localhost ([127.0.0.1]:38622 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vaHDG-00008P-Qf for submit <at> debbugs.gnu.org; Mon, 29 Dec 2025 12:39:23 -0500 Received: from mout-p-101.mailbox.org ([80.241.56.151]:34006) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1vaHDE-00008C-L7 for 80025 <at> debbugs.gnu.org; Mon, 29 Dec 2025 12:39:21 -0500 Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:b231:465::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4dg3PD5W0Jz9tJC; Mon, 29 Dec 2025 18:39:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkov.net; s=MBO0001; t=1767029952; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=W7P/hgtMF5+CHtNQxzts/W8zozX9GmqLEGMtDO2/F3E=; b=oEJ5yXRZOG+o0SRbujZ6XtT7vpkB+gL8BxEL9kSJKET2SQnU3RUGB2Ltk3TEEIdYMHJMDH Npsya/Cgzm1rgmqQIUbjzITPg8g9dgf+SLyF/ydaBaj17c5SKU+B4WxaSN5k+DDD1eKo8Y VbM3iHXiV/RnM/tgwpSk+O4jm3tllekjc2IeNCXhiO3SKHxOlXSk8GD9+I2fa0OE4B9bx2 2lc9tpqWrrXhYvMPORiOt5AOw0PXDDpLqxFbbpl1kJs9g+PKmD2bL6RB7KOVQot/QJG/uK ywogpEiQFBRYfZahKFDbkGtDWofZlktpyp0QdvWzEsarC0QAXqkaBqiiLOztYg== Authentication-Results: outgoing_mbo_mout; dkim=none; spf=pass (outgoing_mbo_mout: domain of juri@HIDDEN designates 2001:67c:2050:b231:465::1 as permitted sender) smtp.mailfrom=juri@HIDDEN From: Juri Linkov <juri@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80025: Margin columns In-Reply-To: <87qzsn9dgm.fsf@HIDDEN> Organization: LINKOV.NET References: <87h5tpj7ch.fsf_-_@HIDDEN> <861pkt3q8e.fsf@HIDDEN> <87cy48nv4o.fsf@HIDDEN> <86ldiwxm9m.fsf@HIDDEN> <87qzsn9dgm.fsf@HIDDEN> Date: Mon, 29 Dec 2025 19:38:10 +0200 Message-ID: <87y0mlkx31.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 4dg3PD5W0Jz9tJC X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 80025 Cc: 80025 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) It seems the branch 'feature/margin-columns' is ready for merging to master (modulo the documentation). Everything works as designed. For example: - 'M-x flymake-mode' adds a margin column for flymake errors/warnings - 'M-x outline-minor-mode' adds a margin column for outline arrows - 'M-x hs-minor-mode' adds a margin column for hideshow indicators - 'M-x flymake-mode' again removes the first column - 'M-x hs-minor-mode' removes the third column - 'M-x outline-minor-mode' removes the remaining column The column order can be changed by the users using mode hooks by reordering the mode symbols in the new variables 'left-margin-columns' and 'right-margin-columns'.
bug-gnu-emacs@HIDDEN:bug#80025; Package emacs.
Full text available.Received: (at 80025) by debbugs.gnu.org; 22 Dec 2025 07:37:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 22 02:37:08 2025 Received: from localhost ([127.0.0.1]:44227 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vXaTc-0008Hm-21 for submit <at> debbugs.gnu.org; Mon, 22 Dec 2025 02:37:08 -0500 Received: from mout-p-202.mailbox.org ([2001:67c:2050:0:465::202]:39444) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1vXaTZ-0008Gw-Cc for 80025 <at> debbugs.gnu.org; Mon, 22 Dec 2025 02:37:06 -0500 Received: from smtp2.mailbox.org (smtp2.mailbox.org [10.196.197.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4dZVMV3rtVz9sq0; Mon, 22 Dec 2025 08:36:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkov.net; s=MBO0001; t=1766389014; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Dox6oEOMP58izBr4tEX2FJrlrCq30HeLoz2b6JiEYfo=; b=xrjVwLx2btJpuNoaTCxkY61RPIo/VYFmswZ9MLziOrWwK5oIVlsEQJ4jwbiZUrSTQOU8bj 7TK3Q/wK216nZQgRAG/h3EIwuMwGtmbd41xIDm/A305yH1+TDGyoZEsGJ2OKSJyT2nfBM8 42FTv8pbqKLuKhdQFYv6yDyEHa42eE8ntxhX3Lz4hmqWQuRNgZDw+XW6DOVjQmwgisHreo yvnom8YF2YzH81AZKmh4erlDKPq+DDWEVDaw+CVRQZfqzzH3uqoXwFk0DfkBv0tImSqJr7 aXl1PpH23SnoSQLaAVImI6nGagfoHyhrSdt/aR8U34EtvcnvjFKoY5A9UDQijg== From: Juri Linkov <juri@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80025: Margin columns In-Reply-To: <86ldiwxm9m.fsf@HIDDEN> Organization: LINKOV.NET References: <87h5tpj7ch.fsf_-_@HIDDEN> <861pkt3q8e.fsf@HIDDEN> <87cy48nv4o.fsf@HIDDEN> <86ldiwxm9m.fsf@HIDDEN> Date: Mon, 22 Dec 2025 09:34:49 +0200 Message-ID: <87qzsn9dgm.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 80025 Cc: 80025 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) >> So I added more comments and tried to push to the new branch 'feature/margin-columns'. >> >> But the push failed with the server error: > > This is a savannah problem, please try again later I tried again, and the branch feature/margin-columns was pushed successfully. In the branch I also copied the same margin-column handling from 'append_glyph' to term.c and also to 'produce_image_glyph'. In these functions also copied the existing code that fills the glyph from the end of functions to margin-column branch that returns immediately afterwards. Not sure if such duplicating of code is right. An alternative would be to intersperse the existing code with a lot of if-conditions such as 'if (!handled_margin_column)' So unlike this, duplication looks cleaner.
bug-gnu-emacs@HIDDEN:bug#80025; Package emacs.
Full text available.Received: (at 80025) by debbugs.gnu.org; 21 Dec 2025 08:38:41 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 21 03:38:41 2025 Received: from localhost ([127.0.0.1]:33154 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vXExd-0003iu-6j for submit <at> debbugs.gnu.org; Sun, 21 Dec 2025 03:38:41 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50114) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vXExa-0003iZ-IR for 80025 <at> debbugs.gnu.org; Sun, 21 Dec 2025 03:38:39 -0500 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 <eliz@HIDDEN>) id 1vXExU-0005LI-GC; Sun, 21 Dec 2025 03:38:33 -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=dMqJmlQVbPQmKsZNIYMr2S0GIsHYp+NAMhbFcDLOf+g=; b=UP6PRyCiHns8 9qHW+SQCt/Gz8ROFS4v1hHdyXmoErUaQEAckskWylPu9K0X3sDvmgV8koXrjXzKCJ6wpy9qVl33Y8 rC5wFbPi0xbYYPpedZq/pgtltFnKyO0A7+zNWsu49b/SP7Njr2kctfYYTAJ+JsGxEEHIsE6yloVUz ieRPWDhMxwg5axwxmxPGKeURRAg6oMd1sZNzTavDJ3bwARvBoMWZ3l5cwWMBXrD03jYUVsMviIWy2 LcywoZgLGvLk9Cq7iRpoR4BYeWlTPfxnVQsz5WGQ77ZtYMcXOO8xgKtJugKVjHPJL07xa2SKxA4e8 AHeHIT8gUxUo6mXGyvBckw==; Date: Sun, 21 Dec 2025 10:38:29 +0200 Message-Id: <86ldiwxm9m.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Juri Linkov <juri@HIDDEN> In-Reply-To: <87cy48nv4o.fsf@HIDDEN> (message from Juri Linkov on Sun, 21 Dec 2025 09:37:11 +0200) Subject: Re: bug#80025: Margin columns References: <87h5tpj7ch.fsf_-_@HIDDEN> <861pkt3q8e.fsf@HIDDEN> <87cy48nv4o.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80025 Cc: 80025 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Juri Linkov <juri@HIDDEN> > Cc: 80025 <at> debbugs.gnu.org > Date: Sun, 21 Dec 2025 09:37:11 +0200 > > So I added more comments and tried to push to the new branch 'feature/margin-columns'. > > But the push failed with the server error: > > error: cannot fork() for gc: Cannot allocate memory > remote: fatal: deflateInit: out of memory (insufficient memory) > error: remote unpack failed: unpack-objects abnormal exit > To git.sv.gnu.org:/srv/git/emacs.git > ! [remote rejected] feature/margin-columns -> feature/margin-columns (unpacker error) > error: failed to push some refs to 'git.sv.gnu.org:/srv/git/emacs.git' This is a savannah problem, please try again later, and if the problem persists, report to savannah-hackers-public@HIDDEN and CC the following individuals: Bob Proulx <bob@HIDDEN> Corwin Brust <corwin@HIDDEN> Thanks.
bug-gnu-emacs@HIDDEN:bug#80025; Package emacs.
Full text available.Received: (at 80025) by debbugs.gnu.org; 21 Dec 2025 07:39:22 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Dec 21 02:39:22 2025 Received: from localhost ([127.0.0.1]:60950 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vXE2D-0000Kv-Jo for submit <at> debbugs.gnu.org; Sun, 21 Dec 2025 02:39:21 -0500 Received: from mout-p-202.mailbox.org ([2001:67c:2050:0:465::202]:54602) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1vXE2B-0000Ka-GZ for 80025 <at> debbugs.gnu.org; Sun, 21 Dec 2025 02:39:20 -0500 Received: from smtp2.mailbox.org (smtp2.mailbox.org [10.196.197.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4dYtSb01tqz9sxm; Sun, 21 Dec 2025 08:39:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkov.net; s=MBO0001; t=1766302751; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=tpkj4lb7P++1qklx0o1QIRIP08HUmio73ni8Dqz39Uk=; b=VHh35G3A5gWprHMvBgU+Mzq0EdQUQ6bjxHXZ5If/dRE15GFDlA1KTXDOV3aDdomSaIUD3b RtaNYbk301BCbcQutIFfgyxYC8gJfjeTOTGxPfneRNMVunhFdSoEzQ5BaoElq5hY4T367f K0r7qE379SPcpmYDhdF0yC1ulp9B55MFrLccidLg0RBg/6wV2eCI+wVxP9VWzh59WF/dkb 7z7yF4C+rXIt/r4B00BvbrCUmVoJEVDfyVq+dMK4O0/IwMJrcucbtAiK07MT4gqoSmLWa8 0XFLtxVm/EWnXuYj+fgTvKACQsHNsq/2NkCCAkGO5ugovQRrO3r40yDFyUsDWw== From: Juri Linkov <juri@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80025: Margin columns In-Reply-To: <861pkt3q8e.fsf@HIDDEN> Organization: LINKOV.NET References: <87h5tpj7ch.fsf_-_@HIDDEN> <861pkt3q8e.fsf@HIDDEN> Date: Sun, 21 Dec 2025 09:37:11 +0200 Message-ID: <87cy48nv4o.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 80025 Cc: 80025 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) >> I see two ways of sending the value of the margin column >> from 'handle_single_display_spec' to 'append_glyph': >> >> 1. using a static variable; >> 2. adding a new field to the struct 'it'. >> >> What variant would be more preferable? > > The second one is cleaner. So I added a new field. >> + glyph = it->glyph_row->glyphs[area] + margin_column; >> + >> + if (margin_column >= it->glyph_row->used[area]) >> + it->glyph_row->used[area] = margin_column + 1; > > I would omit the "+ 1" part in the last line, and then this: > >> - ++it->glyph_row->used[area]; >> + if (!(area == LEFT_MARGIN_AREA || area == RIGHT_MARGIN_AREA)) >> + ++it->glyph_row->used[area]; > > could be left unchanged, AFAICT. I tried to do this, but then it fails. This is because this should not be incremented when there is no filling with spaces, but only direct changing of the existing column value. So I added more comments and tried to push to the new branch 'feature/margin-columns'. But the push failed with the server error: error: cannot fork() for gc: Cannot allocate memory remote: fatal: deflateInit: out of memory (insufficient memory) error: remote unpack failed: unpack-objects abnormal exit To git.sv.gnu.org:/srv/git/emacs.git ! [remote rejected] feature/margin-columns -> feature/margin-columns (unpacker error) error: failed to push some refs to 'git.sv.gnu.org:/srv/git/emacs.git'
bug-gnu-emacs@HIDDEN:bug#80025; Package emacs.
Full text available.
Received: (at 80025) by debbugs.gnu.org; 17 Dec 2025 18:42:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 17 13:42:06 2025
Received: from localhost ([127.0.0.1]:45626 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vVwTN-0005h0-KH
for submit <at> debbugs.gnu.org; Wed, 17 Dec 2025 13:42:05 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:56794)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vVwTL-0005gU-Mc
for 80025 <at> debbugs.gnu.org; Wed, 17 Dec 2025 13:42:04 -0500
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 <eliz@HIDDEN>)
id 1vVwTF-0000U6-Bf; Wed, 17 Dec 2025 13:41:57 -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=dJcb6KPKlCxhGbfZs+0Qi4SuIxwEQSsXy+/F4v3BTcg=; b=sMUqRT80+xnx
idX7eNrpsLx27RWlL1CxVLul3wuLegdSaqJNas7bbSWhx0ZnQhD0Q9DGXw5+PQyCJMxRAq45DoIUU
S/vJA/uxtqytYohS7DRkjl6Z0/T2h6e/8F8nJVV3DI371qheplqvz+LQprQvoepiWXEeMaJsUivS8
d7XxG9QTHt5Un6/rOsmub+DZVZVZZPJMBQ+ATdPiSRW8RkOWwNqU4IHN+dr58AjXPLkFaY2PDbe1R
E96BuzSH2rwIG17ziV3La2RVyVuA1lSG87VoBB2jUAxeVJKMKS00/uQYIp4VGVdv0unF6e/5f3bG2
DAO47dq8N9zbzaWUYpDxlA==;
Date: Wed, 17 Dec 2025 20:41:53 +0200
Message-Id: <861pkt3q8e.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Juri Linkov <juri@HIDDEN>
In-Reply-To: <87h5tpj7ch.fsf_-_@HIDDEN> (message from Juri Linkov on
Wed, 17 Dec 2025 20:28:17 +0200)
Subject: Re: bug#80025: Margin columns
References: <87h5tpj7ch.fsf_-_@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80025
Cc: 80025 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Cc: Eli Zaretskii <eliz@HIDDEN>
> From: Juri Linkov <juri@HIDDEN>
> Date: Wed, 17 Dec 2025 20:28:17 +0200
>
> >> I see that PRODUCE_GLYPHS calls either 'produce_glyphs' directly or
> >> 'FRAME_RIF->produce_glyphs' ('gui_produce_glyphs'). Then both versions
> >> have several calls to 'append_glyph'. This means that the most suitable
> >> place for filling with the SPC character glyph in the margins is
> >> 'append_glyph'?
> >
> > Yes. You need to modify this line:
> >
> > glyph = it->glyph_row->glyphs[area] + it->glyph_row->used[area];
> >
> > It currently makes 'glyph' point to the next glyph-row slot, and then
> > fills that slot with the information about the character. Instead,
> > the new code should (in case of margins only) find the slot whose
> > index is the column number you want to use, and, if that slot is
> > beyond the one identified by used[are] as above, fill the preceding
> > columns with a space glyph.
>
> Thanks for pointing to the right place.
>
> So I tried to do exactly this, filling the columns with the space glyph,
> and it works.
>
> Currently the margin column is hard-coded for testing.
> But since now the hardest part is done, it's trivial
> to get the margin column from the display spec.
>
> I see two ways of sending the value of the margin column
> from 'handle_single_display_spec' to 'append_glyph':
>
> 1. using a static variable;
> 2. adding a new field to the struct 'it'.
>
> What variant would be more preferable?
The second one is cleaner.
> + glyph = it->glyph_row->glyphs[area] + margin_column;
> +
> + if (margin_column >= it->glyph_row->used[area])
> + it->glyph_row->used[area] = margin_column + 1;
I would omit the "+ 1" part in the last line, and then this:
> - ++it->glyph_row->used[area];
> + if (!(area == LEFT_MARGIN_AREA || area == RIGHT_MARGIN_AREA))
> + ++it->glyph_row->used[area];
could be left unchanged, AFAICT.
Thanks.
bug-gnu-emacs@HIDDEN:bug#80025; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 17 Dec 2025 18:30:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 17 13:30:06 2025
Received: from localhost ([127.0.0.1]:45465 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vVwHl-0004o5-UN
for submit <at> debbugs.gnu.org; Wed, 17 Dec 2025 13:30:06 -0500
Received: from lists.gnu.org ([2001:470:142::17]:37776)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1vVwHj-0004lV-Fa
for submit <at> debbugs.gnu.org; Wed, 17 Dec 2025 13:30:04 -0500
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 <juri@HIDDEN>) id 1vVwHc-0003tw-GY
for bug-gnu-emacs@HIDDEN; Wed, 17 Dec 2025 13:29:56 -0500
Received: from mout-p-102.mailbox.org ([80.241.56.152])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256)
(Exim 4.90_1) (envelope-from <juri@HIDDEN>) id 1vVwHY-0005R5-HZ
for bug-gnu-emacs@HIDDEN; Wed, 17 Dec 2025 13:29:55 -0500
Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(No client certificate requested)
by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4dWj550lyjz9thy
for <bug-gnu-emacs@HIDDEN>; Wed, 17 Dec 2025 19:29:45 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkov.net; s=MBO0001;
t=1765996185;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:mime-version:mime-version:content-type:content-type;
bh=UIQ7dp87dL4p/FWyA2YXaTrJ5UrGydA+H7AcvTZyyP4=;
b=ZkJzMdvwOtc9bThrsOKqyJhQwclVMiIpZ6gqCNcNVFAF/RgBHlEQ+Djzxd8s+YUJ1JmXC/
y+4dbC8wgRPjzHdaUkPhQgJozvhAfJBRy1cSLcITc9Dvv02SjSOWPNT33kUSohmw3VX7LV
sSvLzOuZGR19eg9MezTMU0e+PALuX/GEC0wsjvU9k0+GWadYybaEimQAMW3gcNIX8j0l40
u1QSQ56cqwQX5QOZ2Idi2giRdZKzezv8k3WKEz2y5dF5Aa+LV025q7pWF68bBKIwDhS7k0
L7KqMEsiI18/N8IyEAbjU5WRd5XBXQEFM1zFfR7y8HX948Xs9p1V5X9BOwKscw==
From: Juri Linkov <juri@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: Margin columns
Organization: LINKOV.NET
X-Debbugs-Cc: Eli Zaretskii <eliz@HIDDEN>
Date: Wed, 17 Dec 2025 20:28:17 +0200
Message-ID: <87h5tpj7ch.fsf_-_@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Received-SPF: pass client-ip=80.241.56.152; envelope-from=juri@HIDDEN;
helo=mout-p-102.mailbox.org
X-Spam_score_int: -27
X-Spam_score: -2.8
X-Spam_bar: --
X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001,
RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001,
SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)
--=-=-=
Content-Type: text/plain
[moved from emacs-devel]
>> I see that PRODUCE_GLYPHS calls either 'produce_glyphs' directly or
>> 'FRAME_RIF->produce_glyphs' ('gui_produce_glyphs'). Then both versions
>> have several calls to 'append_glyph'. This means that the most suitable
>> place for filling with the SPC character glyph in the margins is
>> 'append_glyph'?
>
> Yes. You need to modify this line:
>
> glyph = it->glyph_row->glyphs[area] + it->glyph_row->used[area];
>
> It currently makes 'glyph' point to the next glyph-row slot, and then
> fills that slot with the information about the character. Instead,
> the new code should (in case of margins only) find the slot whose
> index is the column number you want to use, and, if that slot is
> beyond the one identified by used[are] as above, fill the preceding
> columns with a space glyph.
Thanks for pointing to the right place.
So I tried to do exactly this, filling the columns with the space glyph,
and it works.
Currently the margin column is hard-coded for testing.
But since now the hardest part is done, it's trivial
to get the margin column from the display spec.
I see two ways of sending the value of the margin column
from 'handle_single_display_spec' to 'append_glyph':
1. using a static variable;
2. adding a new field to the struct 'it'.
What variant would be more preferable?
Here is the current state:
--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline; filename=margin_column.patch
diff --git a/src/xdisp.c b/src/xdisp.c
index 06d5481acd3..13f580e0e9d 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -31863,7 +31863,38 @@ append_glyph (struct it *it)
eassert (it->glyph_row);
eassert (it->char_to_display != '\n' && it->char_to_display != '\t');
- glyph = it->glyph_row->glyphs[area] + it->glyph_row->used[area];
+ if (area == LEFT_MARGIN_AREA || area == RIGHT_MARGIN_AREA)
+ {
+ int margin_column = 2;
+ if (margin_column < (area == LEFT_MARGIN_AREA
+ ? WINDOW_LEFT_MARGIN_WIDTH (it->w)
+ : WINDOW_RIGHT_MARGIN_WIDTH (it->w)))
+ {
+ int face_id = lookup_basic_face (it->w, it->f, DEFAULT_FACE_ID);
+ while (it->glyph_row->used[area] < margin_column
+ && it->glyph_row->glyphs[area] + it->glyph_row->used[area]
+ < it->glyph_row->glyphs[area + 1])
+ {
+ struct glyph *fill_glyph =
+ it->glyph_row->glyphs[area] + it->glyph_row->used[area];
+ *fill_glyph = space_glyph;
+ fill_glyph->pixel_width = FRAME_COLUMN_WIDTH (it->f);
+ fill_glyph->face_id = face_id;
+ fill_glyph->frame = it->f;
+ ++it->glyph_row->used[area];
+ }
+
+ glyph = it->glyph_row->glyphs[area] + margin_column;
+
+ if (margin_column >= it->glyph_row->used[area])
+ it->glyph_row->used[area] = margin_column + 1;
+ }
+ else
+ glyph = it->glyph_row->glyphs[area] + it->glyph_row->used[area];
+ }
+ else
+ glyph = it->glyph_row->glyphs[area] + it->glyph_row->used[area];
+
if (glyph < it->glyph_row->glyphs[area + 1])
{
/* If the glyph row is reversed, we need to prepend the glyph
@@ -31928,7 +31959,8 @@ append_glyph (struct it *it)
glyph->resolved_level = 0;
glyph->bidi_type = UNKNOWN_BT;
}
- ++it->glyph_row->used[area];
+ if (!(area == LEFT_MARGIN_AREA || area == RIGHT_MARGIN_AREA))
+ ++it->glyph_row->used[area];
}
else
IT_EXPAND_MATRIX_WIDTH (it, area);
--=-=-=--
Juri Linkov <juri@HIDDEN>:eliz@HIDDEN, bug-gnu-emacs@HIDDEN.
Full text available.eliz@HIDDEN, bug-gnu-emacs@HIDDEN:bug#80025; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.