bug#44983: Truncate long lines of grep output

[Juri Linkov <juri@linkov.net>]

>> It's very strange that after adding the text property 'display "[…]"
>> on a very long line, motion commands are still very slow in that buffer.
>>
>> Could you help to understand why hiding long regions
>> doesn't help to improve performance?
>
> I can try, but please tell which commands are slow.  Is it C-f/C-b,
> C-n/C-p, C-v/M-v, something else?

Hmm, something strange is going on.  After inserting million-char lines:

(dotimes (_ 10)
  (insert (propertize (make-string 1000000 ?a)
           'display "[…]" 'invisible t) "\n"))

No problem, everything is still fast, C-f/C-b, C-n/C-p, C-v/M-v
move fast.  After saving to a file, grep on this file is fast
with the previous patch that hides long lines.

However, when grepping on minified web assets files
where all styles and scripts are on one long line,
then output becomes slower and slower as the line
inserted by the grep process filter grows longer.

It works this way: compilation-filter/grep-filter
inserts the next chunk of the long line, then
font-lock applies the rule from the previous patch
that hides the inserted substring starting from the
fixed position from the beginning of the line until
the end of the line, and repeats the same for every
new inserted chunk of the long line.

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?

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.