From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii 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:28:18 +0200 Message-ID: <834n41db0d.fsf@gnu.org> 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> <87wqgxkcr9.fsf@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1392388159 6503 80.91.229.3 (14 Feb 2014 14:29:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Feb 2014 14:29:19 +0000 (UTC) Cc: dak@gnu.org, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 14 15:29:26 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 1WEJlc-0003vD-SO for ged-emacs-devel@m.gmane.org; Fri, 14 Feb 2014 15:29:25 +0100 Original-Received: from localhost ([::1]:52057 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEJlc-0003SA-F7 for ged-emacs-devel@m.gmane.org; Fri, 14 Feb 2014 09:29:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54771) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEJkp-0002Ye-Mp for emacs-devel@gnu.org; Fri, 14 Feb 2014 09:28:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WEJkk-00032b-DW for emacs-devel@gnu.org; Fri, 14 Feb 2014 09:28:35 -0500 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:40462) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEJkd-0002yP-TV; Fri, 14 Feb 2014 09:28:24 -0500 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0N0Z00O00OXPQD00@mtaout28.012.net.il>; Fri, 14 Feb 2014 16:29:15 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N0Z00MNHPKRH750@mtaout28.012.net.il>; Fri, 14 Feb 2014 16:29:15 +0200 (IST) In-reply-to: <87wqgxkcr9.fsf@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.184 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:169608 Archived-At: > From: Dmitry Gutov > Cc: David Kastrup , emacs-devel@gnu.org > Date: Fri, 14 Feb 2014 16:08:42 +0200 > > 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? Sorry, I'm not sure I understand the questions. What do you mean by "adaptation of `syntax-ppss'"? Information of region boundaries should surely come from the application level, but I wasn't talking about that. I was talking about how this information is _used_. > I guess adapting the default font-lock-fontify-region function and > syntax-propertize to be aware of them would be good To be aware of what? > but that could be done later. No, not "later", "sooner". We need to design first and implement later, not the other way around. We need to define the list of mode-specific features (such as indentation and fontification), and then design how these features will be applied only to a region of the text. One possibility would be a special text property, whose value is the major mode in effect for the text covered by that property. (I'm not saying this is the best idea, I'm just trying to explain what kind of infrastructure would be needed.) > > 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. I never said the region(s) must be contiguous. (Btw, explanation of why a given chunk needs to be aware of the previous chunk would be appreciated.) But yes, all of what you mention, and more, need to be considered, and the design should address these requirements. My point is that we should come up with a list of the requirements, and then design and implement the infrastructure which will support them, instead of implementing multi-mode buffers by piggybacking existing infrastructure, which was never designed to support such features.