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#56682: Fix the long lines font locking related slowdowns Date: Thu, 04 Aug 2022 10:29:18 +0300 Message-ID: <83bkt04gc1.fsf@gnu.org> References: <837d46mjen.fsf@gnu.org> <8335esjppt.fsf@gnu.org> <837d43j198.fsf@gnu.org> <83y1wjhkkh.fsf@gnu.org> <83wnc3hkdg.fsf@gnu.org> <49df74e5-e16a-a532-98d1-66c6ff1eb6c6@yandex.ru> <83pmhuft5a.fsf@gnu.org> <05388e8d8836c2e7ef3e@heytings.org> <136c4fe0fcb9ce5181cb@heytings.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23652"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, gregory@heytings.org, monnier@iro.umontreal.ca To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Aug 04 09:31:08 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 1oJVJy-0005y1-An for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 04 Aug 2022 09:31:06 +0200 Original-Received: from localhost ([::1]:44632 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oJVJw-0005xH-M3 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 04 Aug 2022 03:31:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38782) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJVIw-0005vb-QE for bug-gnu-emacs@gnu.org; Thu, 04 Aug 2022 03:30:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33016) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oJVIw-0003Ej-8w for bug-gnu-emacs@gnu.org; Thu, 04 Aug 2022 03:30:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oJVIw-0003rp-4t for bug-gnu-emacs@gnu.org; Thu, 04 Aug 2022 03:30: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: Thu, 04 Aug 2022 07:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56682 X-GNU-PR-Package: emacs Original-Received: via spool by 56682-submit@debbugs.gnu.org id=B56682.165959817414809 (code B ref 56682); Thu, 04 Aug 2022 07:30:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 4 Aug 2022 07:29:34 +0000 Original-Received: from localhost ([127.0.0.1]:50998 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oJVIU-0003qn-7x for submit@debbugs.gnu.org; Thu, 04 Aug 2022 03:29:34 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:53852) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oJVIP-0003qX-KX for 56682@debbugs.gnu.org; Thu, 04 Aug 2022 03:29:32 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35410) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJVIJ-000337-Hr; Thu, 04 Aug 2022 03:29:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=m8/EsYpr1QPukZ7HfxkSMGLJIRtfQj8O1zTMy6ZJ8H8=; b=iYecmpl+bFcyyQ/1T02s ym6lABatSj6VQ4+8N5rvd18SSY24GhqXow7QpnxJfTgD6ONq960jWGqqNyyxYYMKwknqm5XrwmcaL J5cFcbUeBO1MgIvHnFYO8PjqLoSugf5gzRS+7RRwiR6OMBVYjfJUT2p6Ye1Fph8/Zt2CJU7qupzW4 KEmsbWkWB7CYoIEG7OZ5wdFjGvccswamf2yJqbqYUaXpkfSWXzvrqYQpMGXfCCS6LqxGoLkd2G1qT RtV1OiO3G2DFDnwculrSFfU6RhzTdhuT+X1idNfU0sTMTyecbZl41cDtMgaa4bO9U3/MEz/6cskJO opuHLZee61Dg5w==; Original-Received: from [87.69.77.57] (port=3912 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 1oJVIJ-0006tu-1C; Thu, 04 Aug 2022 03:29:23 -0400 In-Reply-To: (message from Dmitry Gutov on Thu, 4 Aug 2022 03:49:43 +0300) 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:238689 Archived-At: > Date: Thu, 4 Aug 2022 03:49:43 +0300 > Cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, > Eli Zaretskii , monnier@iro.umontreal.ca > From: Dmitry Gutov > > > Now > > compare that with the feature branch, with which the end of the buffer > > is displayed instantaneously.  That five seconds delay is caused by > > fontification-functions. > > At some point we should accept that visiting a huge file might take some > time (5 seconds doesn't sound terrible, depending on the context). > Because the alternative is mis-fontifications and broken display. > > >> Could you clarify what you mean by "access ... to the place where ... > >> is defined"? "new Downloadify.Container" is highlighted by a regular > >> regexp matcher, not some custom elisp code which has to visit the > >> position where the identifier is defined. > >> > > > > Sorry, I cannot be more precise, I don't have the "downloadify.js" file > > here.  It was just a guess, based on what I saw on the screenshot, that > > one function called by fontification-functions collects all class > > definitions and highlights their identifiers elsewhere in the buffer > > with a specific face.  When the buffer is narrowed, that function may > > not see the Downloadify.Container definition (which is, I guess, placed > > near the beginning of the file) anymore. > > Here I'm attaching a version of downloadify.js we can use for comparison > (please rename the extension from .sj to .js locally; Gmail was not > letting it through otherwise). It's not a huge file, just about 88K. > > As long as I keep my Emacs window/frame width half of the desktop, I can > reliably reproduce the problem with the lack of highlighting for > "Downloadify.Container" while other tokens are still highlighted. > > I'm also attaching a screenshot of another problem: suddenly the bottom > several screens of the buffer are mis-highlighted as if starting inside > a string. That very much look like a result of breaking syntax-ppss's > visibility of the buffer. > > So the buffer scrolls quickly but looks bad. I don't understand the point you are trying to make. On the one hand, you say "At some point we should accept that visiting a huge file might take some time", which seems to imply that you agree in general with some (hopefully graceful) degradation when editing files with such long lines. But OTOH you object to have that degradation in the fontification? IOW, you prefer Emacs to become much slower, but still fontify correctly? If so, just enlarge the value of long-line-threshold, with the effect that Emacs will become more sluggish before the long-line optimizations kick in. If this is your point, then maybe lobby for enlarging the default value of that variable. But if you are saying that Emacs should behave as it does with that variable being nil, then I don't understand your position. With that variable nil, Emacs becomes _unusable_, not just slow, with files that are not even too large by any modern measure, just because the lines are very long. And in those cases, why is it wrong to decide that occasional glitches in fontifications are a lesser evil than a complete lockup of the Emacs UI, which usually results in users killing the session? We decided that some imperfection in fontifications are the "graceful degradation" we are willing to endure in order to make Emacs reasonably performant in those cases. What is wrong with that tradeoff? And what alternative tradeoff would you suggest instead? (You mention "broken display" in addition to inaccurate fontifications, but I don't understand what does that allude to. Which instances of broken display did you see, and how to reproduce them?)