From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Major modes using `widen' is a good, even essential, programming practice. Date: Tue, 9 Aug 2022 17:38:22 +0300 Message-ID: <3733e7b0-a5f3-68bd-fbe0-0da535c37381@yandex.ru> References: <6ae35c9306ade07b4c45@heytings.org> <83fsi7wjqe.fsf@gnu.org> <838rnzvup5.fsf@gnu.org> <3036db04-df93-2dff-0364-1e59f95772bc@yandex.ru> <83fsi5veln.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38387"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Cc: monnier@iro.umontreal.ca, acm@muc.de, gregory@heytings.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 09 16:39:29 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 1oLQOG-0009n7-TT for ged-emacs-devel@m.gmane-mx.org; Tue, 09 Aug 2022 16:39:28 +0200 Original-Received: from localhost ([::1]:35244 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oLQOF-0008I6-Hh for ged-emacs-devel@m.gmane-mx.org; Tue, 09 Aug 2022 10:39:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45668) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLQNb-0007dA-59 for emacs-devel@gnu.org; Tue, 09 Aug 2022 10:38:47 -0400 Original-Received: from mail-wm1-x332.google.com ([2a00:1450:4864:20::332]:35607) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oLQNZ-0003PM-6h; Tue, 09 Aug 2022 10:38:46 -0400 Original-Received: by mail-wm1-x332.google.com with SMTP id v131-20020a1cac89000000b003a4bb3f786bso9061910wme.0; Tue, 09 Aug 2022 07:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=U4AcLqqdeQgo3VpB/7TbeuSwIP5HWMYQqeiDpcQA5PQ=; b=edfT2YjuBp78BJQAyDIBVfWV/Uk7rXUbsthqbX1WkNj7FjeyqHeVY2U+hXI7g+Vuui cL3/sv56b444bPFVfS4ZnQWcwvVrcMJT2ruRb07cfqEBUfUWpfmychTTJa0tIsFa1/5m Z7GvGQy5Md0Mxdo6aCqDzQo1gTbCdxox4FJbyWhNzR9hlfSoAgEErGktV8NZBzQC7FEN 06c+IwF8s8kBY6W+zC1VW3RIjPh9GAKMbeco3pmLDRrl134u+ttqDljtobkA8pzNGOUW uKyG8mqFjxyW0QoaaL5H0OhEtzJr+ctWg+CoQJYP6ow+FNNve/0PRm/GCySIb59EFWUw g1pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=U4AcLqqdeQgo3VpB/7TbeuSwIP5HWMYQqeiDpcQA5PQ=; b=u8RHFqZ7GioOjSTwxSRT8f2IBVFMXsxgi9Tfzt/b/1/IgS4BnbQKW6nnp6tWtRZYiD AseBJZio3noby0T3NY3jPB1Dc0gc+DK4BwmI9OI/1txKXpy/dNQ2eX/GXN4QzEhsWrFt oZ0OuoDZiIszPO69KhXlxJMD0s9ew4yyIdoM2c5ai95BnTX/LkDnG5u1BJpHjNPZHYXU 78H4Q/LBGqPvIbyXoZrWU7KW5CwVcenO8HSXSWDk13fmiwiWOe3rl4xD+hJqX7hu3wXd /mdxeuSVJadQfWrKUrnUkAGOz+RjTVcVXEyw8w6cBT4aeMzrT7UIpzAEwrisnphcIj+V vpGQ== X-Gm-Message-State: ACgBeo3WhXWPJ6HiR0Z77Os/gnveaoS/X3Emojts/7wdmbZF5Wb91tUP awIjTGD4v0sgWsnPtAoc9KENPD/gIkI= X-Google-Smtp-Source: AA6agR4PyOYltFe2upkfQg2qP9TCddxxcCM6IR/I7RCQU3WOCNXaFWyyVfUpO1QEXRU62WVaPv17mw== X-Received: by 2002:a05:600c:2059:b0:3a5:92cc:19c5 with SMTP id p25-20020a05600c205900b003a592cc19c5mr1899813wmg.101.1660055905894; Tue, 09 Aug 2022 07:38:25 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id u11-20020a05600c19cb00b003a31b79dc0esm2539168wmq.1.2022.08.09.07.38.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Aug 2022 07:38:25 -0700 (PDT) Content-Language: en-US In-Reply-To: <83fsi5veln.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::332; envelope-from=raaahh@gmail.com; helo=mail-wm1-x332.google.com X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action 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:293309 Archived-At: On 09.08.2022 14:30, Eli Zaretskii wrote: >> 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. I never recommended you to change any of those vars. Doing that brings back pathological slowdowns that don't have anything to do with the speed of parse-partial-sexp. >> 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. > 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), 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. >> 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.