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 22:30:09 +0200 Message-ID: <08b51962-6305-5188-0bea-b17b4139646c@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> <1c82e582-8b90-f3c5-5391-1e88ca4e7ab2@yandex.ru> <4119ea30553e3f90ab8c@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="18434"; 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 21:31:20 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 1lHY9Q-0004iK-0J for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Mar 2021 21:31:20 +0100 Original-Received: from localhost ([::1]:48592 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lHY9P-0005Zs-2T for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Mar 2021 15:31:19 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58160) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lHY97-0005Zf-Vp for bug-gnu-emacs@gnu.org; Wed, 03 Mar 2021 15:31:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45571) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lHY97-0005KE-OI for bug-gnu-emacs@gnu.org; Wed, 03 Mar 2021 15:31:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lHY97-0004Zg-KX for bug-gnu-emacs@gnu.org; Wed, 03 Mar 2021 15:31: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: Wed, 03 Mar 2021 20:31: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.161480342417540 (code B ref 46859); Wed, 03 Mar 2021 20:31:01 +0000 Original-Received: (at 46859) by debbugs.gnu.org; 3 Mar 2021 20:30:24 +0000 Original-Received: from localhost ([127.0.0.1]:57117 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHY8V-0004Yp-SD for submit@debbugs.gnu.org; Wed, 03 Mar 2021 15:30:24 -0500 Original-Received: from mail-wr1-f43.google.com ([209.85.221.43]:37527) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHY8S-0004YW-0l for 46859@debbugs.gnu.org; Wed, 03 Mar 2021 15:30:21 -0500 Original-Received: by mail-wr1-f43.google.com with SMTP id v15so25171583wrx.4 for <46859@debbugs.gnu.org>; Wed, 03 Mar 2021 12:30:19 -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=Qq3hjv+4ektbFQU0agOXnnQlOMGgZ2l8alPISvd9GPU=; b=ks645ckew+Xxd/f0d2kVEImcFig6PV17cUpbiOl1FFRWeKNPEtoSErxG8AVIZhTPrf SULpEvtpDjsRPUs/gM6JlcBXVMlUGZ3Z9g1WJcauErana5mhIgF8eDoQ3K/4TbyGHi/A Xw+iamwkPYXYJF3qxVPH1sB7qD7JKOX7DdMMGNpU63OV7RMH6kYW0iscHoyfal12Qq7n Svo6sz0yBt9/cpeqJPJ3vZcslVBjAGlhVBcmkSW3/DveQK6kbv/bWJrcg8LhwWwAGcO/ DuIw2oE4rnu5jXCQdSzOOLxOeyl+h7jDbXDGkstAUJLfw1eeWo/xhfR6uuKyXTeRzacp zxZg== 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=Qq3hjv+4ektbFQU0agOXnnQlOMGgZ2l8alPISvd9GPU=; b=VJ3Mt1+yqCJe9T/wjsOMDsSYK7w9tlc4FP1NlLgAYnisuDLrFIrL5he7aZXTouN6Cp noaAwtvKKzTrW5UXQSdusINLWXqDXAFQP5vHI1FIFw/youPdCahWmvHnnTY9a8bdehqo FMjjk6POQG5ArvygspZXqHbFw7nhp402XKgx5esNmEF5HEV2RhfD7YkJKSLHKpqH77wP 3NFT0Tf9gOMOVjisJjI9e3CGAh+NfE5LHx387SrKpK1I64nO4TyeQ5ISuEqlLGuuy69a KMPJxB5HH7w5abXTJ9Swl7sM0HLolnyTER+IcU9Pdsa7VzVbW12c44JTcZF1Y+JmMwFv 0Mcg== X-Gm-Message-State: AOAM533eY69d1Y0GzKP9poTVsGxW32i6/8VCK8taUFjTSi114j3PwPDB u7TRPld0IfCLkNiJOWEkfl6Ig9QH4n8= X-Google-Smtp-Source: ABdhPJxdkPTIDr+cAS7TufFkkoUSloQykjyvryAZkNrQtKQqleoqRVPTg28RyNDGtGBb9I9grSpyvw== X-Received: by 2002:adf:f144:: with SMTP id y4mr436972wro.408.1614803414095; Wed, 03 Mar 2021 12:30:14 -0800 (PST) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id y18sm32592598wrq.61.2021.03.03.12.30.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Mar 2021 12:30:13 -0800 (PST) In-Reply-To: <4119ea30553e3f90ab8c@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:201329 Archived-At: On 03.03.2021 21:34, Gregory Heytings wrote: > >>> 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. >> > > I don't know exactly what you want to do, I initially chimed in this > conversation to react to Juri's "GNU grep has no option to truncate > output", to mention that GNU grep does have an option to do this; > perhaps it doesn't do exactly what you want. > > I could be wrong, but I believe that adapting what you want to what GNU > grep provides will always be more efficient than the opposite. That's the general principle I have tried to follow, but Grep has proved suboptimal for a number of purposes (matching one regexp to multiple lines among them). >>> 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? >> > > No, once for each file.  "grep -nbo '^.' FILE" returns a ": of first char>:" line for each line in FILE.  With this you > can easily calculate the offset of a match on a given line.  This will > be more efficient than calculating the offset of a match by parsing each > line with Elisp code. That's still +1 Grep invocation per file, right? Can't say for sure, perhaps it will be more efficient than parsing in Lisp, but at least with Lisp I know that parsing 10-20 matches is fast (and, actually, it's fairly instantaneous with 1000s of matches, as long as we don't encounter pathological files where all contents reside on one line). With your approach we'll have to deal with interpreting Grep outputs which list every line in the searched files. This will almost certainly be slower in the case when there are only handful of matches. But benchmarks welcome.