From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel Subject: Using syntax tables to parse buffer content Date: Mon, 24 May 2021 13:21:00 -0700 Message-ID: <87o8czopcj.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22081"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) To: emacs-devel@gnu.org Cancel-Lock: sha1:54Iwl+tG8HEHm7gydbpXw80FqmE= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 24 22:22:19 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 1llH5e-0005WP-4e for ged-emacs-devel@m.gmane-mx.org; Mon, 24 May 2021 22:22:18 +0200 Original-Received: from localhost ([::1]:56010 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1llH5d-00019A-5x for ged-emacs-devel@m.gmane-mx.org; Mon, 24 May 2021 16:22:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35440) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1llH4p-0000Fz-LP for emacs-devel@gnu.org; Mon, 24 May 2021 16:21:29 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]:57230) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1llH4l-0000fg-9B for emacs-devel@gnu.org; Mon, 24 May 2021 16:21:25 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1llH4g-00042s-7p for emacs-devel@gnu.org; Mon, 24 May 2021 22:21:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:269804 Archived-At: [I sent this to emacs.help a few days ago, but am hoping I'll have better luck over here, sorry...] Hi! I often find myself parsing buffer or file contents using regular expressions, and would much rather be using lower-level character syntax to do it, both for reasons of speed and correctness. I've been looking into using syntax tables to assign certain classes to characters, and using either basic stuff like `skip-syntax-forward', or maybe `parse-partial-sexp', to pull substrings out of a buffer. My main problem now is escaping: I don't know how to treat escaped special characters as non-special. The simplest example is in vCard parsing. A property line might look like this: URL;TYPE=homepage:https\://mygreatpage.com/ ^ ^ ^ I've indicated the significant characters above: they include semicolon, colon, equals, and comma. The semicolon in the URL is escaped, and shouldn't be treated specially. These characters don't seem to fit the existing syntax classes, so I've considered defining my own categories for them. The manual mentions escape syntax characters (the "\" class), but doesn't quite make it clear *what* it escapes: I'm guessing only open/close parentheses, and string delimiters? Then there's character quote (the "/" class), which says the following character will "lose its normal syntactic meaning", but I can't get that to *do* anything. For example, in a text-mode test buffer, I add the "/" syntax class to ?*, then put that character before a space character, thinking it might negate the space's whitespace class. That doesn't happen, though, as (skip-syntax-forward "^ ") still stops at the space. What am I missing, and is this kind of custom escaping possible? I can peek back at the previous character, but at that point it's not too different from regexp parsing. Thanks in advance! Eric