From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Tue, 17 Mar 2015 11:52:03 +0200 Message-ID: <834mpkymrg.fsf@gnu.org> References: <83pp9cwky8.fsf@gnu.org> <85a90ggf2d.fsf@stephe-leake.org> <54E0A40F.5080603@dancol.org> <83sie7un20.fsf@gnu.org> <54E0D181.2080802@dancol.org> <83r3trulse.fsf@gnu.org> <54E0D7E0.305@87.69.4.28> <83h9unukbg.fsf@gnu.org> <54E0DEF8.7020901@dancol> <83egpruiyp.fsf@gnu.org> <54E0FF93.2000104@dancol.org> <833865vp4d.fsf@gnu.org> <54E2355A.90@87.69.4.28> <83vbj1u020.fsf@gnu.org> <54E24CA4.9020601@dancol.org> <83h9uk7ddb.fsf@gnu.org> <54E382A5.5030408@dancol.org> <85a8zcu8gn.fsf@stephe-leake.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1426585964 504 80.91.229.3 (17 Mar 2015 09:52:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Mar 2015 09:52:44 +0000 (UTC) Cc: stephen_leake@stephe-leake.org, emacs-devel@gnu.org To: =?utf-8?Q?Aur=C3=A9lien?= Aptel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 17 10:52:35 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YXoAr-00018C-Tk for ged-emacs-devel@m.gmane.org; Tue, 17 Mar 2015 10:52:34 +0100 Original-Received: from localhost ([::1]:53546 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXoAr-0004w0-25 for ged-emacs-devel@m.gmane.org; Tue, 17 Mar 2015 05:52:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47568) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXoAf-0004vf-2E for emacs-devel@gnu.org; Tue, 17 Mar 2015 05:52:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YXoAa-00082M-DL for emacs-devel@gnu.org; Tue, 17 Mar 2015 05:52:20 -0400 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:47919) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXoAa-000820-4y for emacs-devel@gnu.org; Tue, 17 Mar 2015 05:52:16 -0400 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NLC00800NQ9RQ00@mtaout24.012.net.il> for emacs-devel@gnu.org; Tue, 17 Mar 2015 11:44:29 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NLC00BE3OE5LM00@mtaout24.012.net.il>; Tue, 17 Mar 2015 11:44:29 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.180 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:183948 Archived-At: > Date: Tue, 17 Mar 2015 10:28:13 +0100 > From: Aur=C3=A9lien Aptel > Cc: Emacs development discussions >=20 > > I still need to implement the lexer level, which will either need= to > > call the current elisp lexer, or access the buffer text directly. >=20 > No buffer or string access yet, sorry. I guess you can work around = it > by retrieving each character as an int but that's neither practical > nor efficient. Actually, most accesses to buffer text do precisely that: access one character at a time. The API typically accepts the buffer position. Why do you think this is inefficient? If we think modules will need to access lexical units, we might provide APIs for that, although I expect this to be complicated, due to the different semantics of what a "word" etc. is, buffer-local syntax tables, and other complications. Direct access to buffer text as a C array is also a possibility, but modules that do that will have to handle the gap, and also cope with buffer relocation (on platforms that use ralloc.c).