From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: forward-sexp when on a floating point number Date: Mon, 18 Jan 2016 08:30:27 -0500 Message-ID: References: <87y4bvf59p.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1453123858 20553 80.91.229.3 (18 Jan 2016 13:30:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Jan 2016 13:30:58 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 18 14:30:49 2016 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 1aL9tR-0000K9-1Z for ged-emacs-devel@m.gmane.org; Mon, 18 Jan 2016 14:30:49 +0100 Original-Received: from localhost ([::1]:59779 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aL9tN-000532-7E for ged-emacs-devel@m.gmane.org; Mon, 18 Jan 2016 08:30:45 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50398) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aL9tA-00052R-3y for emacs-devel@gnu.org; Mon, 18 Jan 2016 08:30:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aL9t6-0000nI-Uu for emacs-devel@gnu.org; Mon, 18 Jan 2016 08:30:32 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:11283) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aL9t6-0000nB-Qr for emacs-devel@gnu.org; Mon, 18 Jan 2016 08:30:28 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ArEwA731xV/++PWxdcgxCEAoVVuzcJh0sEAgKBPDkUAQEBAQEBAYEKQQWDXQEBAwFWKAsLNBIUGA2IWwjPIwELIIs6hQwWhBcFjDCoVCOBZoIwIIJ4AQEB X-IPAS-Result: A0ArEwA731xV/++PWxdcgxCEAoVVuzcJh0sEAgKBPDkUAQEBAQEBAYEKQQWDXQEBAwFWKAsLNBIUGA2IWwjPIwELIIs6hQwWhBcFjDCoVCOBZoIwIIJ4AQEB X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="190133359" Original-Received: from 23-91-143-239.cpe.pppoe.ca (HELO pastel.home) ([23.91.143.239]) by ironport2-out.teksavvy.com with ESMTP; 18 Jan 2016 08:30:27 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id A7E825FF5B; Mon, 18 Jan 2016 08:30:27 -0500 (EST) In-Reply-To: (John Wiegley's message of "Sun, 17 Jan 2016 21:08:30 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:198250 Archived-At: >> Lexing via FSM is "standard" in the world of computer languages, so I'm >> pretty sure it'd be good/useful to add such functionality to Emacs's core. > If it can provide identical behavior, simpler and more efficiently, I'm happy > to swap out what we have in core. My suggestion is to *extend* syntax-table, such that (aref ) can return another syntax-table (IOW another state in the FSM, because the char we just considered is part of a token but that token isn't complete yet). Major modes could use it or not. > Yes, we control core, but that doesn't mean it should be the first place we > look to make changes when brewing new ideas. I largely agree. The main reason why it didn't turn out that way for many of the features I added is that I wanted to make use of them, and since most of the packages I work on (and use) are in core, I couldn't make use of those new features in them until that new feature is in core. It's also part of the motivation to try and bring GNU ELPA and core closer together (either by exporting core packages to GNU ELPA like we have now, or by including GNU ELPA packages into core like we want to do but still haven't done). Stefan PS: Lexing via FSM is harder than I make it out to be, of course, since multi-char tokens introduce the question of how to figure out with which state to start lexing (e.g. if we start a command from the middle of a token), as well as how to "tokenize backward" ("single-char tokens" (like we have now) can trivially be parsed with the same FSM going forward and backward, but that's not true for the more general case). Stefan