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: Fri, 14 Feb 2014 11:53:48 -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> <8338jldaju.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1392396882 20596 80.91.229.3 (14 Feb 2014 16:54:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Feb 2014 16:54:42 +0000 (UTC) Cc: emacs-devel@gnu.org, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 14 17:54: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 1WEM2H-0007gH-VJ for ged-emacs-devel@m.gmane.org; Fri, 14 Feb 2014 17:54:46 +0100 Original-Received: from localhost ([::1]:52751 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEM2H-0004uE-AZ for ged-emacs-devel@m.gmane.org; Fri, 14 Feb 2014 11:54:45 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54634) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEM26-0004sE-6X for emacs-devel@gnu.org; Fri, 14 Feb 2014 11:54:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WEM1y-0000u7-5A for emacs-devel@gnu.org; Fri, 14 Feb 2014 11:54:34 -0500 Original-Received: from mercure.iro.umontreal.ca ([132.204.24.67]:52692) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEM1l-0000sY-UA; Fri, 14 Feb 2014 11:54:14 -0500 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 7FAB284DC6; Fri, 14 Feb 2014 11:54:12 -0500 (EST) Original-Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 4FCD41E5913; Fri, 14 Feb 2014 11:53:48 -0500 (EST) Original-Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 34309B40FE; Fri, 14 Feb 2014 11:53:48 -0500 (EST) In-Reply-To: <8338jldaju.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 14 Feb 2014 16:38:13 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 132.204.24.67 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:169622 Archived-At: > 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. And all of those are done in Elisp, so there's no need for C-level changes. >> 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? Like "font-lock-keywords can only look before/after the provided region boundaries by calling special functions". > Examples, please: which conventions are those? There's almost no code > in Emacs that ignores the buffer restrictions (everything uses BEGV > and ZV). That's not the issue. The issue is that code can misbehave if it is prevented from seeing some of the "outer" text. Narrowing is used sufficiently rarely that we don't see it too often, but such problems do occur already with narrowing. > So I think these are quite important, and we should support them > reasonably well, not through kludges. We violently agree. Stefan