From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Reliable after-change-functions (via: Using incremental parsing in Emacs) Date: Sat, 04 Apr 2020 10:13:18 +0300 Message-ID: <83tv1zvi41.fsf@gnu.org> References: <83369o1khx.fsf@gnu.org> <83imijz68s.fsf@gnu.org> <831rp7ypam.fsf@gnu.org> <86wo6yhj4d.fsf@stephe-leake.org> <83r1x6x8df.fsf@gnu.org> <86tv21fgls.fsf@stephe-leake.org> <83zhbtvwsm.fsf@gnu.org> <868sjcfoon.fsf@stephe-leake.org> <83369kwhds.fsf@gnu.org> <867dywdsln.fsf@stephe-leake.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="100332"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 04 09:14:15 2020 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 1jKd0R-000Q1a-Fm for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Apr 2020 09:14:15 +0200 Original-Received: from localhost ([::1]:36062 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jKd0Q-0007Rc-Ik for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Apr 2020 03:14:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39422) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jKczi-0006ki-Ep for emacs-devel@gnu.org; Sat, 04 Apr 2020 03:13:31 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39541) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jKczh-00087E-VZ; Sat, 04 Apr 2020 03:13:30 -0400 Original-Received: from [176.228.60.248] (port=4324 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jKczh-0000BF-9H; Sat, 04 Apr 2020 03:13:29 -0400 In-Reply-To: <867dywdsln.fsf@stephe-leake.org> (message from Stephen Leake on Fri, 03 Apr 2020 16:04:04 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:246373 Archived-At: > From: Stephen Leake > Date: Fri, 03 Apr 2020 16:04:04 -0800 > > >> Since are are calling the parser from C (if it is linked into Emacs, or > >> in a module), I still don't understand. Does C code have to cons to > >> create a string? > > > > If course. How else do you get a UTF-8 encoded string to pass to the > > parser as a copy of buffer text? > > malloc and memcpy. How do you know how much memory to allocate? And memcpy doesn't cut it, because you forgot the encoding step. You could, of course, take the low-level encoding code from coding.c and make your own high-level functions that don't work with Lisp objects. But (a) why bother doing that? and (b) I think you will quickly find out that this is a non-trivial job, since coding.c "knows", to the lowest level, that it's dealing with Lisp objects (buffers or strings), so you'd need pretty much to rewrite everything. It's no accident that the Cygwin port uses the Lisp string machinery even when it needs to convert strings from UTF-16 (see from_unicode), even though it basically needs to convert C strings. > I guess that's what you mean by "cons"; I was assuming you meant the > actual elisp function. No, I meant "consing" as in "make a Lisp string", then encode it (which makes another Lisp string).