unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Juri Linkov <juri@linkov.net>
Cc: 44983@debbugs.gnu.org, dgutov@yandex.ru
Subject: bug#44983: Truncate long lines of grep output
Date: Thu, 03 Dec 2020 16:47:51 +0200	[thread overview]
Message-ID: <83pn3reyjs.fsf@gnu.org> (raw)
In-Reply-To: <87zh2w7ww1.fsf@mail.linkov.net> (message from Juri Linkov on Wed, 02 Dec 2020 22:53:18 +0200)

> From: Juri Linkov <juri@linkov.net>
> Cc: dgutov@yandex.ru, 44983@debbugs.gnu.org
> Date: Wed, 02 Dec 2020 22:53:18 +0200
> 
> > 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.

What are "minified files"?

And when you say "slow" do you mean slow in receiving Grep output,
slow in displaying the received output, or slow in moving though the
*grep* buffer after everything was displayed?

> 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.

Same question as above.

> 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.

What is "output processing", and how did you measure the time it
takes?

> 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.

I suggested to request the equivalent of "cut -c" to be a feature
added to Grep.

Failing that, I don't think Emacs should do something like that,
especially since 'cut' is not guaranteed to be available.  Users who
have such problems can, of course, modify the Grep command to do that.





  reply	other threads:[~2020-12-03 14:47 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-01  8:45 bug#44983: Truncate long lines of grep output Juri Linkov
2020-12-01 15:02 ` Dmitry Gutov
2020-12-01 16:09   ` Eli Zaretskii
2020-12-01 16:46     ` Andreas Schwab
2020-12-01 18:26       ` Eli Zaretskii
2020-12-01 20:35     ` Juri Linkov
2020-12-02  3:21       ` Eli Zaretskii
2020-12-02  9:35         ` Juri Linkov
2020-12-02 10:28           ` Eli Zaretskii
2020-12-02 20:53             ` Juri Linkov
2020-12-03 14:47               ` Eli Zaretskii [this message]
2020-12-03 16:30                 ` Rudolf Schlatte
2020-12-03 21:17                 ` Juri Linkov
2020-12-05 19:47                   ` Juri Linkov
2020-12-06 20:39                     ` Juri Linkov
2020-12-06 21:37                       ` Dmitry Gutov
2020-12-06 21:54                         ` Juri Linkov
2020-12-07  2:41                           ` Dmitry Gutov
2020-12-08 19:41                             ` Juri Linkov
2020-12-09  3:00                               ` Dmitry Gutov
2020-12-09 19:17                                 ` Juri Linkov
2020-12-09 20:06                                   ` Dmitry Gutov
2020-12-10  8:18                                     ` Juri Linkov
2020-12-10 20:48                                       ` Dmitry Gutov
2020-12-09 21:43                                   ` Jean Louis
2020-12-10  8:06                                     ` Juri Linkov
2020-12-10 10:08                                       ` Jean Louis
2020-12-12 20:42                                         ` Juri Linkov
2020-12-13 10:57                                           ` Jean Louis
2020-12-13 15:11                                           ` Eli Zaretskii
2020-12-13 15:37                                             ` Jean Louis
2020-12-13 20:17                                             ` Juri Linkov
2020-12-14 16:15                                               ` Eli Zaretskii
2020-12-14 20:09                                                 ` Dmitry Gutov
2020-12-24 20:33                                   ` Juri Linkov
2020-12-24 23:38                                     ` Dmitry Gutov
2020-12-08  5:35                         ` Richard Stallman
2020-12-08 19:15                           ` Dmitry Gutov
2022-04-29 11:39           ` Lars Ingebrigtsen
2022-04-29 12:22             ` Eli Zaretskii
2022-04-29 12:41               ` Lars Ingebrigtsen
2022-04-29 13:08                 ` Eli Zaretskii
2022-04-30  9:24                   ` Lars Ingebrigtsen
2022-04-30  9:36                     ` Lars Ingebrigtsen
2022-04-30 10:15                       ` Eli Zaretskii
2022-04-30 11:04                         ` Lars Ingebrigtsen
2022-04-29 16:02             ` Dmitry Gutov
2022-04-30  9:40               ` Lars Ingebrigtsen
2022-04-30  9:56                 ` Lars Ingebrigtsen
2022-04-30 10:09                   ` Eli Zaretskii
2022-04-30 10:59                     ` Lars Ingebrigtsen
2022-04-30 11:02                     ` Lars Ingebrigtsen
2022-04-30 11:12                       ` Eli Zaretskii
2022-04-29 17:15             ` Juri Linkov
2022-04-30  0:27               ` Dmitry Gutov
2022-05-01 17:14                 ` Juri Linkov
2020-12-01 20:34   ` Juri Linkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83pn3reyjs.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=44983@debbugs.gnu.org \
    --cc=dgutov@yandex.ru \
    --cc=juri@linkov.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).