From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch Date: Sun, 16 Feb 2014 21:40:18 -0500 Message-ID: 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> <834n41db0d.fsf@gnu.org> <87k3cw53d1.fsf@maru2.md5i.com> <83lhxcbzs2.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1392604839 6790 80.91.229.3 (17 Feb 2014 02:40:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 17 Feb 2014 02:40:39 +0000 (UTC) Cc: Michael Welsh Duggan , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 17 03:40:46 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 1WFE8U-00020K-3X for ged-emacs-devel@m.gmane.org; Mon, 17 Feb 2014 03:40:46 +0100 Original-Received: from localhost ([::1]:36359 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFE8T-0007Xw-LW for ged-emacs-devel@m.gmane.org; Sun, 16 Feb 2014 21:40:45 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45580) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFE8J-0007Xn-Q4 for emacs-devel@gnu.org; Sun, 16 Feb 2014 21:40:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WFE8C-0001oG-Fk for emacs-devel@gnu.org; Sun, 16 Feb 2014 21:40:35 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:36603) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFE83-0001nc-Uo; Sun, 16 Feb 2014 21:40:19 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFFMCo7M/2dsb2JhbABEvw4Xc4IeAQEEAVYcBwULCzQHCxQYDSQuh3AGwS2RCgOIYZwZgV6DFQ X-IPAS-Result: Av8EABK/CFFMCo7M/2dsb2JhbABEvw4Xc4IeAQEEAVYcBwULCzQHCxQYDSQuh3AGwS2RCgOIYZwZgV6DFQ X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="47843799" Original-Received: from 76-10-142-204.dsl.teksavvy.com (HELO pastel.home) ([76.10.142.204]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 16 Feb 2014 21:40:18 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 64D7F600A2; Sun, 16 Feb 2014 21:40:18 -0500 (EST) In-Reply-To: <83lhxcbzs2.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 15 Feb 2014 09:28:29 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:169676 Archived-At: > E.g., what you suggest would require a serious surgery on the design > of the display engine, Not just the display engine: you'd also have to figure out how to handle the load&save of this, how to get things like next-line or rectangle-mark-mode to handle it properly, ... It might be an interesting idea that could be occasionally attractive (maybe for Gnus's rendering of attachments?), but for mmm-mode, it sounds like adding problems rather than providing a solution. > So I really think we should define the requirements first. To me, the requirements look like: - font-lock and syntax-propertize, each sub-part according to its own mode and according to its context which can depend on the immediately preceding chunk (even tho it's in a different mode) as well as on some earlier chunk in the same mode. - indentation is done according to the mode to which BOL belongs, I think. - there can be nesting relationships between chunks, e.g. with two major modes A and B, a sequence of chunks of "A1, B1, A2, B2, A3" could represent "(A1 (B1) A2 (B2) A3)" or "(A1 (B1 (A2) B2) A3)", where indentation of A3 could depend on A1 in the second case but on A2 in the first. - some minor modes might be specific to "chunks in major mode A", while others are "global to the whole buffer". - key-bindings should probably be looked up according to the "mode at point". - navigation should ideally understand the overall structure of the buffer, so forward-sexp knows how to jump over a "sub-chunk" written in another mode. - M-; and many other such commands should use the "mode at point". - not sure whether imenu should combine the list of definitions of all chunks in the buffer. - commands which are mode-agnostic (such as next-line or rectangle-mark-mode) should be unaffected. Not sure if it's the kind of requirements you were thinking about. Stefan