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 19:12:08 +0300 Message-ID: <834jylv1k7.fsf@gnu.org> References: <6ae35c9306ade07b4c45@heytings.org> <83fsi7wjqe.fsf@gnu.org> <838rnzvup5.fsf@gnu.org> <3036db04-df93-2dff-0364-1e59f95772bc@yandex.ru> <83fsi5veln.fsf@gnu.org> <3733e7b0-a5f3-68bd-fbe0-0da535c37381@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14467"; 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 18:24:11 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 1oLS1a-0003ba-Qx for ged-emacs-devel@m.gmane-mx.org; Tue, 09 Aug 2022 18:24:11 +0200 Original-Received: from localhost ([::1]:56058 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oLS1Z-0003wD-DL for ged-emacs-devel@m.gmane-mx.org; Tue, 09 Aug 2022 12:24:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36268) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLRqB-00065x-9j for emacs-devel@gnu.org; Tue, 09 Aug 2022 12:12:23 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:41714) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLRq9-00019X-FT; Tue, 09 Aug 2022 12:12:21 -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=4qXgKgbMhGxrNOASw7n+o4ic0+VwFpiGJoB2MhsXgpI=; b=i4Q3MPeqrnYX UROQ3KGmW8JZB1be3g2x3aGILUxPWk5vUJPXzh+esypatQOXVTIzXgmK4TjRBdul2LOZhKmkiJAc/ 3xotn42+8VRr59sFkIKDZDA2+Z+7mN5FfLPzQVogVxIO9wuVGjO/9zKjtJZHIAbA4zbB9PNg4HNt2 OGnkj8zQOa1TG7l9gp8gYWfePfw6/q7sutp8Qnn5fPWF14gvDyU+G6Kp25ULjLaqNtsh+e0v6fAh+ G/Js2lfE92bZWnIouhor7is1IM1tQpiWkOMMiqDardOuRT0dIfMZxW8k20SJHehiTlqMpjrZamwe7 mVPONC5XfqvS+tzDJM3Oaw==; Original-Received: from [87.69.77.57] (port=3991 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 1oLRq7-0003KA-LD; Tue, 09 Aug 2022 12:12:20 -0400 In-Reply-To: <3733e7b0-a5f3-68bd-fbe0-0da535c37381@yandex.ru> (message from Dmitry Gutov on Tue, 9 Aug 2022 17:38:22 +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:293316 Archived-At: > Date: Tue, 9 Aug 2022 17:38:22 +0300 > Cc: monnier@iro.umontreal.ca, acm@muc.de, gregory@heytings.org, > emacs-devel@gnu.org > From: Dmitry Gutov > > > 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. > > I never recommended you to change any of those vars. Then I don't really understand what is it that you are arguing about. My proposal to Stefan was to make syntax-ppss and friends less of a burden _instead_ of the currently implemented "arbitrary restrictions" that he doesn't like. You seemed to have contradicted my proposal by saying that the file is already displayed quickly enough, but that only happens _with_ those "arbitrary restrictions". So what is your point here? > >> 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. > > To speed up the jump to a far distant part of the buffer after doing an > edit "here", the timer would have to parse the whole buffer between here > and there. Or most of it. I didn't say it should be done from a timer in this case. And it shouldn't. > > 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. > > If you concerned with the speed of font-lock itself (and not with the > speed of syntax-ppss cache maintenance which we've talked about before), I'm concerned with both, because font-lock typically calls syntax-ppss in many modes. > and in your case it might be justified, given the unoptimized build, > then using something like stealth fontifications could indeed speed up > C-v/M-v. Not M->, though. I'm a happy user of stealth fontification in my production sessions, where I run fully optimized builds.