From unknown Sun Jun 22 20:55:53 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#21533 <21533@debbugs.gnu.org> To: bug#21533 <21533@debbugs.gnu.org> Subject: Status: 24.5; current-column result varies between specified spaces using :width and :relative-width Reply-To: bug#21533 <21533@debbugs.gnu.org> Date: Mon, 23 Jun 2025 03:55:53 +0000 retitle 21533 24.5; current-column result varies between specified spaces u= sing :width and :relative-width reassign 21533 emacs submitter 21533 Phil Sainty severity 21533 normal tag 21533 wontfix thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 22 10:45:32 2015 Received: (at submit) by debbugs.gnu.org; 22 Sep 2015 14:45:32 +0000 Received: from localhost ([127.0.0.1]:41812 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZeOp1-0003Qv-TQ for submit@debbugs.gnu.org; Tue, 22 Sep 2015 10:45:32 -0400 Received: from eggs.gnu.org ([208.118.235.92]:48116) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZeOoz-0003Qn-UP for submit@debbugs.gnu.org; Tue, 22 Sep 2015 10:45:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZeOow-00073m-R9 for submit@debbugs.gnu.org; Tue, 22 Sep 2015 10:45:29 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:33121) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeOow-00073a-P6 for submit@debbugs.gnu.org; Tue, 22 Sep 2015 10:45:26 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58068) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeOor-0001YG-0N for bug-gnu-emacs@gnu.org; Tue, 22 Sep 2015 10:45:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZeOoo-0006wV-0d for bug-gnu-emacs@gnu.org; Tue, 22 Sep 2015 10:45:20 -0400 Received: from [219.88.242.59] (port=44443 helo=mail.orcon.net.nz) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeOon-0006uy-GH for bug-gnu-emacs@gnu.org; Tue, 22 Sep 2015 10:45:17 -0400 Received: from [10.1.1.2] (202-150-97-63.bng1.avl.orcon.net.nz [202.150.97.63] (may be forged)) (authenticated bits=0) by mail.orcon.net.nz (8.14.3/8.14.3/Debian-9.4) with ESMTP id t8METPIO039962 for ; Wed, 23 Sep 2015 02:29:26 +1200 Message-ID: <560165C5.2020904@orcon.net.nz> Date: Wed, 23 Sep 2015 02:29:25 +1200 From: Phil Sainty User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: bug-gnu-emacs@gnu.org Subject: 24.5; current-column result varies between specified spaces using :width and :relative-width Content-Type: text/plain; charset=utf-8; format=flowed X-Bayes-Prob: 0.0001 (Score 0: No Bayes scoring rules defined, tokens from: outbound) X-CanIt-Geo: ip=202.150.97.63; country=NZ; latitude=-41; longitude=174.0000; http://maps.google.com/maps?q=-41,174.0000&z=6 X-CanItPRO-Stream: base:outbound X-Canit-Stats-ID: 02PketqS2 - 8a87615179a4 - 20150923 X-Scanned-By: CanIt (www . roaringpenguin . com) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.orcon.net.nz id t8METPIO039962 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) I can't tell whether this is expected behaviour or not? Starting from emacs -Q, in the *scratch* buffer, I get the following results from evaluating these forms with C-j: (progn (insert (propertize " " 'display '(space :width 2))) (current-column)) 2 (progn (insert (propertize " " 'display '(space :relative-width 2))) (current-column)) 1 Which is to say that a specified space of :width 2 occupies 2 columns, while a specified space of :relative-width 2 occupies only 1 column. This behaviour seems to be consistent, such that with :width the current-column result comes from the (rounded) number of real columns over which the specified space(s) stretch; whereas with :relative-width the current-column is the same as it would have been without the text property. I'm confused because the manual doesn't seem to suggest that there should be a difference between the two specifications, other than which character is used as the basis for the visual appearance of the space: (elisp) Specified Space: =E2=80=98:width WIDTH=E2=80=99 If WIDTH is a number, it specifies that the space width should be WIDTH times the normal character width. WIDTH can also be a "pixel width" specification (*note Pixel Specification::). =E2=80=98:relative-width FACTOR=E2=80=99 Specifies that the width of the stretch should be computed from the first character in the group of consecutive characters that have the same =E2=80=98display=E2=80=99 property. The space width is th= e width of that character, multiplied by FACTOR. What I was hoping for was the control of being able to specify a precise :width (because the resulting width of tabs when using :relative-width gets rather tricky in practice when it comes to tabs which are not tab-width wide), but with the (current-column) behaviour of :relative-width. (What I'm actually *doing* is scaling indentation, and so if the column numbers vary with the scaling, then re-indenting the buffer causes changes; and I want the effect to be purely visual.) -Phil From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 22 12:57:17 2015 Received: (at 21533) by debbugs.gnu.org; 22 Sep 2015 16:57:17 +0000 Received: from localhost ([127.0.0.1]:41876 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZeQsX-0006XD-5h for submit@debbugs.gnu.org; Tue, 22 Sep 2015 12:57:17 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:40039) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZeQsU-0006X2-ID for 21533@debbugs.gnu.org; Tue, 22 Sep 2015 12:57:15 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NV3009007VI2400@a-mtaout23.012.net.il> for 21533@debbugs.gnu.org; Tue, 22 Sep 2015 19:57:11 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NV3008Z98FBY760@a-mtaout23.012.net.il>; Tue, 22 Sep 2015 19:57:11 +0300 (IDT) Date: Tue, 22 Sep 2015 19:57:23 +0300 From: Eli Zaretskii Subject: Re: bug#21533: 24.5; current-column result varies between specified spaces using :width and :relative-width In-reply-to: <560165C5.2020904@orcon.net.nz> X-012-Sender: halo1@inter.net.il To: Phil Sainty Message-id: <83y4fyl7d8.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <560165C5.2020904@orcon.net.nz> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21533 Cc: 21533@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 23 Sep 2015 02:29:25 +1200 > From: Phil Sainty > > I can't tell whether this is expected behaviour or not? > > Starting from emacs -Q, in the *scratch* buffer, I get the following > results from evaluating these forms with C-j: > > (progn (insert (propertize " " 'display '(space :width 2))) > (current-column)) > 2 > > (progn (insert (propertize " " 'display '(space :relative-width 2))) > (current-column)) > 1 > > Which is to say that a specified space of :width 2 occupies 2 columns, > while a specified space of :relative-width 2 occupies only 1 column. Simply put, current-column did not support :relative-width. Now it does, so your example should work as expected with the development sources. But beware: current-column is not guaranteed to always produce the exact results you'd expect on GUI displays when wider-than-normal characters are involved. That's because character width in column units is always an integer: 0, 1, or 2, whereas the actual pixel width of those characters depends on the font and is in general not an integral multiple of the "normal character width". For example, try your test case with the (double-width) character ᄀ instead of the space. Or try ^A (Ctrl-A). If you want accurate screen coordinates, use pixel coordinates returned by functions like posn-at-point instead. You can convert the pixel coordinates into units of canonical character width (a.k.a. "columns") if you divide the pixel coordinates by the value returned by the function default-font-width. Also note that :relative-width is only supported on GUI frames. The documentation omitted this crucial fact; I fixed that as well. > (What I'm actually *doing* is scaling indentation, and so if the column > numbers vary with the scaling, then re-indenting the buffer causes > changes; and I want the effect to be purely visual.) If you only ever need to scale TAB and SPC characters, then the above restrictions don't apply, I think. But it is still useful to keep them in mind. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 23 08:32:30 2015 Received: (at submit) by debbugs.gnu.org; 23 Sep 2015 12:32:30 +0000 Received: from localhost ([127.0.0.1]:42437 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZejDp-0003Gq-Ha for submit@debbugs.gnu.org; Wed, 23 Sep 2015 08:32:29 -0400 Received: from eggs.gnu.org ([208.118.235.92]:38854) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZejDm-0003Gh-Eo for submit@debbugs.gnu.org; Wed, 23 Sep 2015 08:32:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZejDl-0002H0-7Z for submit@debbugs.gnu.org; Wed, 23 Sep 2015 08:32:26 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:43342) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZejDl-0002Gw-5l for submit@debbugs.gnu.org; Wed, 23 Sep 2015 08:32:25 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48850) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZejDk-00074X-6u for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2015 08:32:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZejDf-0002EK-LS for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2015 08:32:24 -0400 Received: from [219.88.242.56] (port=53250 helo=mail.orcon.net.nz) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZejDf-0002DL-4m for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2015 08:32:19 -0400 Received: from [10.1.1.2] (202-150-97-63.bng1.avl.orcon.net.nz [202.150.97.63] (may be forged)) (authenticated bits=0) by mail.orcon.net.nz (8.14.3/8.14.3/Debian-9.4) with ESMTP id t8NCWF0S022919 for ; Thu, 24 Sep 2015 00:32:16 +1200 Message-ID: <56029BCF.40205@orcon.net.nz> Date: Thu, 24 Sep 2015 00:32:15 +1200 From: Phil Sainty User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: bug-gnu-emacs@gnu.org Subject: Re: bug#21533: 24.5; current-column result varies between specified spaces using :width and :relative-width References: <560165C5.2020904@orcon.net.nz> <83y4fyl7d8.fsf@gnu.org> In-Reply-To: <83y4fyl7d8.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0: No Bayes scoring rules defined, tokens from: outbound) X-CanIt-Geo: ip=202.150.97.63; country=NZ; latitude=-41; longitude=174.0000; http://maps.google.com/maps?q=-41,174.0000&z=6 X-CanItPRO-Stream: base:outbound X-Canit-Stats-ID: 02PkAwfn1 - 8209fe288d85 - 20150924 X-Scanned-By: CanIt (www . roaringpenguin . com) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Hi Eli, On 23/09/15 04:57, Eli Zaretskii wrote: >> Which is to say that a specified space of :width 2 occupies 2 columns, >> while a specified space of :relative-width 2 occupies only 1 column. > > Simply put, current-column did not support :relative-width. Now it > does, so your example should work as expected with the development > sources. Ah. Well this is quite unfortunate for me. I've recompiled, and can confirm the change. Unfortunately the revised behaviour is actually the opposite to what I was hoping for. (A version of :width with the (now old) column behaviour of :relative-width would have been perfect.) In order for me to manipulate the *apparent* size of indentation without having any *practical* effect on the buffer, it's important that the current-column value for any given character of indentation does not change. If the current-column for a character can change, then simply re-indenting a line/region may cause the number of characters of indentation to change, even if the user had not edited the text since it was originally indented. (calculate-lisp-indent is dependent on current-column, for example.) Is there a way forward for me here? My library is/was *mostly* working how I wanted (I think the cases where using :relative-width had actually caused problems were probably edge cases), and I was intending to propose it as a GNU ELPA package. Assuming the new change is definitely how the existing properties should work, would you consider adding new alternative properties which provide the "specified space widths do not affect column numbers" behaviour? -Phil p.s. Please let me know if you'd like to see examples and/or code? From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 23 08:57:12 2015 Received: (at 21533) by debbugs.gnu.org; 23 Sep 2015 12:57:12 +0000 Received: from localhost ([127.0.0.1]:42445 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zejbj-0003pp-8P for submit@debbugs.gnu.org; Wed, 23 Sep 2015 08:57:11 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:47864) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zejbc-0003pc-ON for 21533@debbugs.gnu.org; Wed, 23 Sep 2015 08:57:06 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NV400H00RRGU100@mtaout27.012.net.il> for 21533@debbugs.gnu.org; Wed, 23 Sep 2015 15:53:23 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NV4009RWRSZP270@mtaout27.012.net.il>; Wed, 23 Sep 2015 15:53:23 +0300 (IDT) Date: Wed, 23 Sep 2015 15:57:02 +0300 From: Eli Zaretskii Subject: Re: bug#21533: 24.5; current-column result varies between specified spaces using :width and :relative-width In-reply-to: <56029BCF.40205@orcon.net.nz> X-012-Sender: halo1@inter.net.il To: Phil Sainty Message-id: <83vbb1jntt.fsf@gnu.org> References: <560165C5.2020904@orcon.net.nz> <83y4fyl7d8.fsf@gnu.org> <56029BCF.40205@orcon.net.nz> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21533 Cc: 21533@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Thu, 24 Sep 2015 00:32:15 +1200 > From: Phil Sainty > > On 23/09/15 04:57, Eli Zaretskii wrote: > >> Which is to say that a specified space of :width 2 occupies 2 columns, > >> while a specified space of :relative-width 2 occupies only 1 column. > > > > Simply put, current-column did not support :relative-width. Now it > > does, so your example should work as expected with the development > > sources. > > Ah. Well this is quite unfortunate for me. > > I've recompiled, and can confirm the change. Unfortunately the > revised behaviour is actually the opposite to what I was hoping for. > (A version of :width with the (now old) column behaviour of > :relative-width would have been perfect.) Then I don't really understand your bug report. Can you explain what was problematic for you in the old behavior? I could easily revert the change I made, if you convince me the previous behavior was correct. > In order for me to manipulate the *apparent* size of indentation > without having any *practical* effect on the buffer, it's important > that the current-column value for any given character of indentation > does not change. > > If the current-column for a character can change, then simply > re-indenting a line/region may cause the number of characters > of indentation to change, even if the user had not edited the > text since it was originally indented. (calculate-lisp-indent > is dependent on current-column, for example.) I don't understand what you are trying to accomplish, on a higher level. Why does it make sense for the apparent size of the indentation to change without affecting the value returned by current-column? And if it does, why can't you override the default behavior of current-column instead of using fancy display properties? > Is there a way forward for me here? Does this do what you want: (insert (propertize " " 'display '(space :width (100)))) (The number 100 is in pixels; see the node "Pixel Specification" in the ELisp manual.) I'm not sure this is not a bug, though. Perhaps we should fix the code in current-column that handles pixel values as well. Or maybe space specs in pixels should always count as one column, I don't know. > My library is/was *mostly* working how I wanted (I think the > cases where using :relative-width had actually caused problems > were probably edge cases), and I was intending to propose it as > a GNU ELPA package. Can you describe those edge cases? > Assuming the new change is definitely how the existing properties > should work, would you consider adding new alternative properties > which provide the "specified space widths do not affect column > numbers" behaviour? See above. And I'm no longer sure the new change is definitely how :relative-width should behave, as it sounds like any space specification in pixels, or actually any value that is not in units of the default character width, seems to be counted as a single character regardless of its actual width. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 08 17:19:20 2019 Received: (at control) by debbugs.gnu.org; 8 Jan 2019 22:19:21 +0000 Received: from localhost ([127.0.0.1]:50622 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ggziS-0004eo-P3 for submit@debbugs.gnu.org; Tue, 08 Jan 2019 17:19:20 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38621) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ggziQ-0004eX-Nw for control@debbugs.gnu.org; Tue, 08 Jan 2019 17:19:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ggziK-0003bM-Vo for control@debbugs.gnu.org; Tue, 08 Jan 2019 17:19:13 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44882) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ggziK-0003b6-SR for control@debbugs.gnu.org; Tue, 08 Jan 2019 17:19:12 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1ggziK-0003xZ-Qg for control@debbugs.gnu.org; Tue, 08 Jan 2019 17:19:12 -0500 Subject: control message for bug 21533 To: X-Mailer: mail (GNU Mailutils 2.99.98) Message-Id: From: Glenn Morris Date: Tue, 08 Jan 2019 17:19:12 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:470:142:3::e X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) tag 21533 = wontfix close 21533 From unknown Sun Jun 22 20:55:53 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 06 Feb 2019 12:24:10 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator