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#44983: Truncate long lines of grep output Date: Fri, 29 Apr 2022 19:02:19 +0300 Message-ID: References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <87tuacf79e.fsf@gnus.org> 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="15404"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Cc: 44983@debbugs.gnu.org To: Lars Ingebrigtsen , Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 29 18:36:46 2022 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 1nkTbq-0003mm-Pa for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 29 Apr 2022 18:36:46 +0200 Original-Received: from localhost ([::1]:41514 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nkTbp-0007Yy-Ip for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 29 Apr 2022 12:36:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52878) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkT5D-0000vu-2w for bug-gnu-emacs@gnu.org; Fri, 29 Apr 2022 12:03:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33038) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nkT5C-0003yY-4c for bug-gnu-emacs@gnu.org; Fri, 29 Apr 2022 12:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nkT5B-0004b7-T7 for bug-gnu-emacs@gnu.org; Fri, 29 Apr 2022 12:03:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 29 Apr 2022 16:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44983 X-GNU-PR-Package: emacs Original-Received: via spool by 44983-submit@debbugs.gnu.org id=B44983.165124815017629 (code B ref 44983); Fri, 29 Apr 2022 16:03:01 +0000 Original-Received: (at 44983) by debbugs.gnu.org; 29 Apr 2022 16:02:30 +0000 Original-Received: from localhost ([127.0.0.1]:55168 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkT4g-0004aH-95 for submit@debbugs.gnu.org; Fri, 29 Apr 2022 12:02:30 -0400 Original-Received: from mail-ed1-f49.google.com ([209.85.208.49]:42804) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkT4d-0004a3-TK for 44983@debbugs.gnu.org; Fri, 29 Apr 2022 12:02:28 -0400 Original-Received: by mail-ed1-f49.google.com with SMTP id z19so9563834edx.9 for <44983@debbugs.gnu.org>; Fri, 29 Apr 2022 09:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=3qmh62eoxG5AphfGeKD4MOZRguVMi/UmIUsJLrItpv4=; b=eMnhc0iiqVmXmgnX3ibb+5EvqgtXhD/zp1lYPtCI/uiTosQ7Gf6XPYQSHr7gjB24O8 cCjFiWa/dKUOOaPREuNjVQFBFgtH2wSkd6Sk4kcfuQAXgG9vBiYC2VwYQxPxi3hl58ZC o/UkVIn8OpWxbHBm+VdIOD23u2jU8Wvmr/4PiwD8d6dD55fOO7sRj/AFZWzG7CEx9cGk QN4Vico1nRgi2Zrt8mra2hiTX3iMDCeUAZLbHm27tfeXxy98q8wq3PRlCUof23vFw9Fj Ue7mE8LAzLG+gojOviPBGlJto7immjzVui7iXz08Y9CGoXJu29vzuoILQUj+EssFX0Ic SAtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=3qmh62eoxG5AphfGeKD4MOZRguVMi/UmIUsJLrItpv4=; b=ZtZT/Miaqltyp81DVxSSkMKTBevB2pC+KEcFnipzOEKCftLr26rhn+/jSX7t519yg/ m4MTuansa5vyVrIlCh3HlRYydWMkaxLZEf7RD8sYdbbCfgsL0QQWrQnv80GGTQ88WWUY gGcmf2PgVHZifTnYrqGqKkEjUm3PDwl0CQXAvu73dGH1I3nMEmk4FOscJq5IpDs4Q4sO Hz6atFtfLG7oStv0rFwL7K0Vcj3z9BfmPQDj/Xugf7jMvefFug5QJR4+KTatEygQI/Es cUECzUqj/H+E/ZCrjK/qLwJizwLCB3/Lb27wQTOGvwBo9A7MLvu4rkYBdhp77ootiJ4a 6vuw== X-Gm-Message-State: AOAM530wLwikKWSgC6/qZ7BGOaH6lQmICXKxeGWwbYjoKljGBpQ0SLrr 5qU+c+iXsIJYCWbx64wjFnI= X-Google-Smtp-Source: ABdhPJxJJ8WlbIOpHXhS4wjMYwnoTCmWmDFUGYN7XlmzhGjI0MWnICIr1DkWxjKZYQPgoHjSxcRSAw== X-Received: by 2002:a05:6402:5201:b0:426:124:a40b with SMTP id s1-20020a056402520100b004260124a40bmr17639673edd.198.1651248142033; Fri, 29 Apr 2022 09:02:22 -0700 (PDT) Original-Received: from [192.168.236.48] ([173.237.64.48]) by smtp.googlemail.com with ESMTPSA id jl26-20020a17090775da00b006f3ef214dbdsm749237ejc.35.2022.04.29.09.02.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Apr 2022 09:02:21 -0700 (PDT) Content-Language: en-US In-Reply-To: <87tuacf79e.fsf@gnus.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:230977 Archived-At: On 29.04.2022 14:39, Lars Ingebrigtsen wrote: > Juri Linkov writes: > >> Maybe instead of using font-lock to hide long parts >> of grep lines, it would be better to do the same >> directly in compilation-filter/grep-filter? > I now have a rough patch that does this, but the problem is that even if > I splat a "..." display over the text, font-lock seems to insist on > going over the data anyway, so the display is still dog slow. > > I thought I remembered there was a way to say to font-lock "ignore this > bit of the buffer", but I can't find it now. Do I misremember? FWIW, this is more or less solved for Xref output buffers these days. And the solution is based on the 'invisible' property. See bug#46859.