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 20:05:21 +0300 Message-ID: <83pmh9tkj2.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> <834jylv1k7.fsf@gnu.org> <82047505-a601-dcb8-ba76-7c0c62cf4ae5@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26000"; 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 19:12:27 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 1oLSmJ-0006Xx-1D for ged-emacs-devel@m.gmane-mx.org; Tue, 09 Aug 2022 19:12:27 +0200 Original-Received: from localhost ([::1]:44096 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oLSmH-00069I-Ul for ged-emacs-devel@m.gmane-mx.org; Tue, 09 Aug 2022 13:12:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46732) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLSfh-0005O3-EP for emacs-devel@gnu.org; Tue, 09 Aug 2022 13:05:39 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43256) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLSfe-000212-KO; Tue, 09 Aug 2022 13:05:34 -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=jjHMuWnLCYpS3wi9VtrFXXkjk0p2+UXlPDJpMAyZA4o=; b=kCZa2mTVhVXG D9eXKzEmtd9tedhycqFUoq+NBnlABetvzo9qheUJ0MqLJ53tmBRyO0oYnaPKHSC6iEZgK6j3asXSo bePoDs3LD//ExVUQK0J67W4+KJAa+xrOBvVLzsO+Pzd0a29H6O2ZebV50gm2Y+Yd3F3Cf+vAlh114 hB5ltyJsQxO7zpycMbbMXvQPJ88r1N3YprblpXSdmp4FnizSOi7RX30s/p7/QmeHQhIux9OC4Si8Y S0HKrz9xY0/6ldTuTEqeT2pVvNYJWLnE2bH8yw7/ciiJ46WkhdDp4538sJlurTRgWqkBWC2omPJWH gn/hS+HaM9IajuIfdMRlhQ==; Original-Received: from [87.69.77.57] (port=3271 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 1oLSfd-0000Rq-PX; Tue, 09 Aug 2022 13:05:34 -0400 In-Reply-To: <82047505-a601-dcb8-ba76-7c0c62cf4ae5@yandex.ru> (message from Dmitry Gutov on Tue, 9 Aug 2022 19:52:46 +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:293324 Archived-At: > Date: Tue, 9 Aug 2022 19:52:46 +0300 > Cc: monnier@iro.umontreal.ca, acm@muc.de, gregory@heytings.org, > emacs-devel@gnu.org > From: Dmitry Gutov > > > 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". > > No, it doesn't. > > You might recall the patch I suggested recently that doesn't change > either of those vars but disables narrowing in handle_fontified_prop. Why is that of importance? More importantly, how is that proposal related to what I was discussing with Stefan? > BTW, you can try js-json-mode in the latest master, I have fixed another > source of slow font-locking there (coming from js-mode). I already did. This trime I got impatient more quickly, and killed the session only after 5 minutes that it was unable to show me dictionary.json (after disabling the narrowing). > Just remove the expression that starts with 'if > (current_buffer->long_line_optimizations_p)' from handle_fontified_prop, > recompile, and visit dictionary.json. Sorry, I cannot afford trying half-baked solutions. I asked you to push a feature branch or an optional feature on master precisely so that I won't need to hack my development branch. When such a feature is available, I'll surely test it in a variety of scenarios, > >> 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. > > "Stealth" syntax-ppss, to have any visible impact, is likely to have the > problem I described: lots of work, the results of which are regularly > discarded. Meaning, lost of wasting CPU energy. Well, my many years of using jit-lock-stealth clearly prove otherwise. By the time I get to revisit the buffers after some break, they are already fully fontified. > What might work better instead (and would benefit specifically the > scenario with a lot of jumping around and editing in different parts of > a large file) is to try to avoid dumping the whole spss cache when the > use edits near BOB, and instead record the fact of such edits but later, > but later try to "revalidate" the cache entries by calling > parse-partial-sexp on the interval where the edits occurred in the > meantime, and keep them if the result shows that the edits should have > no effect on the later values. That's something tree-sitter does, AFAIU, > but for much complex parse tree. > > Anyway, that approach would require some work and subsequent testing, > and it would improve performance for a particular class of operations. > It's not a given that the performance issues you see in CC Mode fit that > profile. Well, I hope someone will actually try to make that happen. > And I hope that somebody could look into improving that 10x difference > between yours and mine performance of parse-partial-sexp first, so then > we could see where the remaining bottlenecks are. That too.