From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Writing syntax-propertize-function for strings in code in strings, etc Date: Sat, 27 Oct 2012 01:52:06 +0400 Message-ID: <508B0606.5040209@yandex.ru> References: <87a9x1jiyu.fsf@yandex.ru> <504FE870.7070002@yandex.ru> <508AE1F2.4000408@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1351288330 9741 80.91.229.3 (26 Oct 2012 21:52:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Oct 2012 21:52:10 +0000 (UTC) Cc: emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 26 23:52:19 2012 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 1TRrpD-0008Gd-3s for ged-emacs-devel@m.gmane.org; Fri, 26 Oct 2012 23:52:19 +0200 Original-Received: from localhost ([::1]:42574 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRrp5-0001k0-8w for ged-emacs-devel@m.gmane.org; Fri, 26 Oct 2012 17:52:11 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:36721) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRrp2-0001js-Pu for emacs-devel@gnu.org; Fri, 26 Oct 2012 17:52:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TRrp1-0005Ih-MD for emacs-devel@gnu.org; Fri, 26 Oct 2012 17:52:08 -0400 Original-Received: from forward20.mail.yandex.net ([95.108.253.145]:59610) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRrp1-0005IN-6S for emacs-devel@gnu.org; Fri, 26 Oct 2012 17:52:07 -0400 Original-Received: from smtp18.mail.yandex.net (smtp18.mail.yandex.net [95.108.252.18]) by forward20.mail.yandex.net (Yandex) with ESMTP id BFC6F10431B2; Sat, 27 Oct 2012 01:52:03 +0400 (MSK) Original-Received: from smtp18.mail.yandex.net (localhost [127.0.0.1]) by smtp18.mail.yandex.net (Yandex) with ESMTP id 99D3F18A0401; Sat, 27 Oct 2012 01:52:03 +0400 (MSK) Original-Received: from 5x166x242x229.dynamic.spb.ertelecom.ru (5x166x242x229.dynamic.spb.ertelecom.ru [5.166.242.229]) by smtp18.mail.yandex.net (nwsmtp/Yandex) with ESMTP id q2OmTGGF-q3OmTq3R; Sat, 27 Oct 2012 01:52:03 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1351288323; bh=ULGHdaETy8k/ExpO34Ee9OmD9q1ghok3MVh1cyckbxk=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=t5l+JSPHF3HpYWObPnyG/LFJr/kNh2ac+QZXqFvuL23GlbS2l35vUWobU2TrMvzba Pk8EOp7cnL3ocfSjB+bVJk4UDNtIpKT9NBv+sroVu/JGJB8z9baZBX+048q5pNvh5L NRK8GduQD3Wmo44lTvOQvQAE5rSTlNp8VDy7JW2E= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 95.108.253.145 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:154531 Archived-At: On 27.10.2012 0:41, Stefan Monnier wrote: >>> Yes, one "push " and one "pop". >> So, I don't see the usefulness of the value in the >> simple case of embedding code in the same language. > > It's for the other cases: strings with strings and comments within strings. Okay. I guess I just don't know [well enough] any languages with different embedded syntaxes. >> Unless we're doing something like the "multiple-modes" use case, which we >> discussed in another thread. > > Yes, it potentially could be used for m-m-m, tho it would only be > a piece of the puzzle (and it's not clear how useful that piece would be > in the end, once we have the whole puzzle). It will help with third-party frameworks, at least, which is what we discussed back then, that (syntax-ppss) will return reasonable values. >>> Of course, this is fine for parse-partial-sexp, but it's a different >>> matter for backward-sexp, where the "pop" would also need to know the >>> . >> Maybe in the latter case the scanning function, when encountering the "pop" >> syntax property, would just skip ahead until it finds the corresponding >> "push"? > > Without knowing the inner syntax table, it's pretty difficult to know > what can be skipped (unless we assume that the "push" can only be marked > with a `syntax-table' text-property). Indeed. But I think it's a reasonable assumption. In all cases I can think about the "region opener" is at least two characters long, and it often depends on the context (like only inside a string). But suppose "push" characters can be set inside a syntax table. Let's move point inside an embedded code region, maybe several levels deep. Now we want to call `forward-sexp'. How will it know the effective syntax-table value at that position?