From unknown Mon Jun 23 11:27:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#61735: 29.0.50; String object in margin not associated correctly with buffer text Resent-From: dalanicolai Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 23 Feb 2023 16:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 61735 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 61735@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.16771699947229 (code B ref -1); Thu, 23 Feb 2023 16:34:02 +0000 Received: (at submit) by debbugs.gnu.org; 23 Feb 2023 16:33:14 +0000 Received: from localhost ([127.0.0.1]:35123 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVEWv-0001sW-Hy for submit@debbugs.gnu.org; Thu, 23 Feb 2023 11:33:14 -0500 Received: from lists.gnu.org ([209.51.188.17]:44506) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVEWs-0001sM-P7 for submit@debbugs.gnu.org; Thu, 23 Feb 2023 11:33:12 -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 ) id 1pVEWp-0006d1-WA for bug-gnu-emacs@gnu.org; Thu, 23 Feb 2023 11:33:10 -0500 Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pVEWm-0007YG-Ru for bug-gnu-emacs@gnu.org; Thu, 23 Feb 2023 11:33:07 -0500 Received: by mail-wm1-x335.google.com with SMTP id m25-20020a7bcb99000000b003e7842b75f2so6889344wmi.3 for ; Thu, 23 Feb 2023 08:33:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=cuTBIA3LCjAYeleO3eBk2x4m+X18AAg6ZRXkP6hJKno=; b=hck+GSwO+iyu3SzJzXcEUTd34/CMFPAZ7jVdluHxUPfReqDZGXl0RoRxkzBDHHEDrH P/gpVf13wFMRLT9/UxqA8qR95lRCGGmRxeifIc9vrIoEnF/Ml2951X/X15iPDci64bvf 9pnOZFruxumgg5lLmQKygb8Q5zMJrQ807cpEOVWesPCHjK3Tz6qQPeqGY6Gy9ilDzac3 r/AURDdxd3gQHQpj0usjr/V6HimjYb7DvKjj7TBE2B2mWgV353b4wmifCsF11kgYXDoz 3n4ZeNx4SFe/MyE3DWhEPQihnD1n7AHG95k3nVo8DErOIIHr2veF9ms0FZB3Yn2kf5b3 ARcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=cuTBIA3LCjAYeleO3eBk2x4m+X18AAg6ZRXkP6hJKno=; b=VkJ/JMhPzPjnIWhJKUZMv1Q7rZp0EdykQ6VK0I1zEV0LAVFQ0mRyiSS9nvtjjdoesg sa3Ee2FSLjdbUo9zwypozKhvG4kHn7ULxjeJOjg8s9yXkgLcDszAqKxW0GlpKu9wRs2y L1RYiS3jorP2cXMEi3EZgdEgza6zUHb8Y/degP9aT8KyCVjMFXGblRmnFCiELMMoVO+V t0AV99ECHlj3D3K0ZMZpXdGLkgG593Cre9gUqB3WOKPvPQ0RS41loQAuJ0TMGkEeDM5d QPHniW1Gt1KvbSfLZdHnwTGDPynMpbNLsmRvt7oLS5nEIC4KBrSEclnmdNxl08HRla5X ijsw== X-Gm-Message-State: AO0yUKUbenj88RQbSFrXmKGG0LRzobW+cEnD4LrnTEkouo5XcEllZLGp 9un9wplSSy6wYe9QR6bIes1x2d4TGIJY28zHrL4ews4nDWo6Ew== X-Google-Smtp-Source: AK7set913tISyN+mkSKkm+Cedm6O4G5QQFUdlxqEuil7nCq5VSjVobSNXeAZIWHvb4A6Jqy3Hhwlgi8JONIfs9VbbKA= X-Received: by 2002:a05:600c:cc8:b0:3dc:56e6:797a with SMTP id fk8-20020a05600c0cc800b003dc56e6797amr571602wmb.196.1677169982138; Thu, 23 Feb 2023 08:33:02 -0800 (PST) MIME-Version: 1.0 From: dalanicolai Date: Thu, 23 Feb 2023 17:32:50 +0100 Message-ID: Content-Type: multipart/alternative; boundary="000000000000036ccb05f56091f5" Received-SPF: pass client-ip=2a00:1450:4864:20::335; envelope-from=dalanicolai@gmail.com; helo=mail-wm1-x335.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) 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: -2.3 (--) --000000000000036ccb05f56091f5 Content-Type: text/plain; charset="UTF-8" The section 'Displaying in the Margins ' of the elisp manual mentions that 'To display something in the margin in association with certain buffer text ... put a before-string property on the text and put the margin display specification on the contents of the before-string'. So this is what I am trying to achieve using the following code ``` (defun baleen-render (data) (pop-to-buffer (get-buffer-create "*baleen*")) (set-window-margins nil 5) (dolist (page data) (dolist (match (cdr page)) (let ((o (make-overlay (point) (progn (insert match) (point))))) (let ((s " ")) (put-text-property 0 1 'display `((margin left-margin) ,(format " %d" (car page))) s) (overlay-put o 'before-string s))) (insert "\n")))) (baleen-render '((1 "test1" "test2") (2 "test3"))) ``` Here, for every 'match' in a 'page' I am creating a new string 's' to which I add the margin display property to 'associate' it with some buffer text by using it as the value for its before-string property. However, although each 's' should get a different display property value via (format " %d" (car page)), all margin entries end up showing the same value of 2 (while the first two lines should show page number 1). To reproduce the error, simply evaluate the code above. Using edebug on 'baleen-render' it can be seen that the code seems correct, i.e. (car page) correctly returns the correct page number. It seems that although I am creating a different string object on each iteration, somehow the object put in the marging seems to be always the same. To me, this looks like a bug. And otherwise, if I am doing something wrong, then of course this report can be seen as a 'help/support request'. Thanks! In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.34, cairo version 1.17.6) of 2022-09-10 built on fedora Repository revision: 4cf9c92e27d20da9453f9abe89d84bee5d776329 Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12014000 System Description: Fedora Linux 37 (Workstation Edition) Configured using: 'configure --with-modules --with-cairo --with-native-compilation --with-json' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB Important settings: value of $LANG: en_US.UTF-8 value of $XMODIFIERS: @im=ibus locale-coding-system: utf-8-unix Major mode: Fundamental Minor modes in effect: tooltip-mode: t global-eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t blink-cursor-mode: t buffer-read-only: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message mailcap yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util text-property-search time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs comp comp-cstr warnings icons subr-x rx cl-seq cl-macs gv cl-extra help-mode bytecomp byte-compile cconv cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils rmc iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads dbusbind inotify dynamic-setting system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process native-compile emacs) Memory information: ((conses 16 77301 10328) (symbols 48 7112 0) (strings 32 19407 1642) (string-bytes 1 593504) (vectors 16 15411) (vector-slots 8 317149 17892) (floats 8 28 58) (intervals 56 372 3) (buffers 1000 13)) --000000000000036ccb05f56091f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The section 'Displaying in the Margins= ' of the elisp manual mentions
that 'To display something in= the margin in association with certain
buffer text ... put a before-str= ing property on the text and put the
margin display specification on the= contents of the before-string'.

