From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: cc-mode fontification feels random Date: Fri, 4 Jun 2021 11:36:05 -0700 Message-ID: <371647e9-9508-ae98-26f0-3649d7ba114e@dancol.org> References: <831r9iw473.fsf@gnu.org> <2d6d1cb0-2e8f-ceea-cb83-3bb840b65115@dancol.org> <83zgw6udxt.fsf@gnu.org> <87czt1zzns.fsf@gmail.com> 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="18611"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier , =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 04 20:39:29 2021 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 1lpEj9-0004Zz-OL for ged-emacs-devel@m.gmane-mx.org; Fri, 04 Jun 2021 20:39:29 +0200 Original-Received: from localhost ([::1]:49308 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lpEj8-000616-E2 for ged-emacs-devel@m.gmane-mx.org; Fri, 04 Jun 2021 14:39:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45728) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lpEfz-0000Lu-9w for emacs-devel@gnu.org; Fri, 04 Jun 2021 14:36:11 -0400 Original-Received: from dancol.org ([96.126.100.184]:58022) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lpEfx-0001WV-82; Fri, 04 Jun 2021 14:36:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=0zfxyOz1lpw0+bcDeWtmq6BXalDc5hQhY5EoW+ohP0s=; b=hgw0WD6yQXJgionjXig3OFL8vl zAihRCTA9iNxCE2+26ni4tLUIQz9tBRrNnd29QJidcExASesTmjzDqMr0wMG8XAet93xTHCpSZq8m CuJ7TLOoRuw63eovXyy16oESsxJJ0EW33RKqNeSMBDQEKL91u9zQFxq/Oyaxv72MwKxI8YzHBt74j qFssWj9pdRrZYr0X88t91CMePoMCn7jop7sBEf5q4MWL9z0aoyziHzYPvjYyHspqUsYGyFRBencZ6 v5+NH+B2FOFW0RIsSj+AquRgM50ObFcPLmEwpFwdtiEBOgfobk4Mag+LtuvUVCFd7Af+Zaw8lHiQj AKO0xCCw==; Original-Received: from [172.92.145.124] (port=55712 helo=[192.168.86.213]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1lpEfu-0004ZB-PX; Fri, 04 Jun 2021 11:36:06 -0700 In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=96.126.100.184; envelope-from=dancol@dancol.org; helo=dancol.org X-Spam_score_int: -26 X-Spam_score: -2.7 X-Spam_bar: -- X-Spam_report: (-2.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.59, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:270397 Archived-At: On 6/4/21 11:25 AM, Stefan Monnier wrote: >> But I don't understand what's stopping these tree-sitter C modules (like >> [1] and [2]) to have access to the buffer's contents directly and have >> the best of both worlds. > I think it's a direct result of them being "modules": the API doesn't > let modules access a buffer's content directly, so it's more efficient > copy the content via `buffer-substring` and toss it on the other side > than having to use something like `char-after`. The problem is more fundamental than that. Internally, each buffer has a gap. External tools that operate on char arrays don't expect a gap. (They also don't expect to operate on Emacs internal coding, but that's another issue.) If we *did* grant direct buffer access via modules, we'd at least have to memcpy half (on average) the buffer to close the gap, then memcpy half the buffer (on average) to open the gap again when we began editing. If we're going to copy anyway, let's just copy via the buffer-substring interface. There's no reason that it has to be particularly inefficient. Besides, memory copies are really, really, ridiculously fast. My system can cat from /dev/zero to /dev/null at ~18GB/sec. Copying a buffer's contents so we can give it to tree-sitter should be no issue at all.