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: Wed, 3 Mar 2021 21:14:02 +0200 Message-ID: <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> References: <87im69uzlt.fsf@mail.linkov.net> <878s74fv27.fsf@mail.linkov.net> <4119ea3055ef8f306fc0@heytings.org> <4119ea30557ef84ca190@heytings.org> <7eb7ee0f-7dba-c90d-cb58-af42c3828643@yandex.ru> <4119ea30554b406efbbf@heytings.org> <4119ea30558f1e4145b0@heytings.org> <4119ea30555e80bdcf7e@heytings.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8451"; 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 Cc: 46859@debbugs.gnu.org To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Mar 03 20:18:01 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 1lHX0T-00023q-6A for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Mar 2021 20:18:01 +0100 Original-Received: from localhost ([::1]:40890 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lHX0S-0004QQ-5j for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Mar 2021 14:18:00 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41352) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lHWxb-00037P-Rz for bug-gnu-emacs@gnu.org; Wed, 03 Mar 2021 14:15:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45467) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lHWxb-0007j1-Hh for bug-gnu-emacs@gnu.org; Wed, 03 Mar 2021 14:15:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lHWxb-0000aW-Di for bug-gnu-emacs@gnu.org; Wed, 03 Mar 2021 14:15:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Mar 2021 19:15:03 +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.16147988592077 (code B ref 46859); Wed, 03 Mar 2021 19:15:03 +0000 Original-Received: (at 46859) by debbugs.gnu.org; 3 Mar 2021 19:14:19 +0000 Original-Received: from localhost ([127.0.0.1]:57001 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHWws-0000XR-Rm for submit@debbugs.gnu.org; Wed, 03 Mar 2021 14:14:19 -0500 Original-Received: from mail-wr1-f51.google.com ([209.85.221.51]:41692) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHWwm-0000X7-II for 46859@debbugs.gnu.org; Wed, 03 Mar 2021 14:14:16 -0500 Original-Received: by mail-wr1-f51.google.com with SMTP id f12so21125343wrx.8 for <46859@debbugs.gnu.org>; Wed, 03 Mar 2021 11:14:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=LHPBk0XCfCXkEhAVCSvA7tVLzIRQ+NAnHhub+PslT+A=; b=nWcQxORZjjXTeClW8PZJ9N9J+Ng2JnoXmsuwtgS2hCxs0bdGlnEXAJOC4/Yd6U6u1H UF01v2izvUKUpHBuiaZ7+Knf5e7rbo8F2LsSSNyWpIS61AO5fj9IiEY0e0HWdSiwIRD1 k9ihqCXt2YUvFTdYT59sjBpxK50xkgvxJ9RK9Y2AF1sf5O8r7rKlvSUXiiqGSxQvhLwV UwA/yfnXwBZAGhVBucTAqcIO+Pd1Bxzdy9inVToJgMm/0aJu46Auf0bV/f36eft+UTHK ieL+6bGzhVbkPILUeRMaQzcHQEr3zcofKARWx2BdF3iViCAxVoAUnr3WhTZ4KEEkLqMI MGJQ== 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:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=LHPBk0XCfCXkEhAVCSvA7tVLzIRQ+NAnHhub+PslT+A=; b=j2g9t2TaN0lYzt4DW0WfVkZaYHiNFKqoE1Cfkc8xZJubmPkvjCyNskxDW4oqdf4imD +8yY0r6f5UuwwkrUWQ53sHMJDtd3isGCC1BiN7iv7KfthQtWgBhmq8//44yBvDNXE8Ou ZQ7GEtB/kp+FynimTLdevndoc2zVYXatk7r/Dm1HhTMV88vMTy+fsoqX4XhQ1mD6ZdGA nDzR3GSfVuF5L6+N/Lhx6pLmYpoDxZgPL6ejJiUcPKHtIXO0LHxwijKA5mjTQMybl+mO dpLCr6hopPH8Zix6GnnrjPzE4KhhFMYVhYO3H44VvvNPwF33ZszZmd8jxF1QUGZfC/qG s64A== X-Gm-Message-State: AOAM533SCENsHq7qqsokU62k5uRCiGBIU4CjnSqZCm6CIKZqjmb3094k 823/NNO79LhWNc2vlnrAgZNCuR7GDQM= X-Google-Smtp-Source: ABdhPJxoWoua+c2vh7tTYGcVZUTYzHNUaxXAZePebBPJouEfCY4eBfqzhQjo0aCFcMEs7DrZUyx+EA== X-Received: by 2002:adf:e7cf:: with SMTP id e15mr208803wrn.346.1614798846807; Wed, 03 Mar 2021 11:14:06 -0800 (PST) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id k4sm43258017wrd.9.2021.03.03.11.14.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Mar 2021 11:14:06 -0800 (PST) In-Reply-To: <4119ea30555e80bdcf7e@heytings.org> 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:201305 Archived-At: On 03.03.2021 19:42, Gregory Heytings wrote: > >>> I wrote too fast.  In fact you can get the column number with GNU >>> grep without parsing the original line: >>> >>> grep -nb -oE '.{0,100}PATTERN.{0,100}' >> >> This outputs byte offset from the beginning of the file, doesn't it? >> > > Yes.  You get, for each match: the line number (from the beginning of > the file), the byte offset (from the beginning of the file) of the first > displayed character, and the context of the match. OK, so we get the byte offset, but not the length of the match (which we'll also need later, for purposes such as highlighting and replacement). And what happens if there are several matches on the same line? We need columns for all of them. >> Which will require at least reading the file into memory to convert. >> > > I don't understand what you mean by that, but it seems to me that in any > case it's much more efficient than parsing the output of grep with Elisp. We currently don't visit the file buffer if it's not already visited, parsing the line in a temp buffer instead. That approach resulted in a nice perf improvement. > And you can easily get the byte offset of each beginning of line with > "grep -nbo '^.'", so calculating the byte offset from the beginning of > the line is easy. Do you mean to suggest we call grep one more time for each matching line?