From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#56682: Fix the long lines font locking related slowdowns Date: Sun, 31 Jul 2022 18:45:16 -0400 Message-ID: References: <837d46mjen.fsf@gnu.org> <8a3eaeef01be5bfaa5ef@heytings.org> <05388e8d8812bfa3695d@heytings.org> <83v8rf5894.fsf@gnu.org> <65cb7c73fd4a999cca00@heytings.org> <8c7321f2f3400a5db9be@heytings.org> <8c7321f2f388e5343475@heytings.org> <8c7321f2f36494299e61@heytings.org> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6404"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: 56682@debbugs.gnu.org, Eli Zaretskii To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 01 00:47:20 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 1oIHiQ-0001Pq-Iw for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 01 Aug 2022 00:47:18 +0200 Original-Received: from localhost ([::1]:59280 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oIHiP-0007Ob-Cr for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 31 Jul 2022 18:47:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35450) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oIHhD-0007OF-3g for bug-gnu-emacs@gnu.org; Sun, 31 Jul 2022 18:46:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49027) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oIHhC-0002sm-Qs for bug-gnu-emacs@gnu.org; Sun, 31 Jul 2022 18:46:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oIHhC-0007tb-MZ for bug-gnu-emacs@gnu.org; Sun, 31 Jul 2022 18:46:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 31 Jul 2022 22:46: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.165930752930296 (code B ref 56682); Sun, 31 Jul 2022 22:46:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 31 Jul 2022 22:45:29 +0000 Original-Received: from localhost ([127.0.0.1]:38773 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIHgf-0007sZ-B2 for submit@debbugs.gnu.org; Sun, 31 Jul 2022 18:45:29 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:28899) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIHgd-0007sJ-KN for 56682@debbugs.gnu.org; Sun, 31 Jul 2022 18:45:28 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 4F4E580722; Sun, 31 Jul 2022 18:45:21 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A515680065; Sun, 31 Jul 2022 18:45:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1659307519; bh=fEzjspiNwKwPUNGHQeg8XIZI6wXUT4onESbwyS0XdxM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=XjIcu2a+rvZ9dSYJDf02j2vaXv+UaEoOZSqGaQOaqcktQQRMffYNPdry1MfnmJbpz ytpUeqpwDE87SnA0ylZcrDtpvSF/PdM1ejCRAoDQnB7cWuslM8HUJdcraaFfNuhPUk SkOJA+cl/II9qnDhLtTVZvvynXsvQ6oRK6qRofvpxajydK0rkY7skpPT6Ka21KLDNY LXiqy4R06lAbJfA5byLOQG+Q+o+TN6rWiqAN7xhCJ11lg/0I4L+dlmhjK8isP9/UD9 dTPPwzHrptdrHz73lErneQPV3m4j0HK19tI9fSIpHCxPG8dcvauvLExEibOc1CeT4v HyDuUz/LQHWag== Original-Received: from milanesa (dyn.144-85-174-155.dsl.vtx.ch [144.85.174.155]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id CF3C8120315; Sun, 31 Jul 2022 18:45:18 -0400 (EDT) In-Reply-To: <8c7321f2f36494299e61@heytings.org> (Gregory Heytings's message of "Sun, 31 Jul 2022 22:06:01 +0000") 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:238373 Archived-At: >> Try `M-: (use-global-map (make-keymap)) RET` >> Should we prevent users from doing that? > It's a misleading question. No "user" would ever do that. Sure, it's > a nice example, but only an Elisp hacker would do that, in the middle of > a debugging session, and they would do that on purpose (although perhaps > without knowing the effect in advance). Which has nothing to do with > a regular user who just opens a file. FWIW, the above is my standard example because I ended up doing exactly that by accident, locking myself out of the session I was trying to debug, so in a sense, I'd have been happy (that one time) if Emacs had prevented me from doing it. >> Let's focus on making it easy to make it work well, rather than making it >> impossible to make it work poorly. > You lost me here. I've read that sentence twenty times, and cannot > understand what you mean. Your current code makes it impossible for a major mode to make Emacs slow by widening in a too-long-line. I'd prefer if we made it easy (i.e. the default) for Emacs to work well in that case, without making it impossible for the major mode to mess things up. E.g. use narrowing (and arrange for the known widening culprit to be disabled) so that the default behavior is sane, but sllow an ELisp package from re-widening (possibly using a specific call to do that) if it thinks it's a good idea (even if it may turn out not to be so). > But if you use heuristics, as I said, you don't need to look at all the > chars between BOB and POS. You try your best to guess, on a small (a few > kilobytes) portion of the buffer, where the strings most likely start and > stop. And if you're only right in 95% of the cases, that's more than fine. For specific languages, you can use various heuristics to guess which quotes start and which quotes end a string (for some languages you can even do it reliably), but `syntax-ppss` handles all kinds of languages (and doesn't have access to such heuristics currently), such as ELisp where it's hard to do it well. I'd prefer to first see concrete examples where speeding up the "syntax-ppss in a 1GB buffer" would make a significant difference to the end-user's experience. Then we can think about what's the better way to solve the problem (which may be to just give up on font-lock altogether, or maybe to refine the `syntax.el` code (maybe move some of it to C), or to speed up `parse-partial-sexp`, or maybe let major modes provide those heuristics to find a "safe point" again (these used to exist, see `syntax-begin-function`, for example, but they tended to suck)). Stefan