From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#16915: 24.3.50; [ruby-mode] Comments in regexps using the extended syntax are not font-locked properly Date: Mon, 10 Mar 2014 10:40:12 -0400 Message-ID: References: <87y50to93u.fsf@yandex.ru> <531D67DE.4030200@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1394462477 29034 80.91.229.3 (10 Mar 2014 14:41:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Mar 2014 14:41:17 +0000 (UTC) Cc: 16915@debbugs.gnu.org, Bozhidar Batsov To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Mar 10 15:41:25 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1WN1ON-0007Kh-QW for geb-bug-gnu-emacs@m.gmane.org; Mon, 10 Mar 2014 15:41:24 +0100 Original-Received: from localhost ([::1]:49146 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WN1OM-0003WA-RF for geb-bug-gnu-emacs@m.gmane.org; Mon, 10 Mar 2014 10:41:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43357) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WN1OB-00038Z-8X for bug-gnu-emacs@gnu.org; Mon, 10 Mar 2014 10:41:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WN1O3-0003Au-Rg for bug-gnu-emacs@gnu.org; Mon, 10 Mar 2014 10:41:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59227) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WN1O3-0003Al-O1 for bug-gnu-emacs@gnu.org; Mon, 10 Mar 2014 10:41:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WN1O3-0007kD-3t for bug-gnu-emacs@gnu.org; Mon, 10 Mar 2014 10:41:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 10 Mar 2014 14:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16915 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16915-submit@debbugs.gnu.org id=B16915.139446242229691 (code B ref 16915); Mon, 10 Mar 2014 14:41:02 +0000 Original-Received: (at 16915) by debbugs.gnu.org; 10 Mar 2014 14:40:22 +0000 Original-Received: from localhost ([127.0.0.1]:60409 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WN1NN-0007il-GI for submit@debbugs.gnu.org; Mon, 10 Mar 2014 10:40:22 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:16788) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WN1NG-0007iW-F3 for 16915@debbugs.gnu.org; Mon, 10 Mar 2014 10:40:15 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFFMCppy/2dsb2JhbAA8CLs1g1kXc4IeAQEEAVYjBQsLDiYHCxQYDSSIHgbBLY0bg28DklqSIIFegxM X-IPAS-Result: Av8EABK/CFFMCppy/2dsb2JhbAA8CLs1g1kXc4IeAQEEAVYjBQsLDiYHCxQYDSSIHgbBLY0bg28DklqSIIFegxM X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="50988486" Original-Received: from 76-10-154-114.dsl.teksavvy.com (HELO pastel.home) ([76.10.154.114]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 10 Mar 2014 10:40:13 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id E11F6606E8; Mon, 10 Mar 2014 10:40:12 -0400 (EDT) In-Reply-To: <531D67DE.4030200@yandex.ru> (Dmitry Gutov's message of "Mon, 10 Mar 2014 09:21:02 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:86718 Archived-At: >> My preference would be to think about it as a "multi-mode" case, and >> hence make it possible to specify a different syntax-table to use within >> the regexp. > I remember this idea, but have a hard time viewing it in the context of our > latest discussion on the subject of multi-modes. > First, why only syntax-table? It was not meant as excluding other data. > For this specific case, a syntax table change is not required, we only > need to be able to view the text between /'s as a separate context Not necessarily required in all cases, but in order to handle the various existing cases in various languages, we need some way to indicate, for instance: - Do double quotes introduce strings when used within this new context? - Do comment chars introduce comments when used within this new context? - Does \ still escape chars in this new context? We usually use syntax-tables for that. They do provide more flexibility than needed (so far), such as making it possible to allow different commenting conventions within the new context. But it seems like a "simple" way to handle the problem, so the extra generality is a bonus. > (but - and this is a change from certain other multi-mode uses - still > fontify uncommented text inside them with the regexp face). But in the > general case, we would at least want to be able to change > font-lock-keywords, too. `font-lock-keywords' can use `syntax-ppss' to decide which rules to use (since syntax-ppss would have to include the "context state" somewhere in its output). It's not terribly convenient to do currently, so we may want to provide a new replacement for font-lock-keywords which makes it easier (and avoids relying on "eval" while we're at it). >> I think of it along the lines of a new syntax-class, applied to the "/" >> char, which would change the syntax-table for the subsequent text. > How would this interact with a new hook that would `syntax-ppss' would run > on the cached entries? The way I imagine it, it would work at the parse-partial-sexp level (extending the returned PPSS with a new field indicating the current syntax-table or something similar). So syntax.el would stay basically unchanged. How that would interact with a new hook? Haven't thought about it yet. > Would its default value look for the chars bearing the new syntax class? I don't really understand the question. But I'd guess that I don't know the answer. Stefan