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:38:13 +0200 Message-ID: <8338jldaju.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1392388704 12520 80.91.229.3 (14 Feb 2014 14:38:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Feb 2014 14:38:24 +0000 (UTC) Cc: emacs-devel@gnu.org, dgutov@yandex.ru To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 14 15:38:32 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 1WEJuR-00046r-M4 for ged-emacs-devel@m.gmane.org; Fri, 14 Feb 2014 15:38:31 +0100 Original-Received: from localhost ([::1]:52100 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEJuR-0001Nf-9Y for ged-emacs-devel@m.gmane.org; Fri, 14 Feb 2014 09:38:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56831) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEJuJ-00013g-Qf for emacs-devel@gnu.org; Fri, 14 Feb 2014 09:38:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WEJuE-0006EG-0H for emacs-devel@gnu.org; Fri, 14 Feb 2014 09:38:23 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:55137) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEJuD-0006Dc-O4 for emacs-devel@gnu.org; Fri, 14 Feb 2014 09:38:17 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0N0Z00300PM6AA00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Fri, 14 Feb 2014 16:38:16 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N0Z003S4PZR1880@a-mtaout20.012.net.il>; Fri, 14 Feb 2014 16:38:16 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:169610 Archived-At: > From: Stefan Monnier > Cc: Dmitry Gutov , emacs-devel@gnu.org > Date: Fri, 14 Feb 2014 09:10:47 -0500 > > I've been following those multiple major mode thingies for quite a few > years now. I don't think we really need a significant new > infrastructure at the C level. Please explain why you think so. My line of reasoning was that since fontification happens on the display engine level, we need to have a way to call a different fontification function for different portions of text. And similarly with indentation and other mode-specific behavior. > What we need instead is some conventions that major modes need to > follow to play well in things like mmm-mode or mumamo. Like what? > E.g. I don't think "pseudo-narrowing" to magically pretend that only the > current "code chunk" exists is going to fly: it will break major modes > that don't follow pretty much the same conventions. Examples, please: which conventions are those? There's almost no code in Emacs that ignores the buffer restrictions (everything uses BEGV and ZV). Even the display engine itself does that. The text outside these restrictions simply does not exist, as far as Emacs is concerned. > As for whether multiple major modes are frequent: I consider comments > and strings as being "text-mode" chunks. Not sure if we'll ever get to > the point of integrating the handling of strings/comments with the > handling of other forms of multi-major-modes, tho. Literate programming is impossible without multi-mode support. Org-style notes and documents are another frequent use case. And I'm sure people will come with more. So I think these are quite important, and we should support them reasonably well, not through kludges.