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: New optimisations for long raw strings in C++ Mode. Date: Thu, 11 Aug 2022 09:21:18 +0300 Message-ID: <83wnbfpag1.fsf@gnu.org> References: <87fsi5xw9l.fsf@gnus.org> <83wnbhtlzb.fsf@gnu.org> <703c2351d96919276449@heytings.org> <83o7wsqlcm.fsf@gnu.org> <83edxoqcnl.fsf@gnu.org> <83a68cqbm0.fsf@gnu.org> <834jykq9m6.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35044"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, gregory@heytings.org, larsi@gnus.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 11 08:28:25 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 1oM1g9-0008wV-BO for ged-emacs-devel@m.gmane-mx.org; Thu, 11 Aug 2022 08:28:25 +0200 Original-Received: from localhost ([::1]:55156 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oM1g8-0002tx-9u for ged-emacs-devel@m.gmane-mx.org; Thu, 11 Aug 2022 02:28:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33516) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oM1ZQ-0007wv-OO for emacs-devel@gnu.org; Thu, 11 Aug 2022 02:21:29 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:47408) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oM1ZO-0007jj-V7; Thu, 11 Aug 2022 02:21:26 -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=tigbAgwGuKgOCeojukwputRQ0fl0IQXo5cZEyZJTnoA=; b=QMfB1Pt7Fv2F hNSeSVeS8Jva6LdlDzEG+SKsYLB9fWf80XHPDKP4XdtIfYedQJrEB63NaR6hmUZR4hUDM/yKTNfpt WbYOpEH693rCzEAVi9RwetMr6FJPj1SCIXIz+FgYMp783z1W/i+ZjOrYOjkmvCikJTWjLOHjnXj8f 7/BPl1uXB7bmKLSehujk6SwcEgI5Bdd5mulfcjHGZM0HnxCVYVJxPpIyTyI8bh2ZiFv4gI/FnB0Dq cGqkc+qlDrTQbSXb2LbJbYVfWjq/K2QKvKX0YHwW3XcV6HErF7xBbM+dboEIcbbMk7ScXDcScZtHz 2DMgKxlCOMjYt0ja721Ddw==; Original-Received: from [87.69.77.57] (port=4962 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 1oM1ZN-00013C-Qy; Thu, 11 Aug 2022 02:21:26 -0400 In-Reply-To: (message from Stefan Monnier on Wed, 10 Aug 2022 18:31:00 -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:293371 Archived-At: > From: Stefan Monnier > Cc: Alan Mackenzie , gregory@heytings.org, larsi@gnus.org, > emacs-devel@gnu.org > Date: Wed, 10 Aug 2022 18:31:00 -0400 > > > Really? Then please tell me how is it that we the humans can detect > > incorrect fontifications even when shown partial strings and comments? > > That's usually because we can tell the difference between valid C code > and human text and then based on that we can heuristically guess whats > comment/strings/code. > Our guesses can be wrong, tho. And making such a guess without some > AI-style thingy is somewhat difficult. All true, but the alternative of going to BOB/BOL and coming back is much worse when BOB/BOL is very far away. > `syntax-begin-function` could use such a thing, but we made it obsolete > because making it work well tends to be costly. More costly than going back 20 million characters and then coming back? IOW, what is and isn't costly could change when compared with alternatives. For example, I recently made one of low-level subroutines in the display engine do something "costly" when the buffer has very long lines, and the result turned out to be a very large win in those cases. The "heavy" calculation is only used when the buffer is flagged to have very long lines; we could do something similar for syntax analysis as well.