From unknown Wed Jun 18 23:06:19 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#76538 <76538@debbugs.gnu.org> To: bug#76538 <76538@debbugs.gnu.org> Subject: Status: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. Reply-To: bug#76538 <76538@debbugs.gnu.org> Date: Thu, 19 Jun 2025 06:06:19 +0000 retitle 76538 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-c= ycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways bloc= ks GNU Emacs. reassign 76538 emacs submitter 76538 Jo=C3=A3o Moreira severity 76538 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 24 22:41:36 2025 Received: (at submit) by debbugs.gnu.org; 25 Feb 2025 03:41:36 +0000 Received: from localhost ([127.0.0.1]:44151 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tmlp8-0004fd-Is for submit@debbugs.gnu.org; Mon, 24 Feb 2025 22:41:36 -0500 Received: from lists.gnu.org ([2001:470:142::17]:47286) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tmjCG-0001es-C8 for submit@debbugs.gnu.org; Mon, 24 Feb 2025 19:53:17 -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 1tmjC8-0002mh-Aj for bug-gnu-emacs@gnu.org; Mon, 24 Feb 2025 19:53:08 -0500 Received: from mout.gmx.net ([212.227.17.20]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tmjC5-0004SO-FM for bug-gnu-emacs@gnu.org; Mon, 24 Feb 2025 19:53:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.se; s=s31663417; t=1740444782; x=1741049582; i=joaomoreira@gmx.se; bh=quqhvhPjqX+ZTha76gpBiBdABp9upH8Qj/fyontiYhM=; h=X-UI-Sender-Class:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type:cc:content-transfer-encoding:content-type:date:from: message-id:mime-version:reply-to:subject:to; b=WxmndL2xXb9LgU9e0ZYJxXRC7UaVTkUDAsWr+YOTW0nKo7oSxxeYSXNRjQbVMeOx oywMLtbXMzHZdpZthApS57A70GkbVT37oFbBVHxdB1zhpDm5MMeGW4HGej8VAA6dC avZNbQBB6/3vHyTOMDdYwxfoK6iO1m+htjE3Cfn7EG0UWG09NDR17+mlRbTRWrbsQ EYoqyqc9Yww15xWGCcByXTAvW8rYgOae303CdpQxTfO77073EFt6IPzaV0yBHkU/7 s2e3Z3mrw2v77Lxx+6dFg6aUfBtLTJuaLjTLY2QF66YnwYt4cUL51W4CkbrGuUPVw h8ywMxeDZKwiEVcdNQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from li-nixos ([177.47.220.78]) by mail.gmx.net (mrgmx105 [212.227.17.174]) with ESMTPSA (Nemesis) id 1MFKGP-1tX5402iN7-002cLy for ; Tue, 25 Feb 2025 01:53:02 +0100 From: =?utf-8?Q?Jo=C3=A3o_Moreira?= To: bug-gnu-emacs@gnu.org Subject: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. X-Debbugs-Cc: Date: Mon, 24 Feb 2025 21:52:45 -0300 Message-ID: <87ikoyetgi.fsf@gmx.se> MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:e15UBuUiz4+ksAhKtj+sgJ1szraC2f/1d1VKQX6GFsJNr0FeRnM Zie/4dgt2eCoec9dlXcVaeQ4iWIjXYW5QdZ6hKLdLVLqJo66P1kjxJMe9k+9DqJzEpfBXYZ reRnsXIIblxfKm31lerzZJUKUerb1V1pzMJWaiSVQJGtvCcTt8nDlniG4RAGjOBg3XRwTtY quWNsTMdl4jFWmvzjUiKw== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:cC1aXiG0988=;mlHijXD2/62QZeM/hynkRFhOhD5 P4NonNkBHUVEotCJQHYiGSd7ARBiC+midQ/uvhG6zMgHrQCgr4PhuWi8fH7ZlcBIMza0coNHL yRfvuOCcZ6CrwZWXvZnevbQXiLA0/sCj6A1C5ZZR4eKf79M9rOSUHqr0CvjKjvM/BQpjZJ3Gd /3aEmr0RfUTm4QyLUDdPaCpDoAksV8lYdyd/ISFfE0hdp7+8ksehuaNhMTYROwuW/I019VG0c mgqRp2pLbjkA8YTY4DWBNfgNbi0JDjyw773FQZD2fqxbCV77njpgLBuwMfQ2wZVpZv++iwGBR FmvBo2nOGSPkGjz6et2DPxIkNdITzjVltqbiobc3PMHByUd32dt5s5P8RJUxRnFztqm+2xG7W h1omIU8Lpa+cq4HfWo169o3hJydqY9EQbsthMh4fPELBTa/C1qctL6kj3lDf6k1bQ2iM8XpnW IEFT+uO5FogmStty8WOesRae3wQFdAzGf7+cJjxUZmNx4xEYhWQ5+jYnq1jjBz4A9yiq4VQBF rA3zIyCwjSI6tfVFXjBzE/P5uCAy4OuPCqZVcEpnzCdJR3mJJHjxyvrg3PTeRgtx5NJG0yulq sxbcwrtAsMCqosV781lhNVJ2zB64KFSQzsXXZlOPsb+HJWxskIXfDmanZ0ZB7mCDm3vJnqMI9 9ut2YFi2mIZ/IrZIt9EFWx3EvmB6cckL9+Yk6kOzs+6G1JVSukgic1wBSVxkOL6AXF6kK7nki +xrXpPDBi7rEqETc7v3pD9Xwwaf3I4uBopTg5FawX8dXJeAAEgbfCVxEoYpcoEkZivPRYFKuH 7YAhXHfuXhbUrHFQBYAo9ncSFI4oxa1q+7GQkPja70rTohkDWaYFTwKJF0nxbnckUQw52fXHl Hvu+Z1rTkUeNISCV6J2h1L96UKUL3RSGDS8DNWHI9atyWi9AFKZ5TgIeSEJkrxqvgD9Jz74Af /jqZYAB5GIMTyR4LiFFoB2pfSogGFRQSMxXu5gNa+GTAUfUSdxyx1SHT2UAQrGr1EoYrlfdIh Cn9+wrZTKliSaEsOwnu3tc6dxCyTgxnu8ZxLataINtwy50X9/shq6VFddqV+krYhZOO8wfmiB ZlO5m5ZgfRSZvtticatnGI7zwQ/uz3XFTO1r4IMqkJrtsOm4BO7tAxmyFpI0nO99Ilu3WioM5 6n1YRMWfystrZJ071cZIV3z2roReXo2baiNwz4gAnlRM6BVtzJZ0Kk4SOZV8CQrTlCQz7fZZN JsNxpAc/v4Coi3nqdfU2zBJUXP+3o2kGwqw0pj5sBH9VkkQjrXVTC1DeIaWqCjaFfNh8ofga5 MWjJ/zsVMsZC99AOa5ugKVwt1Cah37YhDOo/GXh15Eyab6bPhCJqLSoB2dIlizZxKU02baD4K Q8jl3sXVc3wfq1Gr7hfG1Byygm9lpXc/iP/gXq11yNdXyaJnagKiC+1dvv/6TVBCtgvmsWnLQ dkyOtlOSQzVk2zhUWXsORBX9DVaI= Received-SPF: pass client-ip=212.227.17.20; envelope-from=joaomoreira@gmx.se; helo=mout.gmx.net 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Mon, 24 Feb 2025 22:41:32 -0500 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 (-) HAPPENED Using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs while using feature/igc. EXPECTED Magit does not block GNU Emacs. REPRODUCE 1. On a non-customized GNU Emacs feature/igc 48909543bdc7cfb605034398f2757e8d01004aca, eval ```emacs-lisp ;;;; PACKAGES (require 'package) (require 'package-vc) (require 'use-package) (defmacro my-package-install (package &optional feature &rest body) "Set up PACKAGE from an Elisp archive, with rest BODY; require FEATURE instead of PACKAGE if given. PACKAGE is a quoted symbol, FEATURE is a quoted symbol, while BODY consists of balanced expressions. Try to install the package if it is missing. (declare (indent 1)) `(progn ;; replace when not with unless? (unless (package-installed-p ,package) (unless package-archive-contents (package-refresh-contents)) (package-install ,package)))) ;; Set archives. (dolist (package-archive '(("melpa" . "https://melpa.org/packages/")) package-archives) (unless (assoc-default (car package-archive) package-archives) (add-to-list 'package-archives package-archive t))) ;; Initialize. (package-initialize) ;;;; INSTALL (my-package-install 'magit) ;;;; CONFIG (use-package magit :custom (magit-git-executable (executable-find "git")) (magit-perl-executable (executable-find "perl"))) ``` 2. `git clone https://github.com/joaoymoreira/joao.edu.uni.pi22019208901.real-review.git` 3. `cd real-review && rm -rf .git` 4. `git init` 3. Open magit, press S to stage files. 4. On Staged changes, press magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) randomly until it blocks GNU Emacs in showing white screen (all frames). SYSTEM INFORMATION In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.18.2, Xaw3d scroll bars) Repository revision: 48909543bdc7cfb605034398f2757e8d01004aca Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12101014 System Description: NixOS 25.05 (Warbler) Configured using: 'configure --prefix=/nix/store/ji21vqsmpbnqsrq0l2rfvxaxpvpr0b7q-emacs-igc-20250217.0 --disable-build-details --with-modules --with-x-toolkit=lucid --with-cairo --with-xft --with-compress-install --with-toolkit-scroll-bars --with-native-compilation --without-imagemagick --with-mailutils --without-small-ja-dic --with-tree-sitter --with-xinput2 --without-xwidgets --with-dbus --with-selinux --with-mps=yes' Configured features: CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES MPS NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XAW3D XDBE XIM XINPUT2 XPM LUCID ZLIB Important settings: value of $EMACSLOADPATH: value of $EMACSNATIVELOADPATH: value of $LC_CTYPE: pt_BR.UTF-8 value of $LC_TIME: en_DK.UTF-8 value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Fundamental Minor modes in effect: global-git-commit-mode: t magit-auto-revert-mode: t override-global-mode: t 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 minibuffer-regexp-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: /etc/profiles/per-user/joao/share/emacs/site-lisp/elpa/compat-30.0.2.0/compat hides /nix/store/nbi6gy4n0w8h13fna2fqp7a29cdn0km9-emacs-packages-deps/share/emacs/site-lisp/elpa/compat-30.0.2.0/compat /etc/profiles/per-user/joao/share/emacs/site-lisp/elpa/compat-30.0.2.0/compat-30 hides /nix/store/nbi6gy4n0w8h13fna2fqp7a29cdn0km9-emacs-packages-deps/share/emacs/site-lisp/elpa/compat-30.0.2.0/compat-30 /etc/profiles/per-user/joao/share/emacs/site-lisp/elpa/compat-30.0.2.0/compat-29 hides /nix/store/nbi6gy4n0w8h13fna2fqp7a29cdn0km9-emacs-packages-deps/share/emacs/site-lisp/elpa/compat-30.0.2.0/compat-29 /etc/profiles/per-user/joao/share/emacs/site-lisp/elpa/compat-30.0.2.0/compat-28 hides /nix/store/nbi6gy4n0w8h13fna2fqp7a29cdn0km9-emacs-packages-deps/share/emacs/site-lisp/elpa/compat-30.0.2.0/compat-28 /etc/profiles/per-user/joao/share/emacs/site-lisp/elpa/compat-30.0.2.0/compat-27 hides /nix/store/nbi6gy4n0w8h13fna2fqp7a29cdn0km9-emacs-packages-deps/share/emacs/site-lisp/elpa/compat-30.0.2.0/compat-27 /etc/profiles/per-user/joao/share/emacs/site-lisp/elpa/compat-30.0.2.0/compat-26 hides /nix/store/nbi6gy4n0w8h13fna2fqp7a29cdn0km9-emacs-packages-deps/share/emacs/site-lisp/elpa/compat-30.0.2.0/compat-26 /etc/profiles/per-user/joao/share/emacs/site-lisp/elpa/compat-30.0.2.0/compat-25 hides /nix/store/nbi6gy4n0w8h13fna2fqp7a29cdn0km9-emacs-packages-deps/share/emacs/site-lisp/elpa/compat-30.0.2.0/compat-25 /etc/profiles/per-user/joao/share/emacs/site-lisp/elpa/compat-30.0.2.0/compat-autoloads hides /nix/store/nbi6gy4n0w8h13fna2fqp7a29cdn0km9-emacs-packages-deps/share/emacs/site-lisp/elpa/compat-30.0.2.0/compat-autoloads /etc/profiles/per-user/joao/share/emacs/site-lisp/elpa/compat-30.0.2.0/compat-pkg hides /nix/store/nbi6gy4n0w8h13fna2fqp7a29cdn0km9-emacs-packages-deps/share/emacs/site-lisp/elpa/compat-30.0.2.0/compat-pkg /etc/profiles/per-user/joao/share/emacs/site-lisp/elpa/compat-30.0.2.0/compat-macs hides /nix/store/nbi6gy4n0w8h13fna2fqp7a29cdn0km9-emacs-packages-deps/share/emacs/site-lisp/elpa/compat-30.0.2.0/compat-macs /etc/profiles/per-user/joao/share/emacs/site-lisp/elpa/dash-20240510.1327/dash-autoloads hides /nix/store/nbi6gy4n0w8h13fna2fqp7a29cdn0km9-emacs-packages-deps/share/emacs/site-lisp/elpa/dash-20240510.1327/dash-autoloads /etc/profiles/per-user/joao/share/emacs/site-lisp/elpa/dash-20240510.1327/dash hides /nix/store/nbi6gy4n0w8h13fna2fqp7a29cdn0km9-emacs-packages-deps/share/emacs/site-lisp/elpa/dash-20240510.1327/dash /etc/profiles/per-user/joao/share/emacs/site-lisp/elpa/dash-20240510.1327/dash-pkg hides /nix/store/nbi6gy4n0w8h13fna2fqp7a29cdn0km9-emacs-packages-deps/share/emacs/site-lisp/elpa/dash-20240510.1327/dash-pkg /etc/profiles/per-user/joao/share/emacs/site-lisp/elpa/seq-2.24/seq hides /nix/store/nbi6gy4n0w8h13fna2fqp7a29cdn0km9-emacs-packages-deps/share/emacs/site-lisp/elpa/seq-2.24/seq /etc/profiles/per-user/joao/share/emacs/site-lisp/elpa/seq-2.24/seq-autoloads hides /nix/store/nbi6gy4n0w8h13fna2fqp7a29cdn0km9-emacs-packages-deps/share/emacs/site-lisp/elpa/seq-2.24/seq-autoloads /etc/profiles/per-user/joao/share/emacs/site-lisp/elpa/seq-2.24/seq-25 hides /nix/store/nbi6gy4n0w8h13fna2fqp7a29cdn0km9-emacs-packages-deps/share/emacs/site-lisp/elpa/seq-2.24/seq-25 /etc/profiles/per-user/joao/share/emacs/site-lisp/elpa/seq-2.24/seq-pkg hides /nix/store/nbi6gy4n0w8h13fna2fqp7a29cdn0km9-emacs-packages-deps/share/emacs/site-lisp/elpa/seq-2.24/seq-pkg /etc/profiles/per-user/joao/share/emacs/site-lisp/elpa/seq-2.24/seq-24 hides /nix/store/nbi6gy4n0w8h13fna2fqp7a29cdn0km9-emacs-packages-deps/share/emacs/site-lisp/elpa/seq-2.24/seq-24 /nix/store/nbi6gy4n0w8h13fna2fqp7a29cdn0km9-emacs-packages-deps/share/emacs/site-lisp/site-start hides /nix/store/ji21vqsmpbnqsrq0l2rfvxaxpvpr0b7q-emacs-igc-20250217.0/share/emacs/site-lisp/site-start /etc/profiles/per-user/joao/share/emacs/site-lisp/elpa/compat-30.0.2.0/compat hides /nix/store/ji21vqsmpbnqsrq0l2rfvxaxpvpr0b7q-emacs-igc-20250217.0/share/emacs/31.0.50/lisp/emacs-lisp/compat /nix/store/nbi6gy4n0w8h13fna2fqp7a29cdn0km9-emacs-packages-deps/share/emacs/site-lisp/elpa/let-alist-1.0.6/let-alist hides /nix/store/ji21vqsmpbnqsrq0l2rfvxaxpvpr0b7q-emacs-igc-20250217.0/share/emacs/31.0.50/lisp/emacs-lisp/let-alist /etc/profiles/per-user/joao/share/emacs/site-lisp/elpa/seq-2.24/seq hides /nix/store/ji21vqsmpbnqsrq0l2rfvxaxpvpr0b7q-emacs-igc-20250217.0/share/emacs/31.0.50/lisp/emacs-lisp/seq /etc/profiles/per-user/joao/share/emacs/site-lisp/elpa/cl-generic-0.3/cl-generic hides /nix/store/ji21vqsmpbnqsrq0l2rfvxaxpvpr0b7q-emacs-igc-20250217.0/share/emacs/31.0.50/lisp/emacs-lisp/cl-generic Features: (shadow sort mail-extr emacsbug cus-edit cus-start cus-load wid-edit ediff ediff-merg ediff-mult ediff-wind ediff-diff ediff-help ediff-init ediff-util let-alist magit-bookmark bookmark magit-submodule magit-blame magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit magit-sequence magit-notes magit-worktree magit-tag magit-merge magit-branch magit-reset magit-files magit-refs magit-status magit magit-repos magit-apply magit-wip magit-log magit-diff smerge-mode diff git-commit magit-core magit-autorevert autorevert filenotify magit-margin magit-transient log-edit pcvs-util add-log magit-process with-editor magit-mode elp transient pp edmacro kmacro magit-git magit-base which-func imenu vc-git diff-mode track-changes files-x magit-section crm magit-autoloads benchmark format-spec cursor-sensor llama comp comp-cstr cl-extra help-mode magit-section-autoloads llama-autoloads pcase warnings shell pcomplete server compat compat-30 with-editor-autoloads loaddefs-gen radix-tree tar-mode arc-mode archive-mode mm-archive message sendmail yank-media dired dired-loaddefs rfc822 mml mml-sec epa derived gnus-util time-date mailabbrev gmm-utils mailheader mm-decode mm-bodies mm-encode mail-utils gnutls network-stream url-cache url-http url-auth mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr url-gw nsm puny compile text-property-search comint ansi-osc ansi-color ring comp-run comp-common rx epg rfc6068 epg-config finder-inf use-package use-package-ensure use-package-delight use-package-diminish use-package-bind-key bind-key easy-mmode use-package-core package-vc vc vc-dispatcher lisp-mnt emacsql-sqlite-autoloads emojify-logos-autoloads emojify-autoloads ht-autoloads info dash-autoloads jinx-autoloads pdf-tools-autoloads tablist-autoloads vterm-autoloads package browse-url xdg url url-proxy url-privacy url-expand url-methods url-history url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs icons password-cache json subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd touch-screen 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 theme-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 x-toolkit xinput2 x multi-tty move-toolbar make-network-process tty-child-frames native-compile mps emacs) Memory information: ((conses 24 0 0) (symbols 56 0 0) (strings 40 0 0) (string-bytes 1 0) (vectors 24 0) (vector-slots 8 0 0) (floats 24 0 0) (intervals 64 0 0) (buffers 1000 0)) From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 25 11:17:52 2025 Received: (at 76538) by debbugs.gnu.org; 25 Feb 2025 16:17:52 +0000 Received: from localhost ([127.0.0.1]:48112 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tmxd2-0002Q9-90 for submit@debbugs.gnu.org; Tue, 25 Feb 2025 11:17:52 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:34268) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tmxd0-0002Pp-5N for 76538@debbugs.gnu.org; Tue, 25 Feb 2025 11:17:50 -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 1tmxcu-0004Pt-62; Tue, 25 Feb 2025 11:17:44 -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=k/I+rlIm6wQFtDcozdsKA7RqZFoKU5KWvYtXkH3Z0Zw=; b=k8Lwzz5wMpeFbKlgvAAK Fhqa5IMzJH5v/B22vu6pM4NwBfvYitJjZ53IUE5v1Jj/ZeFvQ9eIwAKtfHDSVaEwEzseTuVhhid+T PvGvZuJQI8/sd545bjibS5id8QNQAZQRP1Y1cQlho4dn+gplL7GGG4+58whFbQjgA8OKjELqtGPwD opT0fnuFiOG1s0SbKYPjgvIkDrWIbTaPZ0+u7PqHMKTpDkXpSh26TogNV3HUWAUFlq9JETv4+BJ/w YUL/gSNJN5+k4eTUAbVl56H2uFHs1O9naFM5utNTDdEd6OIx8b+Wg2W2O5nBy2afuU66/v1lOHeQW Hcj75Eqr+jAhag==; Date: Tue, 25 Feb 2025 18:17:40 +0200 Message-Id: <8634g2xal7.fsf@gnu.org> From: Eli Zaretskii To: =?iso-8859-1?Q?Jo=E3o?= Moreira In-Reply-To: <87ikoyetgi.fsf@gmx.se> (bug-gnu-emacs@gnu.org) Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. References: <87ikoyetgi.fsf@gmx.se> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76538 Cc: 76538@debbugs.gnu.org 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 (---) > Date: Mon, 24 Feb 2025 21:52:45 -0300 > From: Jo�o Moreira via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > Using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs while using feature/igc. Isn't this because of the auto-revert mode that Magit turns on by default? See bug#76505 for more details, and a possible workaround. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 25 11:31:35 2025 Received: (at submit) by debbugs.gnu.org; 25 Feb 2025 16:31:35 +0000 Received: from localhost ([127.0.0.1]:48137 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tmxqI-000354-SR for submit@debbugs.gnu.org; Tue, 25 Feb 2025 11:31:35 -0500 Received: from lists.gnu.org ([2001:470:142::17]:47322) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tmxqF-00034n-Ot for submit@debbugs.gnu.org; Tue, 25 Feb 2025 11:31:32 -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 1tmxq9-0001B9-JT for bug-gnu-emacs@gnu.org; Tue, 25 Feb 2025 11:31:25 -0500 Received: from mail-40131.protonmail.ch ([185.70.40.131]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tmxq5-0006b6-WB for bug-gnu-emacs@gnu.org; Tue, 25 Feb 2025 11:31:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1740501072; x=1740760272; bh=DnNttLOHnxs673tcXQwiX3MAYWc+WGXtPGeKkY1/ibI=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=pGR3fHkKtnrwsoYZrAtKwsLIwwQYIS2n/OgQoJGinbiQYs7xOxYgqGH5aTNacK7YP QKDZ0Wk7wlwjviBJ4RiqmZqyB0gYxm24Cpe5bSur3IW9fFzjcnTXrbixuUkC1W4ndO d7F5NskvMTatkusnuCqxYZD4LesYxebcmnZNJtwQTL2fSsZsGe0w6OhX0P9yoTZfVn G2Bi5j+BhJDfWCJhaDDZmqjDlKcHHI2o3q7wI/GIP/bpOyUIKmKW+fD8A5A98ZIOo/ 9TpUTz0msK1ZEVSLLPE873YcNpoQqCoJElqcqGyOWtUJ9UPR9ggGl9il6DKHVmZs46 z50w3TEYa/pLg== Date: Tue, 25 Feb 2025 16:31:07 +0000 To: =?utf-8?Q?Jo=C3=A3o_Moreira_via_Bug_reports_for_GNU_Emacs=2C_the_Swiss_army_knife_of_text_editors?= From: Pip Cet Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. Message-ID: <87o6yqm1g7.fsf@protonmail.com> In-Reply-To: <87ikoyetgi.fsf@gmx.se> References: <87ikoyetgi.fsf@gmx.se> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: e4bd44ca1116d3ced5637e0bfb0a2091ffe3d8c9 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.40.131; envelope-from=pipcet@protonmail.com; helo=mail-40131.protonmail.ch 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_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 Cc: =?utf-8?Q?Jo=C3=A3o_Moreira?= , 76538@debbugs.gnu.org, Helmut Eller 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: -0.0 (/) Jo=C3=A3o Moreira via "Bug reports for GNU Emacs, the Swiss army knife of t= ext editors" writes: > HAPPENED > > Using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) i= n some random ways blocks GNU Emacs while using feature/igc. Thanks for the report! I tried reproducing it, and indeed Emacs hangs for several minutes in back_to_previous_visible_line_start. However, after that, it seems to become usable again. I tried reproducing this again and failed, though. This is a bug, and it seems to be much worse with --with-mps=3Dyes, but the behavior with --with-mps=3Dno is hardly ideal either. The main difference appears to be the charpos<->bytepos cache in the weak marker vector, which grows to 0x8000 entries. That seems excessive, but IIRC, what really matters is the order in which they're tried. > EXPECTED > > Magit does not block GNU Emacs. > > REPRODUCE > > 1. On a non-customized GNU Emacs feature/igc 48909543bdc7cfb605034398f275= 7e8d01004aca, eval > ```emacs-lisp > ;;;; PACKAGES > > (require 'package) > (require 'package-vc) > (require 'use-package) > > (defmacro my-package-install (package &optional feature &rest body) > "Set up PACKAGE from an Elisp archive, with rest BODY; require > FEATURE instead of PACKAGE if given. > > PACKAGE is a quoted symbol, FEATURE is a quoted symbol, while BODY > consists of balanced expressions. > > Try to install the package if it is missing. I had to add a closing quote here. Pip From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 25 12:00:10 2025 Received: (at 76538) by debbugs.gnu.org; 25 Feb 2025 17:00:10 +0000 Received: from localhost ([127.0.0.1]:48205 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tmyHy-0004Nz-1H for submit@debbugs.gnu.org; Tue, 25 Feb 2025 12:00:10 -0500 Received: from mout01.posteo.de ([185.67.36.65]:34607) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tmyHt-0004Hg-V6 for 76538@debbugs.gnu.org; Tue, 25 Feb 2025 12:00:08 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 688FB240027 for <76538@debbugs.gnu.org>; Tue, 25 Feb 2025 17:59:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1740502799; bh=CmjF9OVhEpPfXOBoub7KpuDrX6fQX3A5FeyMSDdAS8k=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=leotaEe2NU8e7bJCNWnjoThFD98IuO8jk5xyV9F7Wkmx+mYhNKtrrEwLl7rj90gPr DjcuSJVKa8EChbsMXybAOLKSfYU8ZVsLHiqY4MDohdGq8y7+fnLYcbaP793XYFc5+X yFd9J3IM+qUmWgP2JI0OWJWzSo56Q+Dyn664UlX85Pd+cEFM1Wvem/+mM39L3041hV LhSTchIr/aFCg0xw+F9VrLuy6IgW6GtwluTTK5xyzc06FuhYvK4sLiXbeKPa+BaoGi hWTZxjZgdeq8rj467MbMYwF4NgnyIcJTsEwMRsSKeBoYyzp8mKm4G+013wDaomScza deYJW4WsG+bDA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Z2P3d4Mltz6tw7; Tue, 25 Feb 2025 17:59:57 +0100 (CET) From: Ihor Radchenko To: Pip Cet Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: <87o6yqm1g7.fsf@protonmail.com> References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> Date: Tue, 25 Feb 2025 16:59:29 +0000 Message-ID: <87o6yqez9q.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 76538 Cc: for@debbugs.gnu.org, Bug@debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o@debbugs.gnu.org, eller.helmut@gmail.com, GNU@debbugs.gnu.org, via@debbugs.gnu.org, reports@debbugs.gnu.org, joaomoreira@gmx.se, 76538@debbugs.gnu.org, Emacs@debbugs.gnu.org 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: -0.3 (/) Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > The main difference appears to be the charpos<->bytepos cache in the > weak marker vector, which grows to 0x8000 entries. That seems > excessive, but IIRC, what really matters is the order in which they're > tried. FYI, I regularly observe bytepos_to_charpos in my perf traces. So, the impact is rather significant. Especially when buffer has many markers. I think we discussed this problem as improved the situation somewhat in https://yhetil.org/emacs-devel/87v81u85hv.fsf@localhost/ Maybe there is something more that can be done? -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 25 12:27:38 2025 Received: (at 76538) by debbugs.gnu.org; 25 Feb 2025 17:27:38 +0000 Received: from localhost ([127.0.0.1]:48271 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tmyiX-0005fA-RU for submit@debbugs.gnu.org; Tue, 25 Feb 2025 12:27:38 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:35526) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tmyiU-0005ek-W3 for 76538@debbugs.gnu.org; Tue, 25 Feb 2025 12:27:36 -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 1tmyiO-0005Y1-3N; Tue, 25 Feb 2025 12:27:29 -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=lIfHr3HA4XXyOG8/2aIlxtatWhi9E0c2EMj9faOoB8E=; b=sfSRvt2RgB71 nvF7+ov1pF9uBKQTURYe7UyLIZ2XxwAEWwxr5fzu3VB0CDlP5orHy+8szbFXnSKUX69Vdiuz3H/bn nOnohbGtuNRC2rWBPY4woBa+W0iA6hRDO6IOgorBxJoSvh0NY/PrMiaAGXPYimc6KU95mG/MOEPeP V2ewBUvednHNQ1tcXqMePeZPkVevNaHBYrLZq7AeyPuRB666FlNP7iab6AR/NefJ62cQTmGxo7drD 8JYavZAt08X28SCuJFjeZ/i95x+42cRyyqSUhu2AyaEFLlMbFt7RHyXDfQ7gALPOp2OrTjgLVSsra kz+/8NO6xVhPcYi9nd3RSA==; Date: Tue, 25 Feb 2025 19:27:21 +0200 Message-Id: <86o6yqvssm.fsf@gnu.org> From: Eli Zaretskii To: Ihor Radchenko In-Reply-To: <87o6yqez9q.fsf@localhost> (message from Ihor Radchenko on Tue, 25 Feb 2025 16:59:29 +0000) Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87o6yqez9q.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76538 Cc: joaomoreira@gmx.se, pipcet@protonmail.com, 76538@debbugs.gnu.org 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 (---) > Cc: for@debbugs.gnu.org, Bug@debbugs.gnu.org, > =?UTF-8?Q?Jo=C3=A3o@debbugs.gnu.org, eller.helmut@gmail.com, > GNU@debbugs.gnu.org, via@debbugs.gnu.org, reports@debbugs.gnu.org, > joaomoreira@gmx.se, 76538@debbugs.gnu.org, Emacs@debbugs.gnu.org > From: Ihor Radchenko > Date: Tue, 25 Feb 2025 16:59:29 +0000 > > Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text > editors" writes: > > > The main difference appears to be the charpos<->bytepos cache in the > > weak marker vector, which grows to 0x8000 entries. That seems > > excessive, but IIRC, what really matters is the order in which they're > > tried. > > FYI, I regularly observe bytepos_to_charpos in my perf traces. So, the > impact is rather significant. Especially when buffer has many markers. > I think we discussed this problem as improved the situation somewhat in > https://yhetil.org/emacs-devel/87v81u85hv.fsf@localhost/ > > Maybe there is something more that can be done? Maybe, but why is this so much worse with MPS? From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 25 12:55:57 2025 Received: (at 76538) by debbugs.gnu.org; 25 Feb 2025 17:55:57 +0000 Received: from localhost ([127.0.0.1]:48322 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tmz9w-0001bY-VH for submit@debbugs.gnu.org; Tue, 25 Feb 2025 12:55:57 -0500 Received: from mail-wm1-x336.google.com ([2a00:1450:4864:20::336]:46495) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tmz9u-0001bI-O2 for 76538@debbugs.gnu.org; Tue, 25 Feb 2025 12:55:55 -0500 Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-438a3216fc2so56538295e9.1 for <76538@debbugs.gnu.org>; Tue, 25 Feb 2025 09:55:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740506148; x=1741110948; 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=+0TkwlU9o9P7meiv6pnOTi9tZCmWLLafcjYTuWhkPh0=; b=VaqPh0XA1oLHnAFqkSpfIGPJN1rf+AWqQrGuS0AxRCAJRL/5uPsb2R01RvI7nwP78V G31MR4166sVEOdzD8OYEIV6yBBs2ZHRJyQhBfJxWU1M6LAHZ1mg60MS6ZCbqniUFWrMa YRJz2+QOtpfo+9Brd9cP0EdgclWCZVsG+1REmcPBKENJUF3beZ9Pt4meDvX+0TEPRDfM g3jGBStw6b9jsyiJyP/34u9qmsW5K0LIS/mbgmquqPgQ2ECfQUqVWcWSIcH2XM2+RZen Tj1Xp8ssnpOH0vn3Y0zRzER+sig5b8NaJFg+k365Lj+mmpXAcHipuRXXALaqU5UXVyOE 4f2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740506148; x=1741110948; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+0TkwlU9o9P7meiv6pnOTi9tZCmWLLafcjYTuWhkPh0=; b=q1VrvV0NlguK5+DL9WxpjVvkyj9OczDdkPUuMtihhs5eWP2u36i7/oA4rKCSdlP5Rm eMu27L4VPoy3eLl4iO02nAwEvuZnALwaWuoR0CphusrnxDCll1fQwaymPluRXdJ4XxbB mCcqOrpdynsibFL20zhrwiCucvIbjOPHqL7mYkC7YxNaieesf+5FvPKWH0uexPCmnjeW nT1BSQ6rk7lq8uVYquQ18iJsvpzfpJNNFWdo64ufGCZ95Z/Sdi9Mlx564Zm+EUzDR/Mp ivrDocoyodtKrmcIAODLYMsiBSKcRQJ0EFcz5Mh2EdFXLOKyx6j2uaNe4qK2q/MLAaAv rVVA== X-Forwarded-Encrypted: i=1; AJvYcCUhHQK4W829b7AOmIBB5S5GRO57v6BtEPsXoYPs+XI/35+YSMg1mAwqikHBnXz0Heo/8PbRvA==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yy2Mw/aeWDiWM3R7DIcI4FaghNkyY99R9xprGy/r51TZ3D2gcvB hDTcMqNs3QWDLeQXsCGpEb1XUZIPHGzrpviO6ARE+Y8GJJDkV6e8 X-Gm-Gg: ASbGncsNhlhIFRS5WADmosNy0WUdkuTJpougZmFtzy4w+83dJT45HSeuhH1ULj/eHMx jXOshmt6rxzBgLPM/UP51RKDDHrYSM+5mexkSlDJw0fDuRMbwkuwu/8xFEFC2cq19vAxdvNf0Qb RzbjnZhk/hnOzkF6meQ/bFr1glwDlr9rYcRpyLfC0TS06jf3Q9TEOhLDn2yGFoJtb7oVMwufkPv IxM3QYkp1L8+3+6CLKiY8SqBtbsT1LWB6KSRw4liX6zrXUSN8Wg9kAVa1qEMKGx2sWQAIwen0kW HTXtofz2oeVP19UujqBIg3UkVVelCtLrgYHXoKpej1cbOVH5FiPZ/9d3kaY= X-Google-Smtp-Source: AGHT+IGfZIhYoRG/ycZRNnIdn9BtDqryfbEFS+wQaVo2cZ/a7cl6Eq6dviQjmUrLQ3KwaquTxp6kcQ== X-Received: by 2002:a05:6000:1844:b0:386:3835:9fec with SMTP id ffacd0b85a97d-38f70826ea0mr17396583f8f.44.1740506148299; Tue, 25 Feb 2025 09:55:48 -0800 (PST) Received: from caladan (dialin-233080.rol.raiffeisen.net. [195.254.233.80]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43ab15475e1sm34404455e9.22.2025.02.25.09.55.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Feb 2025 09:55:47 -0800 (PST) From: Helmut Eller To: Pip Cet Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: <87o6yqm1g7.fsf@protonmail.com> (Pip Cet's message of "Tue, 25 Feb 2025 16:31:07 +0000") References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> Date: Tue, 25 Feb 2025 18:55:46 +0100 Message-ID: <87ldtt29jx.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76538 Cc: =?utf-8?Q?Jo=C3=A3o?= Moreira , =?utf-8?Q?Jo=C3=A3o_Moreira_via_Bug_reports_for_GNU_Emacs=2C_the_Swiss?= =?utf-8?Q?_army_knife_of_text_editors?= , 76538@debbugs.gnu.org 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 (-) --=-=-= Content-Type: text/plain On Tue, Feb 25 2025, Pip Cet wrote: > Thanks for the report! I tried reproducing it, and indeed Emacs hangs > for several minutes in back_to_previous_visible_line_start. However, > after that, it seems to become usable again. I tried reproducing this > again and failed, though. I think I can reproduce this with the attached script and Magit 4.2.0. from .emacs.d. I'm not sure if the non-MPS version is much better in this case. Magit seems to create an impressive number of markers. Helmut --=-=-= Content-Type: text/x-sh Content-Disposition: attachment; filename=magit-test.sh #!/usr/bin/bash EMACS=emacs git clone https://github.com/joaoymoreira/joao.edu.uni.pi22019208901.real-review.git real-review cd real-review rm -rf .git git init git add article poster ELCODE='(progn (package-initialize) (defun magit-test () (let ((buf (magit-status "."))) (pop-to-buffer buf) (delete-other-windows) (goto-char (point-max)) (redisplay))) (magit-test))' $EMACS -Q -eval "$ELCODE" --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 25 15:13:02 2025 Received: (at 76538) by debbugs.gnu.org; 25 Feb 2025 20:13:02 +0000 Received: from localhost ([127.0.0.1]:48630 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tn1Ic-0007uz-06 for submit@debbugs.gnu.org; Tue, 25 Feb 2025 15:13:02 -0500 Received: from mout01.posteo.de ([185.67.36.65]:56633) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tn1IY-0007u9-A8 for 76538@debbugs.gnu.org; Tue, 25 Feb 2025 15:12:59 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 19553240028 for <76538@debbugs.gnu.org>; Tue, 25 Feb 2025 21:12:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1740514371; bh=iPxQoa5O8sIPX+ZiE9VGA2APDlMpD/sR0fWhofqCLfk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=PUTSWJt1MN/vC8ZnmY8zE4FWn3U7pkhJ4kwaEsiNqtQU1hft/MPCYpUsr5cgh9tJM AdUOy2yQyv/zc/2IX7ORogxWO1474s8d4Mx54vA4YFLr8MMk6o/PsdtlcHquQpicQj 68Uy7danlBOFfoLOLWTTePRIcGEj+iF/egTMA89UzZylcHoNdZ6shB/rdOhnX4LdlF spcBhRb5oOz7rtkGe/QSgu3AuiFBNLZgqKYReHPvs5DAIGOXBGupOalIAhjeMFlVMN 0oCxXJa24AKaoAsNs+VIwTK3NDiVyBMq7u6sGpJNmQiR2gzXutVsbnEsp+b1gs6PM7 +AHjV9WkNvK/Q== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Z2TL91gFpz6v16; Tue, 25 Feb 2025 21:12:49 +0100 (CET) From: Ihor Radchenko To: Helmut Eller Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: <87ldtt29jx.fsf@gmail.com> References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> Date: Tue, 25 Feb 2025 20:12:21 +0000 Message-ID: <87ldtteqca.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 76538 Cc: Pip Cet , for@debbugs.gnu.org, Bug@debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o@debbugs.gnu.org, GNU@debbugs.gnu.org, via@debbugs.gnu.org, reports@debbugs.gnu.org, joaomoreira@gmx.se, 76538@debbugs.gnu.org, Emacs@debbugs.gnu.org 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: -0.3 (/) Helmut Eller writes: > I think I can reproduce this with the attached script and Magit > 4.2.0. from .emacs.d. Confirmed with Magit 4.3.0 from ELPA > I'm not sure if the non-MPS version is much better in this case. Magit > seems to create an impressive number of markers. Better for me. The reproducer involves 20+Mb magit buffer with a lot of text hidden. I toyed around with gdb a bit, and it appears to me that the problem is not with the number of markers. Rather an opposite. Marker cache does not help here initially and we need to scan all the way through 20Mb of bytes. In my testing, I looked into the total number of markers in the buffer, and it appears that the number is always fairly small. May someone more familiar with the code check if markers created in buf_charpos_to_bytepos might be created and immediately GCed? That's my impression (maybe totally wrong). -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 26 08:24:36 2025 Received: (at 76538) by debbugs.gnu.org; 26 Feb 2025 13:24:36 +0000 Received: from localhost ([127.0.0.1]:51500 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tnHOt-0000pQ-Dn for submit@debbugs.gnu.org; Wed, 26 Feb 2025 08:24:36 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37832) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tnHOp-0000pC-5P for 76538@debbugs.gnu.org; Wed, 26 Feb 2025 08:24:33 -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 1tnHOj-0000hk-DR; Wed, 26 Feb 2025 08:24:25 -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=RpS3CfTSUyzQ1N1en4G2tOhNJ9cOm6qKWhKVl6K39BI=; b=aiz6u0DSzeDi Jfr9kP03NPo7KXqsCS7js1XEE6qLObn4Opri7iDHCW1LgsbSqgtF5blmdLBumbi1Uaav/IoH2DBci H4ATEruYRBYVOSOZYMhz2xbGczEGQD1I48Om6sHu1uiTQ/F2tcaNjFOU9j7P9b80DmoK/x9v3TKoG Kr5R8Jj8TzJ4GBnbXsS41PEXPiAFe1JUaiYncpigCffN350A9JxsdEVRYE8VstI5tdkyufdT7aS4Y hlaCRhDhm8OhiVdl1HuL1E7R8WykMnT0qs7cpUPs1rQsxRLn37PxXzpwJJiI4qXEXkIRbsGrpyHqU CJoS7KMHd9Xu2XHonNWpBg==; Date: Wed, 26 Feb 2025 15:24:23 +0200 Message-Id: <864j0gx2ig.fsf@gnu.org> From: Eli Zaretskii To: Ihor Radchenko , Stefan Monnier In-Reply-To: <87ldtteqca.fsf@localhost> (message from Ihor Radchenko on Tue, 25 Feb 2025 20:12:21 +0000) Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> <87ldtteqca.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76538 Cc: joaomoreira@gmx.se, pipcet@protonmail.com, eller.helmut@gmail.com, 76538@debbugs.gnu.org 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 (---) > Cc: Pip Cet , for@debbugs.gnu.org, Bug@debbugs.gnu.org, > =?UTF-8?Q?Jo=C3=A3o@debbugs.gnu.org, GNU@debbugs.gnu.org, via@debbugs.gnu.org, > reports@debbugs.gnu.org, joaomoreira@gmx.se, 76538@debbugs.gnu.org, > Emacs@debbugs.gnu.org > From: Ihor Radchenko > Date: Tue, 25 Feb 2025 20:12:21 +0000 > > The reproducer involves 20+Mb magit buffer with a lot of text hidden. > I toyed around with gdb a bit, and it appears to me that the problem is > not with the number of markers. Rather an opposite. Marker cache does > not help here initially and we need to scan all the way through 20Mb of > bytes. ??? AFAIR, we perform binary search there, no? Can you show the details of what you saw in GDB? > In my testing, I looked into the total number of markers in the buffer, > and it appears that the number is always fairly small. How small? > May someone more familiar with the code check if markers created in > buf_charpos_to_bytepos might be created and immediately GCed? That's my > impression (maybe totally wrong). Why is the immediate GC a problem? And why do you think there is an immediate GC? And finally, are we still talking about the igc branch or about master (or both)? From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 26 12:40:21 2025 Received: (at 76538) by debbugs.gnu.org; 26 Feb 2025 17:40:21 +0000 Received: from localhost ([127.0.0.1]:55299 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tnLOO-0007Cq-Nf for submit@debbugs.gnu.org; Wed, 26 Feb 2025 12:40:21 -0500 Received: from mout02.posteo.de ([185.67.36.66]:38263) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tnLOL-0007CX-NZ for 76538@debbugs.gnu.org; Wed, 26 Feb 2025 12:40:18 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id AA134240101 for <76538@debbugs.gnu.org>; Wed, 26 Feb 2025 18:40:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1740591609; bh=P3XAfgchy1bMGjOqx2b9aqm5vpAruBAd7eevWl5/Gts=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=gyOWPBhS3LfSUY9sOuCP1us1Nnh+Zn0w8Oc1OAvrvWhP5s7nfBcIxIeqeaXJFVLN7 09Hn9uW0NcO0N1t85m0PYofBqxaxzU0DhR7YuLtnjfdRCk1+oiwEmGTC2NOmUDGUGa BEa6OUe9NJWYYftChULO7tsnbOAsS38Ri5U7tAuTrxidmv/yxitb6cTHqDbDa5SYxZ d3HwUCisM83EIc0Ff3u43Iyoeb5WvJQHz/46t/8U0MPut/Kb1wlpitd11E61QysA0k +oLHm7qHxtp1rCDkSNFti6C1hyGTblCMC82TBCA/dH6XwgnzfPOja4C2vbM0KqvdNM 5rqSH52lrY8Yw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Z31vW4S04z9rxM; Wed, 26 Feb 2025 18:40:07 +0100 (CET) From: Ihor Radchenko To: Eli Zaretskii Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: <864j0gx2ig.fsf@gnu.org> References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> <87ldtteqca.fsf@localhost> <864j0gx2ig.fsf@gnu.org> Date: Wed, 26 Feb 2025 17:39:39 +0000 Message-ID: <87tt8gobac.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76538 Cc: joaomoreira@gmx.se, pipcet@protonmail.com, 76538@debbugs.gnu.org, eller.helmut@gmail.com, 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: -3.3 (---) Eli Zaretskii writes: >> The reproducer involves 20+Mb magit buffer with a lot of text hidden. >> I toyed around with gdb a bit, and it appears to me that the problem is >> not with the number of markers. Rather an opposite. Marker cache does >> not help here initially and we need to scan all the way through 20Mb of >> bytes. > > ??? AFAIR, we perform binary search there, no? No. AFAIU, the search goes like the following: 1. Go through all the buffer markers and find the nearest marker to charpos/bytepos [ This is O(num_of_markers) on master and O(length_of_marker_array) on feature/igc ] 2. Starting from the nearest marker, scan bytes symbol by symbol until we find the requested charpos/bytepos [ O(distance to nearest marker) ] 3. While scanning, every 5000 bytes, create a new marker to cache the charpos and bytepos. > Can you show the details of what you saw in GDB? Here is what I did: 1. I modified the marker scan in buf_charpos_to_bytepos to record the number of markers in buffer (just stored it in a C variable) 2. I followed the reproducer (C-p from point-max) and paused Emacs from gdb while Emacs was hanging, looking at the backtrace and checking the number of markers 3. I observed ~8-11k markers in the buffer. Notably, the number of markers often decreased while runnign buf_charpos_to_bytepos, indicating that the marker list is cleaned up along the way. >> In my testing, I looked into the total number of markers in the buffer, >> and it appears that the number is always fairly small. > > How small? 8-11k. Probably, not that small after all in terms of absolute numbers. The reason why it is small in my mind is that limiting the loop over markers to 50 iterations max did not speed things up. >> May someone more familiar with the code check if markers created in >> buf_charpos_to_bytepos might be created and immediately GCed? That's my >> impression (maybe totally wrong). > > Why is the immediate GC a problem? And why do you think there is an > immediate GC? And finally, are we still talking about the igc branch > or about master (or both)? I compared with Emacs 30. Emacs 30 takes a few seconds for C-p to work and then does not hang (presumably, marker cache is populated). On feature/igc, I did not manage to wait enough for C-p to compelte (minutes). Why do I think that there is an immediate GC? It is a guess (possibly incorrect). My guess is originating from the fact that bug_charpos_to_bytepos is calling build_marker directly to cache buffer positions. However, the returned Lisp object is not used and thus probably not referenced by any of the roots (it does get stored in the buffer's marker list - but that's a weak array). So, there is a chance that it can be collected the next time IGC decides to run the collection. Given that we produce a large number of markers in buf_charpos_to_bytepos, that "next time" might be very soon. But I may be misunderstanding something important about how IGC code works. -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 26 14:58:07 2025 Received: (at 76538) by debbugs.gnu.org; 26 Feb 2025 19:58:07 +0000 Received: from localhost ([127.0.0.1]:55571 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tnNXi-0005Rt-Ot for submit@debbugs.gnu.org; Wed, 26 Feb 2025 14:58:07 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:29095) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tnNXf-0005RE-Fr for 76538@debbugs.gnu.org; Wed, 26 Feb 2025 14:58:04 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 672A4442D9F; Wed, 26 Feb 2025 14:57:56 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1740599871; bh=Kxbmuniq7zh99MKR3tmz+Ifh5ygGTeVBA2dSYY2m0uA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=bdyK0UE54EUHDDCQLz9S0vR5RlgRkjkd2OlcO1f8+sqqZBWS4WKapgeNY8foQMdn1 MbhBYxpLUHODhv7CuKVxup6rY9n9bpvZSojmsZRHUQedW7K0+aigFV7mUwUjhbGYEs v2Nld9xNgnpIWRfes2SG35HS7NtrccH7hgJvLlcsyvQzjcHQqbRwv2PUPTXYAnCLTd Ym5f44UcfFqv5GB+dQhVx7LeC6YOW5dj3obsJ2tkUu8U264T5CUEPlWhqaRDvkYCzC Jbk9edvCVY0XVa0wjkoi+8sqoj61DKPFjgCnHjG/qsw0TUstKMP11SOHgyyY9FRV+x SXEQriFyZv8rg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id EAAFC442DA0; Wed, 26 Feb 2025 14:57:50 -0500 (EST) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D6E20120331; Wed, 26 Feb 2025 14:57:50 -0500 (EST) From: Stefan Monnier To: Ihor Radchenko Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: <87tt8gobac.fsf@localhost> (Ihor Radchenko's message of "Wed, 26 Feb 2025 17:39:39 +0000") Message-ID: References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> <87ldtteqca.fsf@localhost> <864j0gx2ig.fsf@gnu.org> <87tt8gobac.fsf@localhost> Date: Wed, 26 Feb 2025 14:57:42 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.217 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 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76538 Cc: joaomoreira@gmx.se, Eli Zaretskii , 76538@debbugs.gnu.org, eller.helmut@gmail.com, pipcet@protonmail.com 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 (---) >> ??? AFAIR, we perform binary search there, no? > > No. AFAIU, the search goes like the following: > > 1. Go through all the buffer markers and find the nearest marker to > charpos/bytepos > [ This is O(num_of_markers) on master and O(length_of_marker_array) > on feature/igc ] > 2. Starting from the nearest marker, scan bytes symbol by symbol until > we find the requested charpos/bytepos > [ O(distance to nearest marker) ] > 3. While scanning, every 5000 bytes, create a new marker to cache the > charpos and bytepos. FWIW, I have a branch `scratch/markers-as-gap-array` where I replace the linked list of markers with an "array with a gap" where markers are sorted, so we use a binary search. It might help in your case. It was pretty close to be "ready to merge" at some point, except that I had trouble convincing myself that it was a clear win: in my tests, it made `save-excursion` slower (the current na=EFve data-structure is ideal for most "trivial" uses of `save-excursion`: we create a marker, push it onto the head of the list, do a bit of unrelated work in the body and then come back and just pop the marker that's still at the head of the list) and the cases where it makes the code faster are hard to come by, other than artificial micro-benchmarks. >> How small? > 8-11k. I'd expect around 20MB / 5kB =3D 4k markers, so that seems about right. > Probably, not that small after all in terms of absolute numbers. Definitely not small if you scan it linearly/na=EFvely. > The reason why it is small in my mind is that limiting the loop over > markers to 50 iterations max did not speed things up. We already limit the max number of iterations by increasing progressively the distance considered "close enough", so maybe the problem is simply that we have to choose between spending too much time in the linear scan of the list of markers or we have to spend too much time in the linear scan of the chars. If that's the case, my branch should help significantly. > Why do I think that there is an immediate GC? It is a guess (possibly > incorrect). My guess is originating from the fact that > bug_charpos_to_bytepos is calling build_marker directly to cache buffer > positions. However, the returned Lisp object is not used and thus > probably not referenced by any of the roots (it does get stored in the > buffer's marker list - but that's a weak array). Indeed those cache-markers are referenced only weakly so they currently disappear at every GC. I can't remember if I kept this behavior in my branch, but I remember considering some alternative where we keep every other weak marker. Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 26 15:10:27 2025 Received: (at 76538) by debbugs.gnu.org; 26 Feb 2025 20:10:27 +0000 Received: from localhost ([127.0.0.1]:55596 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tnNjf-00067v-3s for submit@debbugs.gnu.org; Wed, 26 Feb 2025 15:10:27 -0500 Received: from mout02.posteo.de ([185.67.36.66]:44531) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tnNjb-00067Z-66 for 76538@debbugs.gnu.org; Wed, 26 Feb 2025 15:10:25 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id D126E240103 for <76538@debbugs.gnu.org>; Wed, 26 Feb 2025 21:10:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1740600616; bh=IV7l9kNEpa2dm4v+ePBDmFr3gweD+h7JZTmQ3wKtnEs=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding:From; b=VXaHJFUS/FTdaLFthSu/9aF0hZ6+Wmjjxzg7zYzbYFPgJD+Gou7IjL/3Z0xwlrM8I 9s3W1dSrdufXnMF/W4ty/oPS3j1ms9TfGVXk/AZEF4l5TfOHgmJJ/DiX8YfbtI09DX xE+kuk1Koa1lmAino5QCoK2Kl2qsKRQpIiggMutWiKN8GrRye/S4Px3nG5dIqZM7Nc VlsjpSoC0sj4tdQ+4GKtqXJdzP2ZIVEW5FmRoCOSQB5JFyDZEqoXN+5k9QCch+WCBh Cwx4nssBaV9qJ/Ak6MJDQD5PlxBVLxq7uScLprv7XqdbO+xdiBNY+YK+WIZWcLemz3 7gX1A931nGlqQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Z35Dk3g1Qz9rxD; Wed, 26 Feb 2025 21:10:14 +0100 (CET) From: Ihor Radchenko To: Stefan Monnier Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> <87ldtteqca.fsf@localhost> <864j0gx2ig.fsf@gnu.org> <87tt8gobac.fsf@localhost> Date: Wed, 26 Feb 2025 20:09:45 +0000 Message-ID: <87r03ko4c6.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76538 Cc: joaomoreira@gmx.se, Eli Zaretskii , 76538@debbugs.gnu.org, eller.helmut@gmail.com, pipcet@protonmail.com 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 (---) Stefan Monnier writes: > FWIW, I have a branch `scratch/markers-as-gap-array` where I replace the > linked list of markers with an "array with a gap" where markers are > sorted, so we use a binary search. It might help in your case. Maybe not on feature/igc (this bug is about igc). It made changes to the way markers are stored in buffer and your branch might need to be adapted to work with the branch. > It was pretty close to be "ready to merge" at some point, except that > I had trouble convincing myself that it was a clear win: in my tests, it > made `save-excursion` slower (the current na=C3=AFve data-structure is id= eal > for most "trivial" uses of `save-excursion`: we create a marker, > push it onto the head of the list, do a bit of unrelated work in the > body and then come back and just pop the marker that's still at the head > of the list) and the cases where it makes the code faster are hard to > come by, other than artificial micro-benchmarks. FYI, feature/igc is also using an array for markers. So, your approach might not be as bad here. > Indeed those cache-markers are referenced only weakly so they currently > disappear at every GC. I can't remember if I kept this behavior in my > branch, but I remember considering some alternative where we keep every > other weak marker. It may or may not be the case on feature/igc. I think it remains to be the case, and, unlike master, GC on feature/igc may happen at arbitrary time rather than at specific code points. So, it may clear the cache in the middle of the search (AFAIU). --=20 Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 26 16:27:34 2025 Received: (at 76538) by debbugs.gnu.org; 26 Feb 2025 21:27:34 +0000 Received: from localhost ([127.0.0.1]:55803 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tnOwH-0001XL-CV for submit@debbugs.gnu.org; Wed, 26 Feb 2025 16:27:34 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:44726) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tnOvV-0001Vc-Vp for 76538@debbugs.gnu.org; Wed, 26 Feb 2025 16:26:47 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7319E1001EE; Wed, 26 Feb 2025 16:26:39 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1740605198; bh=kxjNx5NiAtqLWomXhDmlzUl4HYiKH7UUtUAYt5DWt0o=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=VYgrn7W9eK2L4pn3sbE5qqjL0IJBf5h/WghSi57lEwMDdBqoM85zqT/l7W8iFKOh+ 8RCdX0dsmQtJhio0eT6LrAlgvYiY1kkK/o0+XUYf8HuzM8F1Cphbl2Fawb6Pcyz0u9 VHb6XOEJ/W6M9egHce5LP2d0oNth//xZMEt3erulLiyJwdoC1MW6YagcCwBIvxcp+e AniRmLQjaUdkM3vfjtFhkGv/zOMrfyeoasfv0zHf+Ozf+kncO5JVc82/h+UwY1FtyI ZnRV9WhneP7UZLb/KORzUJITV2F8XuUkqibs2bOkAjGIp6YuZ4ApvFz0oH4OK11vhn N6Qr38NaXqOJw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 1A488100154; Wed, 26 Feb 2025 16:26:38 -0500 (EST) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 04E05120904; Wed, 26 Feb 2025 16:26:38 -0500 (EST) From: Stefan Monnier To: Ihor Radchenko Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: <87r03ko4c6.fsf@localhost> (Ihor Radchenko's message of "Wed, 26 Feb 2025 20:09:45 +0000") Message-ID: References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> <87ldtteqca.fsf@localhost> <864j0gx2ig.fsf@gnu.org> <87tt8gobac.fsf@localhost> <87r03ko4c6.fsf@localhost> Date: Wed, 26 Feb 2025 16:26:37 -0500 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-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.078 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 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76538 Cc: pipcet@protonmail.com, eller.helmut@gmail.com, Gerd =?windows-1252?Q?M=F6llmann?= , joaomoreira@gmx.se, Eli Zaretskii , 76538@debbugs.gnu.org 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 (---) [ See the end for a possible explanation and solution to the slowdown we see on the igc branch. ] >> FWIW, I have a branch `scratch/markers-as-gap-array` where I replace the >> linked list of markers with an "array with a gap" where markers are >> sorted, so we use a binary search. It might help in your case. > > Maybe not on feature/igc (this bug is about igc). It made changes to the > way markers are stored in buffer and your branch might need to be > adapted to work with the branch. Definitely. Not sure how to proceed, tho. I kind of like the idea of keeping "separate" development on separate branches. But indeed, since the igc branch already changed the implementation of markers, maybe I should rebase my branch on top of igc? >> It was pretty close to be "ready to merge" at some point, except that >> I had trouble convincing myself that it was a clear win: in my tests, it >> made `save-excursion` slower (the current na=C3=AFve data-structure is i= deal >> for most "trivial" uses of `save-excursion`: we create a marker, >> push it onto the head of the list, do a bit of unrelated work in the >> body and then come back and just pop the marker that's still at the head >> of the list) and the cases where it makes the code faster are hard to >> come by, other than artificial micro-benchmarks. > > FYI, feature/igc is also using an array for markers. So, your approach > might not be as bad here. In the igc branch, both adding a marker to a buffer and removing it from a buffer are very fast O(1) operations (even better than the code on `master`, for the case of removal), whereas with my sorted-array-with-gap I need O(log N) time for each of those. =F0=9F=99=81 I can probably improve the performance a bit by taking advantage of locality, but even if I can reduce the average number of iterations through the loop, there is still the fact that the current code doesn't need to iterate at all. >> Indeed those cache-markers are referenced only weakly so they currently >> disappear at every GC. I can't remember if I kept this behavior in my >> branch, but I remember considering some alternative where we keep every >> other weak marker. > It may or may not be the case on feature/igc. I think it remains to be > the case, and, unlike master, GC on feature/igc may happen at arbitrary > time rather than at specific code points. So, it may clear the cache in > the middle of the search (AFAIU). With my sorted-array-with-gap we could be much more sophisticated about the handling of cache-markers: - The data-structure can much more easily handle a large number of markers (even during things like insertion/deletion the updates are significantly cheaper), so there is less pressure the get rid of cache markers. - Because the array is sorted we can easily estimate the usefulness of a given cache-marker (by looking at its distance to the next marker). - We could keep a running cost/benefit analysis for each cache marker, which gets incremented when we need to update the position and decremented when we use the marker for byte<->char conversion. - In the current system, once we have "too many markers" (and that happens pretty quickly) the byte<->char conversion code may fail to find the nearest marker, simply because it's too far from the top, so we end up creating yet more cache-markers. If we're not careful to throw away the cache-markers from the end of the linked-list, this could quickly lead to absurdly large numbers of (cache-)markers. BTW, now that I look at the code, maybe the problem you're bumping into is that on the igc branch, (cache-)markers are added to the rear of the array (as a first approximation), whereas on `master` they're added to the front of the linked list. In `buf_charpos_to_bytepos` we scan the array/list starting from the front, so once the array gets large we never reach the end of the array where we would find the recently-created nearby cache-marker, so instead of using that nearby (cache-)marker we end up creating a new one and paying (again) for a costly long scan. Maybe if we change the `DO_MARKERS` iteration to scan from the end, we'd recover a behavior much closer to what we see on `master`. Gerd? Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 26 16:35:25 2025 Received: (at 76538) by debbugs.gnu.org; 26 Feb 2025 21:35:25 +0000 Received: from localhost ([127.0.0.1]:55829 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tnP3s-000522-Vo for submit@debbugs.gnu.org; Wed, 26 Feb 2025 16:35:25 -0500 Received: from mail-10631.protonmail.ch ([79.135.106.31]:51965) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tnP3q-00051e-LF for 76538@debbugs.gnu.org; Wed, 26 Feb 2025 16:35:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1740605716; x=1740864916; bh=n6eE+t/Sx5qzyuVq82Dvv+k+LMAlp/Y+BW99yxh4jFE=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=YVBME0AXvPn6dbTr/O3Si4MTPgc8qfyw8w/l8QqkoDKPOs0kYDmNGqH2/VNwy+pS/ +L/5o0P29d2zFqMUlGU1lTdl3utb5zC7zll95Gpv1OOuaPGW8d2Rw1A3eEeKWu6Uki sf8gkW9RTVM1u64TnUr3fdYLQiAWad7VmJbS5PP6GG29LTVCnr8j516NR5HiXFvqLl mUz8voEAa8+SJijuB7TnUhE10v3kswHYKgDbGZcdn5uIpAmzycGa4SGJBcvdzKWDMB IlxAiM/OO+dJaDQgEfXY2/8uBR6c0MpMfpujdjbHEUaknf3v3xjbnzGKq8bnz4EJCc 2W12iHuvMb+ZQ== Date: Wed, 26 Feb 2025 21:35:10 +0000 To: Stefan Monnier From: Pip Cet Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. Message-ID: <87plj42xw6.fsf@protonmail.com> In-Reply-To: References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> <87ldtteqca.fsf@localhost> <864j0gx2ig.fsf@gnu.org> <87tt8gobac.fsf@localhost> <87r03ko4c6.fsf@localhost> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 4b31de69193efc48176e79b4f325e38aa122eb02 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: 76538 Cc: Ihor Radchenko , eller.helmut@gmail.com, =?utf-8?Q?Gerd_M=C3=B6llmann?= , joaomoreira@gmx.se, 76538@debbugs.gnu.org, Eli Zaretskii 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 (-) "Stefan Monnier" writes: > [ See the end for a possible explanation and solution to the slowdown > we see on the igc branch. ] > >>> FWIW, I have a branch `scratch/markers-as-gap-array` where I replace th= e >>> linked list of markers with an "array with a gap" where markers are >>> sorted, so we use a binary search. It might help in your case. >> >> Maybe not on feature/igc (this bug is about igc). It made changes to th= e >> way markers are stored in buffer and your branch might need to be >> adapted to work with the branch. > > Definitely. > > Not sure how to proceed, tho. > I kind of like the idea of keeping "separate" development on > separate branches. But indeed, since the igc branch already changed the > implementation of markers, maybe I should rebase my branch on top of igc? That'd be great. It seems we definitely need a better implementation here :-) >>> Indeed those cache-markers are referenced only weakly so they currently >>> disappear at every GC. I can't remember if I kept this behavior in my >>> branch, but I remember considering some alternative where we keep every >>> other weak marker. >> It may or may not be the case on feature/igc. I think it remains to be >> the case, and, unlike master, GC on feature/igc may happen at arbitrary >> time rather than at specific code points. So, it may clear the cache in >> the middle of the search (AFAIU). > > With my sorted-array-with-gap we could be much more sophisticated about > the handling of cache-markers: > > - The data-structure can much more easily handle a large number of > markers (even during things like insertion/deletion the updates are > significantly cheaper), so there is less pressure the get rid of > cache markers. > - Because the array is sorted we can easily estimate the usefulness > of a given cache-marker (by looking at its distance to the next marker)= . > - We could keep a running cost/benefit analysis for each cache marker, > which gets incremented when we need to update the position > and decremented when we use the marker for byte<->char conversion. > - In the current system, once we have "too many markers" (and that > happens pretty quickly) the byte<->char conversion code may fail to > find the nearest marker, simply because it's too far from the top, so > we end up creating yet more cache-markers. If we're not careful to > throw away the cache-markers from the end of the linked-list, this > could quickly lead to absurdly large numbers of (cache-)markers. > > BTW, now that I look at the code, maybe the problem you're bumping into > is that on the igc branch, (cache-)markers are added to the rear of the > array (as a first approximation), whereas on `master` they're added to > the front of the linked list. > > In `buf_charpos_to_bytepos` we scan the array/list starting from > the front, so once the array gets large we never reach the end of the > array where we would find the recently-created nearby cache-marker, so > instead of using that nearby (cache-)marker we end up creating a new one > and paying (again) for a costly long scan. That seems to match what's happening here, with the order of scanning to blame, but... > Maybe if we change the `DO_MARKERS` iteration to scan from the end, > we'd recover a behavior much closer to what we see on `master`. ...I tried doing that, and it didn't work. Maybe I messed up somehow. Pip From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 26 17:40:39 2025 Received: (at 76538) by debbugs.gnu.org; 26 Feb 2025 22:40:39 +0000 Received: from localhost ([127.0.0.1]:55957 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tnQ50-0008Ik-IR for submit@debbugs.gnu.org; Wed, 26 Feb 2025 17:40:38 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:53180) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tnQ4x-0008IT-Cv for 76538@debbugs.gnu.org; Wed, 26 Feb 2025 17:40:36 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 8AE8A442DED; Wed, 26 Feb 2025 17:40:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1740609626; bh=bE+FBEgLOvEVboTtbFEQKZXahntHVt802iApVamGkbs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=gNubOg9KAza/Ji3Nte5bqc7ch/U24RE6DacBcyxeVrpYI4wyqBjDV0i62xGqCtP46 boMiQ6QetC157ghN5kBGRQ1ft6rL5BzxQdNHuBwSP6y6O65DDfuqDyM6Kb49riZfaX RyreMcbp6HRHQoXKqoLqifsUJP4rfxpMW4mkUrQwtV3/UsH1jcYca/G2n7lymaQcP1 dJkv88YJlyfqY9GGZDyy/aozQRcC2Mz31Po0LbVSh0jbEFf34JrNcYQXWA4jE53aUo Ev0UCUnVw2VqkxfTO4o20qSDgu94lWEDsEkAeE3L0j+956hkomzcqTP7ACW60nz+qW Hf7f6BHslTIuw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id A73E8442DE8; Wed, 26 Feb 2025 17:40:26 -0500 (EST) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8F1DA120370; Wed, 26 Feb 2025 17:40:26 -0500 (EST) From: Stefan Monnier To: Pip Cet Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: <87plj42xw6.fsf@protonmail.com> (Pip Cet's message of "Wed, 26 Feb 2025 21:35:10 +0000") Message-ID: References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> <87ldtteqca.fsf@localhost> <864j0gx2ig.fsf@gnu.org> <87tt8gobac.fsf@localhost> <87r03ko4c6.fsf@localhost> <87plj42xw6.fsf@protonmail.com> Date: Wed, 26 Feb 2025 17:40:26 -0500 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-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.217 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 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76538 Cc: Ihor Radchenko , eller.helmut@gmail.com, Gerd =?windows-1252?Q?M=F6llman?= =?windows-1252?Q?n?= , joaomoreira@gmx.se, 76538@debbugs.gnu.org, Eli Zaretskii 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 (---) >> BTW, now that I look at the code, maybe the problem you're bumping into >> is that on the igc branch, (cache-)markers are added to the rear of the >> array (as a first approximation), whereas on `master` they're added to >> the front of the linked list. >> >> In `buf_charpos_to_bytepos` we scan the array/list starting from >> the front, so once the array gets large we never reach the end of the >> array where we would find the recently-created nearby cache-marker, so >> instead of using that nearby (cache-)marker we end up creating a new one >> and paying (again) for a costly long scan. > > That seems to match what's happening here, with the order of scanning to > blame, but... > >> Maybe if we change the `DO_MARKERS` iteration to scan from the end, >> we'd recover a behavior much closer to what we see on `master`. > > ...I tried doing that, and it didn't work. Maybe I messed up somehow. Hmm... yeah, maybe you messed up somehow, or maybe it's because of the "as a first approximation": Gerd's array of markers keeps a free-list so new markers are not really always added to the end, but rather they're added "randomly" in the reverse order where markers were removed from the buffer (until reaching the end of this, at which point it's added to the end of the array). If there are enough markers in the array, anywhere that's not very-near the rear (or the front, depending on the order in which we scan) will simply never be consulted during char<->byte conversion. =F0=9F=99=81 Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 26 17:53:13 2025 Received: (at 76538) by debbugs.gnu.org; 26 Feb 2025 22:53:13 +0000 Received: from localhost ([127.0.0.1]:55989 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tnQHB-0000Rf-9F for submit@debbugs.gnu.org; Wed, 26 Feb 2025 17:53:13 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:53843) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tnQH8-0000RL-LJ for 76538@debbugs.gnu.org; Wed, 26 Feb 2025 17:53:12 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 213E78078F; Wed, 26 Feb 2025 17:53:05 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1740610384; bh=6r+bpvVvjG5gRqHSHlIX4YUIi4ET7QylYAPb+EvOrWg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=meCeii5zCDGMKbeahPH6DaLA69/TNfZB9gAdcH7ALkDdtl0YRLtbTi//P8Xp2rT+5 wv51pujkfxs1ZLr72NV1eRELS5pR5NvKRFiIV+JmrMfV+PwA/uXn/tDmEF+Q0WEB/C lBYEpeyTML9PqcERulXaZRn+CZQzZbOVygnNFwSc/En72Ec08xxDJ0v3VVBYnUhSkn 30F9PacZJ5qG4aIQjTB3ShUSfIMJQUwQ23gp8oR/xezk3DBunts6zpD8CYlfZDOV2y 1PnXDobN7QnzfvCd5+D5QI+yOTHr+/LXP7gNiCIIKGEI/diYvk4os1Yp0SJR7IHfz7 n0QU+sz0UHiNg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 1EFD680683; Wed, 26 Feb 2025 17:53:04 -0500 (EST) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 072661201BB; Wed, 26 Feb 2025 17:53:04 -0500 (EST) From: Stefan Monnier To: Pip Cet Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: (Stefan Monnier's message of "Wed, 26 Feb 2025 17:40:26 -0500") Message-ID: References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> <87ldtteqca.fsf@localhost> <864j0gx2ig.fsf@gnu.org> <87tt8gobac.fsf@localhost> <87r03ko4c6.fsf@localhost> <87plj42xw6.fsf@protonmail.com> Date: Wed, 26 Feb 2025 17:53:03 -0500 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-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.208 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 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76538 Cc: Ihor Radchenko , eller.helmut@gmail.com, Gerd =?windows-1252?Q?M=F6llman?= =?windows-1252?Q?n?= , joaomoreira@gmx.se, 76538@debbugs.gnu.org, Eli Zaretskii 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 (---) > Gerd's array of markers keeps a free-list so new markers are not really > always added to the end, but rather they're added "randomly" in the > reverse order where markers were removed from the buffer (until reaching > the end of this, at which point it's added to the end of the array). > If there are enough markers in the array, anywhere that's not very-near > the rear (or the front, depending on the order in which we scan) will > simply never be consulted during char<->byte conversion. =F0=9F=99=81 Maybe we can confirm this behavior: - in the `buf_*pos_to_*pos` code, in the `DO_MARKERS` loop, we can keep track of the range of indices of the markers we consult. - then when we exit unsuccessfully and create a new cache-marker, we can compare the index of that cache-marker with the indices we consulted. If the index is not within the range of indices we consulted, then this cache-marker is most likely going to be useless (because, if nothing else is changed, next time we need to convert at this position we simply won't find it). Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 26 18:19:53 2025 Received: (at 76538) by debbugs.gnu.org; 26 Feb 2025 23:19:53 +0000 Received: from localhost ([127.0.0.1]:56127 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tnQgy-0001pr-VM for submit@debbugs.gnu.org; Wed, 26 Feb 2025 18:19:53 -0500 Received: from mail-ed1-x533.google.com ([2a00:1450:4864:20::533]:58550) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tnQgv-0001pR-2J for 76538@debbugs.gnu.org; Wed, 26 Feb 2025 18:19:50 -0500 Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-5ded69e6134so445438a12.0 for <76538@debbugs.gnu.org>; Wed, 26 Feb 2025 15:19:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740611982; x=1741216782; 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=5Mtzu8of8eSCznjJZ5lSz4HOzW1rf18IntuvElid/I4=; b=jP1A9c97I5R4vNTEqcZNOOvNMiab3QPeLmS4e5ZAAYpTqbrLhvPDy4ogWhI/RNF3e3 f0bWJdQLfw0hwr+H4vMyiCIqbo6qq+zC+v4F7yC4OdqarYmU+ASKPQnlVQHRpAqIAknL LWLylzL91vtO8idkSOJila50HBtoCsLPl5jLrPp7/NIomNlbzSZndgBE1qUy0PzrjPld WwfUdH4mYOlh5h3Z6QNU5IC7KhnOgClYdGIpzHUW63zmkbq3vdW+IAVatxYhxCazRoPI eAshBNM1NoX9zoLhXGLeRDDsmfFWRWnd0QxxnO97AjrGBLotVHlq24fQppFeZgU5MW6R If4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740611982; x=1741216782; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=5Mtzu8of8eSCznjJZ5lSz4HOzW1rf18IntuvElid/I4=; b=d3XECEgQGm+p2GxOOe6dXASoYhnEhO9uZWJjdgiF/Ztx0DVmkPivQfMJXUUcGtTCLG uHw5oyhEwHtgkJnkgCRXH9M7q796wrxWiQWW3RLCRmSfZBJnwgdTUjanyHwcDUEdrDRy NZ5DFAp6E1Y0GOFOWGSZ9+klA8YK2cqwinQml7BRqmFZN9KPmU4cwESAeLRXTU12P3Tm 2+ZgtjIn1UOZoxRtjBXu6+1fvV/rUFpeXkNoU7dYD2WZEUGkPRz0BA4X6Ycypd7Wc1Qq v358XYXWCd/QaX0NnJA4+WIDXRQAAPVhM7fY9uH84Tu57WeFXA9d5Gv8teqWCtD/GgUQ BfDQ== X-Forwarded-Encrypted: i=1; AJvYcCW8WBLxPJRIMRXABo+JWFLT3pGVWb7EwB/2l0th6EgyOBDSgV/kOkDS1rMa9C1yz6/P1s67uw==@debbugs.gnu.org X-Gm-Message-State: AOJu0Ywgmq3hApsEj2RcMTDTdiWUWZ9vzKKskuptlkLryKJDFaLUbxDi 1cBYJNmE0s3/XPU43tmd/NM2Tq752rZdLnO11cmeSPOTCIliRTl6hRAKF5vo X-Gm-Gg: ASbGncsHlZd/Iz0wRCL6NgCwBOztZrxY+lqpylaCzlyacigTmhPui9NYwUaQxuakD2O nlcYr/YUM5KeEb+7KrXrjwq8w9EUF+NHNotb/t5iw4Nw7+cybqA7UGCivW12cuAafjrfDpmbGGU 7HL1gmT02X5HaGMbDJIkjE1nI3VSt5rGAI4gDdEsXbc5I9VmiX/D3W8nSgjHGnZZhyOcSEIRHri 1MQec0hJBGsBYbDtiJztktTFxnBug/nTaVgy1gAjjusZ+mydDaheGITkkA06+dnjX8T9DvCiXOs DVIf38+Hi9eNJWU/hxIqEZRsToilNkn+hj9X5z36hlTsHLvbj6FJAXWtvWY= X-Google-Smtp-Source: AGHT+IHBQ8pqvcnJ9AMgBZj7EThZHoW0+K8F/iu21CVUmQK57N/sxFG/wNQftMZQJWEl3SaN+1eXww== X-Received: by 2002:a05:6402:51d3:b0:5dc:91c6:8096 with SMTP id 4fb4d7f45d1cf-5e4a0e17803mr6431156a12.30.1740611982099; Wed, 26 Feb 2025 15:19:42 -0800 (PST) Received: from caladan (dialin-233080.rol.raiffeisen.net. [195.254.233.80]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5e4c43a4e26sm161543a12.66.2025.02.26.15.19.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Feb 2025 15:19:41 -0800 (PST) From: Helmut Eller To: Stefan Monnier Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: (Stefan Monnier's message of "Wed, 26 Feb 2025 16:26:37 -0500") References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> <87ldtteqca.fsf@localhost> <864j0gx2ig.fsf@gnu.org> <87tt8gobac.fsf@localhost> <87r03ko4c6.fsf@localhost> Date: Thu, 27 Feb 2025 00:19:41 +0100 Message-ID: <87v7swz436.fsf@gmail.com> 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: 76538 Cc: pipcet@protonmail.com, Ihor Radchenko , Gerd =?utf-8?Q?M=C3=B6llmann?= , joaomoreira@gmx.se, 76538@debbugs.gnu.org, Eli Zaretskii 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 (-) On Wed, Feb 26 2025, Stefan Monnier wrote: [...] > Maybe if we change the `DO_MARKERS` iteration to scan from the end, > we'd recover a behavior much closer to what we see on `master`. > Gerd? D=C3=A9j=C3=A0 vu: https://mail.gnu.org/archive/html/emacs-devel/2024-08/msg00171.html From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 26 23:33:50 2025 Received: (at 76538) by debbugs.gnu.org; 27 Feb 2025 04:33:50 +0000 Received: from localhost ([127.0.0.1]:57437 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tnVao-0004EZ-27 for submit@debbugs.gnu.org; Wed, 26 Feb 2025 23:33:50 -0500 Received: from mail-ej1-x62e.google.com ([2a00:1450:4864:20::62e]:44259) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tnVal-0004EE-MD for 76538@debbugs.gnu.org; Wed, 26 Feb 2025 23:33:48 -0500 Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-abb81285d33so97507166b.0 for <76538@debbugs.gnu.org>; Wed, 26 Feb 2025 20:33:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740630820; x=1741235620; 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=2BbcgMXJIEN5n3M2k55rn0nO+oAS8RJNU/pSiNe+oaQ=; b=EG7auI39rdrx8vODCwsZ7CYEkLcvc4feSIMj9xKVXODxUjG3RVfjSr5BJaXCeCCFOy JVuJzB4fCdRbKYD4i5JAVrYU6vXZPet53EtmFjiHHwDSN1gfuz3KJ1/k132SRetWL9HU Oehio/9t99EQpbHgSYZj3YFIlONWwuTOVQQI++zuSkUwvqYIq7NWGlHT9THBeO7HtD+2 P0p+Uu+6CFbd6ITtGKckdzxC3Uw6lx9b3pgmxus1hYcuYZd6soIgF7wIWg1Pz9c3MT5y 7vQvXnBaHpmcA0PTA9DI/EIU9D9sr1QTuAKyEmVUqPe56OIgm0Ont/ahMN2uEK00ElE6 ZRyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740630820; x=1741235620; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=2BbcgMXJIEN5n3M2k55rn0nO+oAS8RJNU/pSiNe+oaQ=; b=nuse/jyVRMrGbfJ0vLrzFVJTAAFaZRRhaL56MWE5Z0U1wifqCKrVbMIYxWn4GuaBIs 4zp1AUIWcYj6q9uwnZpUiP6bf49ew9o5YMQlqh9SdgkOPgVmY5kkgE6BVyt9/BVPcDYm kFLjTDXnPyuRKVuICjKoPsmWZ6BdbgsRkgsavbtYoZoCpJPOnFD5VNEsMYsjyfF2a9JJ FZK1qnsiBis1M/SMojlTYcdMh8NAYvA4D0YMI+J7NNbnyVahcuvCm9JfRgGG5bJzo21E Vo+4NVdE4ShqC51uvZBY0nW7M8G2N7qCovT6gBXFH0MMWICjcCe9b4/fnlSZh+fib/31 ec2A== X-Forwarded-Encrypted: i=1; AJvYcCUB66XsJAQopzjZzLSMffnDoZZ7L8ozIsJWfkvtj1Egn1qR/E5qt14friRpQ6u9XzyGwrZkGw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YySUoWkwH012rOJlzN/abG7VP+aLSsJsSngzYrJQJHO49YK7QMc xYmmJdmz+g+Rsbc19A/ZuRrb361mTN831yRxxCbAXkm2m4ncqYEX1us11w== X-Gm-Gg: ASbGncv2tGATe7fIIS+CJpVNPb+4U91g0TzajSSHZ8ye584FUSoYasxiYKxT8DwJDPu xACuRb0v8YDDY/Ul+HiihdulwuWdMrygEG04cTtLg7IlPnkNj5/aIXfsbPJtUhPl8UfOqXkv1us f5bQbq/beEWLA2hfW0eJEabfmS+mTUp5qlHthcHNqemTftP/Y6Igt4gDn89UeFsImKYh5R2c/Ni STBJmxk7px5Kg3gvUc0dj/xxsHck9kAP+kE9RU72eEyLbkQO2KcvUnAQRKcgn6OWH1V05etpH9A ADEyqacNuEZgxdSjyuJAOWpX2/8ufZr0QFDhk7n5ZsQh0EsYrB/t0Hkr7tUVr+0UNhpg7NSIOw1 jW6+31jFBbjdcDps6rfQDp79XosqEf5DTy1o= X-Google-Smtp-Source: AGHT+IH6j6Zj7xmN2YkX1Ps4AEqEDXIZ92P292Ckjwv60IsBMSxiWOm1Cf1fxHcQqddHFSkZcjcBGQ== X-Received: by 2002:a17:907:784b:b0:ab7:ea59:2120 with SMTP id a640c23a62f3a-abc099b3571mr2504312766b.10.1740630820279; Wed, 26 Feb 2025 20:33:40 -0800 (PST) Received: from pro2 (p200300e0b742e900d58024e7fc0776a0.dip0.t-ipconnect.de. [2003:e0:b742:e900:d580:24e7:fc07:76a0]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-abf0c0b987asm57025166b.17.2025.02.26.20.33.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Feb 2025 20:33:39 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Stefan Monnier Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> <87ldtteqca.fsf@localhost> <864j0gx2ig.fsf@gnu.org> <87tt8gobac.fsf@localhost> <87r03ko4c6.fsf@localhost> Date: Thu, 27 Feb 2025 05:33:37 +0100 Message-ID: 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: 76538 Cc: pipcet@protonmail.com, eller.helmut@gmail.com, Ihor Radchenko , joaomoreira@gmx.se, 76538@debbugs.gnu.org, Eli Zaretskii 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 (-) Stefan Monnier writes: > Maybe if we change the `DO_MARKERS` iteration to scan from the end, > we'd recover a behavior much closer to what we see on `master`. > Gerd? I don't know, but it might well be that one order is as bad as the other, depending on the order in which markers are added to and removed from the marker array. And I have no intuition what a marker array ends up looking like in a typical use case, alas. Hm. Can we record the insertion order somehow? I guess that's what the heuristic is using? From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 26 23:36:12 2025 Received: (at 76538) by debbugs.gnu.org; 27 Feb 2025 04:36:12 +0000 Received: from localhost ([127.0.0.1]:57451 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tnVd5-0004PR-NM for submit@debbugs.gnu.org; Wed, 26 Feb 2025 23:36:12 -0500 Received: from mail-ej1-x62c.google.com ([2a00:1450:4864:20::62c]:51688) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tnVd3-0004P6-1T for 76538@debbugs.gnu.org; Wed, 26 Feb 2025 23:36:09 -0500 Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-abbd96bef64so82905466b.3 for <76538@debbugs.gnu.org>; Wed, 26 Feb 2025 20:36:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740630962; x=1741235762; 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=Ltlx7ol1nV4iLdCge1iNLwrIvx080E9BeKjCgmJxDuA=; b=UHRv2wMAjD7FTijNxOoLvJVr24PajLKzjcPQhbvgGBLDLYntFvU+3RyIUUIywCA9N/ RN3BBI7aZk6vdV+pqRQ/mI3JBcMfYpuQQtYmDHCKGoHyL7jvtlLDb94w253FK4caKGZD QiIpgUbE2Bmo2v2uFwyUBmulJOFa5xZvqHHuTPxCAiyuCl2NYkJViUkvKR06mUqjaCc+ RCy7YY7mm+/TukE22UjdbnJiLq+6FOu3tGW/IgWDfVN7UuOLj8iLDoVc7oV8wO0wuJ9U iny0iCr7+PN1+yl8g7CcyCMtq3bPbEJC+02xYol1gQsVWdSaSHv4Y6A4wW7LfHBenBG7 3onA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740630962; x=1741235762; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Ltlx7ol1nV4iLdCge1iNLwrIvx080E9BeKjCgmJxDuA=; b=HVSFQ/gOXgtT3OfxTWgi5FhzkgwMmpDlxvFUbRvVzN9O3fOy1wFlsvngqbS5062c/D 439+lV2ncvUrUI+xPXHZA5wOGfrlhV0eeXP6VpiWzvZrVu3qNVd3ysJ1hJE/h/v8Zqdr pN8x2k4p8j0YG/t13OfUFYUjjvNeBKYPuCvEP6ckMD3O021yRDi9trHTfm9zhEtpcvAS UPCyvkB5E0AtH1yKMNZ4SEQ+NzNMD9rbsIFnoI0tRkfUFTBW+t8wGtJx/k23Lw1iLIPm u3vKhkQ7tkWfR7xMk6pY5q6i9hXTgG+LnzgibmNT/p9vlzJqg3hI5MgsNbF/7NYbmOpM oh9g== X-Forwarded-Encrypted: i=1; AJvYcCVWj9RqjGk/g9leFIe/hPytmG4S1Kbhv8qS1NliERlO1zKyDL0toEIUneSXcG3J8QLce84Kxg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwN9hBPn2dchl5el3ke3oHNf8RgO8dw/sthHV5TsKjVua0TWxSM Wk8xd/1l+5Xwe/gfaLcbIhR8/1mzS3mBvDejqIGeN0jnuSdixlIR8BQ5/A== X-Gm-Gg: ASbGncvCoEljk0shlXLV8kEbC5t1mio7gSZea9IHLz7yMzhFxbIOaZaYDEWQ+4gk9vi kB4IqTxrwfSLtqZOYgLH82WmsqtnwnJ7debEmkXtSVPGLqTR9U1IzgxlQE5+/pZH4gIQvZVsKQ8 XUh99SvpQE0XyRncZ+TDvUWCrAN4RGv/9uAminHbWQSWUe1KUEJ8x7MGl0MLtltajgFqyD8C0yr gL/j06iaK8nqwdpBq8NkmaCyTw/ORkfTw1gIid57XYMrioig2jeGhBzVorcnyAX679/LpkCDy1d 1s2xmkSsW4lvhl7p236/5+2QlfHhYedGb6MDWTH4lTiqJTAZPzw1eWBAx3pp/UQszyA5rc4zPrG LZzaztykq29DK47MTmEOj0mmeYcF8lbYIjuk= X-Google-Smtp-Source: AGHT+IHBgTPopHXSpfIMFNd/+PJBV9fi8Yxj0D67zAl0BmpqTJF3f/+I9QY3b+038ZdSmPptIVvUhQ== X-Received: by 2002:a17:906:3181:b0:ab7:e8d6:3b21 with SMTP id a640c23a62f3a-abed0d764demr1109224366b.28.1740630962330; Wed, 26 Feb 2025 20:36:02 -0800 (PST) Received: from pro2 (p200300e0b742e900d58024e7fc0776a0.dip0.t-ipconnect.de. [2003:e0:b742:e900:d580:24e7:fc07:76a0]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-abf0c6ee63csm55834266b.95.2025.02.26.20.36.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Feb 2025 20:36:01 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Helmut Eller Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: <87v7swz436.fsf@gmail.com> References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> <87ldtteqca.fsf@localhost> <864j0gx2ig.fsf@gnu.org> <87tt8gobac.fsf@localhost> <87r03ko4c6.fsf@localhost> <87v7swz436.fsf@gmail.com> Date: Thu, 27 Feb 2025 05:36:00 +0100 Message-ID: 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: 76538 Cc: pipcet@protonmail.com, Ihor Radchenko , Stefan Monnier , joaomoreira@gmx.se, 76538@debbugs.gnu.org, Eli Zaretskii 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 (-) Helmut Eller writes: > On Wed, Feb 26 2025, Stefan Monnier wrote: > > [...] >> Maybe if we change the `DO_MARKERS` iteration to scan from the end, >> we'd recover a behavior much closer to what we see on `master`. >> Gerd? > > D=C3=A9j=C3=A0 vu: > > https://mail.gnu.org/archive/html/emacs-devel/2024-08/msg00171.html :-) From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 27 13:20:39 2025 Received: (at 76538) by debbugs.gnu.org; 27 Feb 2025 18:20:39 +0000 Received: from localhost ([127.0.0.1]:37616 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tniUw-0000Ss-Lw for submit@debbugs.gnu.org; Thu, 27 Feb 2025 13:20:39 -0500 Received: from mout02.posteo.de ([185.67.36.66]:57223) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tniUt-0000Rf-MM for 76538@debbugs.gnu.org; Thu, 27 Feb 2025 13:20:36 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 2911A240101 for <76538@debbugs.gnu.org>; Thu, 27 Feb 2025 19:20:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1740680427; bh=6eyzTvDxyWekrfkamZDjEJvE6obYTGDN7R5+Rp7pqLY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding:From; b=sM75i2/OsE12SbkcFCCIDpDWAxqLCbhqG+82UVJNK1txfX5w7PCy7t6nceaRV36Yk ZonAIebcEg17Poz5HpQf1B5JS84LZAijA3aDykDWno/dyZ6E5ZzHpEEK5oqfHToTYF 8eySkSgrgZu7Koo2WBLPPPOSjsVc8i2gzVlUNRbxKyFlbfhD58KvcQ009/6SrpqoTk SmMXT7ull9QbWdUUbrIt/0lh/kNcNPqdHVWVh2iT2amt81IyNBry85qnwEXvKy7oGX bmoXkIQwaeNoJO7690mmIOaJvpSiiL8ob2v9kXksca81oQ8APVrEsJh6isNeEBq/kz kemx58h1Jcyow== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Z3flY2KX7z9rxD; Thu, 27 Feb 2025 19:20:25 +0100 (CET) From: Ihor Radchenko To: Gerd =?utf-8?Q?M=C3=B6llmann?= Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> <87ldtteqca.fsf@localhost> <864j0gx2ig.fsf@gnu.org> <87tt8gobac.fsf@localhost> <87r03ko4c6.fsf@localhost> Date: Thu, 27 Feb 2025 18:19:56 +0000 Message-ID: <87r03jgshf.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76538 Cc: pipcet@protonmail.com, eller.helmut@gmail.com, Stefan Monnier , joaomoreira@gmx.se, Eli Zaretskii , 76538@debbugs.gnu.org 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 (---) Gerd M=C3=B6llmann writes: > Stefan Monnier writes: > >> Maybe if we change the `DO_MARKERS` iteration to scan from the end, >> we'd recover a behavior much closer to what we see on `master`. >> Gerd? > > I don't know, but it might well be that one order is as bad as the > other, depending on the order in which markers are added to and removed > from the marker array. And I have no intuition what a marker array ends > up looking like in a typical use case, alas. > > Hm. Can we record the insertion order somehow? I guess that's what the > heuristic is using?=20 FYI, I tried various tweaks to that loop while debugging and concluded that DO_MARKERS loop is not the main bottleneck in this particular bug report. I am wondering if anyone else is able to reproduce the problem locally. --=20 Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 27 14:33:12 2025 Received: (at 76538) by debbugs.gnu.org; 27 Feb 2025 19:33:12 +0000 Received: from localhost ([127.0.0.1]:38168 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tnjdA-0004Ic-39 for submit@debbugs.gnu.org; Thu, 27 Feb 2025 14:33:12 -0500 Received: from mail-wr1-x432.google.com ([2a00:1450:4864:20::432]:59444) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tnjd7-0004Hm-GD for 76538@debbugs.gnu.org; Thu, 27 Feb 2025 14:33:10 -0500 Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-38a8b17d7a7so872052f8f.2 for <76538@debbugs.gnu.org>; Thu, 27 Feb 2025 11:33:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740684783; x=1741289583; 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=mtgel4BFNjZsVT4r2uc6RGaeLKmG5n9Ie6dR/t+rkTE=; b=iLSVUz0uyAkJwkGRFZW6Lg9rq3TFS+TLwsHsAgsVeVzASy0ZWtNtbT0ulX0zXU54e6 zi2XBp9gwjou0LPkVqGgPzBvf/RTnDYDbDmDIe2b/F/aQyTSfgevw12LDJhfeQeksWZa z7DmykEnmdmyb/Tmp7gvQNw4iIggT7cnnoT8q0fCWRw2KOteAjZ8PJ8m6ZJyOYasRQz6 l1YBYvHPswkdQdDP8Hqx+WG2rFLWmOCdYdqpfKkcI/Wx0tGKfmobxRtGOxSmqk+GKfNT XJwhWWDSYT94A1Kvz22zEvgFAR94xPIzAxuHC0+qXFcP1Dkq7hySVHtuxRDIy0yR8F4k gzpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740684783; x=1741289583; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=mtgel4BFNjZsVT4r2uc6RGaeLKmG5n9Ie6dR/t+rkTE=; b=MohLJU3eRImYxIyf1MO3Fi8iOihBZpGmksqsu/bbPn6Key+HRw31O+6WZa6AUN0YnF TW4xBgg2Vn3jEL/QFX8LucJJS32jAHVDCQ113iSBbcFTHYnw7pGC1rKlMxU7zaKrydsl yJ4HaaEF1R5teD4X7v32itCfGxU5xoJVkxUAWrCldW7GpYyjZwTt5g7XTPKTIMmf8lUa XbH2+beqLVIchr5qHo2u0aeHN/LdpKSF97DxdS2AL+sfHJp+uhkOOVLmP2U9lPXHhmw1 f02xObKZomzIrckwEIiIxfdoVFYNgom4tiAftaLUBnGQKs1VItwy6lsTBuJWKa169Wl5 xJiA== X-Forwarded-Encrypted: i=1; AJvYcCVtlY/fs1Rj9J581WjHW3O3US0ikwg0FZ6bJm4iKIwKLXfekqS6I9+l0AauqPWaWLU+8SW3AA==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yx4H6gFOtMda7ji/hBGKQDUyNCK6JRbyjbe1n++LVgMaXDLDh2b NcLO5WWTYEKTQHG6mbvq8/txk8UY3wgugOWEFXadP4NuShiYhPDHyxjHtQ== X-Gm-Gg: ASbGncvYj2cfVq1vTGRqi23EImH/8kcXU/QrR0iyAxj4DbkA2BCmvFA+OSQxDYWFUkI IwckmMDL9BqS9Zac6cZWOaEuEqN5DuVCzNU9H2j+PCva+Z+A9oZxHUd/iEUKjb2hx1itYGuZ3is scFJu9N4a6K5Lu2NpYLqnQ0l9TMX7MJt8Q36xBSbxOCJTYpe4eF0w9HUXeggV4WeuS6yjVxb1/O xWyRXxko0xPTqQ0GTLq40UaXU9uOYb/kgFv1VIpPOdqbjdk/QvJfMI8dauc8hyLHswIqvk98kbl uiwRJbTYi7ioFGHiM+7A1e1FjcH1Vy1qE5rzf2VCpGo6jW8XgUAnoWB9cUX4rSU/ZVgSz7xZQP3 ZbV5Hx5TE4r3OhMHo0E4QvE8C4K0+smHOfKc= X-Google-Smtp-Source: AGHT+IGs7+0AS17C6ju++HPe2aKUxrR5FGXDbwxkLYkI2+h1/RtHrJH724IUKyimFVTd7xy5eueLwA== X-Received: by 2002:a05:6000:154b:b0:38f:4f25:1482 with SMTP id ffacd0b85a97d-390eca4840dmr314462f8f.42.1740684782842; Thu, 27 Feb 2025 11:33:02 -0800 (PST) Received: from pro2 (p200300e0b742e900d58024e7fc0776a0.dip0.t-ipconnect.de. [2003:e0:b742:e900:d580:24e7:fc07:76a0]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-390e486eea3sm2886655f8f.101.2025.02.27.11.33.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Feb 2025 11:33:02 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Ihor Radchenko Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: <87r03jgshf.fsf@localhost> References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> <87ldtteqca.fsf@localhost> <864j0gx2ig.fsf@gnu.org> <87tt8gobac.fsf@localhost> <87r03ko4c6.fsf@localhost> <87r03jgshf.fsf@localhost> Date: Thu, 27 Feb 2025 20:33:01 +0100 Message-ID: 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: 76538 Cc: pipcet@protonmail.com, eller.helmut@gmail.com, Stefan Monnier , joaomoreira@gmx.se, 76538@debbugs.gnu.org, Eli Zaretskii 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 (-) Ihor Radchenko writes: > Gerd M=C3=B6llmann writes: > >> Stefan Monnier writes: >> >>> Maybe if we change the `DO_MARKERS` iteration to scan from the end, >>> we'd recover a behavior much closer to what we see on `master`. >>> Gerd? >> >> I don't know, but it might well be that one order is as bad as the >> other, depending on the order in which markers are added to and removed >> from the marker array. And I have no intuition what a marker array ends >> up looking like in a typical use case, alas. >> >> Hm. Can we record the insertion order somehow? I guess that's what the >> heuristic is using?=20 > > FYI, I tried various tweaks to that loop while debugging and concluded > that DO_MARKERS loop is not the main bottleneck in this particular bug > report. > > I am wondering if anyone else is able to reproduce the problem locally. I haven't tried the OP's recipe, but I know that Magit can get really slow, things taking minutes. An example would be a large merge of several hundred files, and with conflicts. The status buffer becomes as good as unusable then. I don't think this started with igc. From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 27 14:49:07 2025 Received: (at 76538) by debbugs.gnu.org; 27 Feb 2025 19:49:07 +0000 Received: from localhost ([127.0.0.1]:38272 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tnjsZ-0005iM-9k for submit@debbugs.gnu.org; Thu, 27 Feb 2025 14:49:07 -0500 Received: from mout02.posteo.de ([185.67.36.66]:46581) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tnjsU-0005h0-Vw for 76538@debbugs.gnu.org; Thu, 27 Feb 2025 14:49:05 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 61C97240101 for <76538@debbugs.gnu.org>; Thu, 27 Feb 2025 20:48:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1740685735; bh=UGo8GCI+9YkTX9epDx6fukUANXKvj21OPysa50GmSk4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding:From; b=a5aIE8M7eDmXe9mEOuiYQ66rkmjo18HdQh1xSTYilWr/1eOf+Z+5/CDFOpKuGmtM4 vJdFHVplsuhRRTb6Rg+FBVJMQLWcv7HBYxbAb/ndiC3bBnMBbewDKdlbKCVJw8USCc eqMXoF9hxNCv9lGwEpgBOsJ8MRFXSmW58TNZRFnJgVkzAgOM5poDI+dkd/CFRWBNOH cT12siO/kgUNBESMSV664fsGytfaFatFpm5oSd/4+ckDwDIyFWkJIEoXvL3rMhRln2 TJQj9JgDZDfn/hOmwJGl2yUg09Q8EXvtsWu/HRHrdxQfdICp9HffvS09DLdidPPl+Q dwL011vCQ8unw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Z3hjf2Lscz6v0M; Thu, 27 Feb 2025 20:48:54 +0100 (CET) From: Ihor Radchenko To: Gerd =?utf-8?Q?M=C3=B6llmann?= Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> <87ldtteqca.fsf@localhost> <864j0gx2ig.fsf@gnu.org> <87tt8gobac.fsf@localhost> <87r03ko4c6.fsf@localhost> <87r03jgshf.fsf@localhost> Date: Thu, 27 Feb 2025 19:48:25 +0000 Message-ID: <87ldtrgody.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76538 Cc: pipcet@protonmail.com, eller.helmut@gmail.com, Stefan Monnier , joaomoreira@gmx.se, 76538@debbugs.gnu.org, Eli Zaretskii 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 (---) Gerd M=C3=B6llmann writes: >> I am wondering if anyone else is able to reproduce the problem locally. > > I haven't tried the OP's recipe, but I know that Magit can get really > slow, things taking minutes. An example would be a large merge of > several hundred files, and with conflicts. The status buffer becomes > as good as unusable then. I don't think this started with igc. In this particular case, igc is hanging forever while master just hangs for a few seconds and then goes back to be responsive. So, something _is_ going on in igc. --=20 Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 27 15:54:30 2025 Received: (at 76538) by debbugs.gnu.org; 27 Feb 2025 20:54:30 +0000 Received: from localhost ([127.0.0.1]:38720 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tnktq-00062k-7V for submit@debbugs.gnu.org; Thu, 27 Feb 2025 15:54:30 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:58184) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tnktn-000624-KT for 76538@debbugs.gnu.org; Thu, 27 Feb 2025 15:54:28 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 91DE9444526; Thu, 27 Feb 2025 15:54:20 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1740689659; bh=Gt/ES9WJXADfdl/uvbliAYb8jhxPTSG5MX0B4qUHbRg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=GZi0cpfvhZoZVVy+uT6GpAVFzw6lvv/kJkw6sJJj8Sd0sGfPkk5fYw8njhzqbedDt QcpD/EGWYLSEYUYjvTgodfqvX17+W4x6onT7VXTBKZ2vWLNbtykMg9rTpos0Cylw4V b8KawR5buBKGbJt6iJzBsxzTnam1r1RKbmenwSZU19v+hqQ1/RbsFgbhCGZQltUokp OS9lJZou7X4pl7h8ZOJPnuL26FjqATX8nAjN7GnekFzgvhK9RUDFJaFo9ucf3fBn1M uDyorTBuMF2i1RkKMLx5vNP/m+Fqeu/agdt3hRlwrbCgekT3Ct27eLq3RGSSo2lXYq RS0FxgLW06Nsw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 865074415AA; Thu, 27 Feb 2025 15:54:19 -0500 (EST) Received: from alfajor (modemcable005.21-80-70.mc.videotron.ca [70.80.21.5]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4CF881203A5; Thu, 27 Feb 2025 15:54:19 -0500 (EST) From: Stefan Monnier To: Ihor Radchenko Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: <87r03jgshf.fsf@localhost> Message-ID: References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> <87ldtteqca.fsf@localhost> <864j0gx2ig.fsf@gnu.org> <87tt8gobac.fsf@localhost> <87r03ko4c6.fsf@localhost> <87r03jgshf.fsf@localhost> Date: Thu, 27 Feb 2025 15:54:18 -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.060 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 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76538 Cc: pipcet@protonmail.com, eller.helmut@gmail.com, Gerd =?windows-1252?Q?M=F6llmann?= , joaomoreira@gmx.se, Eli Zaretskii , 76538@debbugs.gnu.org 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 (---) > FYI, I tried various tweaks to that loop while debugging and concluded > that DO_MARKERS loop is not the main bottleneck in this particular bug > report. The DO_MARKERS is probably not the main bottleneck nowadays, because the code explicitly reduces the "estimated benefit" of remaining in the loop at each iteration and exits once that gets too small. But that just pushes the problem to the subsequent bytes-scan. The main problem is simply that we need to make sure some nearby (cache-)marker is found near the "beginning" of the set of markers we consider. Once this set becomes large the ordering between the markers becomes super-important. The code on `master` behaves a bit like an "move to front" policy which works fairly well for the usual locality properties of buffer navigation, whereas the code on the `igc` branch has a tendency of putting new entries near the end where they risk not being found at all, making the cache ineffective. > I am wondering if anyone else is able to reproduce the problem locally. I haven't looked at the recipe yet, TBH. But I strongly suspect that you're seeing something similar to what happens in the `bytechar-100k-random` benchmark in Helmut Eller's email. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 28 00:09:17 2025 Received: (at 76538) by debbugs.gnu.org; 28 Feb 2025 05:09:18 +0000 Received: from localhost ([127.0.0.1]:43193 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tnsce-0002yx-GT for submit@debbugs.gnu.org; Fri, 28 Feb 2025 00:09:17 -0500 Received: from mail-wm1-x32f.google.com ([2a00:1450:4864:20::32f]:56405) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tnscb-0002y0-DC for 76538@debbugs.gnu.org; Fri, 28 Feb 2025 00:09:14 -0500 Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-4399d14334aso15748885e9.0 for <76538@debbugs.gnu.org>; Thu, 27 Feb 2025 21:09:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740719347; x=1741324147; 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=DvD5IQU/eEdsmxUIuzz/tdY0OiXJ9NvkLZd53Tv1x1Y=; b=NPcYnCN5YYWnEn7Y2wKxG+IiMWI/FV2MaX6x+AkYmzjTLZY0VvnPttRTKvqJnZcGTj /EbUPcCyM0yktljXZdFWS65PiFrrSr991L9HpyggRSRtHWidfCAqDUzo6PREocd/hjlQ O3teORhbyurMiNwo8gAKJxPkXXMIAEauzuBv9D/YmT0Rv1sVGHKQFto9jBAwwv0Cg8sj 3b0DmtZp/Ovsy4CMJ88NCeveWxoot7OU+tk31/yzwn6oFHVRY5wK21uFa8hO8Ask8X8h /rZ53ARAd1BAUOw1eOM+tkvJFs9XHlESaaJGr8KalNXJgRTxIFI0BskVhCAcE4x4aZyZ H8Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740719347; x=1741324147; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=DvD5IQU/eEdsmxUIuzz/tdY0OiXJ9NvkLZd53Tv1x1Y=; b=kfp3cIBzzw1AScCSPEwQgQbVhxXPh5q4lwqrW6Sq7atN1WhN1GsA0mTMm7KRYumB8f vnEmhk056vQzTwItd8YZtiot/owA6bnYXDdplidzJGhunvJ+QtqIo0bgHifs27zi87jP fIiQ9pPSvDRbhz6PWy3C6zmLCtv/7QCEWA0qBoRND0b59YS5Uo6HeMUNndjIEKlwPB+k BZmRAv/F6FJvGwfPYnXEBnMPT/ZZ5b9/d/A7tl9E6YEk0i8xRr1FVoaiNwb19POnjdaU TfSNIRhj0Tuhl2wp8sK7MjB0oSq5H1EgeqM945+vSyQM4Rg1KEST464ypZcVpbtTrJ89 TmIQ== X-Forwarded-Encrypted: i=1; AJvYcCUEX4ByZUE1+qMv+zHvVtoTsaCPwv7yAvBJNXHMcCvP1pRHDHu7ToBPYLo6bpdcARP4AnOeCw==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yx2fUe+HcomodsxFHwAeJ7+mZgPSgRjJZUqBH/TIoYtASgGoxdy ifeP4bBPFDIDttpX01b6oMpKg1tbjFSIBcb2czgzNPz7nxeSxfHYMo99HA== X-Gm-Gg: ASbGncs1ar8scZwzQJf0hgS+dY3nm55LUA8ELoxj71qWV1DGuLDAPdi4lDVDSaPSny5 W3Slyt+73p/IkDA3pUf3sXh7Xr5RPYSO0fexQHnLMWHnrjmtKnVqHtzsFgkisJWsjB4D30vNIym 25p7EVisXOm1Imxh3C7AnxibCmArO7sG0gXn8BicpJNSsbSxwF8TWD6Pcy66a/en+TADkgz2cgk 25TbFQV3zFmiBaHPBwUV9BujUT6r7X+iFGCQXUc5+uXv1ZIxaYSRLSQkX2Dn4gQAYwt+4oPDUWC BVUzfEXG5x7rZl39lx35DMzQK0VRg43VxNeYmFRD5zu01ZsWAQb0in9uawoVSJwBgjLFkCSVUct obFLfZgV/0wZ1Pi8kZLY8hlBs6HBUqg89xQI= X-Google-Smtp-Source: AGHT+IFCnKKVDasCorFLis20KuTs4+C+Yk19runzZ4kYmrnisK8/FhjOFgenMaLunAJCND5azS7z/w== X-Received: by 2002:a05:600c:a03:b0:439:967b:46fc with SMTP id 5b1f17b1804b1-43ba67036bfmr13394465e9.8.1740719346379; Thu, 27 Feb 2025 21:09:06 -0800 (PST) Received: from pro2 (p200300e0b7498a003827111227ebc470.dip0.t-ipconnect.de. [2003:e0:b749:8a00:3827:1112:27eb:c470]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43b7a27abd6sm42979385e9.26.2025.02.27.21.09.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Feb 2025 21:09:05 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Stefan Monnier Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> <87ldtteqca.fsf@localhost> <864j0gx2ig.fsf@gnu.org> <87tt8gobac.fsf@localhost> <87r03ko4c6.fsf@localhost> <87r03jgshf.fsf@localhost> Date: Fri, 28 Feb 2025 06:09:03 +0100 Message-ID: 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: 76538 Cc: pipcet@protonmail.com, eller.helmut@gmail.com, Ihor Radchenko , joaomoreira@gmx.se, 76538@debbugs.gnu.org, Eli Zaretskii 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 (-) Stefan Monnier writes: >> FYI, I tried various tweaks to that loop while debugging and concluded >> that DO_MARKERS loop is not the main bottleneck in this particular bug >> report. > > The DO_MARKERS is probably not the main bottleneck nowadays, because the > code explicitly reduces the "estimated benefit" of remaining in the loop > at each iteration and exits once that gets too small. > > But that just pushes the problem to the subsequent bytes-scan. > > The main problem is simply that we need to make sure some nearby > (cache-)marker is found near the "beginning" of the set of markers we > consider. Once this set becomes large the ordering between the markers > becomes super-important. The code on `master` behaves a bit like an > "move to front" policy which works fairly well for the usual locality > properties of buffer navigation, whereas the code on the `igc` branch > has a tendency of putting new entries near the end where they risk not > being found at all, making the cache ineffective. Right, the order is important because the DO_MARKERS loop relies on the assumption that cache-markers are found "early" in the loop. Or that's how I understand it. >From just reading the code again, and taking into account what Pip said about the number of markers being created, I think what happens in igc is something like this, in buf_charpos_to_bytepos. Let's say we have initially our array of markers [m1, m2, m3, ...]. We are looping over the array with DO_MARKERS. With each round, we decrease our expectations what a good enough marker looks like. M1 would have to be relatively close to the position we are looking for, m2 not so close, m3 may be even farther away, and so on. Okay. Let's say we don't find our position, and add a cache-marker. The array now looks like [m1, m2, m3, ..., c1, ...]. Next time in the function, we loop again. We compare with m1, then m2, m3 as before. But there is nothing saying that we'll reach c1. We add c2 and now have [m1, m2, m3, ..., c2, c1, ...]. And so on, and so on. And we can't really say where c1 and c2 are added in the array. That depends on the free-list, which depends on how markers are added/removed or weakly fixed (fix_marker_vector). Do we know how often fix_marker_vector runs? In any case, I think I would try to change DO_MARKERS to start at the end of the marker vector. If fix_marker_vector runs often enough one could also "straighten" the free-list there, maybe. (Sorry, I can't bring me to dive deep into this, ATM.) From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 28 00:19:52 2025 Received: (at 76538) by debbugs.gnu.org; 28 Feb 2025 05:19:53 +0000 Received: from localhost ([127.0.0.1]:43268 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tnsmr-00043t-P6 for submit@debbugs.gnu.org; Fri, 28 Feb 2025 00:19:52 -0500 Received: from mail-ej1-x62b.google.com ([2a00:1450:4864:20::62b]:60688) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tnsml-00042r-Su for 76538@debbugs.gnu.org; Fri, 28 Feb 2025 00:19:46 -0500 Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-aaee2c5ee6eso243619166b.1 for <76538@debbugs.gnu.org>; Thu, 27 Feb 2025 21:19:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740719977; x=1741324777; 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=vjOB5sP1ziIoU80d054Znh4oNhW/hQS4s7z54D6kPHA=; b=GjyECbBBTj16njVJzsKKnKul58p8CcefrEzfamEuKtDdg/U7W9Fq+ctevtORXkqDRq sdZXqAu3UGwNZpwhJya6+ex0ACyMOIRwkY/uIWRSbrBE7SLjFnVw2FxhRaMEdDoO9USv uIe1O6VSIA1S28hL3/UYkL47ej4jMV3KZwQxAFGD2HuVj/143qDfuJ/PymcXvK8oIRW2 l7HQXuZjUUsPbGKTSGvAlVZKU2l733oEx+xC6Nxn53PY3xrVS6wBrBHW2ijpdtok6yI/ thhrf1Gl+enxUPYa7s7HxxX6uLmoN9M2VTV1PISApyFXH65COAnIRFfU+eXvDpI7VVQc XbXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740719977; x=1741324777; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=vjOB5sP1ziIoU80d054Znh4oNhW/hQS4s7z54D6kPHA=; b=Y3DTHojXu4sALqxbgZlfbqMdP+B4Yv5Zl1UPanrOCvKOPiZUorpA3s3BgHI7LPnP7m Zj1XRH5UVzcZJLlatrx1KvUt8XWw8X9oDRATDif+6iRG/4/wrt/RzROcX+r5tGkPJ5kI 7aHBXBIMGjMJZCv8E4iVMUqw+qFMJgfZQSH9NS1wSXFsCDLNI3Bd9C1wOxxd8uywCrPN QgiaT1ITk7gV/0JsqkIe2XN5HZzRdiL2wuJiIfZT5IA8XCkJaQLlcM52yKD3vTIw/6iu 0RCzQAPsa+6tvFcWEp0adWXeLlb6l8NkEpt5sUKFtzXOj2i3PVoH7oq5OwpvYquAgaGw MwGg== X-Forwarded-Encrypted: i=1; AJvYcCWvjgP7tMiJYY00jxrAb2BWRAa5IPhWPkH/HblkReMapV4MIU7kIg0l8Ynu+cLr/em8L0cNiQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yz3irBFimG2EyovFgEXvj8/EDrR/Q+jhqFq4LpNJj/8wbdHqZFq H/rEozBAECcL4wyCZuQJXpPeSe1ILYZYHGJMYE6brjNuVTBAVtgI4MAJEw== X-Gm-Gg: ASbGncvBRu0sHwTTOkSTV2SpnGBuHAUqWoHYlKYrq7Qz1CnbyDOWmya2ksWIKe1sgsK CkxvCsYHXlSZhogzqejEdMcVyNxPrSoMpy2wsviawpiD1DxMhSqDQqpl2JTXz+JhRZ05Ey98vje SByEpydEfJLDL2ENEGCjWXIpxfaUG0I+o1PW+umBmEVmZizg3SluuuqjCP+uU+SVi4lqDn7SaVB 3TgKmuWBkeHyRupxB3hbh5dqjh+wd+6jwdz7m2O1CI3rm2uRFuIqR026dgqUbMV2B0zpX9t4yYc PwwsW60NKdb5oBRXUYFFFBe+/G6LS1+ac1pnbA8UFUxnhcur1himxcHzry4VXRJpJqCRyhj/Icl JbTCMMfDn6pKjTbVIkjHKUTkqsuA5uA/9RKflESMym1MG+kx5XijOWA== X-Google-Smtp-Source: AGHT+IGFuZfp4SoyAv9AIV3cpMweq9eSDjFjFjXlgCJeFzxgQ0C+41idZ5bCaSj65YUomtZyKVQesQ== X-Received: by 2002:a17:907:60cc:b0:ab7:ee47:993f with SMTP id a640c23a62f3a-abf269b4479mr188578566b.47.1740719976911; Thu, 27 Feb 2025 21:19:36 -0800 (PST) Received: from pro2 (p200300e0b7498a003827111227ebc470.dip0.t-ipconnect.de. [2003:e0:b749:8a00:3827:1112:27eb:c470]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-abf0b86e84csm232514766b.0.2025.02.27.21.19.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Feb 2025 21:19:35 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Stefan Monnier Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> <87ldtteqca.fsf@localhost> <864j0gx2ig.fsf@gnu.org> <87tt8gobac.fsf@localhost> <87r03ko4c6.fsf@localhost> <87r03jgshf.fsf@localhost> Date: Fri, 28 Feb 2025 06:19:34 +0100 Message-ID: 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: 76538 Cc: pipcet@protonmail.com, eller.helmut@gmail.com, Ihor Radchenko , joaomoreira@gmx.se, 76538@debbugs.gnu.org, Eli Zaretskii 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 (-) Gerd M=C3=B6llmann writes: > In any case, I think I would try to change DO_MARKERS to start at the > end of the marker vector. If fix_marker_vector runs often enough one > could also "straighten" the free-list there, maybe. Or one could build a doubly-linked list of markers in most-recently created order. But that would mean 3 array slots per marker in the marker vector. Don't know. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 28 03:20:30 2025 Received: (at 76538) by debbugs.gnu.org; 28 Feb 2025 08:20:30 +0000 Received: from localhost ([127.0.0.1]:44755 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tnvbh-0004uX-VQ for submit@debbugs.gnu.org; Fri, 28 Feb 2025 03:20:30 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:35458) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tnvbe-0004uE-NT for 76538@debbugs.gnu.org; Fri, 28 Feb 2025 03:20:28 -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 1tnvbW-0001b7-Sm; Fri, 28 Feb 2025 03:20:18 -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=6vTW1Q2Qa26jLXba8RVydrjKv73eZ5VZIhaGYfJZT/I=; b=Vy6sWhiYN0auvRLgX5rR 5wO1GGESr+NxvablSaYKDT+BzJSO14jEXUJjV0J80QOuNNBEoHftH1nulp/AnHBUY/g75deKD5Y2j aU0ExqUbqjKgHC0cAmKE37l/tzeqXLG/gsT6DpLwnsmBgkGOi/u4fH1Cjxo3t+3FK+iGo2wc/9wl8 wzLIMjvLqq1H4dkd2enfABHFIZkM4KjxnWRLTeQkGzta/2slre+YeznwXeSMu5tcFmG4HZPe6z/0/ UBzqPMXNylP5vIGxkcgP7HAfGwStSHLwIpzfS7m2NaJ2XJfk/Mdy/ffKt95y86gTYdTwPvgFj4F3X En+WlCBqYdNlag==; Date: Fri, 28 Feb 2025 10:19:56 +0200 Message-Id: <86o6ymscpf.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?utf-8?Q?M=C3=B6llmann?= In-Reply-To: (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Fri, 28 Feb 2025 06:19:34 +0100) Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> <87ldtteqca.fsf@localhost> <864j0gx2ig.fsf@gnu.org> <87tt8gobac.fsf@localhost> <87r03ko4c6.fsf@localhost> <87r03jgshf.fsf@localhost> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76538 Cc: pipcet@protonmail.com, eller.helmut@gmail.com, yantar92@posteo.net, monnier@iro.umontreal.ca, joaomoreira@gmx.se, 76538@debbugs.gnu.org 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: Gerd Möllmann > Cc: Ihor Radchenko , Eli Zaretskii , > eller.helmut@gmail.com, pipcet@protonmail.com, joaomoreira@gmx.se, > 76538@debbugs.gnu.org > Date: Fri, 28 Feb 2025 06:19:34 +0100 > > Gerd Möllmann writes: > > > In any case, I think I would try to change DO_MARKERS to start at the > > end of the marker vector. If fix_marker_vector runs often enough one > > could also "straighten" the free-list there, maybe. > > Or one could build a doubly-linked list of markers in most-recently > created order. But that would mean 3 array slots per marker in the > marker vector. Don't know. How about not relying on buffer markers too much for this job? And in particular, not adding any ephemeral markers when we don't find a close-enough existing marker? We could instead build our own data structure, and make it so we could use efficient search methods. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 28 10:01:20 2025 Received: (at 76538) by debbugs.gnu.org; 28 Feb 2025 15:01:21 +0000 Received: from localhost ([127.0.0.1]:50579 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1to1rb-0007nd-TS for submit@debbugs.gnu.org; Fri, 28 Feb 2025 10:01:20 -0500 Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]:60501) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1to1rX-0007mq-66 for 76538@debbugs.gnu.org; Fri, 28 Feb 2025 10:01:16 -0500 Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-390dd3403fdso1921305f8f.0 for <76538@debbugs.gnu.org>; Fri, 28 Feb 2025 07:01:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740754869; x=1741359669; 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=YnvqJoirOpIRK+gcWxhJpotkImD5vK3VUlANuCFD4Ew=; b=aLbVvdxSHU15xShJTiVaTQ6ap+fkfo0mbuzqFWAUcBeEDa5RH5FsbMYVKI2SuVHvkc eib58xy1PFYl4ekHMBpA/mu+azKJkQ+zIxrSzGKmIz1uo9aIjDKY/5aIYqZOwc5P8EUt 6Nm1PDikcRrghNUQvzxeVOj8pm6TZkdaU88qPZikZbksz0CU5RXW6VUbFZSK+p9f7jYJ CaUwLhkiVbp0/8kdBQoFnfzT9FoI4gIWPN1o0+03Ho80qrl2HOrCymdb+LaHpnkFrNx9 M9KbrvzWBevGCooahotrP9Ax3cyBDQXrwFnbH/DpIz0JL1iyEKPafCU1DltLgLOdyV50 Q+Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740754869; x=1741359669; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=YnvqJoirOpIRK+gcWxhJpotkImD5vK3VUlANuCFD4Ew=; b=kj0DJVh0cihpD3EJMh92tebyUFY/RnJOIuYf/boD4QiL385pL6i9YOVzMyfP5V1KCG +Xbmkln1YZY5vExCBEKt6B1Cv77oDi0uG6eAYaVN31ZYvvSvdpyYFbDpU95Coc/yLuf0 Zgmv+MwW9ZOMMxVYEpEkHKI4BJNDlVsvSqX1PcBb2+d11zsm2zveW8rrCZX2MrWGjfx+ WyppTZJD/ZRMO+00p6Zf0xBaAc4gVzRq4DmsViV08r3DMScxZaat52L/9fYNsEf5tssc xPgTe5r/DjDUtvq9RL9EbbbEc44hJd/pZKfsj689gimDdMrzh9iairAiupkcE6OZSwuu JoSQ== X-Forwarded-Encrypted: i=1; AJvYcCU44IKd0SGKbfYOeiRd9LAN6i0X+fuanuLHw+0u6fAp2kRKNTu0vvt5wm8+JIa3bj6QUwBQ6g==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyP9IPLT0rOpBIaWd18L1lP3+moVhNrfjreMfyhWRmkgqljbeGv A3y4ExvO1n5T28lsD52p/8dcFzrkQYB2CKormLqVSSJAPfmo4pEhszBizg== X-Gm-Gg: ASbGnctj7vKovMeGFWGnbXgbE3ihhyGnxF2tDh+pwUFvF6loWL/uGJ3Q1jQEDpfZI/U sn8AGxHiLjfhp3QZMD0avgwJMhMnvm9M4+VtP/G+f+o9funi1FWX7vRcvrJKA3H2SOKLIOq6vZE otOoSAutj0SHb4JBEiRUHyWVc6OgfJV9CDTlNfTW/sXXW7UE1Ds2+meUMmRoIP50MF8tDFXoQxY osnCbdYuzwbhOQXvxvVXdnjuTDSUZqr1LG86K0jn+3pw5pUyza4PM+EtzuBc/qUu7BR9Qq4R7V9 fVHT0B/P6D6I/eABq+uINrvHhb4UEBoqsn7iE3462Q1847Wkxaa4igi9DZzAVnI87KDhZ7KioNZ kSQUuUnu6h+ThwFJXaizYnE4dKE3LZiDK0R4= X-Google-Smtp-Source: AGHT+IESBUajCNVAZ0saSN4tLEB0xeTm+KvCMMwDePygqY5YPB4MOq7eQG+/noBOl3QeH1rdlTQ1jA== X-Received: by 2002:a05:6000:2a8:b0:38d:df05:4f5 with SMTP id ffacd0b85a97d-390eca5b5c6mr2752866f8f.42.1740754866503; Fri, 28 Feb 2025 07:01:06 -0800 (PST) Received: from pro2 (p200300e0b7498a003827111227ebc470.dip0.t-ipconnect.de. [2003:e0:b749:8a00:3827:1112:27eb:c470]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-390e479608fsm5552498f8f.14.2025.02.28.07.01.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Feb 2025 07:01:05 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Stefan Monnier Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> <87ldtteqca.fsf@localhost> <864j0gx2ig.fsf@gnu.org> <87tt8gobac.fsf@localhost> <87r03ko4c6.fsf@localhost> <87r03jgshf.fsf@localhost> Date: Fri, 28 Feb 2025 16:01:04 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76538 Cc: pipcet@protonmail.com, eller.helmut@gmail.com, Ihor Radchenko , joaomoreira@gmx.se, 76538@debbugs.gnu.org, Eli Zaretskii 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 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Gerd M=C3=B6llmann writes: > Gerd M=C3=B6llmann writes: > >> In any case, I think I would try to change DO_MARKERS to start at the >> end of the marker vector. If fix_marker_vector runs often enough one >> could also "straighten" the free-list there, maybe. > > Or one could build a doubly-linked list of markers in most-recently > created order. But that would mean 3 array slots per marker in the > marker vector. Don't know. Which would be something like the attached. Can someone try this with the original recipe? (It's a quick sketch, and blah blah.) --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Iterating-over-markers-in-most-recently-added-order.patch >From 0153db3935e129c6b8f43ae2f6f98b8a7b570926 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Gerd=20M=C3=B6llmann?= Date: Fri, 28 Feb 2025 15:55:14 +0100 Subject: [PATCH] Iterating over markers in most-recently added order --- src/.lldbinit | 4 ++ src/buffer.h | 67 ++++++++++++++++++----------- src/igc.c | 116 ++++++++++++++++++++++++++++++++++++-------------- src/lisp.h | 2 +- src/pdumper.c | 2 +- 5 files changed, 131 insertions(+), 60 deletions(-) diff --git a/src/.lldbinit b/src/.lldbinit index 01fd51eb07d..17e48fa4967 100644 --- a/src/.lldbinit +++ b/src/.lldbinit @@ -120,3 +120,7 @@ process handle SIGINT --pass true --stop false --notify false #process attach --waitfor --name emacs (--continue) # Attach to future Emacs + +target create temacs +settings set -- target.run-args --batch -l loadup --temacs=pbootstrap --bin-dest '/Users/gerd/.local/bin/' --eln-dest '/Users/gerd/.local/lib/emacs/31.0.50/' +command alias go process launch --working-dir . diff --git a/src/buffer.h b/src/buffer.h index 20599bb3ba4..dcc93807409 100644 --- a/src/buffer.h +++ b/src/buffer.h @@ -714,31 +714,56 @@ #define BVAR(buf, field) ((buf)->field ## _) struct marker_it { -#ifdef HAVE_MPS - Lisp_Object markers, obj; - ptrdiff_t i; +# ifdef HAVE_MPS + struct Lisp_Vector *v; + Lisp_Object obj; + ptrdiff_t slot; # else struct Lisp_Marker *marker; #endif }; -#ifdef HAVE_MPS +# ifdef HAVE_MPS + +enum +{ + IGC_IDX_FREE_LIST = 0, + IGC_IDX_HEAD = 1, + IGC_IDX_START = 2, + + IGC_OFF_NEXT = 0, + IGC_OFF_PREV = 1, + IGC_OFF_MARKER = 2, + IGC_MA_NSLOTS = 3, +}; + +INLINE int +slot_to_index (int slot) +{ + return (slot * IGC_MA_NSLOTS) + IGC_IDX_START; +} + +#define IGC_MA_FREE_LIST(v) v->contents[IGC_IDX_FREE_LIST] +#define IGC_MA_HEAD(v) v->contents[IGC_IDX_HEAD] + +#define IGC_MA_MARKER(v, slot) v->contents[slot_to_index (slot) + IGC_OFF_MARKER] +#define IGC_MA_NEXT(v, slot) v->contents[slot_to_index (slot) + IGC_OFF_NEXT] +#define IGC_MA_PREV(v, slot) v->contents[slot_to_index (slot) + IGC_OFF_PREV] + +#define IGC_MA_NSLOTS(v) ((ASIZE (v) - IGC_IDX_START) / IGC_MA_NSLOTS) + INLINE struct marker_it marker_it_init (struct buffer *b) { - Lisp_Object v = BUF_MARKERS (b); - if (!VECTORP (v)) + Lisp_Object vec = BUF_MARKERS (b); + if (!VECTORP (vec)) return (struct marker_it){ .obj = Qnil }; - Lisp_Object obj = Qnil; - for (ptrdiff_t i = 1; i < ASIZE (v); ++i) - { - obj = AREF (v, i); - if (MARKERP (obj)) - return (struct marker_it) { .i = i, .markers = v, .obj = obj }; - } - - return (struct marker_it) { .obj = Qnil }; + struct Lisp_Vector *v = XVECTOR (vec); + ptrdiff_t slot = XFIXNUM (IGC_MA_HEAD (v)); + if (slot < 0) + return (struct marker_it){ .obj = Qnil }; + return (struct marker_it) { .slot = slot, .v = v, .obj = IGC_MA_MARKER (v, slot) }; } INLINE bool @@ -750,16 +775,8 @@ marker_it_valid (struct marker_it *it) INLINE void marker_it_next (struct marker_it *it) { - it->obj = Qnil; - for (++it->i; it->i < ASIZE (it->markers); ++it->i) - { - Lisp_Object m = AREF (it->markers, it->i); - if (MARKERP (m)) - { - it->obj = m; - break; - } - } + it->slot = XFIXNUM (IGC_MA_NEXT (it->v, it->slot)); + it->obj = it->slot < 0 ? Qnil : IGC_MA_MARKER (it->v, it->slot); } INLINE struct Lisp_Marker * diff --git a/src/igc.c b/src/igc.c index e8e5c892ab3..62c218182ed 100644 --- a/src/igc.c +++ b/src/igc.c @@ -2128,21 +2128,39 @@ fix_vectorlike (mps_ss_t ss, struct Lisp_Vector *v) return MPS_RES_OK; } +static void +unchain (struct Lisp_Vector *v, int slot) +{ + IGC_MA_MARKER (v, slot) = IGC_MA_FREE_LIST (v); + IGC_MA_FREE_LIST (v) = make_fixnum (slot); + + int prev = XFIXNUM (IGC_MA_PREV (v, slot)); + if (prev >= 0) + IGC_MA_NEXT (v, prev) = IGC_MA_NEXT (v, slot); + else + IGC_MA_HEAD (v) = IGC_MA_NEXT (v, slot); + + int next = XFIXNUM (IGC_MA_NEXT (v, slot)); + if (next >= 0) + IGC_MA_PREV (v, next) = IGC_MA_PREV (v, slot); +} + static mps_res_t fix_marker_vector (mps_ss_t ss, struct Lisp_Vector *v) { MPS_SCAN_BEGIN (ss) { - for (size_t i = 0, n = vector_size (v); i < n; ++i) + for (ptrdiff_t slot = XFIXNUM (IGC_MA_HEAD (v)), next; + slot >= 0; slot = next) { - Lisp_Object old = v->contents[i]; - IGC_FIX12_OBJ (ss, &v->contents[i]); + next = XFIXNUM (IGC_MA_NEXT (v, slot)); + + Lisp_Object old = IGC_MA_MARKER (v, slot); + IGC_FIX12_OBJ (ss, &IGC_MA_MARKER (v, slot)); + /* FIXME/igc: this is right for marker vectors only. */ - if (NILP (v->contents[i]) && !NILP (old)) - { - v->contents[i] = v->contents[0]; - v->contents[0] = make_fixnum (i); - } + if (NILP (IGC_MA_MARKER (v, slot)) && !NILP (old)) + unchain (v, slot); } } MPS_SCAN_END (ss); @@ -4517,18 +4535,39 @@ alloc_marker_vector (ptrdiff_t len, Lisp_Object init) static Lisp_Object larger_marker_vector (Lisp_Object v) { - igc_assert (NILP (v) || (VECTORP (v) && XFIXNUM (AREF (v, 0)) < 0)); - ptrdiff_t old_len = NILP (v) ? 0 : ASIZE (v); - ptrdiff_t new_len = max (2, 2 * old_len); - Lisp_Object new_v = alloc_marker_vector (new_len, Qnil); - ptrdiff_t i = 0; + igc_assert (NILP (v) + || (VECTORP (v) + && XFIXNUM (IGC_MA_FREE_LIST (XVECTOR (v))) < 0)); + ptrdiff_t old_nslots = NILP (v) ? 0 : IGC_MA_NSLOTS (v); + ptrdiff_t new_nslots = max (4, 2 * old_nslots); + ptrdiff_t alloc_len = new_nslots * IGC_MA_NSLOTS + IGC_IDX_START; + Lisp_Object new_v = alloc_marker_vector (alloc_len, Qnil); + struct Lisp_Vector *xnew_v = XVECTOR (new_v); + ptrdiff_t slot = 0; if (VECTORP (v)) - for (i = 1; i < ASIZE (v); ++i) - ASET (new_v, i, AREF (v, i)); - for (; i < ASIZE (new_v) - 1; ++i) - ASET (new_v, i, make_fixnum (i + 1)); - ASET (new_v, i, make_fixnum (-1)); - ASET (new_v, 0, make_fixnum (NILP (v) ? 1 : ASIZE (v))); + { + struct Lisp_Vector *xv = XVECTOR (v); + IGC_MA_FREE_LIST (xnew_v) = IGC_MA_FREE_LIST (xv); + IGC_MA_HEAD (xnew_v) = IGC_MA_HEAD (xv); + for (slot = 0; slot < IGC_MA_NSLOTS (v); ++slot) + { + IGC_MA_MARKER (xnew_v, slot) = IGC_MA_MARKER (xv, slot); + IGC_MA_NEXT (xnew_v, slot) = IGC_MA_NEXT (xv, slot); + IGC_MA_PREV (xnew_v, slot) = IGC_MA_PREV (xv, slot); + } + } + else + IGC_MA_HEAD (xnew_v) = make_fixnum (-1); + + for (; slot < IGC_MA_NSLOTS (new_v) - 1; ++slot) + { + IGC_MA_MARKER (xnew_v, slot) = make_fixnum (slot + 1); + IGC_MA_NEXT (xnew_v, slot) = make_fixnum (-1); + IGC_MA_PREV (xnew_v, slot) = make_fixnum (-1); + } + + IGC_MA_MARKER (xnew_v, slot) = make_fixnum (-1); + IGC_MA_FREE_LIST (xnew_v) = make_fixnum (old_nslots); return new_v; } @@ -4537,15 +4576,24 @@ igc_add_marker (struct buffer *b, struct Lisp_Marker *m) { Lisp_Object v = BUF_MARKERS (b); igc_assert (NILP (v) || VECTORP (v)); - ptrdiff_t next_free = NILP (v) ? -1 : XFIXNUM (AREF (v, 0)); - if (next_free < 0) + struct Lisp_Vector *xv = NILP (v) ? NULL : XVECTOR (v); + ptrdiff_t slot = NILP (v) ? -1 : XFIXNUM (IGC_MA_FREE_LIST (xv)); + if (slot < 0) { v = BUF_MARKERS (b) = larger_marker_vector (v); - next_free = XFIXNUM (AREF (v, 0)); + xv = XVECTOR (v); + slot = XFIXNUM (IGC_MA_FREE_LIST (xv)); } - ASET (v, 0, AREF (v, next_free)); - ASET (v, next_free, make_lisp_ptr (m, Lisp_Vectorlike)); - m->index = next_free; + + IGC_MA_FREE_LIST (xv) = IGC_MA_MARKER (xv, slot); + IGC_MA_MARKER (xv, slot) = make_lisp_ptr (m, Lisp_Vectorlike); + IGC_MA_NEXT (xv, slot) = IGC_MA_HEAD (xv); + IGC_MA_PREV (xv, slot) = make_fixnum (-1); + IGC_MA_HEAD (xv) = make_fixnum (slot); + ptrdiff_t next = XFIXNUM (IGC_MA_NEXT (xv, slot)); + if (next >= 0) + IGC_MA_PREV (xv, next) = make_fixnum (slot); + m->slot = slot; m->buffer = b; } @@ -4554,11 +4602,12 @@ igc_remove_marker (struct buffer *b, struct Lisp_Marker *m) { Lisp_Object v = BUF_MARKERS (b); igc_assert (VECTORP (v)); - igc_assert (m->index >= 1 && m->index < ASIZE (v)); - igc_assert (MARKERP (AREF (v, m->index)) && XMARKER (AREF (v, m->index)) == m); - ASET (v, m->index, AREF (v, 0)); - ASET (v, 0, make_fixnum (m->index)); - m->index = -1; + struct Lisp_Vector *xv = XVECTOR (v); + igc_assert (m->slot >= 0 && m->slot < IGC_MA_NSLOTS (v)); + igc_assert (MARKERP (IGC_MA_MARKER (xv, m->slot)) + && XMARKER (IGC_MA_MARKER (xv, m->slot)) == m); + unchain (xv, m->slot); + m->slot = -1; m->buffer = NULL; } @@ -4568,9 +4617,10 @@ igc_remove_all_markers (struct buffer *b) Lisp_Object v = BUF_MARKERS (b); if (VECTORP (v)) { - for (ptrdiff_t i = 1; i < ASIZE (v); ++i) - if (MARKERP (AREF (v, i))) - XMARKER (AREF (v, i))->buffer = NULL; + struct Lisp_Vector *xv = XVECTOR (v); + for (ptrdiff_t slot = 0; slot < IGC_MA_NSLOTS (v); ++slot) + if (MARKERP (IGC_MA_MARKER (xv, slot))) + XMARKER (IGC_MA_MARKER (xv, slot))->buffer = NULL; BUF_MARKERS (b) = Qnil; } } diff --git a/src/lisp.h b/src/lisp.h index 5117059ef73..a4b97189598 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -3083,7 +3083,7 @@ knuth_hash (hash_hash_t hash, unsigned bits) # ifdef HAVE_MPS /* If in a buffer's marker vector, this is the index where it is stored. */ - ptrdiff_t index; + ptrdiff_t slot; # endif } GCALIGNED_STRUCT; diff --git a/src/pdumper.c b/src/pdumper.c index b1484fda144..e94350726ee 100644 --- a/src/pdumper.c +++ b/src/pdumper.c @@ -2228,7 +2228,7 @@ dump_marker (struct dump_context *ctx, const struct Lisp_Marker *marker) dump_field_lv_rawptr (ctx, out, marker, &marker->next, Lisp_Vectorlike, WEIGHT_STRONG); #else - DUMP_FIELD_COPY (out, marker, index); + DUMP_FIELD_COPY (out, marker, slot); #endif DUMP_FIELD_COPY (out, marker, charpos); DUMP_FIELD_COPY (out, marker, bytepos); -- 2.48.1 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 28 10:22:56 2025 Received: (at 76538) by debbugs.gnu.org; 28 Feb 2025 15:22:56 +0000 Received: from localhost ([127.0.0.1]:50819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1to2CV-0001RN-C9 for submit@debbugs.gnu.org; Fri, 28 Feb 2025 10:22:56 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:32902) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1to2CS-0001QS-9J for 76538@debbugs.gnu.org; Fri, 28 Feb 2025 10:22:53 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 0B8C044084B; Fri, 28 Feb 2025 10:22:41 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1740756159; bh=dPFe8/2DghXsHxQHxXJNcUrYlc6VeVrH+1zjcDBSHPQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=J9qvAQWAKNqYyumFW2mKTYTV96UWbw0wIegx0mFuKSHIhCLxls/uuSmvxiJzGLXru yCtJ/At+wywyICedVKIQ+OXjYu/4rAMMWVIAjqhDJq+jkJy7Qjl6rhlxOrtnM7E1gD Z9eYzmjg2T+BExVLBLKtESBSrig9Mo5GPwm13qNR//e+U4x1kzKGrbg/WZLjsveW96 hSCT7pQlHAR6hBNyR1wDx7DGMzr/cfXk2drZPQWE/iLwXdhCeKXUDmFdctqEG9Qde9 rwhDq2uBf4zrHu0vfAuxzTWl+G9RZ/0XxKF9luH/zJFeiU6ZeEykI0a5j6Nj8HVsv+ z0o71AnAw1gCA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9F31F44293C; Fri, 28 Feb 2025 10:22:39 -0500 (EST) Received: from alfajor (unknown [23.233.149.155]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 78536120A3D; Fri, 28 Feb 2025 10:22:39 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: <86o6ymscpf.fsf@gnu.org> Message-ID: References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> <87ldtteqca.fsf@localhost> <864j0gx2ig.fsf@gnu.org> <87tt8gobac.fsf@localhost> <87r03ko4c6.fsf@localhost> <87r03jgshf.fsf@localhost> <86o6ymscpf.fsf@gnu.org> Date: Fri, 28 Feb 2025 10:22:38 -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.004 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 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76538 Cc: yantar92@posteo.net, eller.helmut@gmail.com, pipcet@protonmail.com, Gerd =?windows-1252?Q?M=F6llmann?= , joaomoreira@gmx.se, 76538@debbugs.gnu.org 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 (---) > How about not relying on buffer markers too much for this job? And in > particular, not adding any ephemeral markers when we don't find a > close-enough existing marker? We could instead build our own data > structure, and make it so we could use efficient search methods. FWIW, my sorted-array-with-gap is kind of trying that, after making the choice that the cache is eagerly updated during insertion/deletion. But admittedly, we could keep the markers as they are and use the sorted-array-with-gap only for the cache. This way `save-excursion` would remain as efficient as before. At the cost of extra code, of course. Another attractive choice would be a cache that is flushed during insertion/deletions (like the cache in `syntax-ppss`). In that case it can be a simple growable array with a constant lookup time since we just look at `cache[POS / N]` where N is some arbitrary factor we choose based on a tradeoff of size of the cache vs time to scan the bytes from the cache's info to the actual POS. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 28 11:07:37 2025 Received: (at 76538) by debbugs.gnu.org; 28 Feb 2025 16:07:37 +0000 Received: from localhost ([127.0.0.1]:51400 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1to2tk-0005ii-Oi for submit@debbugs.gnu.org; Fri, 28 Feb 2025 11:07:37 -0500 Received: from mail-4316.protonmail.ch ([185.70.43.16]:33625) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1to2th-0005iE-6v for 76538@debbugs.gnu.org; Fri, 28 Feb 2025 11:07:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1740758844; x=1741018044; bh=Sw6BMb+XpVLFxl+RL6j53CtP/ufB4vjDGnVeGcqXZIg=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=NdoW/GpMqPIF6fX3d3EpZGE/g/ofX/bNj1IM49uQvakCSbpk8wAi4Jo6SQZDYvrM1 Fh5zclVhBuHbqLHuEbGTlTE6cp46X45OYXAFTwo0L9Hp2BxOy+p3/ZUWc6Tk5RdKA2 sa5qR3qMRCxCNqOUEECRoLQ/Zs+6WpF0ffBG2aVSvaS4Eg/VYc0MUuaunqYrGY7fQ1 XLgEmaTRotlBPV14asGotONnlCW1f4XkEp75393FXRYbeLr+vH67SzONpF3FTswCwC eTi/liD7k9dY4yIM1gZURkWmCwxzyreetInTEX7VVUt6gSLRZH0ngwiHP0EmVF1kYs Z2aACQdq05/7g== Date: Fri, 28 Feb 2025 16:07:18 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. Message-ID: <23FNmI2HygVL9NYeMul2F9Q45nWw31E4rpZ-yCso_0Mo9kzd_xRiBv-rq4OOz4dc_FpIDxOmLohU5WzimPWwNaDf8OI6jycKZZdEqt7YLS0=@protonmail.com> In-Reply-To: <86o6ymscpf.fsf@gnu.org> References: <87ikoyetgi.fsf@gmx.se> <87r03ko4c6.fsf@localhost> <87r03jgshf.fsf@localhost> <86o6ymscpf.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: a31f343adbce86652dda9aef15690f19e7053786 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1=_4dFCXY2A6hBwtZkwP6YqezanG0tO6oub9xPoyMxA" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76538 Cc: yantar92@posteo.net, eller.helmut@gmail.com, =?utf-8?Q?Gerd_M=C3=B6llmann?= , monnier@iro.umontreal.ca, joaomoreira@gmx.se, 76538@debbugs.gnu.org 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 (-) --b1=_4dFCXY2A6hBwtZkwP6YqezanG0tO6oub9xPoyMxA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Friday, February 28th, 2025 at 08:19, Eli Zaretskii wrote= : > > From: Gerd M=C3=B6llmann gerd.moellmann@gmail.com >=20 > > Cc: Ihor Radchenko yantar92@posteo.net, Eli Zaretskii eliz@gnu.org, > > eller.helmut@gmail.com, pipcet@protonmail.com, joaomoreira@gmx.se, > > 76538@debbugs.gnu.org > > Date: Fri, 28 Feb 2025 06:19:34 +0100 > >=20 > > Gerd M=C3=B6llmann gerd.moellmann@gmail.com writes: > >=20 > > > In any case, I think I would try to change DO_MARKERS to start at the > > > end of the marker vector. If fix_marker_vector runs often enough one > > > could also "straighten" the free-list there, maybe. > >=20 > > Or one could build a doubly-linked list of markers in most-recently > > created order. But that would mean 3 array slots per marker in the > > marker vector. Don't know. >=20 > How about not relying on buffer markers too much for this job? And in > particular, not adding any ephemeral markers when we don't find a > close-enough existing marker? We could instead build our own data > structure, and make it so we could use efficient search methods. I can't really contribute much to the general discussion, but, if I underst= and correctly, in this specific case the problem is that magit causes redis= play to skip over a large invisible region, finding each newline in it, cal= culating its charpos, then advancing to the next one because the newline is= invisible. So I've tried applying the attached patch, and that seems to avoid the spec= ific problem here: we simply skip to the beginning of the invisible region,= which means only one charpos<->bytepos lookup for the entire region, and i= t doesn't matter too much that it's a slow one. Of course there are still problems caused by the heuristic nature of the ch= arpos<->bytepos caching mechanism, which simply doesn't have very good wors= t-time complexity, but I think the right solution there is to continue work= ing on storing buffer text in a number of chunks (and saving the correct by= tepos/charpos change for each chunk). I have some code for that and I'd ra= ther continue working on it for a while before giving up and spending time = on different implementations of the marker array. That would give us predi= ctable and acceptable worst-case performance, I think, and we wouldn't need= to go out hunting for use cases that come close to the worst case. Pip --b1=_4dFCXY2A6hBwtZkwP6YqezanG0tO6oub9xPoyMxA Content-Type: text/x-patch; name=invisible.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=invisible.patch ZGlmZiAtLWdpdCBhL3NyYy94ZGlzcC5jIGIvc3JjL3hkaXNwLmMKaW5kZXggMTdlMzIwMDc5ZDQu LmM2Y2E1NmY2NTI3IDEwMDY0NAotLS0gYS9zcmMveGRpc3AuYworKysgYi9zcmMveGRpc3AuYwpA QCAtNzY5Myw3ICs3NjkzLDE5IEBAIGJhY2tfdG9fcHJldmlvdXNfdmlzaWJsZV9saW5lX3N0YXJ0 IChzdHJ1Y3QgaXQgKml0KQogCXByb3AgPSBGZ2V0X2NoYXJfcHJvcGVydHkgKG1ha2VfZml4bnVt IChJVF9DSEFSUE9TICgqaXQpIC0gMSksCiAJCQkJICAgUWludmlzaWJsZSwgaXQtPndpbmRvdyk7 CiAJaWYgKFRFWFRfUFJPUF9NRUFOU19JTlZJU0lCTEUgKHByb3ApICE9IDApCi0JICBjb250aW51 ZTsKKwkgIHsKKwkgICAgTGlzcF9PYmplY3QgY2hhcnBvcyA9CisJICAgICAgRnByZXZpb3VzX3Np bmdsZV9jaGFyX3Byb3BlcnR5X2NoYW5nZSAobWFrZV9maXhudW0gKElUX0NIQVJQT1MgKCppdCkg LSAxKSwKKwkJCQkJCSAgICAgUWludmlzaWJsZSwKKwkJCQkJCSAgICAgUW5pbCwKKwkJCQkJCSAg ICAgUW5pbCk7CisJICAgIGlmIChGSVhOVU1QIChjaGFycG9zKSAmJiBYRklYTlVNIChjaGFycG9z KSA8IElUX0NIQVJQT1MgKCppdCkpCisJICAgICAgeworCQlJVF9DSEFSUE9TICgqaXQpID0gWEZJ WE5VTSAoY2hhcnBvcyk7CisJCUlUX0JZVEVQT1MgKCppdCkgPSBidWZfY2hhcnBvc190b19ieXRl cG9zIChjdXJyZW50X2J1ZmZlciwgWEZJWE5VTSAoY2hhcnBvcykpOworCSAgICAgIH0KKwkgICAg Y29udGludWU7CisJICB9CiAgICAgICB9CiAKICAgICAgIGlmIChJVF9DSEFSUE9TICgqaXQpIDw9 IEJFR1YpCg== --b1=_4dFCXY2A6hBwtZkwP6YqezanG0tO6oub9xPoyMxA-- From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 01 02:17:59 2025 Received: (at 76538) by debbugs.gnu.org; 1 Mar 2025 07:17:59 +0000 Received: from localhost ([127.0.0.1]:59701 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1toH6k-0006Bx-6L for submit@debbugs.gnu.org; Sat, 01 Mar 2025 02:17:59 -0500 Received: from mail-ed1-x529.google.com ([2a00:1450:4864:20::529]:58470) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1toH6h-0006Av-3i for 76538@debbugs.gnu.org; Sat, 01 Mar 2025 02:17:55 -0500 Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-5e4f5cc3172so2024289a12.0 for <76538@debbugs.gnu.org>; Fri, 28 Feb 2025 23:17:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740813469; x=1741418269; 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=4WJAwRi31QNcIRzBiWwMRb8evJq+nMQMmoe1fzibPck=; b=c3NvA1fZSLE+iHeOvozB3oo1pc7QT7sSA+SNzZOr6ShSOvirka3DTey2Te5k/wOygR gx7gVMpqW1dYPRnSR+FM+3sq5sFT8avsOXkgGHX0+2aMcRSIkQ+O1oY0OoIpKWLj8Ytn W/PsXTOb0J0YCLrYuc7FkpE9tSmwdHcsG0VvzUVxTi6wayUXhf50FWQWDbFtk11e9+rt rVoNrpWRQYE72D3buoxoy56vbTFgeRZ5ojpBTjSBXVktu1dx8+kGHEQfX34CJsKFzzyq MiTUx8GEWtrnuNVkorG3QZ9sLIrPueboeIlSYJMa0VPzsUQ1h8ji54HSOKNDvIwPnGIA GyDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740813469; x=1741418269; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=4WJAwRi31QNcIRzBiWwMRb8evJq+nMQMmoe1fzibPck=; b=l4T1CWWke9Jl4Mt5A2/w13U/xN5wl70cGnmgBpQTnNSebYdYyWaR3QHJFfYXVOk4+7 TxxI6MbdoxFcKRiFoP2Rz9enPmwL+I5n4QvosFzzwnVlNnqYgkdhSe5wcsTSR3cO2Zni ItegAyMySj0Q9eKp/z+DjRgZZdkhaQ4d0iFqi+NcLM0TpCrujoF1CmPGKI7adEGcTJZh NQFJ/M4qN+Y23fCIn2JJRFXbOrMe7jbrvcHqe3wrOIBbcOmhEYAp08on7/aPUy5AP+Hu pjr6b5TTayWRhzhiFA/stnzYy488LTAryxjHQXi0H416pm16Jne05bNJA1CzSSdkwo29 pQLQ== X-Forwarded-Encrypted: i=1; AJvYcCUiEhsE5tIdjJDppvf+VDOYYfKeKqQRALqsFEOwG4chggF4jpRHa1fp/4xeHGhkSJxC5eaAng==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyeWOc035vbOadu/H+XDB/dzQ6Hjk1mmow5Rb3m5WXpsBV5QfQG /raHpKAE0mCbGTBuuuUPfccQbQAqoGwRaCtDKDHP4owHdda4dA8Jy8HedA== X-Gm-Gg: ASbGnctbU5ov8DUC95ChBU8jeIAztZUrEjSax1EZ29KJwdRlDRbofDeHjQDdxgm+e0I dxFn8bgfSNXo7UgIUbjDKx/mYTOS5tkTjmjswwi1Bja16wCd8N1wkUQrfh24lUbYMlGxoPXKqQ5 QG8a2ZCBxfW7FzaZWFAXdhTbgOVkDn6Gdw5VEf4t0bKqt8wJ25U2YzXHaQo/FIWxIBDnJz3w6nU 6EUjs8BW+/jUNGQicgoz5VlSIm3nisQx7+He283RxxFn/bfAVnEYrxZdv7VBtS9i8rYYlCOykLI E7yNP1QPQecPkDfBreiRw+/Z7w4BlIDnfV7YpUvaV7zmLJDOQG0I5JbENVAyQ7XkzrxVL3gThlQ 4l8Adg9guaTtKnn4X02n2g6b4nE8v6MAzNm3igIVhKQD/sCluzvLTHg== X-Google-Smtp-Source: AGHT+IFspt/r4H34254fVSIl+EJSM8kro4rOW8VcqXH3entnbWl/q7lAWoyPp1V/Db1dlwkN/PPwEQ== X-Received: by 2002:a05:6402:2106:b0:5e0:69df:ccbb with SMTP id 4fb4d7f45d1cf-5e4d6b62349mr6212967a12.28.1740813468447; Fri, 28 Feb 2025 23:17:48 -0800 (PST) Received: from pro2 (p200300e0b7012200492911ca73cb19c8.dip0.t-ipconnect.de. [2003:e0:b701:2200:4929:11ca:73cb:19c8]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5e4c3b6cfc4sm3639055a12.18.2025.02.28.23.17.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Feb 2025 23:17:47 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Stefan Monnier Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> <87ldtteqca.fsf@localhost> <864j0gx2ig.fsf@gnu.org> <87tt8gobac.fsf@localhost> <87r03ko4c6.fsf@localhost> <87r03jgshf.fsf@localhost> Date: Sat, 01 Mar 2025 08:17:45 +0100 Message-ID: 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: 76538 Cc: pipcet@protonmail.com, eller.helmut@gmail.com, Ihor Radchenko , joaomoreira@gmx.se, 76538@debbugs.gnu.org, Eli Zaretskii 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 (-) Gerd M=C3=B6llmann writes: > Gerd M=C3=B6llmann writes: > >> Gerd M=C3=B6llmann writes: >> >>> In any case, I think I would try to change DO_MARKERS to start at the >>> end of the marker vector. If fix_marker_vector runs often enough one >>> could also "straighten" the free-list there, maybe. >> >> Or one could build a doubly-linked list of markers in most-recently >> created order. But that would mean 3 array slots per marker in the >> marker vector. Don't know. > > Which would be something like the attached. Can someone try this with > the original recipe? (It's a quick sketch, and blah blah.) And I think I'll keep that. It makes an overall nicer implementation of DO_MARKERS, keeps add and remove O(1), and provides iteration in most-recently added order, which should be the same as without igc. I like it :-). Until something better comes along, of course. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 01 08:34:10 2025 Received: (at 76538) by debbugs.gnu.org; 1 Mar 2025 13:34:10 +0000 Received: from localhost ([127.0.0.1]:35584 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1toMym-0000Cc-QK for submit@debbugs.gnu.org; Sat, 01 Mar 2025 08:34:09 -0500 Received: from mail-10629.protonmail.ch ([79.135.106.29]:14877) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1toMyj-0000BB-8a for 76538@debbugs.gnu.org; Sat, 01 Mar 2025 08:34:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1740836038; x=1741095238; bh=KIvL/yNGpjEbkYL5uBe176NJQMDu36RLXx9pEirqvYY=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=RpfuHTCtIn5rZ6VY8FiEBrGAUhNHF8tzdJTwjtLBTxUecz9OUij0WYHDhJeQZgLSe 17HIcvr0XFseMFFL4n6AhVUTYQnCVUuqVYfKzi9DjKFnH7z4LcTCDw/K30qpQHKo4N AaZyCP0gJO4nMFId58Lt9oI/EyWnpcCbQ1vkziUCvWjbrQhXsaMD2hYF/DORCjbqxJ beC/4R7OA2PJGSAdRitEY5AaM07gIThnyeJBHRdkoYDq/fJGISVN7ThjIryhww4FQm MELmzGH2r2Jy4Rd8u9BorjAZJMgnlnFQOjIb+n5qE/8JN3kf3H1PzuPWzzkV+tizPf cDatdvfPfN3Ug== Date: Sat, 01 Mar 2025 13:33:54 +0000 To: =?utf-8?Q?Gerd_M=C3=B6llmann?= From: Pip Cet Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. Message-ID: <87jz986fkr.fsf@protonmail.com> In-Reply-To: References: <87ikoyetgi.fsf@gmx.se> <87r03jgshf.fsf@localhost> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: f2853a500909e4d1afa1f216c88a84d6e8ffa0c7 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: 76538 Cc: Ihor Radchenko , eller.helmut@gmail.com, Stefan Monnier , joaomoreira@gmx.se, 76538@debbugs.gnu.org, Eli Zaretskii 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 (-) Gerd M=C3=B6llmann writes: > Gerd M=C3=B6llmann writes: > >> Gerd M=C3=B6llmann writes: >> >>> Gerd M=C3=B6llmann writes: >>> >>>> In any case, I think I would try to change DO_MARKERS to start at the >>>> end of the marker vector. If fix_marker_vector runs often enough one >>>> could also "straighten" the free-list there, maybe. >>> >>> Or one could build a doubly-linked list of markers in most-recently >>> created order. But that would mean 3 array slots per marker in the >>> marker vector. Don't know. >> >> Which would be something like the attached. Can someone try this with >> the original recipe? (It's a quick sketch, and blah blah.) Performance seems slightly better, but not as good as disabling the bytepos<->charpos cache entirely and skipping the DO_MARKERS loop. OTOH, it's not worse! And keeping the markers in an effectively doubly-linked list allows us to sort them whatever way we want. > And I think I'll keep that. It makes an overall nicer implementation of > DO_MARKERS, keeps add and remove O(1), and provides iteration in > most-recently added order, which should be the same as without igc. I think we might want to sort markers at some point: if we start out with the median marker, then the 25-percentile one, then the 75-percentile one, etc., we should arrive at an acceptable one fairly early without changing the scanning code at all! (In more detail, I think we should start with any marker, then choose the one with the greatest distance to all previously-chosen ones next, recursively. I don't remember whether there's a particularly efficient algorithm to do that in the general case, but in the linear case, it's pretty simple, just build a btree and emit it in depth-first order. Fun fact: do the same with a visual color metric and you get a usable color scheme!). > I like it :-). Until something better comes along, of course. I still think I have "something better" in my head, but it's not so much in code form yet, and work on that is quite slow right now, for various reasons, so having a no-worse-than-master solution is important! So I'd be happy to see this merged! If it improves performance to be acceptable, that's most likely sufficient, as far as this problem goes, for merging feature/igc (which I still believe in), even though the xdisp.c change (invisible.patch) I proposed (and analogous ones) should improve things a lot for magit even on master. Pip From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 01 09:12:54 2025 Received: (at 76538) by debbugs.gnu.org; 1 Mar 2025 14:12:54 +0000 Received: from localhost ([127.0.0.1]:36072 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1toNaH-0003qh-Ad for submit@debbugs.gnu.org; Sat, 01 Mar 2025 09:12:53 -0500 Received: from mail-wm1-x32b.google.com ([2a00:1450:4864:20::32b]:46456) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1toNaE-0003q1-Ev for 76538@debbugs.gnu.org; Sat, 01 Mar 2025 09:12:52 -0500 Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-43bb25a8666so2702835e9.1 for <76538@debbugs.gnu.org>; Sat, 01 Mar 2025 06:12:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740838364; x=1741443164; 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=szu/rYLbie7pGEog5aIkolFqKew44eog6Y0IimTXNZs=; b=P3fg8usHErhvMXR05Oa9+8O55+W0dlr3EdT/nT9QYFL6StTAi6kVry3QqwAFIB4RJd cKkNvoD/Xej/PI057GAwqcLMAYkM5gVfMg6L5RU7faVsCJARxu096ugMRoKiXus8lvLz iyM8mkr+CSeScq96mKyjM2hhe1Qco1fmMfF1D5xwY46dQaSJTs3S/0h0ZFVY/moJzuFy R831y1496WyOggWwRa/kZPkkfR2i5IdQR4Y9UPc/xVGKJLqH2AQh3wXSjgfYRj8ZTd32 JH5Zi3ZkHkvOLStBR5IJv8vXH9XpmfOgtkjHIbUZr8cZ3Mq+P7R07P2abukVzJEGFhHa G8hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740838364; x=1741443164; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=szu/rYLbie7pGEog5aIkolFqKew44eog6Y0IimTXNZs=; b=cS8PUVkyM2qrBiQAnhys18JWyYE2bKq6hjPEPtVyMwssBWNJsFM+WxdzuE1Wp4DpaD tUaaSC2Zsxy4D6BwJ7Zaz7EJq5mFj8vbOzgO7t1+xzPZcF/+VNY0AqfjEuRzSyY/JQik PKuCPT1pTX2T2mi+bwfsVKhZv3Ks8cbOKvDpfFrXbDOrp3IKjIYfBwbj6K52zNneV3NJ eGi0sCBoLa96yqN6SecCh/u2Hx6WtwM2SH3K0RQ3inF9RCGSuzxSeyTj1FxU3LCspQ05 /P3gch+BgvITN4Efdm+t8E7CZANh1XObx/Bv83WykG5nyAbbmPeR52AfTqkKJJWo0Scx N6iQ== X-Forwarded-Encrypted: i=1; AJvYcCWbUscRCcPCaSAmyJrl1xKG1HXZNXpB8nGlNgEdVdKthcvjFqfBr5XPWcAgCpIoIXunLFmuNA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyIq412p9hKg37lTAHpIiANFeqENIrdou99oBNzoDIs/uPxQTsT HFVb2qVa3G/dkA9ZHL/Le6NZuGF5Vw0HJmZjAh+MhCg///QG5mCRmQz2Lw== X-Gm-Gg: ASbGncvMjxRxnbSbov7/tDsoc47COBcVMiP0tBqgnoY4AJuiOruCw5gPOmUGG5A5nU1 VuOyYmrSexpTEo7WAxa5AmR7Ie8R0V55U/mU/oxp2a9hHS0yXbR9MxTYDkMVYqc0XktS1eWvNOp b6mr2DKWQsENlSuBkptMF4Wlu6n/hmr+vaSPIhxnJB0a4o9+1fqye2aptgyhbyyRN889Qx1PwQx DrmuC1OM3gKvQWCO27Cnep5D2+Z0dJI+ppzsh3ah+7ZEYOZ6IBb8CAs+qPRpPokrCVWv7SxF5pm 2P6V6IsYusTHqO/iqhYaG6WsOmR6ncHZtgZ7VSFwZaLTcYBURe839NmVzBpLjOunq4xGeXXdXzj gGmM7FNMINxH+YGBhIZzSZ8pmO0aZc/yTUjII4GiQUn+HO4xiR/Te0Q== X-Google-Smtp-Source: AGHT+IF4W7I5yGvbe8KsQqYt39rXgOfsJIUSxnlV1cF36lGpAQGQ+nlR2xGL7qrp6tecllKOHNzBqw== X-Received: by 2002:a05:6000:4027:b0:38f:28dc:ec23 with SMTP id ffacd0b85a97d-390ec7cc23cmr5094902f8f.19.1740838363592; Sat, 01 Mar 2025 06:12:43 -0800 (PST) Received: from pro2 (p200300e0b7012200492911ca73cb19c8.dip0.t-ipconnect.de. [2003:e0:b701:2200:4929:11ca:73cb:19c8]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-390e47b7a73sm8661380f8f.50.2025.03.01.06.12.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 01 Mar 2025 06:12:43 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Pip Cet Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: <87jz986fkr.fsf@protonmail.com> References: <87ikoyetgi.fsf@gmx.se> <87r03jgshf.fsf@localhost> <87jz986fkr.fsf@protonmail.com> Date: Sat, 01 Mar 2025 15:12:41 +0100 Message-ID: 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: 76538 Cc: Ihor Radchenko , eller.helmut@gmail.com, Stefan Monnier , joaomoreira@gmx.se, 76538@debbugs.gnu.org, Eli Zaretskii 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 (-) Pip Cet writes: >>> Which would be something like the attached. Can someone try this with >>> the original recipe? (It's a quick sketch, and blah blah.) > > Performance seems slightly better, but not as good as disabling the > bytepos<->charpos cache entirely and skipping the DO_MARKERS loop. > > OTOH, it's not worse! And keeping the markers in an effectively > doubly-linked list allows us to sort them whatever way we want. That's good to hear, thanks for checking! >> And I think I'll keep that. It makes an overall nicer implementation of >> DO_MARKERS, keeps add and remove O(1), and provides iteration in >> most-recently added order, which should be the same as without igc. > > I think we might want to sort markers at some point: if we start out > with the median marker, then the 25-percentile one, then the > 75-percentile one, etc., we should arrive at an acceptable one fairly > early without changing the scanning code at all! > > (In more detail, I think we should start with any marker, then choose > the one with the greatest distance to all previously-chosen ones next, > recursively. I don't remember whether there's a particularly efficient > algorithm to do that in the general case, but in the linear case, it's > pretty simple, just build a btree and emit it in depth-first order. Fun > fact: do the same with a visual color metric and you get a usable color > scheme!). Or what Stefan or Eli said, I think, something independent of the buffer markers. I'd like to see something like that. >> I like it :-). Until something better comes along, of course. > > I still think I have "something better" in my head, but it's not so much > in code form yet, and work on that is quite slow right now, for various > reasons, so having a no-worse-than-master solution is important! > > So I'd be happy to see this merged! If it improves performance to be > acceptable, that's most likely sufficient, as far as this problem goes, > for merging feature/igc (which I still believe in), even though the > xdisp.c change (invisible.patch) I proposed (and analogous ones) should > improve things a lot for magit even on master. Ok, I'll add it then. (And I'd like to have the other stuff for Magit :-)!) From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 01 09:33:57 2025 Received: (at 76538) by debbugs.gnu.org; 1 Mar 2025 14:33:57 +0000 Received: from localhost ([127.0.0.1]:36306 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1toNue-000604-8u for submit@debbugs.gnu.org; Sat, 01 Mar 2025 09:33:57 -0500 Received: from mail-ed1-x536.google.com ([2a00:1450:4864:20::536]:42470) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1toNub-0005zP-6B for 76538@debbugs.gnu.org; Sat, 01 Mar 2025 09:33:53 -0500 Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-5e4ce6e3b8cso4021893a12.1 for <76538@debbugs.gnu.org>; Sat, 01 Mar 2025 06:33:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740839627; x=1741444427; 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=ajlMO65wdVG8SmaEagh8GWFBw4UVjvuetrr0EUFSjVA=; b=A/dnM616sfveR7TGQgRF+tGlcO+6B7lvVXhv7Wt6IbDpRt9hns8OtqssST7EZN3d5r Ptl16fSABrY/98+9yAcS+CysAYkT9dSJaiWVaHvVmtie7HkWBR0Jtu7zafFj9Dt7UD/h 6m0Tmd9B7S6krHhpWbUp8FX+Q/loOJ8iAR29o/+2ASu0cBuGE7fjwgGEIJh8TuSI/API g4IaKO2GM+yv8b7eH23sGET0fNAzLRr2iIZILNWm3AQimf6XXO0esLPsuY82IjWVygqO TmN1a/RV6fak8rYeYruvWsMvJot7ARBcykvWkgfKYihYuGw9hoggfqO9NKH4z4vqIxnb I1iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740839627; x=1741444427; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=ajlMO65wdVG8SmaEagh8GWFBw4UVjvuetrr0EUFSjVA=; b=qEkKd7Qfydz9uLRzlEkUr10/V6KtAzhExlc6u3UmA79FFJChITLtjoY8DpgLodVh+l 1MT+fsngVYTtrDfiS5yNsILKCsBCbMjuR2DP6tfTpFrYoTz2fQTvbJwMw6YexKR9p7DN CKFuV2jAG2BKZg7Rd1g9ZlH+ggAzqSEfoNoPooK87BLskpPFZsiS9o2xQ2EV0NNRDJfF 39B4SuHadwIDiu+S4xBAsEPjn7yluq04vk8+pkAv534y7h12r2v3XVb/EZ45cUvGBuyn bgKwaRivbkRjwIiKWNjSZjIgXjsVWG3Z5fqsfH7Gj9VJ/XZkIySg1W/BT3bFMLoSA6Lw zcZw== X-Forwarded-Encrypted: i=1; AJvYcCWF18hJkNnAqQdmSAsbneTIO86l8I+suXoke6yCKWlreaDHjwI9D8HXxufRgtv6srj8Rcd/Wg==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yx/+n7E5tJf6MZWbnE0TnFSUuyp/Z3+ei30WE/fxwa4+wWSah7r wS3TcUVhXGBJg1wqjwakUPF/JtSZ+hk0z40eG4AfNc9CxWHDffVjhD8hRg== X-Gm-Gg: ASbGncsEyFhcXefsv5/1+kTAlJC5ohdp6MEsKwJcVunH1pX5dlPT8ApoE2xQ2TFsEcN wdCYwqsqSvxFSMMtTi9wSTK8FrPjGY75IV1QWH8kG3rxwf/5hW2Xt+cxnqd9I+CuR8EgJ1urzI3 7diysT1OQbAERhgYhuHKyAE/YhtDNEUCMyQpVhvF+0v0KNmfytesut7d9not4AD9m76ce5AfTyd mW8rpKvvEkK8/Xw+IABjMnwugoYHo9H6uvJox3uipMHcJYeWO0ahJvPtT9sn0mAUtoQrhu2ShPP MQ08pYlc6IjHlaXlMdu2II3DoszSgZxjlHMYarfMsjWFW2hiZcch/nn1/nzG2d9ZZSIenlW3t3y dSoxkNdiGg5kqNfAXdp13zyZ+TNeZYETCb7pPYkapYSs7HkhRVIYzKA== X-Google-Smtp-Source: AGHT+IEkvuvbWLKypO/p+sBSSFOrJFUDkEnjY+ujwA5v2MYZZ6RMZL5IQUUWa7gLvIs/+otRzPOn8g== X-Received: by 2002:a05:6402:13d4:b0:5e0:8a27:cd36 with SMTP id 4fb4d7f45d1cf-5e4bfacb0a8mr13922015a12.8.1740839626574; Sat, 01 Mar 2025 06:33:46 -0800 (PST) Received: from pro2 (p200300e0b7012200492911ca73cb19c8.dip0.t-ipconnect.de. [2003:e0:b701:2200:4929:11ca:73cb:19c8]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5e4c3bb4bd9sm4157898a12.33.2025.03.01.06.33.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 01 Mar 2025 06:33:45 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Pip Cet Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: References: <87ikoyetgi.fsf@gmx.se> <87r03jgshf.fsf@localhost> <87jz986fkr.fsf@protonmail.com> Date: Sat, 01 Mar 2025 15:33:43 +0100 Message-ID: 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: 76538 Cc: Ihor Radchenko , eller.helmut@gmail.com, Stefan Monnier , joaomoreira@gmx.se, 76538@debbugs.gnu.org, Eli Zaretskii 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 (-) Gerd M=C3=B6llmann writes: > Ok, I'll add it then. Pushed. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 01 11:59:49 2025 Received: (at 76538) by debbugs.gnu.org; 1 Mar 2025 16:59:49 +0000 Received: from localhost ([127.0.0.1]:42408 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1toQBp-000458-IQ for submit@debbugs.gnu.org; Sat, 01 Mar 2025 11:59:49 -0500 Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]:57801) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1toQBl-00044G-Rp for 76538@debbugs.gnu.org; Sat, 01 Mar 2025 11:59:47 -0500 Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-439a331d981so28614935e9.3 for <76538@debbugs.gnu.org>; Sat, 01 Mar 2025 08:59:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740848379; x=1741453179; 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=uHO68Mbbr2COMFrqe+mYgFC1v0brdo8H21Q9Ub9cngo=; b=PkLaKrkGJ9rR7m3jOi7Z1/tLeC6UOJDlWXTYqrIr6jF6eNG+nvm8SEV+y+MvNeiBDo WgLfg1Da4fZHLRaDyZC+rWch5fBf7u8ucd56Zo1BFp8NfeUjqyi5ZbNKAbVian5hKawA E5nkS45uCfyL/kOThrd1VAyBO3QAKUEjJohiFlmNL0ehj7eVlXkCzqD33xD+ZJ+1winz h7ewO2Cge/q7Y04/j3fCObOGGwiS4wUSudZ5bVUhgcKgFBR0Z91hBRCDX7T6kQinMDnD 27FhnlOsrHJeaikDpsacLmYpkb0jg19CFDgr2XxcDwpDYUpu+yITsyEm03/G9aYFRzc6 fhRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740848379; x=1741453179; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=uHO68Mbbr2COMFrqe+mYgFC1v0brdo8H21Q9Ub9cngo=; b=emb3h0t4Qrd1g/9Ca5EH+s/XmspRU70ojGPEApUwm/+fGgJdCXmtBy20U+OGhX7vxM FR0DbR2kqQ3oMepjLKVB0NOQLZPL/+cfAD4XIZaH6fUr8ISSp0BKZxBqg8ZqbOp3Iwx/ LxiUnzTTGAMJ2fptDGC55r4YJOgw5DQarqVEzKmS+9TS+YwkeU9vGNeQdlrImjtYDmDF orDVejagidUN0EqI7TRieIAoUHYpS4KPtfMRKQJkDTN1aCq+0H/yqa3PDIGnF8e+kWh9 VVAP0wP4yHukKJpTpsVlIclyuZHkNGVYFegmJVpVyLjS1plWJ3/olE7mPwL1E+Q9qxww gQgQ== X-Forwarded-Encrypted: i=1; AJvYcCWYVqMMCKqVYAWjblfdWxMthuSaxGRlWTMHh1Htq1dGF0Z9j8UHISYcxpafoC4N+RKvpe092w==@debbugs.gnu.org X-Gm-Message-State: AOJu0YypuCPSKBETaA5wxb/0EczF/wwTlvy963E/awpvHP8iNdAzYByq XkqPjJrJjIwm616yPuL1RBsEQdGXarRHlExjULaAcnniQhAf0mk/ZYERiQ== X-Gm-Gg: ASbGncvfYnQo8NwJZvg0hQtVVPj0lNOFkSfDBFmb0OHQcpCHtsOTuo1cSe2MuKGJnoz gkG9cnt8oCER+T/kZe7DclN1MCQuEljljS+3i+wvR86EKuteS1khKDmj3jnOYTyqZyN55MKjp0M FBRhU1Zb2t643jMBkmJ+rVd006IeHlEf2IsxwW/pJdEwz7bxqcrzZIF4Iz1YP7KqmNN7varhhi6 LZwzYvT5xYLuhCbLSPo4vkxnGLh20wuACxzL8zUctCzTR9XBhDHnC2p4Ok/VlxGVirabgAOf+lV /vMFjOji4x83I/eBxM6x/Kg1VJprEkUNeb2KacnSnEIeZtu4AlIaWqyQLpxPsK69KQc9cecp5fB Ljw== X-Google-Smtp-Source: AGHT+IEXg1SDHYXcIAzRZddNgdVG1hdHkjAp/huva3kIsrs6lPA2o2YvpMWQcqwA94Xo7CGPGsDzGA== X-Received: by 2002:a05:600c:1906:b0:439:8a44:1e68 with SMTP id 5b1f17b1804b1-43ba6a842e4mr52640845e9.28.1740848379417; Sat, 01 Mar 2025 08:59:39 -0800 (PST) Received: from caladan (dialin-233080.rol.raiffeisen.net. [195.254.233.80]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43bab4549ddsm50613285e9.25.2025.03.01.08.59.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 01 Mar 2025 08:59:38 -0800 (PST) From: Helmut Eller To: Gerd =?utf-8?Q?M=C3=B6llmann?= Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llmann=22'?= =?utf-8?Q?s?= message of "Fri, 28 Feb 2025 16:01:04 +0100") References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> <87ldtteqca.fsf@localhost> <864j0gx2ig.fsf@gnu.org> <87tt8gobac.fsf@localhost> <87r03ko4c6.fsf@localhost> <87r03jgshf.fsf@localhost> Date: Sat, 01 Mar 2025 17:59:37 +0100 Message-ID: <87eczgznye.fsf@gmail.com> 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: 76538 Cc: pipcet@protonmail.com, Ihor Radchenko , Stefan Monnier , joaomoreira@gmx.se, 76538@debbugs.gnu.org, Eli Zaretskii 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 (-) On Fri, Feb 28 2025, Gerd M=C3=B6llmann wrote: > +static void > +unchain (struct Lisp_Vector *v, int slot) > +{ > + IGC_MA_MARKER (v, slot) =3D IGC_MA_FREE_LIST (v); > + IGC_MA_FREE_LIST (v) =3D make_fixnum (slot); > + > + int prev =3D XFIXNUM (IGC_MA_PREV (v, slot)); > + if (prev >=3D 0) > + IGC_MA_NEXT (v, prev) =3D IGC_MA_NEXT (v, slot); > + else > + IGC_MA_HEAD (v) =3D IGC_MA_NEXT (v, slot); > + > + int next =3D XFIXNUM (IGC_MA_NEXT (v, slot)); > + if (next >=3D 0) > + IGC_MA_PREV (v, next) =3D IGC_MA_PREV (v, slot); > +} Doing this in the collector looks quite risky. It seems to assume that the mutator is not in the middle of reading from or writing to any of the involved slots. Helmut From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 03 00:58:23 2025 Received: (at 76538) by debbugs.gnu.org; 3 Mar 2025 05:58:23 +0000 Received: from localhost ([127.0.0.1]:43226 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1toyoo-0007KO-My for submit@debbugs.gnu.org; Mon, 03 Mar 2025 00:58:23 -0500 Received: from mail-ej1-x635.google.com ([2a00:1450:4864:20::635]:50428) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1toyom-0007Jy-DW for 76538@debbugs.gnu.org; Mon, 03 Mar 2025 00:58:21 -0500 Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-abf628d653eso187941366b.0 for <76538@debbugs.gnu.org>; Sun, 02 Mar 2025 21:58:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740981494; x=1741586294; 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=xmAbATSJ2zHzhe/hlaLX2ARjOHQjVfGXGYruiCVsjyI=; b=Z7PCel1jkFBSiFj8zoHUOLRWn0W/RWb079voUTu3SYRZ+a50Ln/ycJeAvG8vSrJ4P7 kl3DvdmDxrkWC/6Nk3uw4Zyc5EbZq2Ty3kjndynTSwXbUcbO1sy0eQHLVrjleINGa8Me mjYNPPzQl56V3wUYRdL2uQgBS+1s+KP12Ncgt6okeo8CzNF9QY0H3fDo8NlL179F7hw7 fP2v6HAK7Wus7hHj8FRbLPzOI3SMYtvqYg3j7e2kk/iWeE0NK7knV3HKl+CAP08HtGCz mP3bLiALGS8d5CPQfitPnoOVrwQmFZt8IAd0KYKdD+Kh3CpzrXRLdSKsTMM8Ar6bJcAF /rYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740981494; x=1741586294; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=xmAbATSJ2zHzhe/hlaLX2ARjOHQjVfGXGYruiCVsjyI=; b=rvR4eCWUgvUFpuMMsSby721iYt3NwxUJ9VrrxQHtgNqFuxHAAwMaHPAAkl0pLEDXt6 qcYqomrv1ZbAE5qmv/C5VKqflo/7Oysb12nl2540K0KWYA/0eNdW5g3dxobiUfoGOE6v ljbzLMSznZro/Ef07lO8kJ7eII7efu+4wavHEl9F7j0voTzJPvex9opjH9mo142R7OfH /oQYzY1vR/u/TtY353NAsARsYTl9TcSqkP3H4jQ6l4NXC6DpN6Yc8rihCACPs9/SVDBF 8fKkYvIpEa9fjEdvB9xDuKjDFkIAQLhdt1iRNpY94w0V3faaZILbgsLPWZ5cVe7c/in7 Zo9A== X-Forwarded-Encrypted: i=1; AJvYcCWhf93jTppzFHfDVRuvYGdmz4ye67PuaXikaz01rg6hA52ggT82Kusn1V+kcIrCWGCmml4ffA==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yz5UaEqYH6AElI70wWB2AgvYkew04zx6mJdcGFnZ8NxwAeKd4Ya LHBPtmsdvVWTdTpib/XTlJwFWLK3IwsG5YxnCMOja/nzN+UeWveT6p0B3g== X-Gm-Gg: ASbGncvztRogjdoaHJes1GOrodkIeouuI8XD364xphr0TlgorKUpudaSUMMo/pOuWOB zoHX1ZQn7Od0I5jN1b/42vcl3AD/c4OxS8sfuKFZlhg93TmXS06YwDaX9HU3kusSG/aUgk3QEcu Z+2/MtLyO1xmiJfEFu7ia9Mu0LWvUaz19Ib6i6dXAw3nU114rug8Y6hQoJHJbd8lffbKUpsykNy EIa0niNt1Ymeu31ekzJf1sQRl0Ws90a5/hGzoshbBgTpjc59tBa6KSBgn52mQeJd7SAgIO33ykn m8f7hrAnk4ARxv3/OZz2HA1kIebjFrVJX+iENxyiOKbiO9KdrtQuixtGEQ8h7RikSkhSW55jqGk LgMfg0hFCYL++FV2cSLv2AUwz4QEtgUUG+VYhIIWmYfNvNkddlODTsw== X-Google-Smtp-Source: AGHT+IEd3VeWXSq5WPyTlRV7RNCkB46VUeNWT3H+Ikcf33cXinC1nOLydt7LpkNHzI+evNYIrwgYdw== X-Received: by 2002:a17:906:1199:b0:abf:287d:ccdb with SMTP id a640c23a62f3a-abf287dce9emr1236180766b.27.1740981493461; Sun, 02 Mar 2025 21:58:13 -0800 (PST) Received: from pro2 (p200300e0b7148300591b4f9d8545dfd2.dip0.t-ipconnect.de. [2003:e0:b714:8300:591b:4f9d:8545:dfd2]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ac1db69942bsm55303566b.76.2025.03.02.21.58.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 Mar 2025 21:58:12 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Helmut Eller Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: <87eczgznye.fsf@gmail.com> References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> <87ldtteqca.fsf@localhost> <864j0gx2ig.fsf@gnu.org> <87tt8gobac.fsf@localhost> <87r03ko4c6.fsf@localhost> <87r03jgshf.fsf@localhost> <87eczgznye.fsf@gmail.com> Date: Mon, 03 Mar 2025 06:58:10 +0100 Message-ID: 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: 76538 Cc: pipcet@protonmail.com, Ihor Radchenko , Stefan Monnier , joaomoreira@gmx.se, 76538@debbugs.gnu.org, Eli Zaretskii 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 (-) Helmut Eller writes: > On Fri, Feb 28 2025, Gerd M=C3=B6llmann wrote: > >> +static void >> +unchain (struct Lisp_Vector *v, int slot) >> +{ >> + IGC_MA_MARKER (v, slot) =3D IGC_MA_FREE_LIST (v); >> + IGC_MA_FREE_LIST (v) =3D make_fixnum (slot); >> + >> + int prev =3D XFIXNUM (IGC_MA_PREV (v, slot)); >> + if (prev >=3D 0) >> + IGC_MA_NEXT (v, prev) =3D IGC_MA_NEXT (v, slot); >> + else >> + IGC_MA_HEAD (v) =3D IGC_MA_NEXT (v, slot); >> + >> + int next =3D XFIXNUM (IGC_MA_NEXT (v, slot)); >> + if (next >=3D 0) >> + IGC_MA_PREV (v, next) =3D IGC_MA_PREV (v, slot); >> +} > > Doing this in the collector looks quite risky. It seems to assume that > the mutator is not in the middle of reading from or writing to any of > the involved slots. > Do you have a concrete scenario in mind? From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 03 03:40:05 2025 Received: (at 76538) by debbugs.gnu.org; 3 Mar 2025 08:40:05 +0000 Received: from localhost ([127.0.0.1]:44366 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tp1LI-0003XS-51 for submit@debbugs.gnu.org; Mon, 03 Mar 2025 03:40:05 -0500 Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]:46131) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tp1LE-0003WS-VX for 76538@debbugs.gnu.org; Mon, 03 Mar 2025 03:40:01 -0500 Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-4394a823036so39414075e9.0 for <76538@debbugs.gnu.org>; Mon, 03 Mar 2025 00:40:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740991195; x=1741595995; 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=hecQwfXZHlSnLZSS4s8rPk/voWEsbBnBLQy4fxkwfNQ=; b=WVsRsvhSzGUPW9Bg/fG7dUzR40mERFnKXl1xWD89mfHSFjhjRWhUU9IZfusYs/pFfO e42Wf/H8Eb9IH9XOPJlu03F40ipmc7ONi487AxcPz+3o4j2o9qhMlI8DMjPqBPBptrYZ 7z+hJPjKlXqwl3jvbJvNweaBY2417CYKLDAXcDJKBITf9bIBPIiLStlLCFhn0qGsHkU4 8a6dhntcb3qDPF9KnI6/t4pdDHNqk+H30t+jHgALLKuqYcT9teEXHMilokF1budnj3qy 9MiZacU/oyq5e3bJe2GaP81EwZUGkW27wPDFSZ3l0WazF2QPpTI3SK6rlzvf/gKS1Nz/ gSQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740991195; x=1741595995; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hecQwfXZHlSnLZSS4s8rPk/voWEsbBnBLQy4fxkwfNQ=; b=PkpaE1MYDreL5oCEXbg9Jp7HtNd7Dbfm/RaSXjmJnqPbvFhPyG2bLqLm5gDtFLSiqL gTXU0AokVsk9B6SFwwtg6NpNJfGZL8Aoi5ZtxHestWnpWAiF0lXcf6brr6jlPqwgr+3U nc0iY+5m3yG3mO6cB9k4YDZgHdDch7CjszpKXOHhF3c1EuRqFiMiG3hizBEittTYTlRc qXsvzJwmy7gb6ZpgDhTmxGJmOZdnsK7UukmfGkLnLLBw/Us1jsI3WFPPVxbYlMKEHXB8 /6Ppte4/f3qdBSpIdfFOaTlEMq9Uuha75YQzV3nbk2JMMf9EB8hyDDi122aR4zDPBPGP 7AEQ== X-Forwarded-Encrypted: i=1; AJvYcCWcOxnHztSWs1745HDo4qACt9nNeCW7M1TwykT93/HawIGU463dRJZytKzXnqwr6F8eTsP49A==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yz6PfaZW6Sq4TBuBrO0DoszpR4TFxbdVdXVTrc/e7mHu4JnTWgS 1/tF2hb0XsgVdkk92llZywGnIyt4fmVu+l3rtsHPonJfIDqAcLanHxF/yg== X-Gm-Gg: ASbGncuy9HLWDI7ZGmEGrRFMg4dz1lFuajYNlXIeBcVr0a8kc8dRsBz58OhME32Wea6 spbMq6q2Q+7NQA1XoW5vBsuzVYcFrWLfeJXHHfXOCjtQiJD/J9HmJwmf3UhLXaHpztuDN9taA1Q lDBguhGjo68mWJl+BOIRl2ManrB/SQayuJ+NZZ8HI11sDl5WcGIyRzRC2Zs4gNWhDHR5v2Wm3kt sGOwPdA2lVfsfc8doCSeX8um9TCQ3BLZNpghSMJ5NUCUjKi0zlIP03XGKGiigrda5cGtGFJg5Do /V/yyQHKuo6fFIRc6WzwEItYu5zn5EjOrMCXf2Jxs3cXW8zQFhvXrb/82IPK4O8pl4dlQahygbd hmQ== X-Google-Smtp-Source: AGHT+IGIxgT1q65MffGQAUddmkjkQwSEiFRxn9v3MCfOtjsk1jV5lKjjjbzDtqKmI6b410AmEJI25w== X-Received: by 2002:a05:600c:3c86:b0:439:5a37:815c with SMTP id 5b1f17b1804b1-43ba675a7dbmr92795685e9.20.1740991194460; Mon, 03 Mar 2025 00:39:54 -0800 (PST) Received: from caladan (dialin-233080.rol.raiffeisen.net. [195.254.233.80]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43bc52369f2sm14892735e9.38.2025.03.03.00.39.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Mar 2025 00:39:53 -0800 (PST) From: Helmut Eller To: Gerd =?utf-8?Q?M=C3=B6llmann?= Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llmann=22'?= =?utf-8?Q?s?= message of "Mon, 03 Mar 2025 06:58:10 +0100") References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> <87ldtteqca.fsf@localhost> <864j0gx2ig.fsf@gnu.org> <87tt8gobac.fsf@localhost> <87r03ko4c6.fsf@localhost> <87r03jgshf.fsf@localhost> <87eczgznye.fsf@gmail.com> Date: Mon, 03 Mar 2025 09:39:52 +0100 Message-ID: <87zfi2y0br.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76538 Cc: pipcet@protonmail.com, Ihor Radchenko , Stefan Monnier , joaomoreira@gmx.se, 76538@debbugs.gnu.org, Eli Zaretskii 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 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 03 2025, Gerd M=C3=B6llmann wrote: > Do you have a concrete scenario in mind? To increase the probability of the problem, let's call igc_collect from igc_add_marker, like so: diff --git a/src/igc.c b/src/igc.c index ec714cad435..9bf0a0eca91 100644 --- a/src/igc.c +++ b/src/igc.c @@ -4595,7 +4595,9 @@ igc_add_marker (struct buffer *b, struct Lisp_Marker = *m) =20 IGC_MA_FREE_LIST (xv) =3D IGC_MA_MARKER (xv, slot); IGC_MA_MARKER (xv, slot) =3D make_lisp_ptr (m, Lisp_Vectorlike); - IGC_MA_NEXT (xv, slot) =3D IGC_MA_HEAD (xv); + Lisp_Object head =3D IGC_MA_HEAD (xv); + igc_collect (); + IGC_MA_NEXT (xv, slot) =3D head; IGC_MA_PREV (xv, slot) =3D make_fixnum (-1); IGC_MA_HEAD (xv) =3D make_fixnum (slot); ptrdiff_t next =3D XFIXNUM (IGC_MA_NEXT (xv, slot)); Then, run the code below with ./src/emacs -Q -batch -l /tmp/m.el -f test For me, Emacs seems to enter an endless loop after creating 36 markers. Helmut --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=m.el (defun test () (with-temp-buffer (let ((n 100) (line (make-string 75 ?a)) (markers '()) (debug-on-error t)) (dotimes (i (1+ (/ n 75))) (insert line "\n")) (dotimes (i n) (goto-char (1+ i)) (let ((m (point-marker))) (message "%s" m) (if (zerop (% m 2)) (push m markers)))) (dolist (m markers) (message "%s" m) (goto-char m))))) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 03 04:16:21 2025 Received: (at 76538) by debbugs.gnu.org; 3 Mar 2025 09:16:22 +0000 Received: from localhost ([127.0.0.1]:44582 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tp1uP-0006JL-CE for submit@debbugs.gnu.org; Mon, 03 Mar 2025 04:16:21 -0500 Received: from mail-ej1-x632.google.com ([2a00:1450:4864:20::632]:56697) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tp1uM-0006Is-V6 for 76538@debbugs.gnu.org; Mon, 03 Mar 2025 04:16:19 -0500 Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-abf4d756135so298406166b.1 for <76538@debbugs.gnu.org>; Mon, 03 Mar 2025 01:16:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740993372; x=1741598172; 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=cW0Jt8PQxY+7nQUi2NXsLnwNTvTQz9E6fj/j7gS0ApU=; b=UtpqoGjiGjhE0e08vi2jWp47/mufNbiJveoFHC7FH/t+KItyDQDqax7n+uAOt7hlq9 fzsj+88nyfD2a2IS1+7WXhDhxekctYg/1lhi9y+nhODa+kn/qnobtR0UE7gsDlfpDPFM Kp9PL1tRc3kBW7hoO5lTdMVzP29/bYx+GwLSKSv7Ios/Dsz8bs9MTavlyw9JO2yKFYoz ml2n0qmuMrcImMfaA2yQlgB1ZcztLCyarla6Sa2ZOGtsXchVfhdFgvtqSUrvMvvFgn64 z4kHeH7n+5NzKdA77ilbIGr2hllkOZQNmsCiBq7K4Vmm7xE/MW4WuhVItAgDoK9MyCXE GGTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740993372; x=1741598172; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=cW0Jt8PQxY+7nQUi2NXsLnwNTvTQz9E6fj/j7gS0ApU=; b=pQtbtn4y3ZWZBGNqaML6yBrBh94r6MZcUB2YfaflWMqAKXqyCFJ63X6BbPzaYv6Xah nmky4atY7jxQK5qqL+myAlG9Qf8bWULjyzGL/T9O9UtzmS7dicWzsy21bwpKGt9ujH6+ ieWB8iDVlk2X/FEzFY8z4/hEgfoZ2lmKdyCVvdYVfYmFHNaInq1If6RHcx9bwx3YuJd+ OZ6sxU5K64aejOlHT2oyPrfstxLXN1tNf/cMz0sfGrcPr1WbJAYlJcNNboU61GHYCYAK Ap6xBhtOyCePOfjhVMSvOhEF3tDsTP9HrzDuEtZ2ya00eDqvunSxf5Zt6LbyTsx95SEO PeIw== X-Forwarded-Encrypted: i=1; AJvYcCWHoW3Ysp14KJL7Gi5gF2/5obNmMO/oNMXm1kdScSfJm6AxKdHMqY2kHns3FxHf993rrnXjTQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwZESUHfAxTHKALmnpmIJA6JtbByk9dI18xe713dNP6QiKejBKO yYv8TnujYGMT9f61juyOcq0Av02PA4cSjfy2vIu+UV8xKHNUH2NxIp65cQ== X-Gm-Gg: ASbGnctV1CcQJPJaKwfsn+JzpMOsJ+FJMUqnlunO+FhrFeKgpOedl0hZ59qJuzD2gUU GPXL4r2yuyJfbb0V2jz/QpFwAOp1zJBV1H6SWvSDqyEgSSvYqksXEV/nVv9iSOv9Z7ijCmwTgw4 H4ALuzkysa4PIOrFkoEYngu2kWqBucBj68DgyOqe7FHj6NizMCMY9rMToZwR95M0KGPNYtVib94 xppxZ8YtR4xQqOcomayttyhHobG+L0TZ8i25/lTN0UN6nBgANoIJ1ZOInvF6e168p60OLI2oTw3 +xDAZHw19fqiyxjGOtN2Q/Orgt6la0bV9EgESPs3J3cUfoJ8RnzC6LVXrx+Ygb3VNBHFXonKtQy Vi9psW7sa3LFy54DTSaxv+ChRrnienkU1MWkPIln3G1ipeQepgMHPKg== X-Google-Smtp-Source: AGHT+IFpXzvc39WHtDXGLH4LNHfn8vWhab/lDEcYAu4x9QOsboBhRDXxMSPVPHS3icF8iVkcHGUbNA== X-Received: by 2002:a17:907:7faa:b0:abf:74d6:e2a5 with SMTP id a640c23a62f3a-abf74d6e404mr380663866b.6.1740993372021; Mon, 03 Mar 2025 01:16:12 -0800 (PST) Received: from pro2 (p200300e0b7148300591b4f9d8545dfd2.dip0.t-ipconnect.de. [2003:e0:b714:8300:591b:4f9d:8545:dfd2]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-abf74e85fbfsm205093666b.15.2025.03.03.01.16.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Mar 2025 01:16:11 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Helmut Eller Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: <87zfi2y0br.fsf@gmail.com> References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> <87ldtteqca.fsf@localhost> <864j0gx2ig.fsf@gnu.org> <87tt8gobac.fsf@localhost> <87r03ko4c6.fsf@localhost> <87r03jgshf.fsf@localhost> <87eczgznye.fsf@gmail.com> <87zfi2y0br.fsf@gmail.com> Date: Mon, 03 Mar 2025 10:16:10 +0100 Message-ID: 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: 76538 Cc: pipcet@protonmail.com, Ihor Radchenko , Stefan Monnier , joaomoreira@gmx.se, 76538@debbugs.gnu.org, Eli Zaretskii 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 (-) Helmut Eller writes: > On Mon, Mar 03 2025, Gerd M=C3=B6llmann wrote: > >> Do you have a concrete scenario in mind? > > To increase the probability of the problem, let's call igc_collect from > igc_add_marker, like so: > > diff --git a/src/igc.c b/src/igc.c > index ec714cad435..9bf0a0eca91 100644 > --- a/src/igc.c > +++ b/src/igc.c > @@ -4595,7 +4595,9 @@ igc_add_marker (struct buffer *b, struct Lisp_Marke= r *m) >=20=20 > IGC_MA_FREE_LIST (xv) =3D IGC_MA_MARKER (xv, slot); > IGC_MA_MARKER (xv, slot) =3D make_lisp_ptr (m, Lisp_Vectorlike); > - IGC_MA_NEXT (xv, slot) =3D IGC_MA_HEAD (xv); > + Lisp_Object head =3D IGC_MA_HEAD (xv); > + igc_collect (); > + IGC_MA_NEXT (xv, slot) =3D head; > IGC_MA_PREV (xv, slot) =3D make_fixnum (-1); > IGC_MA_HEAD (xv) =3D make_fixnum (slot); > ptrdiff_t next =3D XFIXNUM (IGC_MA_NEXT (xv, slot)); > > Then, run the code below with > > ./src/emacs -Q -batch -l /tmp/m.el -f test > > For me, Emacs seems to enter an endless loop after creating 36 markers. > > Helmut That's not what I meant, sorry, let me try to ask differently. Without modifying the code, which situation would you call risky? Is it a signal that interrupts the mutator, at the place above for instance? And then lets MPS do what? Or is it a concern for the case that MPS becomes concurrent? Sorry if I'm a bit dense today. It's Rosenmontag, after all :-). From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 03 04:29:15 2025 Received: (at 76538) by debbugs.gnu.org; 3 Mar 2025 09:29:15 +0000 Received: from localhost ([127.0.0.1]:44661 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tp26s-0007Dr-Ir for submit@debbugs.gnu.org; Mon, 03 Mar 2025 04:29:15 -0500 Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]:55494) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tp26p-0007D8-Vu for 76538@debbugs.gnu.org; Mon, 03 Mar 2025 04:29:13 -0500 Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-43994ef3872so26600385e9.2 for <76538@debbugs.gnu.org>; Mon, 03 Mar 2025 01:29:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740994146; x=1741598946; 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=UFOq3BUiByevgwJiUNcquqqBPzdtwC70ZEq1lRtLWNA=; b=GPkPw/L9QOeCflkl6oSoHOTJGa2kYKwBR9PZPSUSHVz3YC0Ry+JPCqZfYnjkZZFGJ8 UPJrQYegHfwhFJTghv+GD+1Sa7f0arBS7lMD+SRDBF6Ui5wrBmzYuJmGIfc09ZK99JrV V6dWBFAb4X1758TXQ7qXaJrL1MFLaRw0HH8Tlk6DnwHBRjUjKshVjR5EKkoDePfWK9y1 hu6/81uOc5TnKT1lJ0zmaGdoIplFuyHdohSmq2yaVRp84VxDFyuYJesesGyfN9yYO8zs QentjZyzsXKKRw6V35Vao+XgATWWjV/qrDIg6lpB+O08YKJ6IzG4gP716e82PWI+nsZX qA+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740994146; x=1741598946; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=UFOq3BUiByevgwJiUNcquqqBPzdtwC70ZEq1lRtLWNA=; b=gI0XGxS9f9sS1KdvEiLAvb/0ApS/itbnuS21Kkx6MLYUzAGw7aJndS8Gbqdb20atYb bYLp+yt3V/hD6TaK8KCoaWbEzKfAwNV12+D3kjX70+KGFuBD2ogPhxB7GRQpMx0rl6rt 7M41/gXlc9DwVGuIcjYJI37AIM/mIiiFn3Tbo/WuK3CdxKwYSINotG6Da5Lbf1F59mDu u5DDKRcGrbu+ppZ2n6zHjLbe4wy5i3uS8xzgA6KgrxAVO7XrdXj9sK5jfX9yjlYfh3ZM uPmPmQkmTqUmKIxft3UuZsb9W07cVO94e20fCyHFKBcOd8Y0BKjpNYPp7QpI9/aR7X6j l20g== X-Forwarded-Encrypted: i=1; AJvYcCWt6a9sxB0EohZGniU//oHE9aqby14gpmBY2AyFKXe/3D0HNQaXbNEeIHUF/+BnRdXJ18ggPw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxpVN9eGdqzMNHwxtvqS8OlkcRSKdaoj38nNqf7ZmQpKRT4IL2R syu15P4q51oU2qiSW1/VnhpBS0wOD6Kb1VpjBy2nUqujLQ1cpErKcTgSxQ== X-Gm-Gg: ASbGncuE8wFiyZTMg/zB3mZnucboOuefFv87mc5OuDC+Xm96cVfvUvbRTX2pMUt8L2k yeMmT5ynjt3GKBSqNNSCLLNOdOaNTA5NK0wYS1BdM+wJYsRLb4GiSkNWfIauH7YfcpK5xxGFTKF 6Pj9iTAuDT31frBYJgxdo/dahTdHqG4NfAYuxFWw+fiVlgscpjtpZyxLgmNsJ2YD+0Lhx8gva5x iZpvk+wBVbiLA+ktQ03T38IqlHiqEtn1hw/T8N5sE2h6hPJ1Hw1D6Aifq3WaJmLLYsPkKMF4ZGn MmyNI2SXRTvxsQYv6T9fMuFcKXP/1WTvkkyj8q2XdwWJJ/cJoEAMYz4KUPPI0P3qz/zM9qfSSul nRg== X-Google-Smtp-Source: AGHT+IE9qo39YPwjOQhwAEgMmklDEtN808hRU1ffVWr6vR3ecIw0pEPnF5QYx9OADKq0QKrMRxK3JQ== X-Received: by 2002:a05:600c:548f:b0:43b:c0fa:f9bc with SMTP id 5b1f17b1804b1-43bc0faff3dmr23280355e9.12.1740994145648; Mon, 03 Mar 2025 01:29:05 -0800 (PST) Received: from caladan (dialin-233080.rol.raiffeisen.net. [195.254.233.80]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43aba532b0dsm180121515e9.13.2025.03.03.01.29.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Mar 2025 01:29:05 -0800 (PST) From: Helmut Eller To: Gerd =?utf-8?Q?M=C3=B6llmann?= Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llmann=22'?= =?utf-8?Q?s?= message of "Mon, 03 Mar 2025 10:16:10 +0100") References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> <87ldtteqca.fsf@localhost> <864j0gx2ig.fsf@gnu.org> <87tt8gobac.fsf@localhost> <87r03ko4c6.fsf@localhost> <87r03jgshf.fsf@localhost> <87eczgznye.fsf@gmail.com> <87zfi2y0br.fsf@gmail.com> Date: Mon, 03 Mar 2025 10:29:04 +0100 Message-ID: <87pliyxy1r.fsf@gmail.com> 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: 76538 Cc: pipcet@protonmail.com, Ihor Radchenko , Stefan Monnier , joaomoreira@gmx.se, 76538@debbugs.gnu.org, Eli Zaretskii 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 (-) On Mon, Mar 03 2025, Gerd M=C3=B6llmann wrote: > That's not what I meant, sorry, let me try to ask differently. Without > modifying the code, which situation would you call risky? Is it a signal > that interrupts the mutator, at the place above for instance? And then > lets MPS do what? Or is it a concern for the case that MPS becomes > concurrent? Yes, concurrency. A concurrent mutator thread could trigger GC at any moment Helmut From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 03 04:37:32 2025 Received: (at 76538) by debbugs.gnu.org; 3 Mar 2025 09:37:33 +0000 Received: from localhost ([127.0.0.1]:44723 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tp2Eu-0007s9-7L for submit@debbugs.gnu.org; Mon, 03 Mar 2025 04:37:32 -0500 Received: from mail-ej1-x62b.google.com ([2a00:1450:4864:20::62b]:49243) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tp2Eq-0007rq-QK for 76538@debbugs.gnu.org; Mon, 03 Mar 2025 04:37:29 -0500 Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-aaecf50578eso801467466b.2 for <76538@debbugs.gnu.org>; Mon, 03 Mar 2025 01:37:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740994642; x=1741599442; 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=uYvc0iNbz4rg6Uxbqx7vVPKEIXRyCSZ1CI56gye4/W0=; b=NoiGC/gOqUFZyZu8lp0rghZNPDBJqKMDKgKHeTqTMzhVDA1lO08n8RKKrjqjumXhzO oIDShF+IH+WZ7zc4BnUGBpvUggh2xI4/KVVECh+jYJBjEUlQo6/cqlM20QPhKCs1IXhF /0Y7lHTNub6oJ3e0cEoco+NymSwopOvWPbuF2Tnq7IPMP73a8qq+DO1E7BsJcvoOb+yB 53+debX438FSAY5VJBu2TUrk7R9gwOc4Vk3PaVESI42spI2cEcKu4gwy3A55TGcusFGB EgBFAMQzZY7Lyu3F2XVmHsU3rwP1aSg6MwZtSQ2FCb+2zsqdFbDz3wj88h8BMx3ga60i EizA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740994642; x=1741599442; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=uYvc0iNbz4rg6Uxbqx7vVPKEIXRyCSZ1CI56gye4/W0=; b=m9uqcGdkt1d30uWIGfBEuRDAQlLNMqrWrE6PKFSnWnkiKTuWlYkjGw7Xz0b5Ya56WP WYukzjbvZUdR/Th6BgsO7NVxVz5ITeO0YyZ9R21Vb/PKLARMnMG1mZm8YP+i3pfnYCVv egCrPoOEzmfGfMI4/xfHA4OpAq5bSYltRg6mcSr0HVIrjGU68+IWJQ8GaXc2kgiw/JeF 5WTeDP5bo6IJGsGF08GhQwDXN+8fmuNG3tklWCbNCKUVf8RscdWcITSHcYc52OfdG4Oc +59vGbtiwXdEtOT68cEFAE9pjL2hSACU7W0jhlSk2E5vWwHvlLQR0lTvXGUHQKr0OcCD zDng== X-Forwarded-Encrypted: i=1; AJvYcCUNeZ8nnmv3pWjjFGaqNHF4xVDcMLSl4stPQXeqndc49lh197S3u+FkuVIz5HpgNa0BvhC8KA==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yz70w1z6IFkaiec4RMVLV24ha/8Qhbss/w8zg2f0IWoLGQ1AVZN og0zJBTqP9flWguqIQErCbotNUz1jU6xWkxwtY4mEfgNngIQQx5lp/VVLw== X-Gm-Gg: ASbGncuEoYwDoOzY/IxdmZoUFRV13ZoR5Ttb7TtAShJf09CGhoTgpTPdx+3IVNQ/OOV +pQ97I45nkVyMqJFrkcIB8+jyp/MARMxp1AE1hOxLSrFbjC3JtykRrwRTVHvSmaP0Oo/n6VGKaT 4Hflwx5ytBvKHn/bmC5G6rFaIQrWw4SWDf5HfV+xqDwq3LWvYD4RNZ7GOPTei9B+qaKkr0/ImNf ea0AEazhq7M+hvZU8Mya3YCKF7TxRFDc9PrGhVky0UXgxh/YlG1My3VeSb9tir6QQGMMvXfWZPi kV0bjRsmT5bSeAP3nyFaZqHmd5mc3IN/XKzOTrvCkoe1r4VWM8TC8wpKXgHIvn0LXxzf5b+cH+r cA/QKD5ezO4W0UtYaIhgXDb6eAYT9igfcbMy/gDAGIRDLcRMkjLZ5eA== X-Google-Smtp-Source: AGHT+IHE3uIvP1a3Drt6zzeuAyKuevohhx1x0IHY22QSHfTD1MtSQ1hcQ1oiGXvsL/ozTvVvGRbCXA== X-Received: by 2002:a17:907:9728:b0:abe:e814:ecb4 with SMTP id a640c23a62f3a-abf25f8dd35mr1515354766b.4.1740994642118; Mon, 03 Mar 2025 01:37:22 -0800 (PST) Received: from pro2 (p200300e0b7148300591b4f9d8545dfd2.dip0.t-ipconnect.de. [2003:e0:b714:8300:591b:4f9d:8545:dfd2]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ac1e46949aasm32586666b.145.2025.03.03.01.37.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Mar 2025 01:37:21 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Helmut Eller Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: <87pliyxy1r.fsf@gmail.com> References: <87ikoyetgi.fsf@gmx.se> <87o6yqm1g7.fsf@protonmail.com> <87ldtt29jx.fsf@gmail.com> <87ldtteqca.fsf@localhost> <864j0gx2ig.fsf@gnu.org> <87tt8gobac.fsf@localhost> <87r03ko4c6.fsf@localhost> <87r03jgshf.fsf@localhost> <87eczgznye.fsf@gmail.com> <87zfi2y0br.fsf@gmail.com> <87pliyxy1r.fsf@gmail.com> Date: Mon, 03 Mar 2025 10:37:20 +0100 Message-ID: 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: 76538 Cc: pipcet@protonmail.com, Ihor Radchenko , Stefan Monnier , joaomoreira@gmx.se, 76538@debbugs.gnu.org, Eli Zaretskii 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 (-) Helmut Eller writes: > On Mon, Mar 03 2025, Gerd M=C3=B6llmann wrote: > >> That's not what I meant, sorry, let me try to ask differently. Without >> modifying the code, which situation would you call risky? Is it a signal >> that interrupts the mutator, at the place above for instance? And then >> lets MPS do what? Or is it a concern for the case that MPS becomes >> concurrent? > > Yes, concurrency. A concurrent mutator thread could trigger GC at any > moment > > Helmut Thanks, and I agree of course. Something for future generations to solve, from my POV at least. Should it ever happen :-). From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 03 05:42:41 2025 Received: (at 76538) by debbugs.gnu.org; 3 Mar 2025 10:42:41 +0000 Received: from localhost ([127.0.0.1]:45130 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tp3Fw-0004RG-Sb for submit@debbugs.gnu.org; Mon, 03 Mar 2025 05:42:41 -0500 Received: from mail-40134.protonmail.ch ([185.70.40.134]:53699) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tp3Fu-0004QP-1g for 76538@debbugs.gnu.org; Mon, 03 Mar 2025 05:42:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1740998550; x=1741257750; bh=bxjgUzeMRx9zUKIzZUM/W4E7mWphEPbvDT8JjFP3UHE=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=Z9zigwRMq4SKPhGXqFmZM9Izhxk+KF0XeqCK2pnhBiK9l2locQ0n11iRa9Ft3EgSi 4TaH3TdjBRD0ZrvUloRp2cZ8tKMgoPTY9Ax4VrIz74xqkfrO8KjfFUJ5cqKmpdWf51 AHSLN/Opm+Sr5taxRMc90hXWdpvPkEuiTFwqZYmyVgQdMMwoTjdqf6Ca0KOGCbeVpp 7/UYUpDBdQXmRRwt4SroMUVGwTbquADc60dHEqlT/QE/fSJjXgCejuhI+momkuiEkn iMSIpRcuzK31WcienwUqh7TPfmX3BwFwiuj7gTHLHIES4+gwJcMUG9hTPXDSqi9JSY qcWAdzb6Kw7hw== Date: Mon, 03 Mar 2025 10:42:25 +0000 To: =?utf-8?Q?Gerd_M=C3=B6llmann?= From: Pip Cet Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. Message-ID: <87tt8axuod.fsf@protonmail.com> In-Reply-To: References: <87ikoyetgi.fsf@gmx.se> <87eczgznye.fsf@gmail.com> <87zfi2y0br.fsf@gmail.com> <87pliyxy1r.fsf@gmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: e376e7135b3fd512a717520b6e46d2e38ad25ba5 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: 76538 Cc: Ihor Radchenko , Helmut Eller , Stefan Monnier , joaomoreira@gmx.se, 76538@debbugs.gnu.org, Eli Zaretskii 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 (-) Gerd M=C3=B6llmann writes: > Helmut Eller writes: > >> On Mon, Mar 03 2025, Gerd M=C3=B6llmann wrote: >> >>> That's not what I meant, sorry, let me try to ask differently. Without >>> modifying the code, which situation would you call risky? Is it a signa= l >>> that interrupts the mutator, at the place above for instance? And then >>> lets MPS do what? Or is it a concern for the case that MPS becomes >>> concurrent? >> >> Yes, concurrency. A concurrent mutator thread could trigger GC at any >> moment >> >> Helmut > > Thanks, and I agree of course. Something for future generations to > solve, from my POV at least. Should it ever happen :-). Here's my current patch series for finalizing markers. Still needs testing to see whether it actually avoids the problem (or will once we stop the world for finalizers, as we should), but it doesn't crash immediately. BTW, I'm currently running with a background thread eagerly triggering GC, which allowed me to find the missing bt.function trace, but hasn't uncovered other bugs so far. So that is concurrent GC, even if it's unlikely to be a performance win right now :-) I have no idea why I hit the assert which required the second patch. It seems to me like a bug in the xdisp.c code, but it's xdisp.c, so who knows? Even though we now emulate the alloc.c code quite precisely, I think feature/igc will accumulate many more markers than alloc.c, since weak objects are collected quite rarely by MPS, IME. Maybe we need to mark "automatic" markers which are never exposed to Lisp and splat them in DO_MARKERS if there are too many of them? A more convoluted approach would be to alternate between considering markers and calculating the charpos for the "best" known marker: do one marker, then one character, repeat. That sort of thing is good for theoretical complexity but rarely useful in practice... >From 31f3a7f25efe3840d42535f65147c40a7298357b Mon Sep 17 00:00:00 2001 From: Pip Cet Subject: [PATCH 1/2] [MPS] finalize markers rather than unchaining them in = the collector * src/buffer.h (marker_it_next): Skip splatted markers. * src/igc.c (fix_marker_vector): Don't call 'unchain'. (finalize_marker): New function, calling 'unchain'. (finalize_vector): Finalize markers. (maybe_finalize): Adjust --- src/buffer.h | 8 ++++++-- src/igc.c | 25 +++++++++++++++++++------ 2 files changed, 25 insertions(+), 8 deletions(-) diff --git a/src/buffer.h b/src/buffer.h index ffe6770ba7b..5a460b9dcee 100644 --- a/src/buffer.h +++ b/src/buffer.h @@ -775,8 +775,12 @@ marker_it_valid (struct marker_it *it) INLINE void marker_it_next (struct marker_it *it) { - it->slot =3D XFIXNUM (IGC_MA_NEXT (it->v, it->slot)); - it->obj =3D it->slot < 0 ? Qnil : IGC_MA_MARKER (it->v, it->slot); + do + { + it->slot =3D XFIXNUM (IGC_MA_NEXT (it->v, it->slot)); + it->obj =3D it->slot < 0 ? Qnil : IGC_MA_MARKER (it->v, it->slot); + } + while (!MARKERP (it->obj) && it->slot > 0); } =20 INLINE struct Lisp_Marker * diff --git a/src/igc.c b/src/igc.c index ec714cad435..54c56309502 100644 --- a/src/igc.c +++ b/src/igc.c @@ -2165,10 +2165,6 @@ fix_marker_vector (mps_ss_t ss, struct Lisp_Vector *= v) =20 =09Lisp_Object old =3D IGC_MA_MARKER (v, slot); =09IGC_FIX12_OBJ (ss, &IGC_MA_MARKER (v, slot)); - -=09/* FIXME/igc: this is right for marker vectors only. */ -=09if (NILP (IGC_MA_MARKER (v, slot)) && !NILP (old)) -=09 unchain (v, slot); } } MPS_SCAN_END (ss); @@ -3567,6 +3563,20 @@ finalize_finalizer (struct Lisp_Finalizer *f) } } =20 +static void +finalize_marker (struct Lisp_Marker *m) +{ + if (m->buffer && BUF_MARKERS (m->buffer)) + { + struct Lisp_Vector *v =3D XVECTOR (BUF_MARKERS (m->buffer)); + if (!BASE_EQ (IGC_MA_MARKER (v, m->slot), make_lisp_ptr (m, Lisp_Vec= torlike)) && +=09 !NILP (IGC_MA_MARKER (v, m->slot))) +=09emacs_abort (); + unchain (v, m->slot); + fprintf (stderr, "unchained %zd\n", (size_t) m->slot); + } +} + /* Turn an existing pseudovector into a PVEC_FREE, keeping its size. */ =20 static void @@ -3641,6 +3651,10 @@ finalize_vector (mps_addr_t v) finalize_finalizer (v); break; =20 + case PVEC_MARKER: + finalize_marker (v); + break; + #ifndef IN_MY_FORK case PVEC_OBARRAY: #endif @@ -3669,7 +3683,6 @@ finalize_vector (mps_addr_t v) case PVEC_XWIDGET: case PVEC_XWIDGET_VIEW: case PVEC_TERMINAL: - case PVEC_MARKER: case PVEC_MODULE_GLOBAL_REFERENCE: igc_assert (!"finalization not implemented"); break; @@ -3745,6 +3758,7 @@ maybe_finalize (mps_addr_t client, enum pvec_type tag= ) case PVEC_NATIVE_COMP_UNIT: case PVEC_SUBR: case PVEC_FINALIZER: + case PVEC_MARKER: { =09mps_res_t res =3D mps_finalize (global_igc->arena, &ref); =09IGC_CHECK_RES (res); @@ -3759,7 +3773,6 @@ maybe_finalize (mps_addr_t client, enum pvec_type tag= ) case PVEC_WEAK_HASH_TABLE: case PVEC_NORMAL_VECTOR: case PVEC_FREE: - case PVEC_MARKER: case PVEC_OVERLAY: case PVEC_SYMBOL_WITH_POS: case PVEC_MISC_PTR: --=20 2.48.1 >From 9148e4c387294b06a471c25d07279d207b1d45c9 Mon Sep 17 00:00:00 2001 From: Pip Cet Subject: [PATCH 2/2] XXX why is this change necessary? --- src/xdisp.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/src/xdisp.c b/src/xdisp.c index 577d5b1b401..2c349bb9adf 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -6714,9 +6714,15 @@ handle_composition_prop (struct it *it) string =3D it->string; s =3D SDATA (string) + pos_byte; if (STRING_MULTIBYTE (string)) -=09it->c =3D STRING_CHAR (s); +=09{ +=09 it->c =3D STRING_CHAR (s); +=09 it->len =3D CHAR_BYTES (it->c); +=09} else -=09it->c =3D *s; +=09{ +=09 it->c =3D *s; +=09 it->len =3D 1; +=09} } else { @@ -6724,6 +6730,7 @@ handle_composition_prop (struct it *it) pos_byte =3D IT_BYTEPOS (*it); string =3D Qnil; it->c =3D FETCH_CHAR (pos_byte); + it->len =3D it->multibyte_p ? CHAR_BYTES (it->c) : 1; } =20 /* If there's a valid composition and point is not inside of the --=20 2.48.1 From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 03 06:33:50 2025 Received: (at 76538) by debbugs.gnu.org; 3 Mar 2025 11:33:50 +0000 Received: from localhost ([127.0.0.1]:45407 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tp43R-0008BR-GL for submit@debbugs.gnu.org; Mon, 03 Mar 2025 06:33:49 -0500 Received: from mail-ed1-x52f.google.com ([2a00:1450:4864:20::52f]:55445) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tp43K-0008B0-Bu for 76538@debbugs.gnu.org; Mon, 03 Mar 2025 06:33:47 -0500 Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-5e549af4927so1694793a12.2 for <76538@debbugs.gnu.org>; Mon, 03 Mar 2025 03:33:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741001616; x=1741606416; 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=j27WdMEZJaS6komwSOygduCztMjF6T93vJVLVCNHM44=; b=bGKraEgnbPtwWAeGRb+v9knAjJ3YdKzc7ExNDzJxVpsMw8YifWqFijNhFSVY4kF0p4 x49nOijo7sJjHzrE/XIUmUaV+efAatTho1AXC6UpWl537nByN5cFZRtAuFT+bXHG2h63 fSBlJEaHBNxZQ+0n+JptHpozzDiIdcMiBzsotCLoblzZPHMRomr1aEJXFydbCDsvxD6D XBMPI0f4rQFUX3VuUBRhDy691R6XKXWt2zNhHgpymklsjVJsbzLO8ViO7zfgyQQ+om4C JAB4U4ZuY8qLULR0XCplmVKkv0PdJcLvQMWiStC1iBml65TsgD+ZiG54wtcxHh0M0mm9 al1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741001616; x=1741606416; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=j27WdMEZJaS6komwSOygduCztMjF6T93vJVLVCNHM44=; b=m1l5A4y5CBZfxlyQJbu+K0kYdnHYLOo3mDNjG+uaROXwTcMIgXXXPoISGSLVigpEKm kN3jtJGWpPlqW9N3w2Xy2IziF5KprhoR5hqItMTVwQB+olH1y0iOPCfHvLyP1K+8cVwK 1CRCjggduNcNYuq2d4yrlPxbROPtXA1r4T2Zbm1Qt+qGWmW6MIXVfLXbAq9gnXL5xMP4 c81Otcrg35U+ErnPlXpPWtF2Q24BoU5bAX69bh5S75/3Q4syVKGAwNi0FFEVn1ZFdaSW mfnxqjLsw5+XEZtcSkurmIbIscW2A+ZdGIGqd1bHjggmgYLaQvJludMQ8A/MB/wyk8GW aB7Q== X-Forwarded-Encrypted: i=1; AJvYcCUxT+7u2GOaq9pbPC6P8tnuRvipydRbceUZRd7z2LqiFbEUoRWWfzDvrqiA7BB5yNn0XdZbMg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxxaUIAVhyUj+1QHC40s+MDru/atRYW9gs5jrV3tKnKOy8Ie4js idnnHT6PPEJA05LVNOKKx17pLv5XPfRA1JWDN1fphTbzEQukbUDmuc+TeQ== X-Gm-Gg: ASbGncslZ9T60FJuXdfgmzQo0qHTul4Q595MbDQaVcOuv4AgC1JajgKu0cf2UYANkTs +zBRXVUnz7utQzk++Qb2SHRY4pvRmJ9NzDqv0g92tngle6GBecwupoV5qtci1o3lJ5sjEEBmE8m JZLpfSj7DcRgwW8NOY6Sdyz9DAUWLuWah7ZuQt6OnCIHK3kR/4EjaApaBjRx2vu6MAzgdkBG/5v nAuqmt6+GKqjSHiaJt1gwH5ZyF5bSAYaBTQikD77siCWJnQSwce4qIRuylT8pshrj43MSZphEyu +8JMemFdt7u47wplLzWB2tYi6SjpSLAXNFlE0BHQOMJmhYWN2ondesEHmeyapKWSnIXjzEI2Zk6 WAcvtNggyqUfxQG5LlydI6rn1EoHlVkmX+vTgjLQClFDfLaVX5bdUaw== X-Google-Smtp-Source: AGHT+IGb/lF07M7Tuevx7XTnyWKlWg689F0FhxVtgycC9N1mrxESHOUzO27Acig7XnndMAZnqScCRQ== X-Received: by 2002:a17:906:f586:b0:abf:7b38:7e64 with SMTP id a640c23a62f3a-abf7b38837dmr299853466b.43.1741001615594; Mon, 03 Mar 2025 03:33:35 -0800 (PST) Received: from pro2 (p200300e0b7148300591b4f9d8545dfd2.dip0.t-ipconnect.de. [2003:e0:b714:8300:591b:4f9d:8545:dfd2]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-abf46a3ac00sm510390166b.25.2025.03.03.03.33.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Mar 2025 03:33:35 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Pip Cet Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: <87tt8axuod.fsf@protonmail.com> References: <87ikoyetgi.fsf@gmx.se> <87eczgznye.fsf@gmail.com> <87zfi2y0br.fsf@gmail.com> <87pliyxy1r.fsf@gmail.com> <87tt8axuod.fsf@protonmail.com> Date: Mon, 03 Mar 2025 12:33:34 +0100 Message-ID: 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: 76538 Cc: Ihor Radchenko , Helmut Eller , Stefan Monnier , joaomoreira@gmx.se, 76538@debbugs.gnu.org, Eli Zaretskii 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 (-) Pip Cet writes: > Here's my current patch series for finalizing markers. Still needs > testing to see whether it actually avoids the problem (or will once we > stop the world for finalizers, as we should), but it doesn't crash > immediately. > > BTW, I'm currently running with a background thread eagerly triggering > GC, which allowed me to find the missing bt.function trace, but hasn't > uncovered other bugs so far. So that is concurrent GC, even if it's > unlikely to be a performance win right now :-) :-). > I have no idea why I hit the assert which required the second patch. It > seems to me like a bug in the xdisp.c code, but it's xdisp.c, so who > knows? Yeah, that doesn't look right. Normally, string_char_and_length should have been used to get characters from a C string. > Even though we now emulate the alloc.c code quite precisely, I think > feature/igc will accumulate many more markers than alloc.c, since weak > objects are collected quite rarely by MPS, IME. Maybe we need to mark > "automatic" markers which are never exposed to Lisp and splat them in > DO_MARKERS if there are too many of them? > > A more convoluted approach would be to alternate between considering > markers and calculating the charpos for the "best" known marker: do one > marker, then one character, repeat. That sort of thing is good for > theoretical complexity but rarely useful in practice... I'd like to see something not using markers at all, TBH. Otherwise, LGTM. Only thing I saw is this: > +static void > +finalize_marker (struct Lisp_Marker *m) > +{ > + if (m->buffer && BUF_MARKERS (m->buffer)) ^^^^^^^^^^^ NILP From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 03 09:01:22 2025 Received: (at 76538) by debbugs.gnu.org; 3 Mar 2025 14:01:22 +0000 Received: from localhost ([127.0.0.1]:46501 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tp6ME-00054e-47 for submit@debbugs.gnu.org; Mon, 03 Mar 2025 09:01:22 -0500 Received: from mail-4322.protonmail.ch ([185.70.43.22]:31973) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tp6MA-00053z-Ui for 76538@debbugs.gnu.org; Mon, 03 Mar 2025 09:01:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1741010472; x=1741269672; bh=t3y6KnkrzAd6TUT1jpfgsUGwYzgIMDbaqhn35Xumoyk=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=eYzoH98L3r6u2sx4tJTKWbzMLDH6jgNtdXEfOTu08EWcoku8U4/nQXh3kTC8x/oTZ 8itb2x5m2IHgnozgQsywDDx9fG58PS503krbXLn7Vy4l8pwRHMdxP0eocEhqgoRdFG atOs6/IJ/m2J+Hy25n1dtZn6L2NDtBVdlcldlz9hZan130VMs7AEwgVbPCNH6YCey7 eUEKy+zQwYa2U4RODyDtQ79sYe7yfhxhma5ABMOZpJ0QNBOUH3MATCgDdZHoklMwKJ rpYsVWBr4+nFvN9PLoxsPwEZMxnKxZdpSi/EyuJXPoBE917Kqf8H6IIpoRwMG2f6IE 7UdoiGcGSIQ6Q== Date: Mon, 03 Mar 2025 14:01:06 +0000 To: =?utf-8?Q?Gerd_M=C3=B6llmann?= From: Pip Cet Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. Message-ID: <87bjuixlh9.fsf@protonmail.com> In-Reply-To: References: <87ikoyetgi.fsf@gmx.se> <87eczgznye.fsf@gmail.com> <87zfi2y0br.fsf@gmail.com> <87pliyxy1r.fsf@gmail.com> <87tt8axuod.fsf@protonmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 8fc12adbf5008bb93e33d3cfcf2fa9bfbb309250 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: 76538 Cc: Ihor Radchenko , Helmut Eller , Stefan Monnier , joaomoreira@gmx.se, 76538@debbugs.gnu.org, Eli Zaretskii 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 (-) Gerd M=C3=B6llmann writes: > Pip Cet writes: > >> Here's my current patch series for finalizing markers. Still needs >> testing to see whether it actually avoids the problem (or will once we >> stop the world for finalizers, as we should), but it doesn't crash >> immediately. >> >> BTW, I'm currently running with a background thread eagerly triggering >> GC, which allowed me to find the missing bt.function trace, but hasn't >> uncovered other bugs so far. So that is concurrent GC, even if it's >> unlikely to be a performance win right now :-) > > :-). > >> I have no idea why I hit the assert which required the second patch. It >> seems to me like a bug in the xdisp.c code, but it's xdisp.c, so who >> knows? > > Yeah, that doesn't look right. Normally, string_char_and_length should > have been used to get characters from a C string. > >> Even though we now emulate the alloc.c code quite precisely, I think >> feature/igc will accumulate many more markers than alloc.c, since weak >> objects are collected quite rarely by MPS, IME. Maybe we need to mark >> "automatic" markers which are never exposed to Lisp and splat them in >> DO_MARKERS if there are too many of them? >> >> A more convoluted approach would be to alternate between considering >> markers and calculating the charpos for the "best" known marker: do one >> marker, then one character, repeat. That sort of thing is good for >> theoretical complexity but rarely useful in practice... > > I'd like to see something not using markers at all, TBH. > > Otherwise, LGTM. Only thing I saw is this: > >> +static void >> +finalize_marker (struct Lisp_Marker *m) >> +{ >> + if (m->buffer && BUF_MARKERS (m->buffer)) > ^^^^^^^^^^^ > NILP Thanks! The fprintf should also go, but testing revealed a somewhat more difficult problem: when garbage_collection_messages is true, the maybe_process_messages call in maybe_finalize can try to print to a buffer, which is bad because we're in the middle of tearing down one. I think we should remove that call, to be honest, and put it in maybe_quit instead, since some messages may cause us to print messages or run Lisp. Alternatively, we could use pending_funcalls or a similar mechanism. WDYT? Pip From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 03 09:13:49 2025 Received: (at 76538) by debbugs.gnu.org; 3 Mar 2025 14:13:49 +0000 Received: from localhost ([127.0.0.1]:46626 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tp6YG-0005yF-Q1 for submit@debbugs.gnu.org; Mon, 03 Mar 2025 09:13:49 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51786) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tp6YD-0005xu-5Y for 76538@debbugs.gnu.org; Mon, 03 Mar 2025 09:13:46 -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 1tp6Y5-0006SZ-Ho; Mon, 03 Mar 2025 09:13:38 -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=9xXRNlTlv2XSwQ10JGFt+I54aXw2hbcbkLxhOlxwSSs=; b=VuLYf3Mqs63r DutjrNr6kZuVQN0cxQDo+52wZT+BKlrv7OxXxmmFlI+IZuILtqsPONZjQyJQcNOxLCRCO7/swst7J H/zww3WTrJvVDCDDnLOfOZ2882GzgU7ONXTGE4G9GOEYY0TmmBNCCIFtupIyEx9nO6oYiwG4aeMUS 3/i3mOeRWH23AoKW03M8d5URLHGZXcpL0gX0ESTGOVUKDXca02FkvW5+x+RNNyfG9mmYw0B8CISkz 5cCKkYJVKm/kJr7BnHix5IvkT1gItnRSUZiVtgz3w1fSDDxDQXbqktEGXRxuHpxBF3C43LfH3EAIu DSbGj7j2ABa6aQ/vFSXNeQ==; Date: Mon, 03 Mar 2025 16:13:32 +0200 Message-Id: <86y0xmkxrn.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87tt8axuod.fsf@protonmail.com> (message from Pip Cet on Mon, 03 Mar 2025 10:42:25 +0000) Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. References: <87ikoyetgi.fsf@gmx.se> <87eczgznye.fsf@gmail.com> <87zfi2y0br.fsf@gmail.com> <87pliyxy1r.fsf@gmail.com> <87tt8axuod.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76538 Cc: yantar92@posteo.net, eller.helmut@gmail.com, gerd.moellmann@gmail.com, monnier@iro.umontreal.ca, joaomoreira@gmx.se, 76538@debbugs.gnu.org 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 (---) > Date: Mon, 03 Mar 2025 10:42:25 +0000 > From: Pip Cet > Cc: Helmut Eller , Stefan Monnier , Ihor Radchenko , Eli Zaretskii , joaomoreira@gmx.se, 76538@debbugs.gnu.org > > I have no idea why I hit the assert which required the second patch. Which assertion was that? Is there any way of triggering that on the master branch, or on the igc branch without first applying the patch? > It seems to me like a bug in the xdisp.c code, but it's xdisp.c, so > who knows? I suspect it->len is not used when the character is composed, because the actual character in the buffer text is not relevant in that case, as the results of the composition determine how many bytes to skip to get to the next "display element". > - it->c = STRING_CHAR (s); > + { > + it->c = STRING_CHAR (s); > + it->len = CHAR_BYTES (it->c); > + } This is sub-optimal; please use string_char_and_length instead. > @@ -6724,6 +6730,7 @@ handle_composition_prop (struct it *it) > pos_byte = IT_BYTEPOS (*it); > string = Qnil; > it->c = FETCH_CHAR (pos_byte); > + it->len = it->multibyte_p ? CHAR_BYTES (it->c) : 1; Likewise here. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 03 09:24:03 2025 Received: (at 76538) by debbugs.gnu.org; 3 Mar 2025 14:24:03 +0000 Received: from localhost ([127.0.0.1]:46777 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tp6iA-0006jD-Uc for submit@debbugs.gnu.org; Mon, 03 Mar 2025 09:24:03 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:40821) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tp6i6-0006iE-Qr for 76538@debbugs.gnu.org; Mon, 03 Mar 2025 09:23:59 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 2DE35441781; Mon, 3 Mar 2025 09:23:50 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1741011829; bh=zHTHpHib/ucAP5QkSSUvwJcYG4L5Qh7Vtbe3n3NqlOE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=h2LadZND8bobY4bV4zGmoUbdML+Jr2g2upJyzoiecAyowbs6PAyaqsYS4a0IiQdnm hker+IBTYkRlgxjEPxOZ0L1KBCxc1QBSQDjtSja6CwSwHo4U3oIfL5Ai9usjmhNGRE aPSnORklRL38JI19BXU9h9widApnFatkcEq3cSafBBPM8TV2HjB0ptRqCgBWlTEPnv YIcX0MSe8Z40DWdxehUm01VnvtN9MCbvktTTnMtGf9EPzOlyiZ5By25+isIZ8zyr6c y+Z4b7kwXtz+bGqyiCW5Mw1LznBI5v78stmkJY+LqiMqzC9jqhIvJ7Cvx6Tp8AFNVF vuQmhTGyjDycg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 1DEB2441767; Mon, 3 Mar 2025 09:23:49 -0500 (EST) Received: from pastel (unknown [104.247.242.5]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id BB61D120572; Mon, 3 Mar 2025 09:23:48 -0500 (EST) From: Stefan Monnier To: Pip Cet Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: <87tt8axuod.fsf@protonmail.com> (Pip Cet's message of "Mon, 03 Mar 2025 10:42:25 +0000") Message-ID: References: <87ikoyetgi.fsf@gmx.se> <87eczgznye.fsf@gmail.com> <87zfi2y0br.fsf@gmail.com> <87pliyxy1r.fsf@gmail.com> <87tt8axuod.fsf@protonmail.com> Date: Mon, 03 Mar 2025 09:23:47 -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.372 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 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76538 Cc: Ihor Radchenko , Helmut Eller , Gerd =?windows-1252?Q?M=F6llmann?= , joaomoreira@gmx.se, 76538@debbugs.gnu.org, Eli Zaretskii 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 (---) > Even though we now emulate the alloc.c code quite precisely, I think > feature/igc will accumulate many more markers than alloc.c, since weak > objects are collected quite rarely by MPS, IME. One of the benefits of using a better markers cache would be to reduce reliance on the GC, indeed. E.g. my array-with-gap will tend not to accumulate cache-markers indefinitely because it always finds the closest (cache-)marker before deciding whether we need to add another one. [ Of course, if the GC never triggers, cache-markers can still accumulate needlessly, e.g. if you regularly `erase-buffer`, which causes all the (cache-)markers to be moved to point-min, or in a comint buffer where you regularly cut the beginning to keep the buffer from growing indefinitely. ] > Maybe we need to mark "automatic" markers which are never exposed to > Lisp and splat them in DO_MARKERS if there are too many of them? Getting rid of the GC's involvement in flushing the cache would be good. Doing it at every DO_MARKERS might be requires care if we don't want it to be too costly. [ Also, with the current un-ordered setup, it could be hard to know which ones to throw out. Again, a better cache would help in this regard. ] Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 03 09:31:58 2025 Received: (at 76538) by debbugs.gnu.org; 3 Mar 2025 14:31:58 +0000 Received: from localhost ([127.0.0.1]:46844 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tp6pp-0007VL-O7 for submit@debbugs.gnu.org; Mon, 03 Mar 2025 09:31:58 -0500 Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]:53459) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tp6pn-0007Uq-FN for 76538@debbugs.gnu.org; Mon, 03 Mar 2025 09:31:56 -0500 Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-43bbb440520so13071555e9.2 for <76538@debbugs.gnu.org>; Mon, 03 Mar 2025 06:31:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741012309; x=1741617109; 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=mMt8gt5xAxJZuW7u+ixyoOTgCI4/S6PHtTq8WRzaRKc=; b=QsST6Gw9bAtYJLoNsctL7drfK7ztIrCL7587Oy/7u9YyPUJ3bZuLVhB2Q5q1TF8cRi k4yl6eVxIpcNOtIl/SvJ3RpUBT2ntntTLLdB87u/lnwdUzCFJsoJ3Uv3enqjLKpUkaUJ d9DjLq11DTGvAIKz1J6krICjBUeSHbI9Jiw9gH1GCMu0/DEYm5y4DxhI6aAMTjNUd5sO z5qfBY4AgEScrDfwr5LrIc2D7ofqOxiIX9+a0AqTcuGu6WOflKqyVsvBFiQNa4lFRyps Bx/0EJD7GL/jhtIHLE330aKGGxx3tecbqe7bblhiJAfeXNnK/f8OLx7GbMldO/gLgSXW Vpww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741012309; x=1741617109; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mMt8gt5xAxJZuW7u+ixyoOTgCI4/S6PHtTq8WRzaRKc=; b=nGF3bS5vKzZAHp8n8mQHBtoEdQDtsn5IQrp/f5kQe1lulXL2SXtSq7v8t/RhJEH9sm Bh2SzQaNQWtKWKxBERnD03L55t2Lv/506hrb2J6mEQ6aNWWTVyQQcL3obRmCQg3UkE56 t5oahwold1kKi9DGcC6a4kKLe9GGeTbwmBHMQ3eeH7vLZYgi6g9PdrkAHyOHthzd0jnc uGxZumOJywddxXzdpxM9rFmBe71CMCZeYBU5Pxnn6BIVmwhaiWBSjI+uKKnLvbKCtZ0P brb+ZCALwyR2pd0LXWFA35fF8KJzxW7jVk4VqSvRVOP/beFz3zQl7QtxGaU+aXvScpaq DBvw== X-Forwarded-Encrypted: i=1; AJvYcCUnU4+2lXPkxIR2i0nXVPEotQGyxVE/oEhjeCTi6Ks+vOENtbK4I/MAsxYTQ/oTUksL0iraow==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwHW3+2KQUUpBFxdZBNp7fjSyZVYnSmBEsdcsBhquHrksyeLAy7 rsj4G9+6evXXNdsdJDjRbyGIyOWc/jJuRv4PtneprYfCczQu7moJRZZ9Iw== X-Gm-Gg: ASbGncu9apO1IE8avpNb79cUtyyZuIUbHQ8f0sH0Ie6P34YQcjNXabMgU5Ffnmn6d4u cgtyjz9ouAPKWbDgZhc5JGtf9pvl0WHvtRZKMth/NDw6nNHzcXlLiewB/PKCcAJ/RKhjlqjxp0W JsEIjemnq23KCjYlLuXBkYaAfL1xkymFtRUzeanyZB5r+IXyY74rhygY1Hh30CV31fKY/Cx9Ts5 rRupj2iAkTgyi3gOp24s7ajUOyNEVVx68reKC8uffzvK8yMkpeM9F8oNnfqnpBEsrpiFwHjYIhQ Zix5rglMQJQ9sS5D52zx1ltfkdRdnZO6aHd90a5W6RyvqmKfTNZ+UItM6e2jpNJYsB0vjLGeduk wutecN8tB2eHr4Paxp1oi/V4nKjcQX6fy7JT0stTCi6W4D5C/8K+Jww== X-Google-Smtp-Source: AGHT+IFLr6PgpBL+8wtVEN9i0Ew/TTgGqg2b96aUkYeZYXjtUfewPfmgxYZ2T37ABCLA1Xz/HNQTHw== X-Received: by 2002:a05:600c:4f12:b0:43b:8198:f713 with SMTP id 5b1f17b1804b1-43ba66d9e7emr133558475e9.4.1741012308653; Mon, 03 Mar 2025 06:31:48 -0800 (PST) Received: from pro2 (p200300e0b7148300591b4f9d8545dfd2.dip0.t-ipconnect.de. [2003:e0:b714:8300:591b:4f9d:8545:dfd2]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43bbbff18b3sm53711615e9.24.2025.03.03.06.31.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Mar 2025 06:31:48 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Pip Cet Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. In-Reply-To: <87bjuixlh9.fsf@protonmail.com> References: <87ikoyetgi.fsf@gmx.se> <87eczgznye.fsf@gmail.com> <87zfi2y0br.fsf@gmail.com> <87pliyxy1r.fsf@gmail.com> <87tt8axuod.fsf@protonmail.com> <87bjuixlh9.fsf@protonmail.com> Date: Mon, 03 Mar 2025 15:31:46 +0100 Message-ID: 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: 76538 Cc: Ihor Radchenko , Helmut Eller , Stefan Monnier , joaomoreira@gmx.se, 76538@debbugs.gnu.org, Eli Zaretskii 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 (-) Pip Cet writes: > Thanks! The fprintf should also go, but testing revealed a somewhat > more difficult problem: when garbage_collection_messages is true, the > maybe_process_messages call in maybe_finalize can try to print to a > buffer, which is bad because we're in the middle of tearing down one. I > think we should remove that call, to be honest, and put it in maybe_quit > instead, since some messages may cause us to print messages or run Lisp. > > Alternatively, we could use pending_funcalls or a similar mechanism. > > WDYT? Sounds okay. The simpler the better, I'd say. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 03 09:47:16 2025 Received: (at 76538) by debbugs.gnu.org; 3 Mar 2025 14:47:16 +0000 Received: from localhost ([127.0.0.1]:47002 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tp74d-0000D7-6l for submit@debbugs.gnu.org; Mon, 03 Mar 2025 09:47:16 -0500 Received: from mail-10628.protonmail.ch ([79.135.106.28]:44339) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tp74U-0000Bj-Uv for 76538@debbugs.gnu.org; Mon, 03 Mar 2025 09:47:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1741013219; x=1741272419; bh=5+xC3JSVO5fQ6dMu4M6cptnpn/mMDExirXc7N9r62uA=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=XUcR+UaL0oKjEBnX4ewn1TEtGH9aNSuuUpos1xnxrvLFZJUqrSP/EYqoWlgYRD4Wz YzgXsgF4brxj7vT4gq1YwatRj1js3p4YhFv4YIzsI2i7otuE+kH/QTUk/Yroh2l9Or ShoWpP7e/ilgNI38FbShVrd2wrUN/C31nfF0k6iU4JMnyuipKVHzl9L6pCQEp2w5CB ezBLPcmyswk8QX+T7Ij2pdLMbcvXNKzee+VqCUNNdaeUeaHCuh5CBzZS1TXj/sBWTv LocRndGLk0AZwm8H2OveZiQrbXx1OWInfhImfgDOGcSaOp8rlYes3gLucEzBV5dXJo TxdCRU+Yu2oKw== Date: Mon, 03 Mar 2025 14:46:55 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. Message-ID: <8734fuxjcv.fsf@protonmail.com> In-Reply-To: <86y0xmkxrn.fsf@gnu.org> References: <87ikoyetgi.fsf@gmx.se> <87eczgznye.fsf@gmail.com> <87zfi2y0br.fsf@gmail.com> <87pliyxy1r.fsf@gmail.com> <87tt8axuod.fsf@protonmail.com> <86y0xmkxrn.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: d3677330996cbf7e68c75d37563a4b22a0be939b MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 76538 Cc: yantar92@posteo.net, eller.helmut@gmail.com, gerd.moellmann@gmail.com, monnier@iro.umontreal.ca, joaomoreira@gmx.se, 76538@debbugs.gnu.org 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 (-) "Eli Zaretskii" writes: >> Date: Mon, 03 Mar 2025 10:42:25 +0000 >> From: Pip Cet >> Cc: Helmut Eller , Stefan Monnier >> , Ihor Radchenko , >> Eli Zaretskii , joaomoreira@gmx.se, >> 76538@debbugs.gnu.org >> >> I have no idea why I hit the assert which required the second patch. > > Which assertion was that? Is there any way of triggering that on the > master branch, or on the igc branch without first applying the patch? Not on the master branch itself, I have to change the "5000" to "50000" in the marker code, which I don't think should cause this assertion violation. The reproducer script is the magit.bash script Helmut provided, this patch, and hitting C-p C-p C-n C-n when the magit window opens. diff --git a/src/marker.c b/src/marker.c index 4ab68ec7bbe..61f7af3f904 100644 --- a/src/marker.c +++ b/src/marker.c @@ -97,6 +97,7 @@ #define CONSIDER(CHARPOS, BYTEPOS)=09=09=09=09=09\ {=09=09=09=09=09=09=09=09=09\ ptrdiff_t this_charpos =3D (CHARPOS);=09=09=09=09=09\ bool changed =3D false;=09=09=09=09=09=09=09\ + considered++;=09=09=09=09=09=09=09=09\ =09=09=09=09=09=09=09=09=09\ if (this_charpos =3D=3D charpos)=09=09=09=09=09=09\ {=09=09=09=09=09=09=09=09=09\ @@ -194,6 +195,7 @@ buf_charpos_to_bytepos (struct buffer *b, ptrdiff_t cha= rpos) two best approximations is all single-byte, we interpolate the result immediately. */ =20 + ptrdiff_t considered =3D 0; CONSIDER (BUF_PT (b), BUF_PT_BYTE (b)); CONSIDER (BUF_GPT (b), BUF_GPT_BYTE (b)); CONSIDER (BUF_BEGV (b), BUF_BEGV_BYTE (b)); @@ -219,7 +221,10 @@ buf_charpos_to_bytepos (struct buffer *b, ptrdiff_t ch= arpos) eassert (best_below <=3D charpos && charpos <=3D best_above); if (charpos - best_below < best_above - charpos) { - bool record =3D charpos - best_below > 5000; + bool record =3D charpos - best_below > 50000; + + if (record) +=09fprintf (stderr, "recording (1) starting at %ld %ld %ld\n", best_below,= charpos, considered); =20 while (best_below < charpos) =09{ @@ -244,7 +249,10 @@ buf_charpos_to_bytepos (struct buffer *b, ptrdiff_t ch= arpos) } else { - bool record =3D best_above - charpos > 5000; + bool record =3D best_above - charpos > 50000; + + if (record) +=09fprintf (stderr, "recording (2) starting at %ld %ld %ld\n", charpos, be= st_above, considered); =20 while (best_above > charpos) =09{ @@ -278,6 +286,7 @@ #define CONSIDER(BYTEPOS, CHARPOS)=09=09=09=09=09\ {=09=09=09=09=09=09=09=09=09\ ptrdiff_t this_bytepos =3D (BYTEPOS);=09=09=09=09=09\ int changed =3D false;=09=09=09=09=09=09=09\ + considered++;=09=09=09=09=09=09=09=09\ =09=09=09=09=09=09=09=09=09\ if (this_bytepos =3D=3D bytepos)=09=09=09=09=09=09\ {=09=09=09=09=09=09=09=09=09\ @@ -342,6 +351,7 @@ buf_bytepos_to_charpos (struct buffer *b, ptrdiff_t byt= epos) best_below =3D BEG; best_below_byte =3D BEG_BYTE; =20 + ptrdiff_t considered =3D 0; CONSIDER (BUF_PT_BYTE (b), BUF_PT (b)); CONSIDER (BUF_GPT_BYTE (b), BUF_GPT (b)); CONSIDER (BUF_BEGV_BYTE (b), BUF_BEGV (b)); @@ -366,7 +376,10 @@ buf_bytepos_to_charpos (struct buffer *b, ptrdiff_t by= tepos) =20 if (bytepos - best_below_byte < best_above_byte - bytepos) { - bool record =3D bytepos - best_below_byte > 5000; + bool record =3D bytepos - best_below_byte > 50000; + + if (record) +=09fprintf (stderr, "recording (3) starting at %ld %ld %ld\n", bytepos, be= st_below_byte, considered); =20 while (best_below_byte < bytepos) =09{ @@ -393,8 +406,10 @@ buf_bytepos_to_charpos (struct buffer *b, ptrdiff_t by= tepos) } else { - bool record =3D best_above_byte - bytepos > 5000; + bool record =3D best_above_byte - bytepos > 50000; =20 + if (record) +=09fprintf (stderr, "recording (4) starting at %ld %ld %ld\n", bytepos, be= st_above_byte, considered); while (best_above_byte > bytepos) =09{ =09 best_above--; it looks like this: it =3D {window =3D 0x555557caa01d, w =3D 0x555557caa018, f =3D 0x55= 5555e74658, method =3D GET_FROM_BUFFER, stop_charpos =3D 27353858, prev_sto= p =3D 347705, base_level_stop =3D 0, end_charpos =3D 27353858, medium_narro= wing_begv =3D 27244404, medium_narrowing_zv =3D 27353858, large_narrowing_b= egv =3D 27103730, large_narrowing_zv =3D 27353858, s =3D 0x0, string_nchars= =3D 0, multibyte_p =3D true, tab_line_p =3D false, header_line_p =3D false= , string_from_display_prop_p =3D false, string_from_prefix_prop_p =3D false= , from_disp_prop_p =3D false, ellipsis_p =3D false, avoid_cursor_p =3D fals= e, dp =3D 0x0, dpvec =3D 0x0, dpend =3D 0x0, dpvec_char_len =3D 0, dpvec_fa= ce_id =3D 0, saved_face_id =3D 0, ctl_chars =3D {0x0 }, s= tart =3D {pos =3D {charpos =3D 347705, bytepos =3D 348476}, overlay_string_= index =3D -1, string_pos =3D {charpos =3D -1, bytepos =3D -1}, dpvec_index = =3D -1}, current =3D {pos =3D {charpos =3D 27353857, bytepos =3D 27355172},= overlay_string_index =3D -1, string_pos =3D {charpos =3D -1, bytepos =3D -= 1}, dpvec_index =3D -1}, n_overlay_strings =3D 0, overlay_strings_charpos = =3D 27353857, overlay_strings =3D {0x0 }, string_overlays= =3D {0x0 }, string =3D 0x0, from_overlay =3D 0x0, stack = =3D {{string =3D 0x0, string_nchars =3D 0, end_charpos =3D 0, stop_charpos = =3D 0, prev_stop =3D 0, base_level_stop =3D 0, cmp_it =3D {stop_pos =3D 0, = id =3D 0, ch =3D 0, rule_idx =3D 0, lookback =3D 0, nglyphs =3D 0, reversed= _p =3D false, parent_it =3D 0x0, charpos =3D 0, nchars =3D 0, nbytes =3D 0,= from =3D 0, to =3D 0, width =3D 0}, face_id =3D 0, u =3D {image =3D {objec= t =3D 0x0, slice =3D {x =3D 0x0, y =3D 0x0, width =3D 0x0, height =3D 0x0},= image_id =3D 0}, stretch =3D {object =3D 0x0}, xwidget =3D {object =3D 0x0= }}, position =3D {charpos =3D 0, bytepos =3D 0}, current =3D {pos =3D {char= pos =3D 0, bytepos =3D 0}, overlay_string_index =3D 0, string_pos =3D {char= pos =3D 0, bytepos =3D 0}, dpvec_index =3D 0}, from_overlay =3D 0x0, area = =3D LEFT_MARGIN_AREA, method =3D GET_FROM_BUFFER, paragraph_embedding =3D N= EUTRAL_DIR, multibyte_p =3D false, string_from_display_prop_p =3D false, st= ring_from_prefix_prop_p =3D false, display_ellipsis_p =3D false, avoid_curs= or_p =3D false, bidi_p =3D false, from_disp_prop_p =3D false, line_wrap =3D= TRUNCATE, voffset =3D 0, space_width =3D 0x0, font_height =3D 0x0}, {strin= g =3D 0x0, string_nchars =3D 0, end_charpos =3D 0, stop_charpos =3D 0, prev= _stop =3D 0, base_level_stop =3D 0, cmp_it =3D {stop_pos =3D 0, id =3D 0, c= h =3D 0, rule_idx =3D 0, lookback =3D 0, nglyphs =3D 0, reversed_p =3D fals= e, parent_it =3D 0x0, charpos =3D 0, nchars =3D 0, nbytes =3D 0, from =3D 0= , to =3D 0, width =3D 0}, face_id =3D 0, u =3D {image =3D {object =3D 0x0, = slice =3D {x =3D 0x0, y =3D 0x0, width =3D 0x0, height =3D 0x0}, image_id = =3D 0}, stretch =3D {object =3D 0x0}, xwidget =3D {object =3D 0x0}}, positi= on =3D {charpos =3D 0, bytepos =3D 0}, current =3D {pos =3D {charpos =3D 0,= bytepos =3D 0}, overlay_string_index =3D 0, string_pos =3D {charpos =3D 0,= bytepos =3D 0}, dpvec_index =3D 0}, from_overlay =3D 0x0, area =3D LEFT_MA= RGIN_AREA, method =3D GET_FROM_BUFFER, paragraph_embedding =3D NEUTRAL_DIR,= multibyte_p =3D false, string_from_display_prop_p =3D false, string_from_p= refix_prop_p =3D false, display_ellipsis_p =3D false, avoid_cursor_p =3D fa= lse, bidi_p =3D false, from_disp_prop_p =3D false, line_wrap =3D TRUNCATE, = voffset =3D 0, space_width =3D 0x0, font_height =3D 0x0}, {string =3D 0x0, = string_nchars =3D 0, end_charpos =3D 0, stop_charpos =3D 0, prev_stop =3D 0= , base_level_stop =3D 0, cmp_it =3D {stop_pos =3D 0, id =3D 0, ch =3D 0, ru= le_idx =3D 0, lookback =3D 0, nglyphs =3D 0, reversed_p =3D false, parent_i= t =3D 0x0, charpos =3D 0, nchars =3D 0, nbytes =3D 0, from =3D 0, to =3D 0,= width =3D 0}, face_id =3D 0, u =3D {image =3D {object =3D 0x0, slice =3D {= x =3D 0x0, y =3D 0x0, width =3D 0x0, height =3D 0x0}, image_id =3D 0}, stre= tch =3D {object =3D 0x0}, xwidget =3D {object =3D 0x0}}, position =3D {char= pos =3D 0, bytepos =3D 0}, current =3D {pos =3D {charpos =3D 0, bytepos =3D= 0}, overlay_string_index =3D 0, string_pos =3D {charpos =3D 0, bytepos =3D= 0}, dpvec_index =3D 0}, from_overlay =3D 0x0, area =3D LEFT_MARGIN_AREA, m= ethod =3D GET_FROM_BUFFER, paragraph_embedding =3D NEUTRAL_DIR, multibyte_p= =3D false, string_from_display_prop_p =3D false, string_from_prefix_prop_p= =3D false, display_ellipsis_p =3D false, avoid_cursor_p =3D false, bidi_p = =3D false, from_disp_prop_p =3D false, line_wrap =3D TRUNCATE, voffset =3D = 0, space_width =3D 0x0, font_height =3D 0x0}, {string =3D 0x0, string_nchar= s =3D 0, end_charpos =3D 0, stop_charpos =3D 0, prev_stop =3D 0, base_level= _stop =3D 0, cmp_it =3D {stop_pos =3D 0, id =3D 0, ch =3D 0, rule_idx =3D 0= , lookback =3D 0, nglyphs =3D 0, reversed_p =3D false, parent_it =3D 0x0, c= harpos =3D 0, nchars =3D 0, nbytes =3D 0, from =3D 0, to =3D 0, width =3D 0= }, face_id =3D 0, u =3D {image =3D {object =3D 0x0, slice =3D {x =3D 0x0, y= =3D 0x0, width =3D 0x0, height =3D 0x0}, image_id =3D 0}, stretch =3D {obj= ect =3D 0x0}, xwidget =3D {object =3D 0x0}}, position =3D {charpos =3D 0, b= ytepos =3D 0}, current =3D {pos =3D {charpos =3D 0, bytepos =3D 0}, overlay= _string_index =3D 0, string_pos =3D {charpos =3D 0, bytepos =3D 0}, dpvec_i= ndex =3D 0}, from_overlay =3D 0x0, area =3D LEFT_MARGIN_AREA, method =3D GE= T_FROM_BUFFER, paragraph_embedding =3D NEUTRAL_DIR, multibyte_p =3D false, = string_from_display_prop_p =3D false, string_from_prefix_prop_p =3D false, = display_ellipsis_p =3D false, avoid_cursor_p =3D false, bidi_p =3D false, f= rom_disp_prop_p =3D false, line_wrap =3D TRUNCATE, voffset =3D 0, space_wid= th =3D 0x0, font_height =3D 0x0}, {string =3D 0x0, string_nchars =3D 0, end= _charpos =3D 0, stop_charpos =3D 0, prev_stop =3D 0, base_level_stop =3D 0,= cmp_it =3D {stop_pos =3D 0, id =3D 0, ch =3D 0, rule_idx =3D 0, lookback = =3D 0, nglyphs =3D 0, reversed_p =3D false, parent_it =3D 0x0, charpos =3D = 0, nchars =3D 0, nbytes =3D 0, from =3D 0, to =3D 0, width =3D 0}, face_id = =3D 0, u =3D {image =3D {object =3D 0x0, slice =3D {x =3D 0x0, y =3D 0x0, w= idth =3D 0x0, height =3D 0x0}, image_id =3D 0}, stretch =3D {object =3D 0x0= }, xwidget =3D {object =3D 0x0}}, position =3D {charpos =3D 0, bytepos =3D = 0}, current =3D {pos =3D {charpos =3D 0, bytepos =3D 0}, overlay_string_ind= ex =3D 0, string_pos =3D {charpos =3D 0, bytepos =3D 0}, dpvec_index =3D 0}= , from_overlay =3D 0x0, area =3D LEFT_MARGIN_AREA, method =3D GET_FROM_BUFF= ER, paragraph_embedding =3D NEUTRAL_DIR, multibyte_p =3D false, string_from= _display_prop_p =3D false, string_from_prefix_prop_p =3D false, display_ell= ipsis_p =3D false, avoid_cursor_p =3D false, bidi_p =3D false, from_disp_pr= op_p =3D false, line_wrap =3D TRUNCATE, voffset =3D 0, space_width =3D 0x0,= font_height =3D 0x0}}, sp =3D 0, selective =3D 0, what =3D IT_CHARACTER, f= ace_id =3D 0, selective_display_ellipsis_p =3D true, ctl_arrow_p =3D true, = face_box_p =3D false, start_of_box_run_p =3D false, end_of_box_run_p =3D fa= lse, overlay_strings_at_end_processed_p =3D false, ignore_overlay_strings_a= t_pos_p =3D false, glyph_not_available_p =3D false, starts_in_middle_of_cha= r_p =3D false, face_before_selective_p =3D false, constrain_row_ascent_desc= ent_p =3D false, line_number_produced_p =3D false, align_visually_p =3D fal= se, line_wrap =3D TRUNCATE, base_face_id =3D 0, c =3D 10, len =3D 0, cmp_it= =3D {stop_pos =3D 27353857, id =3D -1, ch =3D -2, rule_idx =3D 0, lookback= =3D 0, nglyphs =3D 0, reversed_p =3D false, parent_it =3D 0x7fffffffb8f0, = charpos =3D 0, nchars =3D 0, nbytes =3D 0, from =3D 0, to =3D 0, width =3D = 0}, char_to_display =3D 0, glyphless_method =3D GLYPHLESS_DISPLAY_THIN_SPAC= E, image_id =3D 0, xwidget =3D 0x0, slice =3D {x =3D 0x0, y =3D 0x0, width = =3D 0x0, height =3D 0x0}, space_width =3D 0x0, voffset =3D 0, tab_width =3D= 8, font_height =3D 0x0, object =3D 0x555557cdf2bd, position =3D {charpos = =3D 27353857, bytepos =3D 27355172}, truncation_pixel_width =3D 9, continua= tion_pixel_width =3D 0, first_visible_x =3D 0, last_visible_x =3D 1881, las= t_visible_y =3D 1836, extra_line_spacing =3D 0, max_extra_line_spacing =3D = 0, override_ascent =3D -1, override_descent =3D 0, override_boff =3D 0, gly= ph_row =3D 0x0, area =3D TEXT_AREA, nglyphs =3D 1, pixel_width =3D 0, ascen= t =3D 0, descent =3D 0, max_ascent =3D 0, max_descent =3D 0, phys_ascent = =3D 0, phys_descent =3D 0, max_phys_ascent =3D 0, max_phys_descent =3D 0, c= urrent_x =3D 0, wrap_prefix_width =3D 0, continuation_lines_width =3D 0, eo= l_pos =3D {charpos =3D 0, bytepos =3D 0}, current_y =3D 396, first_vpos =3D= 0, vpos =3D 22, hpos =3D 0, lnum =3D 0, lnum_bytepos =3D 0, lnum_width =3D= 0, lnum_pixel_width =3D 0, pt_lnum =3D 0, stretch_adjust =3D 0, left_user_= fringe_bitmap =3D 0, right_user_fringe_bitmap =3D 0, left_user_fringe_face_= id =3D 0, right_user_fringe_face_id =3D 0, bidi_p =3D true, bidi_it =3D {by= tepos =3D 27355172, charpos =3D 27353857, ch =3D 10, nchars =3D 1, ch_len = =3D 1, type =3D NEUTRAL_B, type_after_wn =3D NEUTRAL_B, orig_type =3D NEUTR= AL_B, resolved_level =3D 0 '\000', isolate_level =3D 0 '\000', invalid_leve= ls =3D 0, invalid_isolates =3D 0, prev =3D {charpos =3D 0, type =3D UNKNOWN= _BT, orig_type =3D UNKNOWN_BT}, last_strong =3D {charpos =3D 0, type =3D UN= KNOWN_BT, orig_type =3D UNKNOWN_BT}, next_for_neutral =3D {charpos =3D -1, = type =3D UNKNOWN_BT, orig_type =3D UNKNOWN_BT}, prev_for_neutral =3D {charp= os =3D -1, type =3D UNKNOWN_BT, orig_type =3D UNKNOWN_BT}, next_for_ws =3D = {charpos =3D 0, type =3D UNKNOWN_BT, orig_type =3D UNKNOWN_BT}, bracket_pai= ring_pos =3D -1, bracket_enclosed_type =3D UNKNOWN_BT, next_en_pos =3D 0, n= ext_en_type =3D UNKNOWN_BT, sos =3D L2R, scan_dir =3D 0, disp_pos =3D -1, d= isp_prop =3D 0, stack_idx =3D 0, level_stack =3D {{next_for_neutral_pos =3D= 0, next_for_neutral_type =3D 0, last_strong_type =3D 0, prev_for_neutral_t= ype =3D 0, level =3D 0 '\000', flags =3D 0 '\000'} }, st= ring =3D {lstring =3D 0x0, s =3D 0x0, schars =3D 0, bufpos =3D 0, from_disp= _str =3D false, unibyte =3D false}, w =3D 0x555557caa018, paragraph_dir =3D= NEUTRAL_DIR, separator_limit =3D -1, first_elt =3D false, new_paragraph = =3D true, frame_window_p =3D true}, paragraph_embedding =3D NEUTRAL_DIR, mi= n_width_property =3D 0x0, min_width_start =3D 0} Should this combination ever be valid? it->what =3D IT_CHARACTER it->c =3D 10 it->len =3D 0 >> It seems to me like a bug in the xdisp.c code, but it's xdisp.c, so >> who knows? > > I suspect it->len is not used when the character is composed, because The character isn't composed, is it? It's a plain newline. >> -=09it->c =3D STRING_CHAR (s); >> +=09{ >> +=09 it->c =3D STRING_CHAR (s); >> +=09 it->len =3D CHAR_BYTES (it->c); >> +=09} > > This is sub-optimal; please use string_char_and_length instead. Will do, if we need to fix this at all. >> @@ -6724,6 +6730,7 @@ handle_composition_prop (struct it *it) >> pos_byte =3D IT_BYTEPOS (*it); >> string =3D Qnil; >> it->c =3D FETCH_CHAR (pos_byte); >> + it->len =3D it->multibyte_p ? CHAR_BYTES (it->c) : 1; > > Likewise here. I was looking for fetch_char_and_length, but I guess string_char_and_length (BYTE_POS_ADDR (pos_byte), &it->len) works, too? I'll try reducing the patch to just the 5000 -> 50000 thing next. Pip From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 03 10:33:37 2025 Received: (at 76538) by debbugs.gnu.org; 3 Mar 2025 15:33:37 +0000 Received: from localhost ([127.0.0.1]:50095 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tp7nU-0004ZE-LW for submit@debbugs.gnu.org; Mon, 03 Mar 2025 10:33:37 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:60132) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tp7nS-0004Yy-2s for 76538@debbugs.gnu.org; Mon, 03 Mar 2025 10:33:35 -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 1tp7nL-0005yl-45; Mon, 03 Mar 2025 10:33:27 -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=KohJG1YDsBPL+sr0aza7NQOanJypbiGWfh5yXp7ZMrI=; b=kxSj2kqebD60 O2TbDH7+MNm/E04RR910/qk3MYf3Igc4exNETLxjv2pxDMbtbXFbEGMfHmqeYVsWEDO+WPjy2ICCM y3LolE0zUpzkuQ7NyrxLRd2+CZ+swPnCiDEqfe75gqT2Q1KvxeYIpYXvZ7qFR3qf/VMBLyqhtwchq LzpoXpDydH2fNLjfUL0vz9o+OGS5i9MZC2byGYK18WRPXiARXCrKbr5jYlYmoh22SmkRKjEcuF4El NlIc+E6esmunjDedGSHjR4rMQYdkf7D8AmD27P/NGGM53pWV6kQJLEWiPcCcNZSwvZ/PFtX+e2i7h h0wNn1hIDgQr9ULiMDSjCQ==; Date: Mon, 03 Mar 2025 17:33:23 +0200 Message-Id: <86ikoqku2k.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <8734fuxjcv.fsf@protonmail.com> (message from Pip Cet on Mon, 03 Mar 2025 14:46:55 +0000) Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. References: <87ikoyetgi.fsf@gmx.se> <87eczgznye.fsf@gmail.com> <87zfi2y0br.fsf@gmail.com> <87pliyxy1r.fsf@gmail.com> <87tt8axuod.fsf@protonmail.com> <86y0xmkxrn.fsf@gnu.org> <8734fuxjcv.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76538 Cc: yantar92@posteo.net, eller.helmut@gmail.com, gerd.moellmann@gmail.com, monnier@iro.umontreal.ca, joaomoreira@gmx.se, 76538@debbugs.gnu.org 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 (---) > Date: Mon, 03 Mar 2025 14:46:55 +0000 > From: Pip Cet > Cc: gerd.moellmann@gmail.com, eller.helmut@gmail.com, monnier@iro.umontreal.ca, yantar92@posteo.net, joaomoreira@gmx.se, 76538@debbugs.gnu.org > > Should this combination ever be valid? > > it->what = IT_CHARACTER > it->c = 10 > it->len = 0 > > >> It seems to me like a bug in the xdisp.c code, but it's xdisp.c, so > >> who knows? > > > > I suspect it->len is not used when the character is composed, because > > The character isn't composed, is it? It's a plain newline. AFAIR, the value of it->len for a newline is never used, because we are at the end of a line, and will then jump to the next visible line anyway (or stop iteration altogether). Which is not to say I'm against the changes, I'm just trying to explain why it never caused us any assertion violations till now. > >> - it->c = STRING_CHAR (s); > >> + { > >> + it->c = STRING_CHAR (s); > >> + it->len = CHAR_BYTES (it->c); > >> + } > > > > This is sub-optimal; please use string_char_and_length instead. > > Will do, if we need to fix this at all. > > >> @@ -6724,6 +6730,7 @@ handle_composition_prop (struct it *it) > >> pos_byte = IT_BYTEPOS (*it); > >> string = Qnil; > >> it->c = FETCH_CHAR (pos_byte); > >> + it->len = it->multibyte_p ? CHAR_BYTES (it->c) : 1; > > > > Likewise here. > > I was looking for fetch_char_and_length, but I guess > string_char_and_length (BYTE_POS_ADDR (pos_byte), &it->len) works, too? Yes. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 03 10:54:20 2025 Received: (at 76538) by debbugs.gnu.org; 3 Mar 2025 15:54:20 +0000 Received: from localhost ([127.0.0.1]:50323 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tp87X-0006IZ-Bg for submit@debbugs.gnu.org; Mon, 03 Mar 2025 10:54:19 -0500 Received: from mail-40131.protonmail.ch ([185.70.40.131]:21257) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tp87T-0006Hi-TG for 76538@debbugs.gnu.org; Mon, 03 Mar 2025 10:54:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1741017248; x=1741276448; bh=HMcNXxhV11mNyEleqCy30t/QlymJkIR5NbjMpyd7tbM=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=hZH35gg16jJm6MHKYNPR+R9yyiS1aALrkzWEAnClz3tI1ojb1zFcHufyejFvJRD69 K6+Tvnr2VDvVuKxsCqOdB8a2gUWwj0GoHfJDggL+FH+NXE6R7cwHOxfefnnbhldSMr x42dxihEWNa6OrQbUj7NGnTNbrwXKkRmZL/dboluMJJNt2LqRd1rQLw0WNt3iT//tP rbI5wNXg3oNoWpSqX55hqrQ77bjFT3PH975n3l2OBIwa5d8dD8O5fA/HEPq8OY28Iy wfLEb8zll6iiqBwX8c/P4qlgE9TjqXx263xM0RuE5ctDXtclqBx6KDE0iHe4OCebck CwjUrKXseblgg== Date: Mon, 03 Mar 2025 15:54:02 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. Message-ID: <87pliyw1ol.fsf@protonmail.com> In-Reply-To: <86ikoqku2k.fsf@gnu.org> References: <87ikoyetgi.fsf@gmx.se> <87zfi2y0br.fsf@gmail.com> <87pliyxy1r.fsf@gmail.com> <87tt8axuod.fsf@protonmail.com> <86y0xmkxrn.fsf@gnu.org> <8734fuxjcv.fsf@protonmail.com> <86ikoqku2k.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 5d1e464bf19752bd7414359ec0c551cbf25abd68 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: 76538 Cc: yantar92@posteo.net, eller.helmut@gmail.com, gerd.moellmann@gmail.com, monnier@iro.umontreal.ca, joaomoreira@gmx.se, 76538@debbugs.gnu.org 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 (-) "Eli Zaretskii" writes: >> Date: Mon, 03 Mar 2025 14:46:55 +0000 >> From: Pip Cet >> Cc: gerd.moellmann@gmail.com, eller.helmut@gmail.com, monnier@iro.umontr= eal.ca, yantar92@posteo.net, joaomoreira@gmx.se, 76538@debbugs.gnu.org >> >> Should this combination ever be valid? >> >> it->what =3D IT_CHARACTER >> it->c =3D 10 >> it->len =3D 0 >> >> >> It seems to me like a bug in the xdisp.c code, but it's xdisp.c, so >> >> who knows? >> > >> > I suspect it->len is not used when the character is composed, because >> >> The character isn't composed, is it? It's a plain newline. > > AFAIR, the value of it->len for a newline is never used, because we > are at the end of a line, and will then jump to the next visible line > anyway (or stop iteration altogether). The way I read set_iterator_to_next: set_iterator_to_next (struct it *it, bool reseat_p) { if (max_redisplay_ticks > 0) update_redisplay_ticks (1, it->w); switch (it->method) { case GET_FROM_BUFFER: /* The current display element of IT is a character from =09 current_buffer. Advance in the buffer, and maybe skip over =09 invisible lines that are so because of selective display. */ if (ITERATOR_AT_END_OF_LINE_P (it) && reseat_p) =09reseat_at_next_visible_line_start (it, false); ... else { =09 eassert (it->len !=3D 0); it depends on the value of reseat_p, which is false in my case, where it's called from here: if (it->what =3D=3D IT_CHARACTER && it->c =3D=3D '\n' && CHARPOS (it->position) =3D=3D IT_CHARPOS (*it)) { if (it->bidi_p && bidi_it_prev) =09*bidi_it_prev =3D it->bidi_it; set_iterator_to_next (it, false); it->c =3D 0; return true; } > Which is not to say I'm against the changes, I'm just trying to > explain why it never caused us any assertion violations till now. Thank you very much, I appreciate that! I too wonder how creating fewer cache markers somehow causes us to run into a problem that the master branch (with one marker per 5000 chars) doesn't, and we should try to understand that before considering whether to skip over long Qinvisible sections in back_to_previous_line_start etc, IMHO (it makes magit more usable but I'm not really comfortable suggesting changes to that code given my current (lack of) understanding). Pip From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 03 11:43:57 2025 Received: (at 76538) by debbugs.gnu.org; 3 Mar 2025 16:43:57 +0000 Received: from localhost ([127.0.0.1]:50780 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tp8tZ-00028l-1Q for submit@debbugs.gnu.org; Mon, 03 Mar 2025 11:43:57 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45954) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tp8tV-00028J-9x for 76538@debbugs.gnu.org; Mon, 03 Mar 2025 11:43:54 -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 1tp8tO-0001L5-9q; Mon, 03 Mar 2025 11:43:46 -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=OyvwGN7wh1ILW3hdq+vl86o89lw1XEATYX7opUcZto4=; b=rO5gyG2b6Fcv oEZx6PO+k71a1l+Ft+4MI/RRvEwFaO7sV6yQEokzL+q2s1VtQusGuA19EOnDcW0WbGLqDoDwVQcFw vJXe+QV8LrSzHEE4K8Qfcoou3KjBNqUxvs9cMBYzRcASCzfT725whxVdjxAzRnoio1Biy47oo4hQv ojk0Ez8ZmbD8FAzJ3rdBFUZoAD+nJIwViYI3+Glvn++BTxX7V8rk6oZoO2+B5VEKR3JQVOmuwXbmR tbskkT2o6HcEK1YCTSZNBlfcikwNnRhCAbHbCXrHSuMvpiQekWBfEM86flhenOUx49SvlpRvkwgA8 /+4CGTrIb4GMPkAiZ2n3nA==; Date: Mon, 03 Mar 2025 18:43:40 +0200 Message-Id: <864j0akqtf.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87pliyw1ol.fsf@protonmail.com> (message from Pip Cet on Mon, 03 Mar 2025 15:54:02 +0000) Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. References: <87ikoyetgi.fsf@gmx.se> <87zfi2y0br.fsf@gmail.com> <87pliyxy1r.fsf@gmail.com> <87tt8axuod.fsf@protonmail.com> <86y0xmkxrn.fsf@gnu.org> <8734fuxjcv.fsf@protonmail.com> <86ikoqku2k.fsf@gnu.org> <87pliyw1ol.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76538 Cc: yantar92@posteo.net, eller.helmut@gmail.com, gerd.moellmann@gmail.com, monnier@iro.umontreal.ca, joaomoreira@gmx.se, 76538@debbugs.gnu.org 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 (---) > Date: Mon, 03 Mar 2025 15:54:02 +0000 > From: Pip Cet > Cc: gerd.moellmann@gmail.com, eller.helmut@gmail.com, monnier@iro.umontreal.ca, yantar92@posteo.net, joaomoreira@gmx.se, 76538@debbugs.gnu.org > > "Eli Zaretskii" writes: > > > AFAIR, the value of it->len for a newline is never used, because we > > are at the end of a line, and will then jump to the next visible line > > anyway (or stop iteration altogether). > > The way I read set_iterator_to_next: > > set_iterator_to_next (struct it *it, bool reseat_p) > { > > if (max_redisplay_ticks > 0) > update_redisplay_ticks (1, it->w); > > switch (it->method) > { > case GET_FROM_BUFFER: > /* The current display element of IT is a character from > current_buffer. Advance in the buffer, and maybe skip over > invisible lines that are so because of selective display. */ > if (ITERATOR_AT_END_OF_LINE_P (it) && reseat_p) > reseat_at_next_visible_line_start (it, false); > ... > else > { > eassert (it->len != 0); > > it depends on the value of reseat_p, which is false in my case, where > it's called from here: > > if (it->what == IT_CHARACTER > && it->c == '\n' > && CHARPOS (it->position) == IT_CHARPOS (*it)) > { > if (it->bidi_p && bidi_it_prev) > *bidi_it_prev = it->bidi_it; > set_iterator_to_next (it, false); > it->c = 0; > return true; > } I meant this place in display_line, which is where we handle display iteration that reaches EOL: if (ITERATOR_AT_END_OF_LINE_P (it)) { int used_before = row->used[TEXT_AREA]; [...] /* Consume the line end. This skips over invisible lines. */ set_iterator_to_next (it, true); <<<<<<<<<<<<<<<<<<<< it->continuation_lines_width = 0; break; } As for the call with 'false' as 2nd arg: First, when it->bidi_p is true, we don't use it->len for moving to the next display element. And second, this place (and another similar to it) are in functions that are used to jump far away, so they are always followed by a call to 'reseat'. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 03 12:07:20 2025 Received: (at 76538) by debbugs.gnu.org; 3 Mar 2025 17:07:20 +0000 Received: from localhost ([127.0.0.1]:51018 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tp9GA-0003w6-Kp for submit@debbugs.gnu.org; Mon, 03 Mar 2025 12:07:20 -0500 Received: from mail-4322.protonmail.ch ([185.70.43.22]:43383) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tp9G5-0003v4-5S for 76538@debbugs.gnu.org; Mon, 03 Mar 2025 12:07:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1741021625; x=1741280825; bh=CedHmVtrSm9ydTelVheBfsVAaaJdtM1JH7OJrEz42z8=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=uCr9oS1eBCKAA1QD/rkItAlELKcGCZ78CIB6hu52A4d6T2zKjWBVDTr8gmXEERwE/ MiZKkWuhJ+kwkY2+kXKAswWrLo/3GjfI5CyxBAvlnz0adV3UxuRAiyW9C98BUGdPfb l6taWZjuzlLXiQX3hAsNYRue+vN0Z9o/z7EFHWuaPkU36JyS+lnh2ouxsc0QlGmxWX zvuYRLd/USyCh+slrjFACbI+C42w0/+er1USrGAl0n77gfK3s3TUyttU+jLKYcB5R2 SDsWf1vhA2zjZ1jrtSgtPskiY4nXX9Iw1MO8aVHj8ztbO3c9pyqhUBtirxRe9BZvoE uhcj9SggMx8zQ== Date: Mon, 03 Mar 2025 17:07:02 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. Message-ID: <87r03e9h7s.fsf@protonmail.com> In-Reply-To: <864j0akqtf.fsf@gnu.org> References: <87ikoyetgi.fsf@gmx.se> <87pliyxy1r.fsf@gmail.com> <87tt8axuod.fsf@protonmail.com> <86y0xmkxrn.fsf@gnu.org> <8734fuxjcv.fsf@protonmail.com> <86ikoqku2k.fsf@gnu.org> <87pliyw1ol.fsf@protonmail.com> <864j0akqtf.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: ebe00f62bfe2ae7b713f459ceabc93de8bfecb4f 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: 76538 Cc: yantar92@posteo.net, eller.helmut@gmail.com, gerd.moellmann@gmail.com, monnier@iro.umontreal.ca, joaomoreira@gmx.se, 76538@debbugs.gnu.org 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 (-) "Eli Zaretskii" writes: >> Date: Mon, 03 Mar 2025 15:54:02 +0000 >> From: Pip Cet >> Cc: gerd.moellmann@gmail.com, eller.helmut@gmail.com, monnier@iro.umontr= eal.ca, yantar92@posteo.net, joaomoreira@gmx.se, 76538@debbugs.gnu.org >> >> "Eli Zaretskii" writes: >> >> > AFAIR, the value of it->len for a newline is never used, because we >> > are at the end of a line, and will then jump to the next visible line >> > anyway (or stop iteration altogether). >> >> The way I read set_iterator_to_next: >> >> set_iterator_to_next (struct it *it, bool reseat_p) >> { >> >> if (max_redisplay_ticks > 0) >> update_redisplay_ticks (1, it->w); >> >> switch (it->method) >> { >> case GET_FROM_BUFFER: >> /* The current display element of IT is a character from >> =09 current_buffer. Advance in the buffer, and maybe skip over >> =09 invisible lines that are so because of selective display. */ >> if (ITERATOR_AT_END_OF_LINE_P (it) && reseat_p) >> =09reseat_at_next_visible_line_start (it, false); >> ... >> else >> { >> =09 eassert (it->len !=3D 0); >> >> it depends on the value of reseat_p, which is false in my case, where >> it's called from here: >> >> if (it->what =3D=3D IT_CHARACTER >> && it->c =3D=3D '\n' >> && CHARPOS (it->position) =3D=3D IT_CHARPOS (*it)) >> { >> if (it->bidi_p && bidi_it_prev) >> =09*bidi_it_prev =3D it->bidi_it; >> set_iterator_to_next (it, false); >> it->c =3D 0; >> return true; >> } > > I meant this place in display_line, which is where we handle display > iteration that reaches EOL: > > if (ITERATOR_AT_END_OF_LINE_P (it)) > =09{ > =09 int used_before =3D row->used[TEXT_AREA]; > =09 [...] > =09 /* Consume the line end. This skips over invisible lines. */ > =09 set_iterator_to_next (it, true); <<<<<<<<<<<<<<<<<<<< > =09 it->continuation_lines_width =3D 0; > =09 break; > =09} > > As for the call with 'false' as 2nd arg: First, when it->bidi_p is > true, we don't use it->len for moving to the next display element. True. Moving the eassert inside the if might be the minimal change there. > And second, this place (and another similar to it) are in functions > that are used to jump far away, so they are always followed by a call > to 'reseat'. (gdb) bt #0 0x00007ffff5b38e3c in ??? () at /lib64/libc.so.6 #1 0x00007ffff5ae2da6 in raise () at /lib64/libc.so.6 #2 0x000055555578ac0f in terminate_due_to_signal (sig=3D6, backtrace_limit= =3D2147483647) at emacs.c:462 #3 0x0000555555842adb in die (msg=3D0x5555559ab358 "it->len !=3D 0", file= =3D0x5555559aa5d7 "xdisp.c", line=3D8823) at alloc.c:7444 #4 0x00005555555f7b8c in set_iterator_to_next (it=3D0x7fffffffb8e0, reseat= _p=3Dfalse) at xdisp.c:8823 #5 0x00005555555f4040 in forward_to_next_line_start (it=3D0x7fffffffb8e0, = skipped_p=3D0x7fffffffae9e, bidi_it_prev=3D0x0) at xdisp.c:7541 #6 0x00005555555f4e57 in reseat_at_next_visible_line_start (it=3D0x7ffffff= fb8e0, on_newline_p=3Dfalse) at xdisp.c:7781 #7 0x0000555555611609 in redisplay_internal () at xdisp.c:17408 #8 0x000055555560f596 in redisplay () at xdisp.c:16672 #9 0x0000555555797f4e in read_char (commandflag=3D1, map=3D0x555557f08453,= prev_event=3D0x0, used_mouse_menu=3D0x7fffffffd025, end_time=3D0x0) at key= board.c:2672 #10 0x00005555557acd81 in read_key_sequence (keybuf=3D0x7fffffffd2a0, prompt=3D0x0, dont_downcase_last=3Dfalse, can= _return_switch_frame=3Dtrue, fix_current_buffer=3Dtrue, prevent_redisplay= =3Dfalse, disable_text_conversion_p=3Dfalse) at keyboard.c:10757 #11 0x0000555555793fb4 in command_loop_1 () at keyboard.c:1424 #12 0x000055555587bb35 in internal_condition_case (bfun=3D0x555555793b66 , handlers=3D0x90, hfun=3D0x555555792f64 ) at eval= .c:1602 #13 0x0000555555793710 in command_loop_2 (handlers=3D0x90) at keyboard.c:11= 63 #14 0x000055555587af29 in internal_catch (tag=3D0x12420, func=3D0x555555793= 6e2 , arg=3D0x90) at eval.c:1282 #15 0x000055555579369e in command_loop () at keyboard.c:1141 #16 0x00005555557929e6 in recursive_edit_1 () at keyboard.c:749 #17 0x0000555555792c1a in Frecursive_edit () at keyboard.c:832 #18 0x000055555578e1d8 in main (argc=3D4, argv=3D0x7fffffffd778) at emacs.c:2562 (gdb) bt full #0 0x00007ffff5b38e3c in ??? () at /lib64/libc.so.6 #1 0x00007ffff5ae2da6 in raise () at /lib64/libc.so.6 #2 0x000055555578ac0f in terminate_due_to_signal (sig=3D6, backtrace_limit= =3D2147483647) at emacs.c:462 #3 0x0000555555842adb in die (msg=3D0x5555559ab358 "it->len !=3D 0", file= =3D0x5555559aa5d7 "xdisp.c", line=3D8823) at alloc.c:7444 #4 0x00005555555f7b8c in set_iterator_to_next (it=3D0x7fffffffb8e0, reseat= _p=3Dfalse) at xdisp.c:8823 #5 0x00005555555f4040 in forward_to_next_line_start (it=3D0x7fffffffb8e0, = skipped_p=3D0x7fffffffae9e, bidi_it_prev=3D0x0) at xdisp.c:7541 old_selective =3D 0 newline_found_p =3D false n =3D 0 MAX_NEWLINE_DISTANCE =3D 500 #6 0x00005555555f4e57 in reseat_at_next_visible_line_start (it=3D0x7ffffff= fb8e0, on_newline_p=3Dfalse) at xdisp.c:7781 skipped_p =3D false bidi_it_prev =3D {bytepos =3D 35802240, charpos =3D 35802240, ch = =3D 314, nchars =3D 16, ch_len =3D 140737488334608, type =3D 1435070560, ty= pe_after_wn =3D 21845, orig_type =3D 4294946544, resolved_level =3D -1 '\37= 7', isolate_level =3D 127 '\177', invalid_levels =3D 38442363915953017, inv= alid_isolates =3D 93824998311872, prev =3D {charpos =3D 79200, type =3D 792= 00, orig_type =3D UNKNOWN_BT}, last_strong =3D {charpos =3D 79200, type =3D= 1433343524, orig_type =3D 21845}, next_for_neutral =3D {charpos =3D 33216,= type =3D 4294946624, orig_type =3D 32767}, prev_for_neutral =3D {charpos = =3D 93824993945891, type =3D 33216, orig_type =3D UNKNOWN_BT}, next_for_ws = =3D {charpos =3D 93825034033728, type =3D UNKNOWN_BT, orig_type =3D UNKNOWN= _BT}, bracket_pairing_pos =3D 33216, bracket_enclosed_type =3D 4294946672, = next_en_pos =3D 93825034033725, next_en_type =3D 4294946704, sos =3D (L2R |= R2L | unknown: 0x7ffc), scan_dir =3D 1433347019, disp_pos =3D 0, disp_prop= =3D 1473452605, stack_idx =3D 21845, level_stack =3D {{next_for_neutral_po= s =3D 140737488334768, next_for_neutral_type =3D 0, last_strong_type =3D 7,= prev_for_neutral_type =3D 0, level =3D 211 '\323', flags =3D 87 'W'}, {nex= t_for_neutral_pos =3D 93824998232672, next_for_neutral_type =3D 0, last_str= ong_type =3D 0, prev_for_neutral_type =3D 0, level =3D 0 '\000', flags =3D = 0 '\000'}, {next_for_neutral_pos =3D 0, next_for_neutral_type =3D 0, last_s= trong_type =3D 6, prev_for_neutral_type =3D 6, level =3D 255 '\377', flags = =3D 255 '\377'}, {next_for_neutral_pos =3D 93824993924644, next_for_neutral= _type =3D 5, last_strong_type =3D 7, prev_for_neutral_type =3D 0, level =3D= 211 '\323', flags =3D 87 'W'}, {next_for_neutral_pos =3D 140737488334832, = next_for_neutral_type =3D 2, last_strong_type =3D 5, prev_for_neutral_type = =3D 0, level =3D 111 'o', flags =3D 85 'U'}, {next_for_neutral_pos =3D 7920= 0, next_for_neutral_type =3D 0, last_strong_type =3D 4, prev_for_neutral_ty= pe =3D 7, level =3D 255 '\377', flags =3D 255 '\377'}, {next_for_neutral_po= s =3D 93824998232672, next_for_neutral_type =3D 0, last_strong_type =3D 0, = prev_for_neutral_type =3D 0, level =3D 0 '\000', flags =3D 0 '\000'}, {next= _for_neutral_pos =3D 0, next_for_neutral_type =3D 0, last_strong_type =3D 0= , prev_for_neutral_type =3D 0, level =3D 255 '\377', flags =3D 255 '\377'},= {next_for_neutral_pos =3D 93824993924644, next_for_neutral_type =3D 0, las= t_strong_type =3D 2, prev_for_neutral_type =3D 0, level =3D 0 '\000', flags= =3D 0 '\000'}, {next_for_neutral_pos =3D 140737488334960, next_for_neutral= _type =3D 1, last_strong_type =3D 3, prev_for_neutral_type =3D 0, level =3D= 111 'o', flags =3D 85 'U'}, {next_for_neutral_pos =3D 140737488335088, nex= t_for_neutral_type =3D 0, last_strong_type =3D 2, prev_for_neutral_type =3D= 3, level =3D 255 '\377', flags =3D 255 '\377'}, {next_for_neutral_pos =3D = 140737488336208, next_for_neutral_type =3D 0, last_strong_type =3D 6, prev_= for_neutral_type =3D 3, level =3D 255 '\377', flags =3D 255 '\377'}, {next_= for_neutral_pos =3D 93825001920248, next_for_neutral_type =3D 0, last_stron= g_type =3D 5, prev_for_neutral_type =3D 3, level =3D 229 '\345', flags =3D = 87 'W'}, {next_for_neutral_pos =3D 87337062896, next_for_neutral_type =3D 0= , last_strong_type =3D 0, prev_for_neutral_type =3D 0, level =3D 0 '\000', = flags =3D 0 '\000'}, {next_for_neutral_pos =3D 65424, next_for_neutral_type= =3D 0, last_strong_type =3D 6, prev_for_neutral_type =3D 0, level =3D 0 '\= 000', flags =3D 0 '\000'}, {next_for_neutral_pos =3D 93824993924644, next_f= or_neutral_type =3D 0, last_strong_type =3D 2, prev_for_neutral_type =3D 0,= level =3D 0 '\000', flags =3D 0 '\000'}, {next_for_neutral_pos =3D 1407374= 88335280, next_for_neutral_type =3D 0, last_strong_type =3D 2, prev_for_neu= tral_type =3D 6, level =3D 111 'o', flags =3D 85 'U'}, {next_for_neutral_po= s =3D 0, next_for_neutral_type =3D 0, last_strong_type =3D 2, prev_for_neut= ral_type =3D 3, level =3D 255 '\377', flags =3D 255 '\377'}, {next_for_neut= ral_pos =3D 140737488336208, next_for_neutral_type =3D 0, last_strong_type = =3D 0, prev_for_neutral_type =3D 2, level =3D 34 '"', flags =3D 2 '\002'}, = {next_for_neutral_pos =3D 93825001920248, next_for_neutral_type =3D 0, last= _strong_type =3D 5, prev_for_neutral_type =3D 3, level =3D 229 '\345', flag= s =3D 87 'W'}, {next_for_neutral_pos =3D 0, next_for_neutral_type =3D 0, la= st_strong_type =3D 0, prev_for_neutral_type =3D 0, level =3D 0 '\000', flag= s =3D 1 '\001'}, {next_for_neutral_pos =3D 93825006600960, next_for_neutral= _type =3D 0, last_strong_type =3D 0, prev_for_neutral_type =3D 0, level =3D= 0 '\000', flags =3D 0 '\000'}, {next_for_neutral_pos =3D 35802240, next_fo= r_neutral_type =3D 0, last_strong_type =3D 0, prev_for_neutral_type =3D 0, = level =3D 0 '\000', flags =3D 0 '\000'}, {next_for_neutral_pos =3D 0, next_= for_neutral_type =3D 0, last_strong_type =3D 0, prev_for_neutral_type =3D 0= , level =3D 0 '\000', flags =3D 0 '\000'}, {next_for_neutral_pos =3D 33216,= next_for_neutral_type =3D 0, last_strong_type =3D 4, prev_for_neutral_type= =3D 5, level =3D 1 '\001', flags =3D 0 '\000'}, {next_for_neutral_pos =3D = 79200, next_for_neutral_type =3D 0, last_strong_type =3D 4, prev_for_neutra= l_type =3D 5, level =3D 1 '\001', flags =3D 0 '\000'}, {next_for_neutral_po= s =3D 93825035534240, next_for_neutral_type =3D 1, last_strong_type =3D 0, = prev_for_neutral_type =3D 0, level =3D 0 '\000', flags =3D 0 '\000'}, {next= _for_neutral_pos =3D 140737488335184, next_for_neutral_type =3D 5, last_s--= Type for more, q to quit, c to continue without paging-- trong_type =3D 5, prev_for_neutral_type =3D 2, level =3D 148 '\224', flags = =3D 85 'U'}, {next_for_neutral_pos =3D 140737488335536, next_for_neutral_ty= pe =3D 0, last_strong_type =3D 4, prev_for_neutral_type =3D 7, level =3D 23= 1 '\347', flags =3D 87 'W'}, {next_for_neutral_pos =3D 93825035346400, next= _for_neutral_type =3D 0, last_strong_type =3D 4, prev_for_neutral_type =3D = 6, level =3D 233 '\351', flags =3D 87 'W'}, {next_for_neutral_pos =3D 14073= 7488335328, next_for_neutral_type =3D 2, last_strong_type =3D 7, prev_for_n= eutral_type =3D 4, level =3D 148 '\224', flags =3D 85 'U'}, {next_for_neutr= al_pos =3D 140737488335536, next_for_neutral_type =3D 0, last_strong_type = =3D 6, prev_for_neutral_type =3D 6, level =3D 242 '\362', flags =3D 87 'W'}= , {next_for_neutral_pos =3D 0, next_for_neutral_type =3D 0, last_strong_typ= e =3D 4, prev_for_neutral_type =3D 7, level =3D 231 '\347', flags =3D 87 'W= '}, {next_for_neutral_pos =3D 0, next_for_neutral_type =3D 0, last_strong_t= ype =3D 0, prev_for_neutral_type =3D 0, level =3D 0 '\000', flags =3D 0 '\0= 00'}, {next_for_neutral_pos =3D 93825035346400, next_for_neutral_type =3D 0= , last_strong_type =3D 0, prev_for_neutral_type =3D 0, level =3D 0 '\000', = flags =3D 0 '\000'}, {next_for_neutral_pos =3D 93825033678435, next_for_neu= tral_type =3D 0, last_strong_type =3D 0, prev_for_neutral_type =3D 0, level= =3D 0 '\000', flags =3D 0 '\000'}, {next_for_neutral_pos =3D 9382502821723= 2, next_for_neutral_type =3D 0, last_strong_type =3D 6, prev_for_neutral_ty= pe =3D 4, level =3D 122 'z', flags =3D 87 'W'}, {next_for_neutral_pos =3D 9= 3824998232672, next_for_neutral_type =3D 0, last_strong_type =3D 0, prev_fo= r_neutral_type =3D 0, level =3D 0 '\000', flags =3D 0 '\000'}, {next_for_ne= utral_pos =3D 0, next_for_neutral_type =3D 0, last_strong_type =3D 6, prev_= for_neutral_type =3D 7, level =3D 255 '\377', flags =3D 255 '\377'}, {next_= for_neutral_pos =3D 93824998232672, next_for_neutral_type =3D 0, last_stron= g_type =3D 0, prev_for_neutral_type =3D 0, level =3D 0 '\000', flags =3D 0 = '\000'}, {next_for_neutral_pos =3D 0, next_for_neutral_type =3D 0, last_str= ong_type =3D 2, prev_for_neutral_type =3D 0, level =3D 255 '\377', flags = =3D 255 '\377'}, {next_for_neutral_pos =3D 93824995578802, next_for_neutral= _type =3D 0, last_strong_type =3D 0, prev_for_neutral_type =3D 0, level =3D= 0 '\000', flags =3D 0 '\000'}, {next_for_neutral_pos =3D 140737488335456, = next_for_neutral_type =3D 2, last_strong_type =3D 0, prev_for_neutral_type = =3D 7, level =3D 136 '\210', flags =3D 85 'U'}, {next_for_neutral_pos =3D 9= 3825033678435, next_for_neutral_type =3D 0, last_strong_type =3D 4, prev_fo= r_neutral_type =3D 6, level =3D 0 '\000', flags =3D 0 '\000'}, {next_for_ne= utral_pos =3D 93824998232672, next_for_neutral_type =3D 0, last_strong_type= =3D 0, prev_for_neutral_type =3D 0, level =3D 0 '\000', flags =3D 0 '\000'= }, {next_for_neutral_pos =3D 0, next_for_neutral_type =3D 0, last_strong_ty= pe =3D 4, prev_for_neutral_type =3D 1, level =3D 255 '\377', flags =3D 255 = '\377'}, {next_for_neutral_pos =3D 93824996179882, next_for_neutral_type = =3D 1, last_strong_type =3D 0, prev_for_neutral_type =3D 0, level =3D 133 '= \205', flags =3D 85 'U'}, {next_for_neutral_pos =3D 93825035534240, next_fo= r_neutral_type =3D 1, last_strong_type =3D 0, prev_for_neutral_type =3D 0, = level =3D 0 '\000', flags =3D 0 '\000'}, {next_for_neutral_pos =3D 14073748= 8335520, next_for_neutral_type =3D 0, last_strong_type =3D 4, prev_for_neut= ral_type =3D 3, level =3D 0 '\000', flags =3D 0 '\000'}, {next_for_neutral_= pos =3D 140737488335520, next_for_neutral_type =3D 0, last_strong_type =3D = 5, prev_for_neutral_type =3D 5, level =3D 93 ']', flags =3D 85 'U'}, {next_= for_neutral_pos =3D 224, next_for_neutral_type =3D 0, last_strong_type =3D = 4, prev_for_neutral_type =3D 1, level =3D 87 'W', flags =3D 87 'W'}, {next_= for_neutral_pos =3D 140737488335568, next_for_neutral_type =3D 0, last_stro= ng_type =3D 3, prev_for_neutral_type =3D 1, level =3D 93 ']', flags =3D 85 = 'U'}, {next_for_neutral_pos =3D 140737488335568, next_for_neutral_type =3D = 0, last_strong_type =3D 4, prev_for_neutral_type =3D 3, level =3D 0 '\000',= flags =3D 0 '\000'}, {next_for_neutral_pos =3D 15264, next_for_neutral_typ= e =3D 0, last_strong_type =3D 6, prev_for_neutral_type =3D 0, level =3D 0 '= \000', flags =3D 0 '\000'}, {next_for_neutral_pos =3D 140737488336464, next= _for_neutral_type =3D 0, last_strong_type =3D 7, prev_for_neutral_type =3D = 1, level =3D 95 '_', flags =3D 85 'U'}, {next_for_neutral_pos =3D 27353857,= next_for_neutral_type =3D 0, last_strong_type =3D 4, prev_for_neutral_type= =3D 3, level =3D 255 '\377', flags =3D 255 '\377'}, {next_for_neutral_pos = =3D 4294967552, next_for_neutral_type =3D 0, last_strong_type =3D 4, prev_f= or_neutral_type =3D 3, level =3D 0 '\000', flags =3D 0 '\000'}, {next_for_n= eutral_pos =3D 0, next_for_neutral_type =3D 4, last_strong_type =3D 2, prev= _for_neutral_type =3D 0, level =3D 0 '\000', flags =3D 0 '\000'}, {next_for= _neutral_pos =3D 140737488335808, next_for_neutral_type =3D 0, last_strong_= type =3D 0, prev_for_neutral_type =3D 0, level =3D 0 '\000', flags =3D 0 '\= 000'}, {next_for_neutral_pos =3D 0, next_for_neutral_type =3D 0, last_stron= g_type =3D 0, prev_for_neutral_type =3D 0, level =3D 0 '\000', flags =3D 0 = '\000'}, {next_for_neutral_pos =3D 140737488335760, next_for_neutral_type = =3D 0, last_strong_type =3D 0, prev_for_neutral_type =3D 0, level =3D 0 '\0= 00', flags =3D 0 '\000'}, {next_for_neutral_pos =3D 93825047111837, next_fo= r_neutral_type =3D 1, last_strong_type =3D 7, prev_for_neutral_type =3D 0, = level =3D 5 '\005', flags =3D 0 '\000'}, {next_for_neutral_pos =3D 27353857= , next_for_neutral_type =3D 0, last_strong_type =3D 0, prev_for_neutral_typ= e =3D 0, level =3D 0 '\000', flags =3D 0 '\000'}, {next_for_neutral_pos =3D= 48, next_for_neutral_type =3D 0, last_strong_type =3D 0, prev_for_neutral_= type =3D 0, level =3D 0 '\000', flags =3D 0 '\000'}, {next_for_neutral_pos = =3D 0, next_for_neutral_type =3D 0, last_strong_type =3D 2, prev_for_neutra= l_type =3D 6, level =3D 255 '\377', flags =3D 255 '\377'}, {next_for_neutra= l_pos =3D 93824998232672, next_for_neutral_type =3D 0, last_strong_type =3D= 0, prev_for_neutral_type =3D 0, level =3D 0 '\000', flags =3D 0 '\000'}, {= next_for_neutral_pos =3D 0, next_for_neutral_type =3D 0, last_strong_type = =3D 0, prev_for_neutral_type =3D 4, level =3D 161 '\241', flags =3D 1 '\001= '}, {next_for_neutral_pos =3D 27353858, next_for_neutral_type =3D 1, last_s= trong_type =3D 0, prev_for_neutral_type =3D 0, level =3D 0 '\000', flags = =3D 0 '\000'}, {next_for_neutral_pos =3D 140733193388033, next_for_neutral_= type =3D 2, last_strong_type =3D 0, prev_for_neutral_type =3D 7, level =3D = 136 '\210', flags =3D 85 'U'}, {next_for_neutral_pos =3D 93825033678435, ne= xt_for_neutral_type =3D 0, last_strong_type =3D 4, prev_for_neutral_type = =3D 2, level =3D 0 '\000', flags =3D 0 '\000'}, {next_for_neutral_pos =3D 9= 3824998232672, next_for_neutral_type =3D 0, last_strong_type =3D 0, prev_fo= r_neutral_type =3D 0, level =3D 0 '\000', flags =3D 0 '\000'}, {next_for_ne= utral_pos =3D 0, next_for_neutral_type =3D 0, last_strong_type =3D 0, prev_= for_neutral_type =3D 0, level =3D 255 '\377', flags =3D 255 '\377'}, {next_= for_neutral_pos =3D 93824996179882, next_for_neutral_type =3D 1, last_stron= g_type =3D 0, prev_for_neutral_type =3D 0, level =3D 133 '\205', flags =3D = 85 'U'}, {next_for_neutral_pos =3D 140737488335952, next_for_neutral_type = =3D 0, last_strong_type =3D 5, prev_for_neutral_type =3D 6, level =3D 145 '= \221', flags =3D 85 'U'}--Type for more, q to quit, c to continue wit= hout paging-- , {next_for_neutral_pos =3D 27353857, next_for_neutral_type =3D 1, last_str= ong_type =3D 0, prev_for_neutral_type =3D 4, level =3D 161 '\241', flags = =3D 1 '\001'}, {next_for_neutral_pos =3D 46752, next_for_neutral_type =3D 3= , last_strong_type =3D 2, prev_for_neutral_type =3D 1, level =3D 240 '\360'= , flags =3D 87 'W'}, {next_for_neutral_pos =3D 0, next_for_neutral_type =3D= 0, last_strong_type =3D 0, prev_for_neutral_type =3D 0, level =3D 0 '\000'= , flags =3D 0 '\000'}, {next_for_neutral_pos =3D 140737488335984, next_for_= neutral_type =3D 0, last_strong_type =3D 4, prev_for_neutral_type =3D 2, le= vel =3D 0 '\000', flags =3D 0 '\000'}, {next_for_neutral_pos =3D 1407374883= 35984, next_for_neutral_type =3D 2, last_strong_type =3D 4, prev_for_neutra= l_type =3D 7, level =3D 145 '\221', flags =3D 85 'U'}, {next_for_neutral_po= s =3D 27353857, next_for_neutral_type =3D 3, last_strong_type =3D 2, prev_f= or_neutral_type =3D 1, level =3D 240 '\360', flags =3D 87 'W'}, {next_for_n= eutral_pos =3D 93825035534240, next_for_neutral_type =3D 1, last_strong_typ= e =3D 0, prev_for_neutral_type =3D 0, level =3D 0 '\000', flags =3D 0 '\000= '}, {next_for_neutral_pos =3D 93824998232672, next_for_neutral_type =3D 0, = last_strong_type =3D 0, prev_for_neutral_type =3D 0, level =3D 0 '\000', fl= ags =3D 0 '\000'}, {next_for_neutral_pos =3D 140737488336088, next_for_neut= ral_type =3D 3, last_strong_type =3D 6, prev_for_neutral_type =3D 0, level = =3D 40 '(', flags =3D 218 '\332'}, {next_for_neutral_pos =3D 93824996249801= , next_for_neutral_type =3D 2, last_strong_type =3D 1, prev_for_neutral_typ= e =3D 0, level =3D 0 '\000', flags =3D 0 '\000'}, {next_for_neutral_pos =3D= 140737488336144, next_for_neutral_type =3D 4, last_strong_type =3D 5, prev= _for_neutral_type =3D 0, level =3D 146 '\222', flags =3D 85 'U'}, {next_for= _neutral_pos =3D 140737488336184, next_for_neutral_type =3D 0, last_strong_= type =3D 0, prev_for_neutral_type =3D 5, level =3D 255 '\377', flags =3D 25= 5 '\377'}, {next_for_neutral_pos =3D 93824996249801, next_for_neutral_type = =3D 1, last_strong_type =3D 0, prev_for_neutral_type =3D 0, level =3D 0 '\0= 00', flags =3D 0 '\000'}, {next_for_neutral_pos =3D 27355173, next_for_neut= ral_type =3D 2, last_strong_type =3D 0, prev_for_neutral_type =3D 4, level = =3D 161 '\241', flags =3D 1 '\001'}, {next_for_neutral_pos =3D 140736853489= 715, next_for_neutral_type =3D 0, last_strong_type =3D 0, prev_for_neutral_= type =3D 4, level =3D 193 '\301', flags =3D 115 's'}, {next_for_neutral_pos= =3D 93824996249801, next_for_neutral_type =3D 0, last_strong_type =3D 0, p= rev_for_neutral_type =3D 0, level =3D 0 '\000', flags =3D 0 '\000'}, {next_= for_neutral_pos =3D 140737488336368, next_for_neutral_type =3D 6, last_stro= ng_type =3D 6, prev_for_neutral_type =3D 4, level =3D 146 '\222', flags =3D= 85 'U'}, {next_for_neutral_pos =3D 93459923358642, next_for_neutral_type = =3D 0, last_strong_type =3D 0, prev_for_neutral_type =3D 0, level =3D 0 '\0= 00', flags =3D 0 '\000'}, {next_for_neutral_pos =3D 27353858, next_for_neut= ral_type =3D 5, last_strong_type =3D 4, prev_for_neutral_type =3D 0, level = =3D 161 '\241', flags =3D 1 '\001'}, {next_for_neutral_pos =3D 27353857, ne= xt_for_neutral_type =3D 0, last_strong_type =3D 4, prev_for_neutral_type = =3D 6, level =3D 255 '\377', flags =3D 255 '\377'}, {next_for_neutral_pos = =3D 93824998232672, next_for_neutral_type =3D 0, last_strong_type =3D 0, pr= ev_for_neutral_type =3D 0, level =3D 0 '\000', flags =3D 0 '\000'}, {next_f= or_neutral_pos =3D 2147483648010, next_for_neutral_type =3D 1, last_strong_= type =3D 0, prev_for_neutral_type =3D 4, level =3D 161 '\241', flags =3D 1 = '\001'}, {next_for_neutral_pos =3D 93824996179882, next_for_neutral_type = =3D 1, last_strong_type =3D 0, prev_for_neutral_type =3D 0, level =3D 133 '= \205', flags =3D 85 'U'}, {next_for_neutral_pos =3D 140737488336336, next_f= or_neutral_type =3D 0, last_strong_type =3D 5, prev_for_neutral_type =3D 6,= level =3D 145 '\221', flags =3D 85 'U'}, {next_for_neutral_pos =3D 1407374= 88336416, next_for_neutral_type =3D 5, last_strong_type =3D 7, prev_for_neu= tral_type =3D 6, level =3D 232 '\350', flags =3D 87 'W'}, {next_for_neutral= _pos =3D 24192, next_for_neutral_type =3D 3, last_strong_type =3D 2, prev_f= or_neutral_type =3D 1, level =3D 240 '\360', flags =3D 87 'W'}, {next_for_n= eutral_pos =3D 0, next_for_neutral_type =3D 0, last_strong_type =3D 0, prev= _for_neutral_type =3D 0, level =3D 0 '\000', flags =3D 0 '\000'}, {next_for= _neutral_pos =3D 93824998256864, next_for_neutral_type =3D 0, last_strong_t= ype =3D 6, prev_for_neutral_type =3D 2, level =3D 121 'y', flags =3D 88 'X'= }, {next_for_neutral_pos =3D 140737488336368, next_for_neutral_type =3D 0, = last_strong_type =3D 0, prev_for_neutral_type =3D 4, level =3D 193 '\301', = flags =3D 115 's'}, {next_for_neutral_pos =3D 93825044950192, next_for_neut= ral_type =3D 0, last_strong_type =3D 0, prev_for_neutral_type =3D 0, level = =3D 0 '\000', flags =3D 0 '\000'}, {next_for_neutral_pos =3D 14073748833659= 2, next_for_neutral_type =3D 5, last_strong_type =3D 2, prev_for_neutral_ty= pe =3D 3, level =3D 94 '^', flags =3D 85 'U'}, {next_for_neutral_pos =3D 0,= next_for_neutral_type =3D 0, last_strong_type =3D 4, prev_for_neutral_type= =3D 3, level =3D 255 '\377', flags =3D 255 '\377'}, {next_for_neutral_pos = =3D 140733210146464, next_for_neutral_type =3D 5, last_strong_type =3D 4, p= rev_for_neutral_type =3D 5, level =3D 161 '\241', flags =3D 1 '\001'}, {nex= t_for_neutral_pos =3D 109415430, next_for_neutral_type =3D 5, last_strong_t= ype =3D 7, prev_for_neutral_type =3D 6, level =3D 232 '\350', flags =3D 87 = 'W'}, {next_for_neutral_pos =3D 109415830, next_for_neutral_type =3D 1, las= t_strong_type =3D 0, prev_for_neutral_type =3D 4, level =3D 161 '\241', fla= gs =3D 1 '\001'}, {next_for_neutral_pos =3D 27355172, next_for_neutral_type= =3D 7, last_strong_type =3D 7, prev_for_neutral_type =3D 7, level =3D 255 = '\377', flags =3D 255 '\377'}, {next_for_neutral_pos =3D 27353858, next_for= _neutral_type =3D 0, last_strong_type =3D 6, prev_for_neutral_type =3D 4, l= evel =3D 167 '\247', flags =3D 85 'U'}, {next_for_neutral_pos =3D 27353858,= next_for_neutral_type =3D 5, last_strong_type =3D 4, prev_for_neutral_type= =3D 5, level =3D 161 '\241', flags =3D 1 '\001'}, {next_for_neutral_pos = =3D 27353857, next_for_neutral_type =3D 0, last_strong_type =3D 4, prev_for= _neutral_type =3D 3, level =3D 255 '\377', flags =3D 255 '\377'}, {next_for= _neutral_pos =3D 0, next_for_neutral_type =3D 0, last_strong_type =3D 0, pr= ev_for_neutral_type =3D 0, level =3D 0 '\000', flags =3D 0 '\000'}, {next_f= or_neutral_pos =3D 0, next_for_neutral_type =3D 0, last_strong_type =3D 0, = prev_for_neutral_type =3D 0, level =3D 0 '\000', flags =3D 0 '\000'}, {next= _for_neutral_pos =3D 0, next_for_neutral_type =3D 0, last_strong_type =3D 4= , prev_for_neutral_type =3D 3, level =3D 255 '\377', flags =3D 255 '\377'},= {next_for_neutral_pos =3D 140737488336592, next_for_neutral_type =3D 0, la= st_strong_type =3D 0, prev_for_neutral_type =3D 4, level =3D 193 '\301', fl= ags =3D 115 's'}, {next_for_neutral_pos =3D 48, next_for_neutral_type =3D 0= , last_strong_type =3D 0, prev_for_neutral_type =3D 0, level =3D 0 '\000', = flags =3D 0 '\000'}, {next_for_neutral_pos =3D 140737488336640, next_for_ne= utral_type =3D 5, last_strong_type =3D 6, prev_for_neutral_type =3D 1, leve= l =3D 94 '^', flags =3D 85 'U'}, {next_for_neutral_pos =3D 140737488336640,= next_for_neutral_type =3D 0, last_strong_type =3D 4, prev_for_neutral_type= =3D 3, level =3D 255 '\377', flags =3D 255 '\377'}, {next_for_neutral_pos = =3D 16777216, ne--Type for more, q to quit, c to continue without pag= ing-- xt_for_neutral_type =3D 0, last_strong_type =3D 4, prev_for_neutral_type = =3D 3, level =3D 255 '\377', flags =3D 255 '\377'}, {next_for_neutral_pos = =3D 140737488336704, next_for_neutral_type =3D 4, last_strong_type =3D 3, p= rev_for_neutral_type =3D 2, level =3D 95 '_', flags =3D 85 'U'}, {next_for_= neutral_pos =3D 347705, next_for_neutral_type =3D 4, last_strong_type =3D 7= , prev_for_neutral_type =3D 4, level =3D 5 '\005', flags =3D 0 '\000'}, {ne= xt_for_neutral_pos =3D 139646566646552, next_for_neutral_type =3D 0, last_s= trong_type =3D 4, prev_for_neutral_type =3D 3, level =3D 255 '\377', flags = =3D 255 '\377'}, {next_for_neutral_pos =3D 348476, next_for_neutral_type = =3D 0, last_strong_type =3D 4, prev_for_neutral_type =3D 3, level =3D 255 '= \377', flags =3D 255 '\377'}, {next_for_neutral_pos =3D 140737488336832, ne= xt_for_neutral_type =3D 0, last_strong_type =3D 3, prev_for_neutral_type = =3D 3, level =3D 94 '^', flags =3D 85 'U'}, {next_for_neutral_pos =3D 14748= 54845, next_for_neutral_type =3D 0, last_strong_type =3D 0, prev_for_neutra= l_type =3D 0, level =3D 0 '\000', flags =3D 0 '\000'}, {next_for_neutral_po= s =3D 348476, next_for_neutral_type =3D 1, last_strong_type =3D 7, prev_for= _neutral_type =3D 0, level =3D 5 '\005', flags =3D 0 '\000'}}, string =3D {= lstring =3D 0x555557e528e8, s =3D 0x7fffffffb8e0 "\355(\345WUU", schars =3D= 140737488336832, bufpos =3D 8890582302720, from_disp_str =3D true, unibyte= =3D false}, w =3D 0x0, paragraph_dir =3D NEUTRAL_DIR, separator_limit =3D = 0, first_elt =3D false, new_paragraph =3D false, frame_window_p =3D false} newline_found_p =3D false #7 0x0000555555611609 in redisplay_internal () at xdisp.c:17408 it =3D {window =3D 0x555557e528ed, w =3D 0x555557e528e8, f =3D 0x55= 5555e916f8, method =3D GET_FROM_BUFFER, stop_charpos =3D 27353858, prev_sto= p =3D 347705, base_level_stop =3D 0, end_charpos =3D 27353858, medium_narro= wing_begv =3D 27255690, medium_narrowing_zv =3D 27353858, large_narrowing_b= egv =3D 27103730, large_narrowing_zv =3D 27353858, s =3D 0x0, string_nchars= =3D 0, multibyte_p =3D true, tab_line_p =3D false, header_line_p =3D false= , string_from_display_prop_p =3D false, string_from_prefix_prop_p =3D false= , from_disp_prop_p =3D false, ellipsis_p =3D false, avoid_cursor_p =3D fals= e, dp =3D 0x0, dpvec =3D 0x0, dpend =3D 0x0, dpvec_char_len =3D 0, dpvec_fa= ce_id =3D 0, saved_face_id =3D 0, ctl_chars =3D {0x0 }, s= tart =3D {pos =3D {charpos =3D 347705, bytepos =3D 348476}, overlay_string_= index =3D -1, string_pos =3D {charpos =3D -1, bytepos =3D -1}, dpvec_index = =3D -1}, current =3D {pos =3D {charpos =3D 27353857, bytepos =3D 27355172},= overlay_string_index =3D -1, string_pos =3D {charpos =3D -1, bytepos =3D -= 1}, dpvec_index =3D -1}, n_overlay_strings =3D 0, overlay_strings_charpos = =3D 27353857, overlay_strings =3D {0x0 }, string_overlays= =3D {0x0 }, string =3D 0x0, from_overlay =3D 0x0, stack = =3D {{string =3D 0x0, string_nchars =3D 0, end_charpos =3D 0, stop_charpos = =3D 0, prev_stop =3D 0, base_level_stop =3D 0, cmp_it =3D {stop_pos =3D 0, = id =3D 0, ch =3D 0, rule_idx =3D 0, lookback =3D 0, nglyphs =3D 0, reversed= _p =3D false, parent_it =3D 0x0, charpos =3D 0, nchars =3D 0, nbytes =3D 0,= from =3D 0, to =3D 0, width =3D 0}, face_id =3D 0, u =3D {image =3D {objec= t =3D 0x0, slice =3D {x =3D 0x0, y =3D 0x0, width =3D 0x0, height =3D 0x0},= image_id =3D 0}, stretch =3D {object =3D 0x0}, xwidget =3D {object =3D 0x0= }}, position =3D {charpos =3D 0, bytepos =3D 0}, current =3D {pos =3D {char= pos =3D 0, bytepos =3D 0}, overlay_string_index =3D 0, string_pos =3D {char= pos =3D 0, bytepos =3D 0}, dpvec_index =3D 0}, from_overlay =3D 0x0, area = =3D LEFT_MARGIN_AREA, method =3D GET_FROM_BUFFER, paragraph_embedding =3D N= EUTRAL_DIR, multibyte_p =3D false, string_from_display_prop_p =3D false, st= ring_from_prefix_prop_p =3D false, display_ellipsis_p =3D false, avoid_curs= or_p =3D false, bidi_p =3D false, from_disp_prop_p =3D false, line_wrap =3D= TRUNCATE, voffset =3D 0, space_width =3D 0x0, font_height =3D 0x0}, {strin= g =3D 0x0, string_nchars =3D 0, end_charpos =3D 0, stop_charpos =3D 0, prev= _stop =3D 0, base_level_stop =3D 0, cmp_it =3D {stop_pos =3D 0, id =3D 0, c= h =3D 0, rule_idx =3D 0, lookback =3D 0, nglyphs =3D 0, reversed_p =3D fals= e, parent_it =3D 0x0, charpos =3D 0, nchars =3D 0, nbytes =3D 0, from =3D 0= , to =3D 0, width =3D 0}, face_id =3D 0, u =3D {image =3D {object =3D 0x0, = slice =3D {x =3D 0x0, y =3D 0x0, width =3D 0x0, height =3D 0x0}, image_id = =3D 0}, stretch =3D {object =3D 0x0}, xwidget =3D {object =3D 0x0}}, positi= on =3D {charpos =3D 0, bytepos =3D 0}, current =3D {pos =3D {charpos =3D 0,= bytepos =3D 0}, overlay_string_index =3D 0, string_pos =3D {charpos =3D 0,= bytepos =3D 0}, dpvec_index =3D 0}, from_overlay =3D 0x0, area =3D LEFT_MA= RGIN_AREA, method =3D GET_FROM_BUFFER, paragraph_embedding =3D NEUTRAL_DIR,= multibyte_p =3D false, string_from_display_prop_p =3D false, string_from_p= refix_prop_p =3D false, display_ellipsis_p =3D false, avoid_cursor_p =3D fa= lse, bidi_p =3D false, from_disp_prop_p =3D false, line_wrap =3D TRUNCATE, = voffset =3D 0, space_width =3D 0x0, font_height =3D 0x0}, {string =3D 0x0, = string_nchars =3D 0, end_charpos =3D 0, stop_charpos =3D 0, prev_stop =3D 0= , base_level_stop =3D 0, cmp_it =3D {stop_pos =3D 0, id =3D 0, ch =3D 0, ru= le_idx =3D 0, lookback =3D 0, nglyphs =3D 0, reversed_p =3D false, parent_i= t =3D 0x0, charpos =3D 0, nchars =3D 0, nbytes =3D 0, from =3D 0, to =3D 0,= width =3D 0}, face_id =3D 0, u =3D {image =3D {object =3D 0x0, slice =3D {= x =3D 0x0, y =3D 0x0, width =3D 0x0, height =3D 0x0}, image_id =3D 0}, stre= tch =3D {object =3D 0x0}, xwidget =3D {object =3D 0x0}}, position =3D {char= pos =3D 0, bytepos =3D 0}, current =3D {pos =3D {charpos =3D 0, bytepos =3D= 0}, overlay_string_index =3D 0, string_pos =3D {charpos =3D 0, bytepos =3D= 0}, dpvec_index =3D 0}, from_overlay =3D 0x0, area =3D LEFT_MARGIN_AREA, m= ethod =3D GET_FROM_BUFFER, paragraph_embedding =3D NEUTRAL_DIR, multibyte_p= =3D false, string_from_display_prop_p =3D false, string_from_prefix_prop_p= =3D false, display_ellipsis_p =3D false, avoid_cursor_p =3D false, bidi_p = =3D false, from_disp_prop_p =3D false, line_wrap =3D TRUNCATE, voffset =3D = 0, space_width =3D 0x0, font_height =3D 0x0}, {string =3D 0x0, string_nchar= s =3D 0, end_charpos =3D 0, stop_charpos =3D 0, prev_stop =3D 0, base_level= _stop =3D 0, cmp_it =3D {stop_pos =3D 0, id =3D 0, ch =3D 0, rule_idx =3D 0= , lookback =3D 0, nglyphs =3D 0, reversed_p =3D false, parent_it =3D 0x0, c= harpos =3D 0, nchars =3D 0, nbytes =3D 0, from =3D 0, to =3D 0, width =3D 0= }, face_id =3D 0, u =3D {image =3D {object =3D 0x0, slice =3D {x =3D 0x0, y= =3D 0x0, width =3D 0x0, height =3D 0x0}, image_id =3D 0}, stretch =3D {obj= ect =3D 0x0}, xwidget =3D {object =3D 0x0}}, position =3D {charpos =3D 0, b= ytepos =3D 0}, current =3D {pos =3D {charpos =3D 0, bytepos =3D 0}, overlay= _string_index =3D 0, string_pos =3D {charpos =3D 0, bytepos =3D 0}, dpvec_i= ndex =3D 0}, from_overlay =3D 0x0, area =3D LEFT_MARGIN_AREA, method =3D GE= T_FROM_BUFFER, paragraph_embedding =3D NEUTRAL_DIR, multibyte_p =3D false, = string_from_display_prop_p =3D false, string_from_prefix_prop_p =3D false, = display_ellipsis_p =3D false, avoid_cursor_p =3D false, bidi_p =3D false, f= rom_disp_prop_p =3D false, line_--Type for more, q to quit, c to cont= inue without paging-- wrap =3D TRUNCATE, voffset =3D 0, space_width =3D 0x0, font_height =3D 0x0}= , {string =3D 0x0, string_nchars =3D 0, end_charpos =3D 0, stop_charpos =3D= 0, prev_stop =3D 0, base_level_stop =3D 0, cmp_it =3D {stop_pos =3D 0, id = =3D 0, ch =3D 0, rule_idx =3D 0, lookback =3D 0, nglyphs =3D 0, reversed_p = =3D false, parent_it =3D 0x0, charpos =3D 0, nchars =3D 0, nbytes =3D 0, fr= om =3D 0, to =3D 0, width =3D 0}, face_id =3D 0, u =3D {image =3D {object = =3D 0x0, slice =3D {x =3D 0x0, y =3D 0x0, width =3D 0x0, height =3D 0x0}, i= mage_id =3D 0}, stretch =3D {object =3D 0x0}, xwidget =3D {object =3D 0x0}}= , position =3D {charpos =3D 0, bytepos =3D 0}, current =3D {pos =3D {charpo= s =3D 0, bytepos =3D 0}, overlay_string_index =3D 0, string_pos =3D {charpo= s =3D 0, bytepos =3D 0}, dpvec_index =3D 0}, from_overlay =3D 0x0, area =3D= LEFT_MARGIN_AREA, method =3D GET_FROM_BUFFER, paragraph_embedding =3D NEUT= RAL_DIR, multibyte_p =3D false, string_from_display_prop_p =3D false, strin= g_from_prefix_prop_p =3D false, display_ellipsis_p =3D false, avoid_cursor_= p =3D false, bidi_p =3D false, from_disp_prop_p =3D false, line_wrap =3D TR= UNCATE, voffset =3D 0, space_width =3D 0x0, font_height =3D 0x0}}, sp =3D 0= , selective =3D 0, what =3D IT_CHARACTER, face_id =3D 0, selective_display_= ellipsis_p =3D true, ctl_arrow_p =3D true, face_box_p =3D false, start_of_b= ox_run_p =3D false, end_of_box_run_p =3D false, overlay_strings_at_end_proc= essed_p =3D false, ignore_overlay_strings_at_pos_p =3D false, glyph_not_ava= ilable_p =3D false, starts_in_middle_of_char_p =3D false, face_before_selec= tive_p =3D false, constrain_row_ascent_descent_p =3D false, line_number_pro= duced_p =3D false, align_visually_p =3D false, line_wrap =3D TRUNCATE, base= _face_id =3D 0, c =3D 10, len =3D 0, cmp_it =3D {stop_pos =3D 27353857, id = =3D -1, ch =3D -2, rule_idx =3D 0, lookback =3D 0, nglyphs =3D 0, reversed_= p =3D false, parent_it =3D 0x7fffffffb8e0, charpos =3D 0, nchars =3D 0, nby= tes =3D 0, from =3D 0, to =3D 0, width =3D 0}, char_to_display =3D 0, glyph= less_method =3D GLYPHLESS_DISPLAY_THIN_SPACE, image_id =3D 0, xwidget =3D 0= x0, slice =3D {x =3D 0x0, y =3D 0x0, width =3D 0x0, height =3D 0x0}, space_= width =3D 0x0, voffset =3D 0, tab_width =3D 8, font_height =3D 0x0, object = =3D 0x555557e87fbd, position =3D {charpos =3D 27353857, bytepos =3D 2735517= 2}, truncation_pixel_width =3D 9, continuation_pixel_width =3D 0, first_vis= ible_x =3D 0, last_visible_x =3D 1881, last_visible_y =3D 2070, extra_line_= spacing =3D 0, max_extra_line_spacing =3D 0, override_ascent =3D -1, overri= de_descent =3D 0, override_boff =3D 0, glyph_row =3D 0x0, area =3D TEXT_ARE= A, nglyphs =3D 1, pixel_width =3D 0, ascent =3D 0, descent =3D 0, max_ascen= t =3D 0, max_descent =3D 0, phys_ascent =3D 0, phys_descent =3D 0, max_phys= _ascent =3D 0, max_phys_descent =3D 0, current_x =3D 0, wrap_prefix_width = =3D 0, continuation_lines_width =3D 0, eol_pos =3D {charpos =3D 0, bytepos = =3D 0}, current_y =3D 396, first_vpos =3D 0, vpos =3D 22, hpos =3D 0, lnum = =3D 0, lnum_bytepos =3D 0, lnum_width =3D 0, lnum_pixel_width =3D 0, pt_lnu= m =3D 0, stretch_adjust =3D 0, left_user_fringe_bitmap =3D 0, right_user_fr= inge_bitmap =3D 0, left_user_fringe_face_id =3D 0, right_user_fringe_face_i= d =3D 0, bidi_p =3D true, bidi_it =3D {bytepos =3D 27355172, charpos =3D 27= 353857, ch =3D 10, nchars =3D 1, ch_len =3D 1, type =3D NEUTRAL_B, type_aft= er_wn =3D NEUTRAL_B, orig_type =3D NEUTRAL_B, resolved_level =3D 0 '\000', = isolate_level =3D 0 '\000', invalid_levels =3D 0, invalid_isolates =3D 0, p= rev =3D {charpos =3D 0, type =3D UNKNOWN_BT, orig_type =3D UNKNOWN_BT}, las= t_strong =3D {charpos =3D 0, type =3D UNKNOWN_BT, orig_type =3D UNKNOWN_BT}= , next_for_neutral =3D {charpos =3D -1, type =3D UNKNOWN_BT, orig_type =3D = UNKNOWN_BT}, prev_for_neutral =3D {charpos =3D -1, type =3D UNKNOWN_BT, ori= g_type =3D UNKNOWN_BT}, next_for_ws =3D {charpos =3D 0, type =3D UNKNOWN_BT= , orig_type =3D UNKNOWN_BT}, bracket_pairing_pos =3D -1, bracket_enclosed_t= ype =3D UNKNOWN_BT, next_en_pos =3D 0, next_en_type =3D UNKNOWN_BT, sos =3D= L2R, scan_dir =3D 0, disp_pos =3D -1, disp_prop =3D 0, stack_idx =3D 0, le= vel_stack =3D {{next_for_neutral_pos =3D 0, next_for_neutral_type =3D 0, la= st_strong_type =3D 0, prev_for_neutral_type =3D 0, level =3D 0 '\000', flag= s =3D 0 '\000'} }, string =3D {lstring =3D 0x0, s =3D 0x= 0, schars =3D 0, bufpos =3D 0, from_disp_str =3D false, unibyte =3D false},= w =3D 0x555557e528e8, paragraph_dir =3D NEUTRAL_DIR, separator_limit =3D -= 1, first_elt =3D false, new_paragraph =3D true, frame_window_p =3D true}, p= aragraph_embedding =3D NEUTRAL_DIR, min_width_property =3D 0x0, min_width_s= tart =3D 0} row =3D 0x30 w =3D 0x555557e528e8 sw =3D 0x555557e528e8 fr =3D 0x555555e916f8 must_finish =3D true match_p =3D true tlbufpos =3D {charpos =3D 347705, bytepos =3D 348476} tlendpos =3D {charpos =3D 0, bytepos =3D 0} number_of_visible_frames =3D 1 sf =3D 0x555555e916f8 polling_stopped_here =3D false tail =3D 0x0 frame =3D 0x555555e916fd hscroll_retries =3D 0 garbaged_frame_retries =3D 0 consider_all_windows_p =3D false update_miniwindow_p =3D true --Type for more, q to quit, c to continue without paging-- count =3D {bytes =3D 128} previous_frame =3D 0x7fffffffb870 current_matrices_cleared =3D false new_count =3D -17792 #8 0x000055555560f596 in redisplay () at xdisp.c:16672 #9 0x0000555555797f4e in read_char (commandflag=3D1, map=3D0x555557f08453,= prev_event=3D0x0, used_mouse_menu=3D0x7fffffffd025, end_time=3D0x0) at key= board.c:2672 echo_current =3D false c =3D 0x0 local_getcjmp =3D {{__jmpbuf =3D {140737488342752, 93824994751784, = 93824998232672, 0, 0, 140737488342640, 93824995519404, 1465334272}, __mask_= was_saved =3D -12576, __saved_mask =3D {__val =3D {93824995565511, 93825035= 961443, 128, 93825035961459, 0, 140737488342752, 93824995270759, 9382499823= 2672, 0, 0, 15774553331185344768, 93824994728855, 0, 140737488342944, 93824= 994753775, 0}}}} save_jump =3D {{__jmpbuf =3D {110770, -4294967296, 93825015696904, = 93825035961427, 140737488342848, 93824995251736, 93825035961443, 9382503596= 1427}, __mask_was_saved =3D -12448, __saved_mask =3D {__val =3D {9382503596= 1424, 93825035961443, 93825035961427, 93824998280960, 48288, 48288, 48288, = 93824994728855, 48288, 140737488343008, 93824994735190, 139642271682304, 93= 825035961427, 93824998232672, 0, 0}}}} tem =3D 0x555555854874 save =3D 0x7fffffffcdc0 previous_echo_area_message =3D 0x0 also_record =3D 0x0 reread =3D false recorded =3D false polling_stopped_here =3D false orig_kboard =3D 0x555555cf5e60 jmpcount =3D {bytes =3D 93824995370437} c_volatile =3D 0x0 #10 0x00005555557acd81 in read_key_sequence (keybuf=3D0x7fffffffd2a0, prompt=3D0x0, dont_downcase_last=3Dfalse, can= _return_switch_frame=3Dtrue, fix_current_buffer=3Dtrue, prevent_redisplay= =3Dfalse, disable_text_conversion_p=3Dfalse) at keyboard.c:10757 interrupted_kboard =3D 0x555555cf5e60 interrupted_frame =3D 0x555555e916f8 key =3D 0x55555593027b used_mouse_menu =3D false echo_local_start =3D 0 last_real_key_start =3D 0 keys_local_start =3D 0 new_binding =3D 0x7fffffffd1d8 count =3D {bytes =3D 96} t =3D 0 echo_start =3D 0 keys_start =3D 0 current_binding =3D 0x555557f08453 first_unbound =3D 31 mock_input =3D 0 used_mouse_menu_history =3D {false } fkey =3D {parent =3D 0x7ffff49f7873, map =3D 0x7ffff49f7873, start = =3D 0, end =3D 0} --Type for more, q to quit, c to continue without paging-- keytran =3D {parent =3D 0x7ffff2313473, map =3D 0x7ffff2313473, sta= rt =3D 0, end =3D 0} indec =3D {parent =3D 0x7ffff49f7863, map =3D 0x7ffff49f7863, start= =3D 0, end =3D 0} shift_translated =3D false delayed_switch_frame =3D 0x0 original_uppercase =3D 0x0 original_uppercase_position =3D -1 disabled_conversion =3D false starting_buffer =3D 0x555557e87fb8 fake_prefixed_keys =3D 0x0 first_event =3D 0x0 second_event =3D 0x0 #11 0x0000555555793fb4 in command_loop_1 () at keyboard.c:1424 cmd =3D 0x1ce16c0 keybuf =3D {0x74a0, 0x0, 0x0, 0x7fffffffd2d0, 0x555555876bac , 0x575739e0, 0x7fffffffd340, 0x555555881fc7 , 0x7ffff49f04f3, 0x60, 0x55555587770e , 0x0, 0xb, 0x= b430, 0x555555b0d260 , 0x0, 0x0, 0x60, 0x7fffffffd340, 0x555555a7c= 260 , 0x7fffffffd380, 0x55555587c0d3 , 0x100000030, 0x90, 0x30, 0x555555bdfdb0, 0x55555578fb19 , 0x90, 0x7fffffffd3b0, 0x55555587bfc6 } i =3D 1 last_pt =3D 27353857 prev_modiff =3D 25881 prev_buffer =3D 0x555557e87fb8 #12 0x000055555587bb35 in internal_condition_case (bfun=3D0x555555793b66 , handlers=3D0x90, hfun=3D0x555555792f64 ) at eval= .c:1602 val =3D 0x55555578fb19 c =3D 0x555555bdfdb0 #13 0x0000555555793710 in command_loop_2 (handlers=3D0x90) at keyboard.c:11= 63 val =3D 0x90 #14 0x000055555587af29 in internal_catch (tag=3D0x12420, func=3D0x555555793= 6e2 , arg=3D0x90) at eval.c:1282 val =3D 0x61600000000 c =3D 0x555555bdfc70 #15 0x000055555579369e in command_loop () at keyboard.c:1141 #16 0x00005555557929e6 in recursive_edit_1 () at keyboard.c:749 count =3D {bytes =3D 32} val =3D 0x5555558817e3 #17 0x0000555555792c1a in Frecursive_edit () at keyboard.c:832 count =3D {bytes =3D 0} buffer =3D 0x0 #18 0x000055555578e1d8 in main (argc=3D4, argv=3D0x7fffffffd778) at emacs.c= :2562 stack_bottom_variable =3D 0x1 old_argc =3D 5 dump_file =3D 0x0 no_loadup =3D false junk =3D 0x0 dname_arg =3D 0x0 ch_to_dir =3D 0x0 --Type for more, q to quit, c to continue without paging-- original_pwd =3D 0x0 dump_mode =3D 0x0 skip_args =3D 0 temacs =3D 0x0 attempt_load_pdump =3D true only_version =3D false rlim =3D {rlim_cur =3D 10022912, rlim_max =3D 18446744073709551615} lc_all =3D 0x0 sockfd =3D -1 module_assertions =3D false From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 03 14:17:30 2025 Received: (at 76538) by debbugs.gnu.org; 3 Mar 2025 19:17:30 +0000 Received: from localhost ([127.0.0.1]:51980 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tpBI9-0005qR-NM for submit@debbugs.gnu.org; Mon, 03 Mar 2025 14:17:30 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:34436) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tpBI3-0005q9-Ck for 76538@debbugs.gnu.org; Mon, 03 Mar 2025 14:17:26 -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 1tpBHr-00030a-Hz; Mon, 03 Mar 2025 14:17:11 -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=qjXGhBqQrl6FSJ8W0jVg2t2NRiqR7ZhUZExpvhrvH10=; b=Fn2/zj64k0/c e1DyOiYxkoh2IsK3NJXP7LlHKdPcBMPABbr8v1xbyrFOaLOVIfnM3D5ZcrQlcPTHgP1G/cEByJxP/ m8DvOGNOjkeCs0jyzAD02+264t9Ohza+7yzHIwuZv8rAA3hTn5AcodfmZb8oBgP6apzxL2teL8wHu rAJmwOSc3/a6z19/wzfALF17e0xDSRv8cas2nEnte+dXvHgrqXVcLazy8SNTN3v/X8p/tznok3w6o xscDrLwLwESse5hrCrcybJE1Zx0EXz1eMV6UjPHwcRcCe15blt735onBZerTVYxwRmQ3wzLEhNS3d aspW3Yonju8q09YD07740Q==; Date: Mon, 03 Mar 2025 21:17:01 +0200 Message-Id: <8634ftlyaa.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87r03e9h7s.fsf@protonmail.com> (message from Pip Cet on Mon, 03 Mar 2025 17:07:02 +0000) Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs. References: <87ikoyetgi.fsf@gmx.se> <87pliyxy1r.fsf@gmail.com> <87tt8axuod.fsf@protonmail.com> <86y0xmkxrn.fsf@gnu.org> <8734fuxjcv.fsf@protonmail.com> <86ikoqku2k.fsf@gnu.org> <87pliyw1ol.fsf@protonmail.com> <864j0akqtf.fsf@gnu.org> <87r03e9h7s.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76538 Cc: yantar92@posteo.net, eller.helmut@gmail.com, gerd.moellmann@gmail.com, monnier@iro.umontreal.ca, joaomoreira@gmx.se, 76538@debbugs.gnu.org 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 (---) > Date: Mon, 03 Mar 2025 17:07:02 +0000 > From: Pip Cet > Cc: gerd.moellmann@gmail.com, eller.helmut@gmail.com, monnier@iro.umontreal.ca, yantar92@posteo.net, joaomoreira@gmx.se, 76538@debbugs.gnu.org > > "Eli Zaretskii" writes: > > > As for the call with 'false' as 2nd arg: First, when it->bidi_p is > > true, we don't use it->len for moving to the next display element. > > True. Moving the eassert inside the if might be the minimal change > there. No, I think setting it->len correctly would be a better, cleaner change. Not that I understand how come you hit this assertion while we never do on master...