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: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch Date: Fri, 14 Feb 2014 16:08:42 +0200 Message-ID: <87wqgxkcr9.fsf@yandex.ru> References: <87r47bi1e5.fsf@yandex.ru> <52F96284.50507@yandex.ru> <52FAE12B.6060101@yandex.ru> <52FC3BEE.60604@yandex.ru> <52FCD2B4.5080006@yandex.ru> <52FD9F1D.50205@yandex.ru> <83mwhucg1h.fsf@gnu.org> <878ute589i.fsf@fencepost.gnu.org> <83d2iqc84m.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1392386939 22764 80.91.229.3 (14 Feb 2014 14:08:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Feb 2014 14:08:59 +0000 (UTC) Cc: David Kastrup , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 14 15:09:07 2014 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 1WEJRy-0001dK-3q for ged-emacs-devel@m.gmane.org; Fri, 14 Feb 2014 15:09:06 +0100 Original-Received: from localhost ([::1]:51928 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEJRx-0008BQ-L3 for ged-emacs-devel@m.gmane.org; Fri, 14 Feb 2014 09:09:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50765) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEJRp-0008Ad-Dz for emacs-devel@gnu.org; Fri, 14 Feb 2014 09:09:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WEJRk-0004BZ-3S for emacs-devel@gnu.org; Fri, 14 Feb 2014 09:08:57 -0500 Original-Received: from mail-ee0-x22d.google.com ([2a00:1450:4013:c00::22d]:35932) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEJRj-0004BN-Sk; Fri, 14 Feb 2014 09:08:52 -0500 Original-Received: by mail-ee0-f45.google.com with SMTP id b15so5699751eek.32 for ; Fri, 14 Feb 2014 06:08:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=tQGowEYHHGKfrWTey3krBIAdfMiVAXhVPvkSFrYEsOw=; b=xYxvAgQNqpD5C+otvLrVqZdoqL584ic9xW66MViEyYReQ9dIiTEALJ3x50ke3qvDiU boDv87nUaQe1gonDQ6kiHCkP1iy3djNpQHnStxKxhMvfqxqUZ7XcciHU/rLBw1KSqYOM 9BgjtimIArKqIwGFqZpbIhWiw4IP5F7L9npwE5sgNe8l3GteYht9H2/UsaW/ZOZumFX6 zyEEu5o4IarHrPc8ypgoQ3Y/qNAMffKzIvETjNkypizs/RCfX0QaP9hHhticBRuuPdhQ FXYOAVHNmxb2dMzgoCSqgD/62POgEaqVtnI8dBL0bEXv26nkoqjGhCXjczH9cNklnBLL VniA== X-Received: by 10.15.41.140 with SMTP id s12mr9499170eev.4.1392386930903; Fri, 14 Feb 2014 06:08:50 -0800 (PST) Original-Received: from axl (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by mx.google.com with ESMTPSA id s46sm20190643eeb.0.2014.02.14.06.08.47 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 14 Feb 2014 06:08:49 -0800 (PST) In-Reply-To: <83d2iqc84m.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 14 Feb 2014 12:15:53 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c00::22d 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:169604 Archived-At: Eli Zaretskii writes: > I agree that being able to support portions of a buffer that specify > their own major mode is an important feature. I'm just saying that we > need a suitable infrastructure for that, instead of trying to exploit > unrelated features, which seem like "a good idea". The first hint of a "suitable infrastructure" would be the adaptation of `syntax-ppss'. Where the information about region boundaries would come from, if not from mmm-mode? Text properties? Overlay properties? Where would they come from, if not from mmm-mode or similar package? I guess adapting the default font-lock-fontify-region function and syntax-propertize to be aware of them would be good, but that could be done later. > Yes, something like that. Basically, somehow present to major-mode > features only a portion of the buffer (e.g., by narrowing internally). This doest address primary mode regions, which a) need to see the previous chunks of the same mode, b) (for most functions) ignore the chunks of the submodes. But not for indentation: in some (!) mode combinations, the contents of submode regions influence indentation in the primary regions, namely in JSP, ERB and similar templates.