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: Tue, 09 Aug 2022 14:30:28 +0300 Message-ID: <83fsi5veln.fsf@gnu.org> References: <6ae35c9306ade07b4c45@heytings.org> <83fsi7wjqe.fsf@gnu.org> <838rnzvup5.fsf@gnu.org> <3036db04-df93-2dff-0364-1e59f95772bc@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14889"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, acm@muc.de, gregory@heytings.org, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 09 13:32:55 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 1oLNTi-0003cI-NU for ged-emacs-devel@m.gmane-mx.org; Tue, 09 Aug 2022 13:32:54 +0200 Original-Received: from localhost ([::1]:48546 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oLNTh-0004YN-AF for ged-emacs-devel@m.gmane-mx.org; Tue, 09 Aug 2022 07:32:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36430) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLNRc-0003Y2-Aq for emacs-devel@gnu.org; Tue, 09 Aug 2022 07:30:51 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37596) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLNRb-0004tY-7S; Tue, 09 Aug 2022 07:30:43 -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=D2q2Gmh245WzAqKbWuX4OcTIGGCfbwnVIPaLJFTMPq0=; b=H2oWTJzq217M Ii1ZT8iF7SFyktpT1xl5RcD6cRp7AJPxWj77s6Ggeqf5A7aI7a2NuZM3mguOUyB4S5SKsJ0qaqoBL OZUTz4wnMJfiwdaFRXDcFzx/HqJwMg17HfwrNXCEKJaWZ54RgNwNFj78E2OXZzOSNukkjoY7X320V pVfAtRDcgAuR46QkOdYwgF/Q5zb1gtnsLlgSxIM1Vhee6jqbeT5z+F+5u/5A0i5KamRSyOSxH3C+b NPPKp47EZv6pWdEwtudO1aE5OnvxEDxaRdTrWy5oBXWRDoWPJEc1cyna1SOIdqO85aEXeLKI1jQ/A aVAmwwFHKtKwYBIM2Fhp9Q==; Original-Received: from [87.69.77.57] (port=2607 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 1oLNRX-00020g-K2; Tue, 09 Aug 2022 07:30:40 -0400 In-Reply-To: <3036db04-df93-2dff-0364-1e59f95772bc@yandex.ru> (message from Dmitry Gutov on Tue, 9 Aug 2022 00:16:23 +0300) 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:293301 Archived-At: > Date: Tue, 9 Aug 2022 00:16:23 +0300 > Cc: acm@muc.de, gregory@heytings.org, emacs-devel@gnu.org > From: Dmitry Gutov > > On 08.08.2022 14:30, Eli Zaretskii wrote: > > 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. > > The file is already displayed "quickly enough". What do you mean by "quickly enough"? With this recipe: emacs -Q M-: (setq long-line-threshold nil) RET M-: (setq syntax-wholeline-max most-positive-fixnum) RET visiting dictionary.json, a 19MB single-line file, takes "forever" (I killed it after 20 minutes) before it shows anything in the window. And since both variables use "arbitrary restrictions", and both can cause inaccurate/incorrect/wrong/buggy/ fontifications, my proposal above was to do something smarter. > What's going to happen then, if the timer hasn't fired yet? We should process a relatively small portion of the buffer around the new position of point. Not surprisingly, this is precisely how jit-lock is supposed to work, if only the stuff called through fontification-functions obeyed the region which it was told to process. > And for the timer's work to be useful, it has to had happened > between the last edit and the subsequent navigation. A lot of idle > timers like that = a lot of discarded work. Not if the user will subsequently visit the place where the "discarded work" was invested. Full disclosure: I'm a long-time and very happy user of jit-lock stealth fontifications.