GNU bug report logs - #44983
Truncate long lines of grep output

Previous Next

Package: emacs;

Reported by: Juri Linkov <juri <at> linkov.net>

Date: Tue, 1 Dec 2020 08:56:01 UTC

Severity: normal

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44983 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: bug#44983: Truncate long lines of grep output
Date: Wed, 02 Dec 2020 22:53:18 +0200
>> Or maybe the problem is caused by special characters
>> used in minified web assets that contain many '{' chars.
>> And indeed, after inserting 100 thousands of '{'
>>
>> (insert (propertize (make-string 100000 ?{)
>>          'display "[…]" 'invisible t) "\n")
>>
>> and saving to a file, later visiting such file
>> Emacs becomes unresponsive for indefinite time.
>> But visiting the file with 100 thousands '{'
>> with find-file-literally causes no such problem.
>
> Does it help to set bidi-inhibit-bpa non-nil?

This helped to open the file with a lot of '{'.
But on minified files grep.el is still very slow.

Then instead of hiding long lines using font-lock,
I tried to do the same using the process filter:

(defun grep-filter ()
  (save-excursion
    (let ((end (point-marker)))
      (goto-char compilation-filter-start)
      (forward-line 0)
      (while (< (point) end)
        (let ((eol (line-end-position)))
          (when (> (- eol (point)) 64)
            (put-text-property (+ 64 (point)) (line-end-position)
                               'display "[…]"))
          (forward-line 1))))))

Still very slow.  Then tried to delete the excessive parts of long lines:

(defun grep-filter-try ()
  (save-excursion
    (let ((end (point-marker)))
      (goto-char compilation-filter-start)
      (forward-line 0)
      (while (< (point) end)
        (let ((eol (line-end-position)))
          (when (> (- eol (point)) 64)
            (delete-region (min (+ 64 (point)) (point-max)) (line-end-position)))
          (forward-line 1))))))

Now Emacs becomes more responsive.  But still output processing
takes too much time.

Finally, the last thing to try was the same solution that Richard
showed in bug#44941:

  grep -a "$@" | cut -c -200

that gives the best possible result.

I doubt that it would be possible to invent something better.

So the question is should this be customizable for adding
`cut -c` automatically to the end of the grep command line,
possibly with `stdbuf -oL` suggested by Andreas.




This bug report was last modified 3 years and 19 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.