From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#44983: Truncate long lines of grep output Date: Sat, 30 Apr 2022 14:12:45 +0300 Message-ID: <83fslu964y.fsf@gnu.org> References: <87v9dlc3ti.fsf_-_@mail.linkov.net> <83ft4pik35.fsf@gnu.org> <87sg8p5kw0.fsf@mail.linkov.net> <83eek8hoyx.fsf@gnu.org> <87h7p4r1n9.fsf@mail.linkov.net> <87tuacf79e.fsf@gnus.org> <87bkwi6h9l.fsf@gnus.org> <874k2a6gjo.fsf@gnus.org> <83o80i992v.fsf@gnu.org> <87r15e4yvw.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8949"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dgutov@yandex.ru, 44983@debbugs.gnu.org, juri@linkov.net To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Apr 30 13:13:21 2022 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 1nkl2P-0002C4-8L for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Apr 2022 13:13:21 +0200 Original-Received: from localhost ([::1]:50762 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nkl2N-0003P7-TO for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Apr 2022 07:13:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37094) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkl27-0003Ot-5r for bug-gnu-emacs@gnu.org; Sat, 30 Apr 2022 07:13:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33854) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nkl26-0001LP-Lz for bug-gnu-emacs@gnu.org; Sat, 30 Apr 2022 07:13:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nkl26-0005zC-Hu for bug-gnu-emacs@gnu.org; Sat, 30 Apr 2022 07:13:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Apr 2022 11:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44983 X-GNU-PR-Package: emacs Original-Received: via spool by 44983-submit@debbugs.gnu.org id=B44983.165131717022989 (code B ref 44983); Sat, 30 Apr 2022 11:13:02 +0000 Original-Received: (at 44983) by debbugs.gnu.org; 30 Apr 2022 11:12:50 +0000 Original-Received: from localhost ([127.0.0.1]:55984 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkl1u-0005yj-2C for submit@debbugs.gnu.org; Sat, 30 Apr 2022 07:12:50 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:43774) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkl1r-0005yW-Gx for 44983@debbugs.gnu.org; Sat, 30 Apr 2022 07:12:47 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:42842) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkl1l-0001Kf-Nb; Sat, 30 Apr 2022 07:12:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=+cp02sqp6GaP7/04pTYsqE//rfunjuO48WNbIq8tOiE=; b=CccGVuAHPdQp g+5lvKg5abC/tKfEuYG4IGy7GjvZfWEal6p2bK1ZlwjFs5wTVAnP+nMzbLs9i0ZSZZ1RbY2XzhAKv FDB4DqIAN5H6pxGjOI4mNuT80NYF4Y9ptmP4sRCutwU66hrHg7MDvbQ2VFaGOboCaGghJ3YI6gsmG XMvYrp9XgpLck9wuW19tjqO/t/uxyB+PqKctQ29O6OBsa0j12fE9mlNNZuMzwCVAOKbHw9ZDiWsGz 3MVUqwpJ91ibuF4SbFQvZOQIPlLkHazD57abvFgA1s82JZTnJKfLDhNF36ZcQPR9d9qakCHjdI7yI HRXMilD7LpEj1MIvuMjePw==; Original-Received: from [87.69.77.57] (port=4258 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkl1l-0004Oe-4y; Sat, 30 Apr 2022 07:12:41 -0400 In-Reply-To: <87r15e4yvw.fsf@gnus.org> (message from Lars Ingebrigtsen on Sat, 30 Apr 2022 13:02:59 +0200) 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:231015 Archived-At: > From: Lars Ingebrigtsen > Cc: dgutov@yandex.ru, 44983@debbugs.gnu.org, juri@linkov.net > Date: Sat, 30 Apr 2022 13:02:59 +0200 > > Eli Zaretskii writes: > > > We are not. The display engine will never call jit-lock on a region > > that starts in invisible text. But a region that starts in visible > > text can end in invisible text, and font-lock doesn't pay attention to > > invisibility spec, AFAIR, it just looks at the buffer text > > disregarding everything else. > > Yes, that's correct, I think. But shouldn't it be smarter here? That > is, the display engine does know that all the text it inserted was > invisible No, it doesn't know that. The display engine handles the 'fontified' property first, and the invisible property only after that. Even more importantly, the display engine handles these properties only when it gets to a character with that property, so it's enough that we have a single character with no invisible property that needs to be fontified, to have the display engine invoke jit-lock on a chunk of text starting with that visible character.