So this is what I am trying to = achieve using the following code

```
(defun baleen-render (data)<= br>=C2=A0 (pop-to-buffer (get-buffer-create "*baleen*"))
=C2= =A0 (set-window-margins nil 5)
=C2=A0 (dolist (page data)
=C2=A0 =C2= =A0 (dolist (match (cdr page))
=C2=A0 =C2=A0 =C2=A0 (let ((o (make-overl= ay (point)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(progn (insert match)
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (point)))))
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 (let ((s " "))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 (put-text-property 0 1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'display = `((margin left-margin) ,(format " %d" (car page)))
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0s)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (overlay-put o= 'before-string s)))
=C2=A0 =C2=A0 =C2=A0 (insert "\n"))))=

(baleen-render '((1 "test1" "test2") (2 &qu= ot;test3")))
```

Here, for every 'match' in a 'p= age' I am creating a new string 's'
to which I add the margi= n display property to 'associate' it
with some buffer text by us= ing it as the value for its before-string
property.
However, although= each 's' should get a different display property value
via (for= mat " %d" (car page)), all margin entries end up showing the
s= ame value of 2 (while the first two lines should show page number 1).
To reproduce the error, simply evaluate the code above. Using edebug on'baleen-render' it can be seen that the code seems correct, i.e. = (car
page) correctly returns the correct page number.

It seems th= at although I am creating a different string object on each
iteration, s= omehow the object put in the marging seems to be always the
same.
To me, this looks like a bug. And otherwise, if I am doing something
wr= ong, then of course this report can be seen as a 'help/support
= request'. Thanks!

In GNU Emacs 29.0.50 (build = 1, x86_64-pc-linux-gnu, GTK+ Version
=C2=A03.24.34, cairo version 1.17.6= ) of 2022-09-10 built on fedora
Repository revision: 4cf9c92e27d20da9453= f9abe89d84bee5d776329
Repository branch: master
Windowing system dist= ributor 'The X.Org Foundation', version 11.0.12014000
System Des= cription: Fedora Linux 37 (Workstation Edition)

Configured using:=C2=A0'configure --with-modules --with-cairo --with-native-compilation=
=C2=A0--with-json'

Configured features:
ACL CAIRO DBUS FR= EETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBSELINUX LIBXM= L2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND SQL= ITE3 THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM
XINPUT2 XPM GTK3 ZLIB=

Important settings:
=C2=A0 value of $LANG: en_US.UTF-8
=C2=A0= value of $XMODIFIERS: @im=3Dibus
=C2=A0 locale-coding-system: utf-8-uni= x

Major mode: Fundamental

Minor modes in effect:
=C2=A0 to= oltip-mode: t
=C2=A0 global-eldoc-mode: t
=C2=A0 show-paren-mode: t=C2=A0 electric-indent-mode: t
=C2=A0 mouse-wheel-mode: t
=C2=A0 to= ol-bar-mode: t
=C2=A0 menu-bar-mode: t
=C2=A0 file-name-shadow-mode: = t
=C2=A0 global-font-lock-mode: t
=C2=A0 blink-cursor-mode: t
=C2= =A0 buffer-read-only: t
=C2=A0 line-number-mode: t
=C2=A0 indent-tabs= -mode: t
=C2=A0 transient-mark-mode: t
=C2=A0 auto-composition-mode: = t
=C2=A0 auto-encryption-mode: t
=C2=A0 auto-compression-mode: t
<= br>Load-path shadows:
None found.

Features:
(shadow sort mail-= extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc82= 2 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-uti= l text-property-search time-date mm-decode mm-bodies
mm-encode mail-pars= e rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
comp comp-cstr war= nings icons subr-x rx cl-seq cl-macs gv cl-extra
help-mode bytecomp byte= -compile cconv cl-lib sendmail rfc2047 rfc2045
ietf-drums mm-util mail-p= rsvr mail-utils rmc iso-transl tooltip eldoc
paren electric uniquify edi= ff-hook vc-hooks lisp-float-type elisp-mode
mwheel term/x-win x-win term= /common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated= -list replace newcomment text-mode lisp-mode
prog-mode register page tab= -bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse= jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer na= dvice seq simple cl-generic
indonesian philippine cham georgian utf-8-la= ng misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-= ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian c= yrillic chinese
composite emoji-zwj charscript charprop case-table epa-h= ook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loadd= efs
faces cus-face macroexp files window text-properties overlay sha1 md= 5
base64 format env code-pages mule custom widget keymap
hashtable-pr= int-readable backquote threads dbusbind inotify
dynamic-setting system-f= ont-setting font-render-setting cairo
move-toolbar gtk x-toolkit xinput2= x multi-tty make-network-process
native-compile emacs)

Memory in= formation:
((conses 16 77301 10328)
=C2=A0(symbols 48 7112 0)
=C2= =A0(strings 32 19407 1642)
=C2=A0(string-bytes 1 593504)
=C2=A0(vecto= rs 16 15411)
=C2=A0(vector-slots 8 317149 17892)
=C2=A0(floats 8 28 5= 8)
=C2=A0(intervals 56 372 3)
=C2=A0(buffers 1000 13))


--000000000000036ccb05f56091f5-- From unknown Mon Jun 23 11:27:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#61735: 29.0.50; String object in margin not associated correctly with buffer text Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 23 Feb 2023 17:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61735 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: dalanicolai , Stefan Monnier Cc: 61735@debbugs.gnu.org Received: via spool by 61735-submit@debbugs.gnu.org id=B61735.167717434515259 (code B ref 61735); Thu, 23 Feb 2023 17:46:02 +0000 Received: (at 61735) by debbugs.gnu.org; 23 Feb 2023 17:45:45 +0000 Received: from localhost ([127.0.0.1]:35224 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVFf6-0003y2-M6 for submit@debbugs.gnu.org; Thu, 23 Feb 2023 12:45:44 -0500 Received: from eggs.gnu.org ([209.51.188.92]:46988) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVFf5-0003xq-Bz for 61735@debbugs.gnu.org; Thu, 23 Feb 2023 12:45:43 -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 ) id 1pVFew-00065b-Am; Thu, 23 Feb 2023 12:45:37 -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=PzF+9ySyHe5H5mepf6uVDjw+4aQtABIK2HjHmRh1ZhI=; b=hBMv+jDDuoRM In9TDcRFPRfiGYbCgEOaGxgj+mozrWGm3w9Nf0L6+Uiz2R2XiVTTq42nbHxpxQuHu0MpK11N8Agig L1JIVjmJymhlHBLpYg3YVs6kv4eqD2sbbt6zLiiTXJhNRH0QLR+k/ROXXxDUY3fPyYi8bBjngvuJz DW+DjEWlrF7l86ULX07Rrj4KURjrTIpR87s60KfmOmxTYl5dFZL1hH1pDKGF4khWtfTxt5GK43Jci ZrYvrdGgED5OYkkz77TJY8x3oVSR2t5/w9qfxLK+9KaF6IgjYJGt4rNQXpNNC28G7C/SLeXwDCAyA pnSZSRbJU0MqDqq7CdXRJw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVFeu-0006kB-KP; Thu, 23 Feb 2023 12:45:33 -0500 Date: Thu, 23 Feb 2023 19:45:29 +0200 Message-Id: <83h6vcp96u.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from dalanicolai on Thu, 23 Feb 2023 17:32:50 +0100) References: X-Spam-Score: -2.3 (--) 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: -3.3 (---) > From: dalanicolai > Date: Thu, 23 Feb 2023 17:32:50 +0100 > > (defun baleen-render (data) > (pop-to-buffer (get-buffer-create "*baleen*")) > (set-window-margins nil 5) > (dolist (page data) > (dolist (match (cdr page)) > (let ((o (make-overlay (point) > (progn (insert match) > (point))))) > (let ((s " ")) > (put-text-property 0 1 > 'display `((margin left-margin) ,(format " %d" (car page))) > s) > (overlay-put o 'before-string s))) > (insert "\n")))) > > (baleen-render '((1 "test1" "test2") (2 "test3"))) > ``` > > Here, for every 'match' in a 'page' I am creating a new string 's' > to which I add the margin display property to 'associate' it > with some buffer text by using it as the value for its before-string > property. > However, although each 's' should get a different display property value > via (format " %d" (car page)), all margin entries end up showing the > same value of 2 (while the first two lines should show page number 1). > > To reproduce the error, simply evaluate the code above. Using edebug on > 'baleen-render' it can be seen that the code seems correct, i.e. (car > page) correctly returns the correct page number. > > It seems that although I am creating a different string object on each > iteration, somehow the object put in the marging seems to be always the > same. Is it really true that you create a different string object every time? Add a copy-sequence call there, like this: (let ((s (copy-sequence " "))) and the code does what you expect. Stefan, am I missing something here? From unknown Mon Jun 23 11:27:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#61735: 29.0.50; String object in margin not associated correctly with buffer text Resent-From: dalanicolai Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 23 Feb 2023 18:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61735 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 61735@debbugs.gnu.org, Stefan Monnier Received: via spool by 61735-submit@debbugs.gnu.org id=B61735.167717553026717 (code B ref 61735); Thu, 23 Feb 2023 18:06:02 +0000 Received: (at 61735) by debbugs.gnu.org; 23 Feb 2023 18:05:30 +0000 Received: from localhost ([127.0.0.1]:35245 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVFyE-0006wq-03 for submit@debbugs.gnu.org; Thu, 23 Feb 2023 13:05:30 -0500 Received: from mail-wr1-f50.google.com ([209.85.221.50]:41690) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVFyC-0006wZ-PF for 61735@debbugs.gnu.org; Thu, 23 Feb 2023 13:05:29 -0500 Received: by mail-wr1-f50.google.com with SMTP id bt28so4720029wrb.8 for <61735@debbugs.gnu.org>; Thu, 23 Feb 2023 10:05:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1bwTT+U3sqVoVpqAZOKIWTBEol2wdNlf7zNN8IchQqk=; b=PnofIJU8QHnxobQ6j0PVZoatcCg7Z3QaNQQVFyKdx9I9awwjZzsWa5X/fSxMXTdWLT ndB7onvPgoWIaqntxBkJoBHVl5RfzjhVGkqm8pqLTApaUjTVZegQmN0E0n/vCUBYG/3O rqnybgZmN6zCVkWGzCRdLlwmC67BxNrL4esVaD8PYkJWXeh1wNUkFEBKXnkERlCXovlY 6hiqBvSYXK5fw+wxTnQLpXRbpNbqhnzfcbDNvR5NAnWU7jmhDNfeqcEZm3hH+ED3FoVD rBC1aaLEFL0n3WcU/6IJ9d2xP1I6pvULDgHcxpi5ITHMDIVgwYGzCOig16rWaPSdKyA6 OSGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1bwTT+U3sqVoVpqAZOKIWTBEol2wdNlf7zNN8IchQqk=; b=nzUu4a0tX9p+P5AtV2f1VauFdHOnSh+Na+ZEWWjE87jiwm9McjJjECtc2X8TMdCl+L 74wfvzCHCYHIwUMj1rnf9pEzsWw2e/BsMyvjJEt2Czhom0ZOIYCEM71+QnASP6CLwvBH Tg6SdDeFAKnvjqvFvc+OPRfym8Ba/ZVohTYShT5Xllmi22tPIWScKInc2IwIyRp8l+c1 YpPEkUOL6s2ZL3DM21JF+x/p2hFC/M0gn/Iot6hMt8eJNDxof/CXI35pQRR4djKzZs1/ b8PHDI2uu7DXt2FFvuBbSvc2chKKIs8KtECgYwGBBD/FjF/KhUlWTkb4zcEfeZEKmqpl SGzw== X-Gm-Message-State: AO0yUKWr49KVEhkYNQbfj3xLHJWLIECaLX+bO/2KK9vaLMNlcg2QMbuy RD6+xWkN9kF4s9gkW+Cvge8ZMznnICIL2trh6rQ= X-Google-Smtp-Source: AK7set/L6UIiugK/YcS/CWyEAjqxhMEiCJCZh8UqqdHvEkOara87kDqTBUs2xNtUf/Giy/QVavNBU0nM8LphWfc6RWw= X-Received: by 2002:a5d:6410:0:b0:2c5:8377:3eaf with SMTP id z16-20020a5d6410000000b002c583773eafmr590707wru.2.1677175522670; Thu, 23 Feb 2023 10:05:22 -0800 (PST) MIME-Version: 1.0 References: <83h6vcp96u.fsf@gnu.org> In-Reply-To: <83h6vcp96u.fsf@gnu.org> From: dalanicolai Date: Thu, 23 Feb 2023 19:05:11 +0100 Message-ID: Content-Type: multipart/alternative; boundary="000000000000413cff05f561db54" X-Spam-Score: 0.0 (/) 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 (-) --000000000000413cff05f561db54 Content-Type: text/plain; charset="UTF-8" Aha, it appears that I do not really understand how storing strings in memory works. Indeed, I assumed that I was creating new strings because (eq " " " ") is nil. I guess I have to read up on it (again). Obviously... thanks again for your quick helpful response! On Thu, 23 Feb 2023 at 18:45, Eli Zaretskii wrote: > > From: dalanicolai > > Date: Thu, 23 Feb 2023 17:32:50 +0100 > > > > (defun baleen-render (data) > > (pop-to-buffer (get-buffer-create "*baleen*")) > > (set-window-margins nil 5) > > (dolist (page data) > > (dolist (match (cdr page)) > > (let ((o (make-overlay (point) > > (progn (insert match) > > (point))))) > > (let ((s " ")) > > (put-text-property 0 1 > > 'display `((margin left-margin) ,(format " > %d" (car page))) > > s) > > (overlay-put o 'before-string s))) > > (insert "\n")))) > > > > (baleen-render '((1 "test1" "test2") (2 "test3"))) > > ``` > > > > Here, for every 'match' in a 'page' I am creating a new string 's' > > to which I add the margin display property to 'associate' it > > with some buffer text by using it as the value for its before-string > > property. > > However, although each 's' should get a different display property value > > via (format " %d" (car page)), all margin entries end up showing the > > same value of 2 (while the first two lines should show page number 1). > > > > To reproduce the error, simply evaluate the code above. Using edebug on > > 'baleen-render' it can be seen that the code seems correct, i.e. (car > > page) correctly returns the correct page number. > > > > It seems that although I am creating a different string object on each > > iteration, somehow the object put in the marging seems to be always the > > same. > > Is it really true that you create a different string object every > time? Add a copy-sequence call there, like this: > > (let ((s (copy-sequence " "))) > > and the code does what you expect. > > Stefan, am I missing something here? > --000000000000413cff05f561db54 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Aha, it appears that I do not really understand how s= toring strings in memory works.
Indeed, I assumed that I was crea= ting new strings because (eq " " " ") is nil.
I guess I have to read up on it (again).

Obviousl= y... thanks again for your quick helpful response!

On Thu, 23 Feb = 2023 at 18:45, Eli Zaretskii <eliz@gnu.o= rg> wrote:
dalanicolai@gmail.com>
> Date: Thu, 23 Feb 2023 17:32:50 +0100
>
> (defun baleen-render (data)
>=C2=A0 =C2=A0(pop-to-buffer (get-buffer-create "*baleen*")) >=C2=A0 =C2=A0(set-window-margins nil 5)
>=C2=A0 =C2=A0(dolist (page data)
>=C2=A0 =C2=A0 =C2=A0(dolist (match (cdr page))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(let ((o (make-overlay (point)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (progn (insert match)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(point))))) >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(let ((s " "))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(put-text-property 0 1
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 'display `((margin left-margin) ,(fo= rmat " %d" (car page)))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 s)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(overlay-put o 'before-str= ing s)))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(insert "\n"))))
>
> (baleen-render '((1 "test1" "test2") (2 "= test3")))
> ```
>
> Here, for every 'match' in a 'page' I am creating a ne= w string 's'
> to which I add the margin display property to 'associate' it > with some buffer text by using it as the value for its before-string > property.
> However, although each 's' should get a different display prop= erty value
> via (format " %d" (car page)), all margin entries end up sho= wing the
> same value of 2 (while the first two lines should show page number 1).=
>
> To reproduce the error, simply evaluate the code above. Using edebug o= n
> 'baleen-render' it can be seen that the code seems correct, i.= e. (car
> page) correctly returns the correct page number.
>
> It seems that although I am creating a different string object on each=
> iteration, somehow the object put in the marging seems to be always th= e
> same.

Is it really true that you create a different string object every
time?=C2=A0 Add a copy-sequence call there, like this:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (let ((s (copy-sequence " ")))

and the code does what you expect.

Stefan, am I missing something here?
--000000000000413cff05f561db54-- From unknown Mon Jun 23 11:27:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#61735: 29.0.50; String object in margin not associated correctly with buffer text Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 23 Feb 2023 18:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61735 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: dalanicolai Cc: 61735@debbugs.gnu.org, Eli Zaretskii Received: via spool by 61735-submit@debbugs.gnu.org id=B61735.167717741530023 (code B ref 61735); Thu, 23 Feb 2023 18:37:02 +0000 Received: (at 61735) by debbugs.gnu.org; 23 Feb 2023 18:36:55 +0000 Received: from localhost ([127.0.0.1]:35291 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVGSc-0007oB-VT for submit@debbugs.gnu.org; Thu, 23 Feb 2023 13:36:55 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:62200) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVGSa-0007nw-Vd for 61735@debbugs.gnu.org; Thu, 23 Feb 2023 13:36:53 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 7DF4F442D1E; Thu, 23 Feb 2023 13:36:47 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 20BCE44167D; Thu, 23 Feb 2023 13:36:46 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1677177406; bh=XC1VTgx3OhNccUx5ahSB5gkHpjwsUxGZBejTSP/jGZ0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=UYfdki5MqpBASoLUnQ7S3U6crZmLubNtqTNQ1hJpYOTyVzW4eUfmGFNZXBwXVj8xy THLRwHYoTliYIQf3CUL2PBg2xcAi0iTqMsiUyf5t9PgA982Es3BcvyjIV6B2hpq2q2 1YrO4iw0pU0FzO7ExwNzBWYK9aABn2NS71PNp76i7gqGwGE8E/Wdri6n1TsTr2yeeL iduDq8VlwlMp6YAEatXRY0YN/YWcbYD6f1ZYqk95bzYnEqqRIe29150qkOrshsJ/pT h16/FKW9R2wjQYMHyMuiWP6wIuZ8fnpni7b/8sQNnDgCl0Iz3cRrPfH3PmBajVITkW xN0tUD4z7+tRQ== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E9A7D120B04; Thu, 23 Feb 2023 13:36:45 -0500 (EST) From: Stefan Monnier In-Reply-To: (dalanicolai@gmail.com's message of "Thu, 23 Feb 2023 19:05:11 +0100") Message-ID: References: <83h6vcp96u.fsf@gnu.org> Date: Thu, 23 Feb 2023 13:36:44 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.144 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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: -3.3 (---) > Indeed, I assumed that I was creating new strings because (eq " " " ") > is nil. Your test can return nil even if new strings aren't created at runtime (e.g. because each source code string gets its own runtime string). It may be nil in your test, but it may also return t (I think if you byte-compile your test it will return t). >> > (let ((s " ")) Here you have a single " " string in your source code. And no it's not recreated each time, it will be the same one reused everytime (and modified by `put-text-property`). You can use `propertize` instead. Stefan From unknown Mon Jun 23 11:27:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#61735: 29.0.50; String object in margin not associated correctly with buffer text Resent-From: dalanicolai Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 23 Feb 2023 19:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61735 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 61735@debbugs.gnu.org, Eli Zaretskii Received: via spool by 61735-submit@debbugs.gnu.org id=B61735.16771822596320 (code B ref 61735); Thu, 23 Feb 2023 19:58:02 +0000 Received: (at 61735) by debbugs.gnu.org; 23 Feb 2023 19:57:39 +0000 Received: from localhost ([127.0.0.1]:35406 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVHil-0001dr-Br for submit@debbugs.gnu.org; Thu, 23 Feb 2023 14:57:39 -0500 Received: from mail-wm1-f49.google.com ([209.85.128.49]:45974) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVHik-0001de-30 for 61735@debbugs.gnu.org; Thu, 23 Feb 2023 14:57:38 -0500 Received: by mail-wm1-f49.google.com with SMTP id d41-20020a05600c4c2900b003e9e066550fso263679wmp.4 for <61735@debbugs.gnu.org>; Thu, 23 Feb 2023 11:57:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4nZUIpC0cNjJgFEYObJBqNgvfq0H1KWTQQiM6q/lalk=; b=Lz0omd3BrRV45bbdeAnVjvWDhS/QZ3O1TGMBhZZF9mVRncfi/b3zgGyz1sY2ZawdSP 2X+Ns+1Ph3A6LQIwapSmRXm+4AQS+PDQWFV7UoVqBa7rYO492Frnz6Tkgcc3zWmtPfrL vX5yUt1AquhGJG9zHXuSQar8ZOWzcdNWWmY33cVoRbzmDqcv9KdNdi2RZXE5vTqXYUFS J54639Fn7KeSjj3FJ42nmAlAVLZUkYSEYj+8CG3G8XDqIM9kun7GIy9cKc+5YqtkBO82 jW2ntfowrVKDGNGUpTjd/Cwse7TCMOz1py4ge1Q4yAaHLA+ZJIv7zt3Uw/F1a3JjliGu zdYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4nZUIpC0cNjJgFEYObJBqNgvfq0H1KWTQQiM6q/lalk=; b=lCoe0Rza3PuxmiFT5H7sGpENYnFaWyD4IqhsRewwaJ5MTpjDXugu3KGVzUukBVKIRZ 8kGCEfGuRZfo+HhqADGabDCrHsSISvSFF5GIT+TuDmq5NTvPAVubpgdv6ERWkiyKqexL q8n7KALdfaFGVOYm26OSjxhMM5RGVZ10f7jCa03KQ+lMZLvs9N9fZvmCTJTXqBxhqJJf FkIbXN9QV8a0CaijmG7kxwUrUngiCAQWKEi8X3zkksmEul04WpYzlrOiKBjYo/TyB9y2 jWUUbDYgAb4lifc95KHq5ShBKtdVKZP2KQekNVgFYhwv3M9Jbklnr9d2fgLjtGJrE+iU yjEA== X-Gm-Message-State: AO0yUKXzRiKrU6f3FIxpAAor+zNTZXLFO70kMueR5dY+R2i4YM2xOH34 WbBl8GYkP90hrrNBZlhbEMIjuGCsNz21o5Np8tg= X-Google-Smtp-Source: AK7set82OaKO/+yphCp3W9Gw9/se1ItrhdRdfiaghcZ5AtQ79WxkYFQiipJOFNhSRjI3VpXeno4b62jVjGiHiiMxH4g= X-Received: by 2002:a05:600c:502c:b0:3df:fc69:e977 with SMTP id n44-20020a05600c502c00b003dffc69e977mr551262wmr.5.1677182252087; Thu, 23 Feb 2023 11:57:32 -0800 (PST) MIME-Version: 1.0 References: <83h6vcp96u.fsf@gnu.org> In-Reply-To: From: dalanicolai Date: Thu, 23 Feb 2023 20:57:20 +0100 Message-ID: Content-Type: multipart/alternative; boundary="0000000000005bfd6f05f5636c03" X-Spam-Score: 0.0 (/) 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 (-) --0000000000005bfd6f05f5636c03 Content-Type: text/plain; charset="UTF-8" Thanks for that explanation. Indeed, I found it hard to find a thorough explanation anywhere. Also, thanks for reminding me about propertize. On Thu, 23 Feb 2023 at 19:36, Stefan Monnier wrote: > > Indeed, I assumed that I was creating new strings because (eq " " " ") > > is nil. > > Your test can return nil even if new strings aren't created at runtime > (e.g. because each source code string gets its own runtime string). > > It may be nil in your test, but it may also return t (I think if you > byte-compile your test it will return t). > > >> > (let ((s " ")) > > Here you have a single " " string in your source code. And no it's not > recreated each time, it will be the same one reused everytime (and > modified by `put-text-property`). > > You can use `propertize` instead. > > > Stefan > > --0000000000005bfd6f05f5636c03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for that explanation. Indeed, I found it hard = to find a thorough
explanation anywhere. Also, thanks for remindi= ng me about propertize.


<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, 23 Feb 2023 at 19:36, Stefan M= onnier <monnier@iro.umontrea= l.ca> wrote:
> Indeed, I assumed that I was creating new strings because (eq &quo= t; " " ")
> is nil.

Your test can return nil even if new strings aren't created at runtime<= br> (e.g. because each source code string gets its own runtime string).

It may be nil in your test, but it may also return t (I think if you
byte-compile your test it will return t).

>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(let ((s " "))

Here you have a single " " string in your source code.=C2=A0 And = no it's not
recreated each time, it will be the same one reused everytime (and
modified by `put-text-property`).

You can use `propertize` instead.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan

--0000000000005bfd6f05f5636c03-- From unknown Mon Jun 23 11:27:16 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: dalanicolai Subject: bug#61735: closed (Re: bug#61735: 29.0.50; String object in margin not associated correctly with buffer text) Message-ID: References: X-Gnu-PR-Message: they-closed 61735 X-Gnu-PR-Package: emacs Reply-To: 61735@debbugs.gnu.org Date: Tue, 12 Sep 2023 01:07:01 +0000 Content-Type: multipart/mixed; boundary="----------=_1694480821-29963-1" This is a multi-part message in MIME format... ------------=_1694480821-29963-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #61735: 29.0.50; String object in margin not associated correctly with buff= er text which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 61735@debbugs.gnu.org. --=20 61735: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D61735 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1694480821-29963-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 61735-done) by debbugs.gnu.org; 12 Sep 2023 01:06:23 +0000 Received: from localhost ([127.0.0.1]:55499 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qfrrD-0007mL-1B for submit@debbugs.gnu.org; Mon, 11 Sep 2023 21:06:23 -0400 Received: from mail-lf1-x12a.google.com ([2a00:1450:4864:20::12a]:51222) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qfrrB-0007m8-BT for 61735-done@debbugs.gnu.org; Mon, 11 Sep 2023 21:06:21 -0400 Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-5008d16cc36so8596174e87.2 for <61735-done@debbugs.gnu.org>; Mon, 11 Sep 2023 18:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694480771; x=1695085571; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=POIoZf1ASYK0pRfTiHMS3bXRluwrU+/0beqxnq+Cggw=; b=iXqzA+koDn0Q9nADUQxPMG2HUwnp3Z8FXAa/bAg53M+cV9L5PKGUrgTwDBQab8JyLJ 7a5Wcj0ZVekA9q325EqEG+F0K+qWuZ6V2WSGldXDFJ596Xu+xdigwQe5qh+58tz11Z0N pnrJ9rcOFL3sKxu/GoMQpDoer0hN3SGzukWuv7KPMpRnVoQLxihtzVdeoe4MRR6Aw6jh 4vJsw1gzmc9hoH+8TqIw/H2hPL051faIEwljhW/yAhVFLB6wnYCRgnK8/gyGWzzSqvtF TJa1TNAfbaOfogjPOzBXsNOK4WfejMH7TX6+0nZwFtEqYxonrXajyT8qVieIcYsmA2bj obRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694480771; x=1695085571; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=POIoZf1ASYK0pRfTiHMS3bXRluwrU+/0beqxnq+Cggw=; b=XfnHj7FS8R/QAsrFln2S8YP8wZqwEn3YozzB17gCUzODPXL/IAEodpUf7qdyJmOmqr vDxRGNoF+lqe+ERCL2v09nyKygj7u0WNk3a6v6yp1j5KjMFE1F+JBqcIDGD0kDuxIJSz Jf1yHgChfIGLi0fm1UQyfGiAEz0oHTXpPlzNekuCcBxkrgxtVTmuVxNeFiwrU9odapm/ QjWr/CeCilyHUJnJXl/r9s/Wr2iuWaDRvvo48kX3sUZGuO+5L6PSRbA/xTDGf7j35hMw PfWq9zLSfDKiBAnxi1yF61J794qEB+9N3eGPuVJXnRVl6wrXkTSONpFhVdD9IFRpyPmh bs4w== X-Gm-Message-State: AOJu0Yx7/nIhipFjNkH9OC2bd6+Kxj5yOgX/IPch2p/uoWYBrZ4ZB83b /CfPvFGzS/iqKOZsF/QlDEFCsjg9hi5cfYB1Q9M= X-Google-Smtp-Source: AGHT+IHbHCyQHW4N13kMF0zkSFuYXN0c4LnSKRJHUKGYpE4kgh2KPqaQYzFLL2TRC27gOmlZH1WHwMQm0mjnNFboKy8= X-Received: by 2002:a2e:861a:0:b0:2b9:f27f:e491 with SMTP id a26-20020a2e861a000000b002b9f27fe491mr9207137lji.42.1694480770860; Mon, 11 Sep 2023 18:06:10 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Mon, 11 Sep 2023 18:06:10 -0700 From: Stefan Kangas In-Reply-To: (dalanicolai@gmail.com's message of "Thu, 23 Feb 2023 20:57:20 +0100") References: <83h6vcp96u.fsf@gnu.org> MIME-Version: 1.0 Date: Mon, 11 Sep 2023 18:06:10 -0700 Message-ID: Subject: Re: bug#61735: 29.0.50; String object in margin not associated correctly with buffer text To: dalanicolai Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61735-done Cc: Eli Zaretskii , 61735-done@debbugs.gnu.org, Stefan Monnier 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 (-) dalanicolai writes: > Thanks for that explanation. Indeed, I found it hard to find a thorough > explanation anywhere. Also, thanks for reminding me about propertize. I think the conclusion here is that this was not a bug, so I'm closing this now. If this conclusion is incorrect, please reply to this email (use "Reply to all" in your email client) and we can reopen the bug report. ------------=_1694480821-29963-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 23 Feb 2023 16:33:14 +0000 Received: from localhost ([127.0.0.1]:35123 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVEWv-0001sW-Hy for submit@debbugs.gnu.org; Thu, 23 Feb 2023 11:33:14 -0500 Received: from lists.gnu.org ([209.51.188.17]:44506) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVEWs-0001sM-P7 for submit@debbugs.gnu.org; Thu, 23 Feb 2023 11:33:12 -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 ) id 1pVEWp-0006d1-WA for bug-gnu-emacs@gnu.org; Thu, 23 Feb 2023 11:33:10 -0500 Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pVEWm-0007YG-Ru for bug-gnu-emacs@gnu.org; Thu, 23 Feb 2023 11:33:07 -0500 Received: by mail-wm1-x335.google.com with SMTP id m25-20020a7bcb99000000b003e7842b75f2so6889344wmi.3 for ; Thu, 23 Feb 2023 08:33:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=cuTBIA3LCjAYeleO3eBk2x4m+X18AAg6ZRXkP6hJKno=; b=hck+GSwO+iyu3SzJzXcEUTd34/CMFPAZ7jVdluHxUPfReqDZGXl0RoRxkzBDHHEDrH P/gpVf13wFMRLT9/UxqA8qR95lRCGGmRxeifIc9vrIoEnF/Ml2951X/X15iPDci64bvf 9pnOZFruxumgg5lLmQKygb8Q5zMJrQ807cpEOVWesPCHjK3Tz6qQPeqGY6Gy9ilDzac3 r/AURDdxd3gQHQpj0usjr/V6HimjYb7DvKjj7TBE2B2mWgV353b4wmifCsF11kgYXDoz 3n4ZeNx4SFe/MyE3DWhEPQihnD1n7AHG95k3nVo8DErOIIHr2veF9ms0FZB3Yn2kf5b3 ARcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=cuTBIA3LCjAYeleO3eBk2x4m+X18AAg6ZRXkP6hJKno=; b=VkJ/JMhPzPjnIWhJKUZMv1Q7rZp0EdykQ6VK0I1zEV0LAVFQ0mRyiSS9nvtjjdoesg sa3Ee2FSLjdbUo9zwypozKhvG4kHn7ULxjeJOjg8s9yXkgLcDszAqKxW0GlpKu9wRs2y L1RYiS3jorP2cXMEi3EZgdEgza6zUHb8Y/degP9aT8KyCVjMFXGblRmnFCiELMMoVO+V t0AV99ECHlj3D3K0ZMZpXdGLkgG593Cre9gUqB3WOKPvPQ0RS41loQAuJ0TMGkEeDM5d QPHniW1Gt1KvbSfLZdHnwTGDPynMpbNLsmRvt7oLS5nEIC4KBrSEclnmdNxl08HRla5X ijsw== X-Gm-Message-State: AO0yUKUbenj88RQbSFrXmKGG0LRzobW+cEnD4LrnTEkouo5XcEllZLGp 9un9wplSSy6wYe9QR6bIes1x2d4TGIJY28zHrL4ews4nDWo6Ew== X-Google-Smtp-Source: AK7set913tISyN+mkSKkm+Cedm6O4G5QQFUdlxqEuil7nCq5VSjVobSNXeAZIWHvb4A6Jqy3Hhwlgi8JONIfs9VbbKA= X-Received: by 2002:a05:600c:cc8:b0:3dc:56e6:797a with SMTP id fk8-20020a05600c0cc800b003dc56e6797amr571602wmb.196.1677169982138; Thu, 23 Feb 2023 08:33:02 -0800 (PST) MIME-Version: 1.0 From: dalanicolai Date: Thu, 23 Feb 2023 17:32:50 +0100 Message-ID: Subject: 29.0.50; String object in margin not associated correctly with buffer text To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary="000000000000036ccb05f56091f5" Received-SPF: pass client-ip=2a00:1450:4864:20::335; envelope-from=dalanicolai@gmail.com; helo=mail-wm1-x335.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit 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: -2.3 (--) --000000000000036ccb05f56091f5 Content-Type: text/plain; charset="UTF-8" The section 'Displaying in the Margins ' of the elisp manual mentions that 'To display something in the margin in association with certain buffer text ... put a before-string property on the text and put the margin display specification on the contents of the before-string'. So this is what I am trying to achieve using the following code ``` (defun baleen-render (data) (pop-to-buffer (get-buffer-create "*baleen*")) (set-window-margins nil 5) (dolist (page data) (dolist (match (cdr page)) (let ((o (make-overlay (point) (progn (insert match) (point))))) (let ((s " ")) (put-text-property 0 1 'display `((margin left-margin) ,(format " %d" (car page))) s) (overlay-put o 'before-string s))) (insert "\n")))) (baleen-render '((1 "test1" "test2") (2 "test3"))) ``` Here, for every 'match' in a 'page' I am creating a new string 's' to which I add the margin display property to 'associate' it with some buffer text by using it as the value for its before-string property. However, although each 's' should get a different display property value via (format " %d" (car page)), all margin entries end up showing the same value of 2 (while the first two lines should show page number 1). To reproduce the error, simply evaluate the code above. Using edebug on 'baleen-render' it can be seen that the code seems correct, i.e. (car page) correctly returns the correct page number. It seems that although I am creating a different string object on each iteration, somehow the object put in the marging seems to be always the same. To me, this looks like a bug. And otherwise, if I am doing something wrong, then of course this report can be seen as a 'help/support request'. Thanks! In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.34, cairo version 1.17.6) of 2022-09-10 built on fedora Repository revision: 4cf9c92e27d20da9453f9abe89d84bee5d776329 Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12014000 System Description: Fedora Linux 37 (Workstation Edition) Configured using: 'configure --with-modules --with-cairo --with-native-compilation --with-json' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB Important settings: value of $LANG: en_US.UTF-8 value of $XMODIFIERS: @im=ibus locale-coding-system: utf-8-unix Major mode: Fundamental Minor modes in effect: tooltip-mode: t global-eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t blink-cursor-mode: t buffer-read-only: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message mailcap yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util text-property-search time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs comp comp-cstr warnings icons subr-x rx cl-seq cl-macs gv cl-extra help-mode bytecomp byte-compile cconv cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils rmc iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads dbusbind inotify dynamic-setting system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process native-compile emacs) Memory information: ((conses 16 77301 10328) (symbols 48 7112 0) (strings 32 19407 1642) (string-bytes 1 593504) (vectors 16 15411) (vector-slots 8 317149 17892) (floats 8 28 58) (intervals 56 372 3) (buffers 1000 13)) --000000000000036ccb05f56091f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The section 'Displaying in the Margins= ' of the elisp manual mentions
that 'To display something in= the margin in association with certain
buffer text ... put a before-str= ing property on the text and put the
margin display specification on the= contents of the before-string'.

So this is what I am trying to = achieve using the following code

```
(defun baleen-render (data)<= br>=C2=A0 (pop-to-buffer (get-buffer-create "*baleen*"))
=C2= =A0 (set-window-margins nil 5)
=C2=A0 (dolist (page data)
=C2=A0 =C2= =A0 (dolist (match (cdr page))
=C2=A0 =C2=A0 =C2=A0 (let ((o (make-overl= ay (point)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(progn (insert match)
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (point)))))
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 (let ((s " "))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 (put-text-property 0 1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'display = `((margin left-margin) ,(format " %d" (car page)))
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0s)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (overlay-put o= 'before-string s)))
=C2=A0 =C2=A0 =C2=A0 (insert "\n"))))=

