From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.bugs Subject: bug#48839: 28.0.50; Emacs freezes and takes 100% CPU with C-h v l Date: Sat, 05 Jun 2021 10:11:28 +0200 Message-ID: <87wnr8ohk5.fsf@fastmail.fm> References: <87czt16ydq.fsf@fastmail.fm> <83bl8kltb8.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32736"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.5.13; emacs 28.0.50 Cc: mail@daniel-mendler.de, 48839@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jun 05 10:14:22 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lpRRl-0008DN-Q5 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 05 Jun 2021 10:14:22 +0200 Original-Received: from localhost ([::1]:51618 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lpRRk-0005o9-OA for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 05 Jun 2021 04:14:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38430) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lpRRT-0005bJ-Gd for bug-gnu-emacs@gnu.org; Sat, 05 Jun 2021 04:14:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36726) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lpRRS-0004B2-N1 for bug-gnu-emacs@gnu.org; Sat, 05 Jun 2021 04:14:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lpRRS-0000Hq-Dt for bug-gnu-emacs@gnu.org; Sat, 05 Jun 2021 04:14:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Jun 2021 08:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48839 X-GNU-PR-Package: emacs Original-Received: via spool by 48839-submit@debbugs.gnu.org id=B48839.16228808151061 (code B ref 48839); Sat, 05 Jun 2021 08:14:02 +0000 Original-Received: (at 48839) by debbugs.gnu.org; 5 Jun 2021 08:13:35 +0000 Original-Received: from localhost ([127.0.0.1]:48272 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpRQx-0000Gy-3l for submit@debbugs.gnu.org; Sat, 05 Jun 2021 04:13:35 -0400 Original-Received: from out5-smtp.messagingengine.com ([66.111.4.29]:53861) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpRQr-0000Gh-HX for 48839@debbugs.gnu.org; Sat, 05 Jun 2021 04:13:30 -0400 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 698455C00F3; Sat, 5 Jun 2021 04:13:20 -0400 (EDT) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sat, 05 Jun 2021 04:13:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= references:from:to:cc:subject:date:in-reply-to:message-id :mime-version:content-type; s=fm3; bh=PdC0wbdOSDpGAwkC8RAj/eqnfX DhMLLmylcmJxw3AE4=; b=mT/mVZK9YKmDDo1PpkA5ctSeQO82adj5FGXDZ224qW i+m6WF/h+i+e/Tv9dV0Ohwrg/jHaG2OL7EGhHI/0f6Uy9zrRVP99kITJRt8pYA0Z eVBDj+ja8e0KCH/xvip7c5TZ3RoyG5YLVjAqefAL+WgTfAoKUotbd/u49MsltfMj 0knMfa70GRH8FrgDN26CQeUErGOz5Df95G0omerp9ucQK78uagSensHHOtzPN1iN 7l5Mi9y6EPVmpPt3C7gwnnLGk8qejnhYfCB7s8xXavQuqeqK11b9w6CtytxzmaCu 42KtczpXk9T+ENDwKut1R9QU3d82kIA/NPgL6h4tOm+g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=PdC0wb dOSDpGAwkC8RAj/eqnfXDhMLLmylcmJxw3AE4=; b=dydnGYmHdS1Qb0goTtMcPx 0P1G/1fwkgEZdQKBP0+ExY8GQKpOe74BqrcX/H7xalhR0je+pzZj/j9EpWBtiSya /9e/I/+pqmSdIyMQI0wfGGD7YVGrvEZ3zAdY5w9yp2RULa77TzFwjvPZ7ldzjXfD RfL5C1wpDMovIseOHjUiNklbVdJaa1//HEtCYsLmU1KLVWoiBCEA6lZMcdVWfP/5 ZNcVlWnxlzIFD6woHFvrifAyflSogmGKgL9KQkCDFQLrBn+ZeeUz2YYlY1BM0C/h RZ1pKLbmY+HCWlltCZ8bYojn0bKZFN9ul45PFbN6JPv96DIdeGGCw0HYpRb06Ggw == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedtfedgtdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfhgfhffvufffjgfkgggtsehttdertddtredtnecuhfhrohhmpefvrghsshhi lhhoucfjohhrnhcuoehthhhorhhnsehfrghsthhmrghilhdrfhhmqeenucggtffrrghtth gvrhhnpefgtdegffegheeuieetheekfeevjefggeefhfehieevhfeuuedtiedtjeefueeg ffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthh horhhnsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 5 Jun 2021 04:13:17 -0400 (EDT) In-reply-to: <83bl8kltb8.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:208046 Archived-At: Eli Zaretskii writes: Hi Eli and Daniel, >> Looking at the marginalia code, I can see no evil, and indeed I can >> un-marginaliarize the sample to >> >> (let ((print-escape-newlines t) >> (print-escape-control-characters t) >> (print-escape-multibyte t)) >> (string-width (prin1-to-string load-history))) >> >> which freezes my emacs in the same way. Concretely, `prin1-to-string' >> finishes and returns a 1.3 MB string and then `string-width' will run >> indefinitely on that. > > string-width on the current master has a design bug, which causes it > to be VERY slow on very long strings, if those strings don't include > newlines or similar characters. I'm working on fixing that design > bug, but meanwhile: why does marginalia need to compute the width of > such very long strings? that sounds like a design bug in marginalia. > The simplest fix is not to compute string-width of any string whose > length is greater than, say, 300 characters. Does that help in this > case? Yes, with this patch I can make the issue go away with no observable difference in the things marginalia displays. --8<---------------cut here---------------start------------->8--- diff -u --label /home/horn/.emacs.d/elpa/marginalia-20210530.158/marginalia.el --label \#\ /home/horn/.emacs.d/elpa/marginalia-20210530.158/marginalia.el /tmp/buffer-content-yqLXyF --- /home/horn/.emacs.d/elpa/marginalia-20210530.158/marginalia.el +++ # @@ -450,8 +450,12 @@ ((marginalia--symbol-class sym) :face 'marginalia-type) ((let ((print-escape-newlines t) (print-escape-control-characters t) - (print-escape-multibyte t)) - (prin1-to-string (if (boundp sym) (symbol-value sym) 'unbound))) + (print-escape-multibyte t) + (str-val (prin1-to-string + (if (boundp sym) + (symbol-value sym) + 'unbound)))) + (substring str-val 0 (min (length str-val) 300))) :truncate (/ marginalia-truncate-width 3) :face 'marginalia-variable) ((documentation-property sym 'variable-documentation) :truncate marginalia-truncate-width :face 'marginalia-documentation)))) Diff finished. Sat Jun 5 10:09:24 2021 --8<---------------cut here---------------end--------------->8--- Bye, Tassilo