From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Matt Swift Newsgroups: gmane.emacs.bugs Subject: Re: confusion over undocumented syntax-table features, font-lock and syntax-tables Date: Sun, 16 Feb 2003 00:46:57 -0500 Sender: bug-gnu-emacs-bounces+gnu-bug-gnu-emacs=m.gmane.org@gnu.org Message-ID: References: <200302152337.RAA15707@eel.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1045374380 29977 80.91.224.249 (16 Feb 2003 05:46:20 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 16 Feb 2003 05:46:20 +0000 (UTC) Cc: Luc Teirlinck Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18kHd4-0007nM-00 for ; Sun, 16 Feb 2003 06:46:18 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18kHe1-0003oO-00 for gnu-bug-gnu-emacs@m.gmane.org; Sun, 16 Feb 2003 00:47:17 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18kHdu-0003mp-00 for bug-gnu-emacs@gnu.org; Sun, 16 Feb 2003 00:47:10 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18kHdr-0003fj-00 for bug-gnu-emacs@gnu.org; Sun, 16 Feb 2003 00:47:08 -0500 Original-Received: from pool-68-160-54-133.bos.east.verizon.net ([68.160.54.133] helo=beth.swift.xxx) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18kHdq-0003bk-00 for bug-gnu-emacs@gnu.org; Sun, 16 Feb 2003 00:47:06 -0500 Original-Received: from beth.swift.xxx (swift@localhost [127.0.0.1]) h1G5kvBH008414verify=FAIL); Sun, 16 Feb 2003 00:46:57 -0500 Original-Received: (from swift@localhost) by beth.swift.xxx (8.12.6/8.12.6/Debian-8) id h1G5kv2o008412; Sun, 16 Feb 2003 00:46:57 -0500 Original-To: bug-gnu-emacs@gnu.org In-Reply-To: <200302152337.RAA15707@eel.dms.auburn.edu> (Luc Teirlinck's message of "Sat, 15 Feb 2003 17:37:26 -0600 (CST)") User-Agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/21.2 X-Mailscanner: clean (beth.swift.xxx) X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Bug reports for GNU Emacs, the Swiss army knife of text editors List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: bug-gnu-emacs-bounces+gnu-bug-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.bugs:4470 X-Report-Spam: http://spam.gmane.org/gmane.emacs.bugs:4470 >> "L" == Luc wrote: L> Hence there indeed is either an inaccuracy in the Elisp manual and the L> various documentation strings you alluded to in your prior posting or L> the usage in the packages you mentioned is inappropriate. L> I do not know which of the two alternatives applies. L> For string quote, it seems really strange. L> - Syntax class: string quote L> "String quote characters" (designated by `"') are used in many L> languages, including Lisp and C, to delimit string constants. L> The same string quote character appears at the beginning and the L> end of a string. Such quoted strings do not nest. What seems to be implied here by "the same" is that if distinct chars C and D are both declared as string-quote class, then for example the buffer substring C----D++++D====C contains the delimited string constants "----D++++D====" and "++++". If the initial C matched the next string-quote char rather than the next C, then the two strings would be "----" and "====". Perhaps the authors of these packages thought they would get the second result if they did not specify a matching character. Perhaps it was indeed necessary in an earlier version of Emacs. Perhaps it means something significant that no one has mentioned yet (I checked the source and it would take a long time for me to answer it that way; I am not really interested in the answer, it is just an issue that came up as a possible answer while I was trying to solve another problem.) L> Thus, if a package mentions the identical character as a matcher, then L> this seems totally redundant. If it mentions another character, it L> seems dangerous (at least to me), since plenty of Lisp code might L> expect the identical character to match, relying on the above quote. Following is a crude (i.e. incomplete) listing of packages in the latest CVS Emacs that specify a matching char for a char of class other than ( or ). You can't get a complete list with a single regexp match (the quoting and quote marks will drive you crazy, and many packages do not set the syntax table with constants), and this is trimmed of some false hits: ./progmodes/m4-mode.el:(modify-syntax-entry ?# "<\n" m4-mode-syntax-table) ./progmodes/m4-mode.el:(modify-syntax-entry ?\n ">#" m4-mode-syntax-table) ./textmodes/bibtex.el: (modify-syntax-entry ?$ "$$ " st) ./textmodes/sgml-mode.el: (modify-syntax-entry ?\" "\"\"" table)) ./textmodes/sgml-mode.el: (modify-syntax-entry ?\' "\"'" table)) Again with latest CVS Emacs, sh-script.el doesn't set it vars simply, but starting a fresh emacs and entering sh-mode[bash], then C-hs gives: C-j ># which means: endcomment, matches # " "" which means: string, matches " ' "' which means: string, matches ' ` "` which means: string, matches `