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.devel Subject: Re: Major modes using `widen' is a good, even essential, programming practice. Date: Mon, 08 Aug 2022 14:30:30 +0300 Message-ID: <838rnzvup5.fsf@gnu.org> References: <6ae35c9306ade07b4c45@heytings.org> <83fsi7wjqe.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3549"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, gregory@heytings.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 08 13:31:58 2022 Return-path: Envelope-to: ged-emacs-devel@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 1oL0zG-0000kb-1s for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Aug 2022 13:31:58 +0200 Original-Received: from localhost ([::1]:58412 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oL0zE-0005E8-Dr for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Aug 2022 07:31:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35484) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oL0yF-0004Af-Bh for emacs-devel@gnu.org; Mon, 08 Aug 2022 07:31:00 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43368) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oL0yE-0003f2-6s; Mon, 08 Aug 2022 07:30:54 -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=lzj4dSw7qSiL9VFWjRG8HPQVoWL0nGN4NRpnrbE4IRY=; b=Tccma2IMrnx+ lJVWhvY+78WJJDQVW0nHIpk7Oaj74O9lqZyrXyWK0T0cEaI/hKLKSGTk25ffXrVnqXeJlCzE5IKcT ukJZUu3UKsZ+u8TMMkebbhJVq2HKy02Hv46h5O7g+77DEK/Hy9jotYtW6x+vb70Fwnc4s0kdnW0LO By5Gb6jGMzHPZZaJ6efv2HrzjT3EVaYbeEI0dGsp4REF+kk+1VLlh2/hRxfn8JRZ5JsmltMA/TGBh JuNcX1WMxJNyJjJ/FhDNxkPeDFEbKfkz9jRqW80tKY+2Ep1CTtcKNnpdnCaohiBoYtuIu3qLryYt7 7rnhxORQuX9U5Wr3GqPcfw==; Original-Received: from [87.69.77.57] (port=1270 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 1oL0y3-0000pv-B6; Mon, 08 Aug 2022 07:30:48 -0400 In-Reply-To: (message from Stefan Monnier on Mon, 08 Aug 2022 05:25:21 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:293252 Archived-At: > From: Stefan Monnier > Cc: acm@muc.de, gregory@heytings.org, emacs-devel@gnu.org > Date: Mon, 08 Aug 2022 05:25:21 -0400 > > > The intent is clearly that fontifications don't look far beyond these > > two points, because otherwise the whole design of jit-lock and its > > invocations during redisplay is basically thrown out the window. > > Usually, font-lock rules don't look before BOL or after EOL, indeed, But BOL and EOL could also be very far away, so that, too, needs some reasonable limit. > *except* via `syntax-ppss` which does look at all the text from BOB > to point. To make up for that, `syntax-ppss` relies heavily on caching, > so that it *usually* doesn't need to look very far at all (and if > there's no `syntax-propertize-function`, it's usually quite fast > because it's fully coded in C). > > For GB-sized buffers, even the fast C code of `syntax-ppss` incurs > a significant delay in the "unusual" case, so have various options: I reported this for a 18MB single-line file, which is way below the GB bar. The problem is that the initial full scan can take "forever" in those files, and that basically means we cannot edit such files in practice. So if you dislike the current solution of locked narrowing, how about making syntax-ppss work in chunks (perhaps from an idle timer?), after initially scanning only the first small portion of the file. The goal is to have the file displayed quickly enough, and thereafter complete the scan when possible.