(baleen-render '((1 "test1" "test2") (2 &qu= ot;test3")))
```

Here, for every 'match' in a 'p= age' I am creating a new string 's'
to which I add the margi= n display property to 'associate' it
with some buffer text by us= ing it as the value for its before-string
property.
However, although= each 's' should get a different display property value
via (for= mat " %d" (car page)), all margin entries end up showing the
s= ame value of 2 (while the first two lines should show page number 1).
To reproduce the error, simply evaluate the code above. Using edebug on'baleen-render' it can be seen that the code seems correct, i.e. = (car
page) correctly returns the correct page number.

It seems th= at although I am creating a different string object on each
iteration, s= omehow the object put in the marging seems to be always the
same.
To me, this looks like a bug. And otherwise, if I am doing something
wr= ong, then of course this report can be seen as a 'help/support
= request'. Thanks!

In GNU Emacs 29.0.50 (build = 1, x86_64-pc-linux-gnu, GTK+ Version
=C2=A03.24.34, cairo version 1.17.6= ) of 2022-09-10 built on fedora
Repository revision: 4cf9c92e27d20da9453= f9abe89d84bee5d776329
Repository branch: master
Windowing system dist= ributor 'The X.Org Foundation', version 11.0.12014000
System Des= cription: Fedora Linux 37 (Workstation Edition)

Configured using:=C2=A0'configure --with-modules --with-cairo --with-native-compilation=
=C2=A0--with-json'

Configured features:
ACL CAIRO DBUS FR= EETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBSELINUX LIBXM= L2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND SQL= ITE3 THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM
XINPUT2 XPM GTK3 ZLIB=

Important settings:
=C2=A0 value of $LANG: en_US.UTF-8
=C2=A0= value of $XMODIFIERS: @im=3Dibus
=C2=A0 locale-coding-system: utf-8-uni= x

Major mode: Fundamental

Minor modes in effect:
=C2=A0 to= oltip-mode: t
=C2=A0 global-eldoc-mode: t
=C2=A0 show-paren-mode: t=C2=A0 electric-indent-mode: t
=C2=A0 mouse-wheel-mode: t
=C2=A0 to= ol-bar-mode: t
=C2=A0 menu-bar-mode: t
=C2=A0 file-name-shadow-mode: = t
=C2=A0 global-font-lock-mode: t
=C2=A0 blink-cursor-mode: t
=C2= =A0 buffer-read-only: t
=C2=A0 line-number-mode: t
=C2=A0 indent-tabs= -mode: t
=C2=A0 transient-mark-mode: t
=C2=A0 auto-composition-mode: = t
=C2=A0 auto-encryption-mode: t
=C2=A0 auto-compression-mode: t
<= br>Load-path shadows:
None found.

Features:
(shadow sort mail-= extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc82= 2 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-uti= l text-property-search time-date mm-decode mm-bodies
mm-encode mail-pars= e rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
comp comp-cstr war= nings icons subr-x rx cl-seq cl-macs gv cl-extra
help-mode bytecomp byte= -compile cconv cl-lib sendmail rfc2047 rfc2045
ietf-drums mm-util mail-p= rsvr mail-utils rmc iso-transl tooltip eldoc
paren electric uniquify edi= ff-hook vc-hooks lisp-float-type elisp-mode
mwheel term/x-win x-win term= /common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated= -list replace newcomment text-mode lisp-mode
prog-mode register page tab= -bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse= jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer na= dvice seq simple cl-generic
indonesian philippine cham georgian utf-8-la= ng misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-= ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian c= yrillic chinese
composite emoji-zwj charscript charprop case-table epa-h= ook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loadd= efs
faces cus-face macroexp files window text-properties overlay sha1 md= 5
base64 format env code-pages mule custom widget keymap
hashtable-pr= int-readable backquote threads dbusbind inotify
dynamic-setting system-f= ont-setting font-render-setting cairo
move-toolbar gtk x-toolkit xinput2= x multi-tty make-network-process
native-compile emacs)

Memory in= formation:
((conses 16 77301 10328)
=C2=A0(symbols 48 7112 0)
=C2= =A0(strings 32 19407 1642)
=C2=A0(string-bytes 1 593504)
=C2=A0(vecto= rs 16 15411)
=C2=A0(vector-slots 8 317149 17892)
=C2=A0(floats 8 28 5= 8)
=C2=A0(intervals 56 372 3)
=C2=A0(buffers 1000 13))


--000000000000036ccb05f56091f5-- ------------=_1694480821-29963-1--