From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el Date: Mon, 8 Mar 2021 04:56:47 +0200 Message-ID: <5cca8644-f111-57b6-442d-e39f21090fea@yandex.ru> References: <87im69uzlt.fsf@mail.linkov.net> <25782781-4baa-5d44-99a1-2e57552ab3a0@yandex.ru> <666564dc-0252-6bf5-04e1-58c9916cffbe@yandex.ru> <92f18de5-6dae-8041-2da0-e4b782f9003e@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34856"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 To: Theodor Thornhill , juri@linkov.net, 46859@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Mar 08 03:58:08 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 1lJ65w-0008xy-LS for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Mar 2021 03:58:08 +0100 Original-Received: from localhost ([::1]:59850 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lJ65v-0003CN-Mx for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 07 Mar 2021 21:58:07 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50586) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lJ65q-0003CH-1E for bug-gnu-emacs@gnu.org; Sun, 07 Mar 2021 21:58:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58515) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lJ65p-0005G4-QU for bug-gnu-emacs@gnu.org; Sun, 07 Mar 2021 21:58:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lJ65p-0000SX-Q7 for bug-gnu-emacs@gnu.org; Sun, 07 Mar 2021 21:58:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Mar 2021 02:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46859 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 46859-submit@debbugs.gnu.org id=B46859.16151722221670 (code B ref 46859); Mon, 08 Mar 2021 02:58:01 +0000 Original-Received: (at 46859) by debbugs.gnu.org; 8 Mar 2021 02:57:02 +0000 Original-Received: from localhost ([127.0.0.1]:41828 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJ64s-0000Qr-Ao for submit@debbugs.gnu.org; Sun, 07 Mar 2021 21:57:02 -0500 Original-Received: from mail-wm1-f51.google.com ([209.85.128.51]:37791) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJ64r-0000QM-4o for 46859@debbugs.gnu.org; Sun, 07 Mar 2021 21:57:01 -0500 Original-Received: by mail-wm1-f51.google.com with SMTP id f22-20020a7bc8d60000b029010c024a1407so2900307wml.2 for <46859@debbugs.gnu.org>; Sun, 07 Mar 2021 18:57:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=H+QyGXWYqfgmBXUYZ3AB+K2oxGxNxkUrb+d1lRaKVhs=; b=b3prgwsmJCbIxTpAbgClG8HESGXCcvlSh7+GF12ZVsXpVzVt5SHuOKo7ODhRh+jnMo 1UyKgStVwFch/aGB88gmacDo3EAClLKp8165w/jRMuN7oWN7Czv3wuLoOIxvvKnL1eyN TbORP0ZEgpKlUewVx9qmmeLqZKcznd1Ozw3LA5WnFE1eZnLJBYOSbSWsm5DRd/RN0GxQ b+Tl/TCM+Iz0rmhh4l/fS9jkSKmZUyvXfJN4GRppAzm2R+f47xVtQlgzOt2DseWPjYyH +MHml3901WU91HL9552M5mb+qDAf94FBiDD+w+4BuOVV/njCFfpIgIPiEm9HUCJ+ySTm DO0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=H+QyGXWYqfgmBXUYZ3AB+K2oxGxNxkUrb+d1lRaKVhs=; b=L0dAn3OGv1JjPsXRm+jkJ1luTM036amRjF+KnjQ0XlwsYBe//waMwjY4WfKejyDx07 B3yZZ7h6LQtk+c+kldDYqCaR0exTPXoQZIZOMtCnxXzB9m+38f32LBAM+HcIT/jqonWi +FOYM+DOUXM5pbCZDOGP8xDT1WoxxGPZpnAtcaMXF3DPnD2IZxAlxhM5wjiRZ3mbTShC VnSWmTS8BBTyHfr22W77zFpzpxy9rYOuFg+xk6fTUgTRnugEKzz1dIeK/XaNAF5NUzaz iNZqTem1qeQV+tdUqrjWH+cpdmoyIkuC1ardraDzSxMXqSM/yVP8qerMVyTywCgGk2XZ D2ag== X-Gm-Message-State: AOAM532JG+pP1o4YzNoxPgRz92S6xFjKrOj9bunEQdxbi9eVSV7jnvTP Z/T8cn0Nz1v2E7LLsz2nsVT6MKwEGrk= X-Google-Smtp-Source: ABdhPJw190gM+iWcaWy3o25yIC+AqjBh7i7CbNSvqp6WWvXCMFLMONBV/r+NwQBAIRMT04IAHBg1sw== X-Received: by 2002:a1c:23d0:: with SMTP id j199mr19846581wmj.52.1615172215199; Sun, 07 Mar 2021 18:56:55 -0800 (PST) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id u4sm16805487wrm.24.2021.03.07.18.56.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Mar 2021 18:56:54 -0800 (PST) In-Reply-To: Content-Language: en-US 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:201797 Archived-At: On 07.03.2021 22:16, Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: >> That would mean interpreting the xref-truncate-line-to value (or >> however the var could be renamed) as the maximum number of chars to >> render on the line*per match*. And if there is too much text between >> them, those parts can become "(truncated...)". Your current >> implementation can cut off valid matches, and we probably want to >> preserve them if feasible. OTOH, the default value could go down to >> 200 with this approach. >> > Yeah, I had an implementation where I "snipped" between matches and > concatenated them together, but that still yielded too large a line for > my emacs on a 3 million char length file, so I scrapped that idea. I > guess it still is possible, though! It should be able to perform better now, now that xref--insert-xrefs doesn't have to delete most of the text its inserted in these scenarios. We didn't really anticipate summary lines this long and the memory churn that came with them. If you still get lines that are loo long in these cases, even with all extra text snipped away, hiding parts of the summary using text properties should be possible. I just tried putting 'invisible' on the whole line after column 600, and scrolling became instantaneous again. As long as we undo these properties (or, perhaps, scroll the visible part?) when xref-next-line is called, the user would still be able to visit all matches.