From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup 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 10:54:49 +0100 Organization: Organization?!? Message-ID: <878ute589i.fsf@fencepost.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1392371712 1526 80.91.229.3 (14 Feb 2014 09:55:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Feb 2014 09:55:12 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 14 10:55:19 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 1WEFUL-0000nj-8M for ged-emacs-devel@m.gmane.org; Fri, 14 Feb 2014 10:55:17 +0100 Original-Received: from localhost ([::1]:50583 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEFUK-0006KC-Ty for ged-emacs-devel@m.gmane.org; Fri, 14 Feb 2014 04:55:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54755) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEFUC-0006Jo-GS for emacs-devel@gnu.org; Fri, 14 Feb 2014 04:55:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WEFU7-0002Gh-6I for emacs-devel@gnu.org; Fri, 14 Feb 2014 04:55:08 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:45464) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEFU6-0002Ez-Vh for emacs-devel@gnu.org; Fri, 14 Feb 2014 04:55:03 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WEFU4-0000YQ-Bs for emacs-devel@gnu.org; Fri, 14 Feb 2014 10:55:00 +0100 Original-Received: from x2f44336.dyn.telefonica.de ([2.244.67.54]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 14 Feb 2014 10:55:00 +0100 Original-Received: from dak by x2f44336.dyn.telefonica.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 14 Feb 2014 10:55:00 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 32 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: x2f44336.dyn.telefonica.de X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:inzOMI0ZAQ3EIDaTe8Ygs1NzsJs= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:169600 Archived-At: Eli Zaretskii writes: >> Date: Fri, 14 Feb 2014 06:44:13 +0200 >> From: Dmitry Gutov >> Cc: emacs-devel@gnu.org >> >> Half-kidding aside, yeah, it sounds like indirect buffers might need >> some bugfixing to be usable as a building block for mmm-mode. > > I think features that want mode-specific behavior in some region of a > file need new infrastructure (that needs to be discussed and designed > first). Doing this mmm-style is IMO a terrible kludge that cannot > possibly work well. Serious functionality like that should stop > piggy-backing unrelated features in Emacs, and request infrastructure > that will serve them. Straining Emacs Lisp-related extensibility for > that is simply wrong, as it puts gratuitous pressure on existing > infrastructure, and stands in the way of future development by > imposing impossible backward compatibility requirements. It's not like there isn't use for it: flex and bison files (pattern/action) are multiple mode on a large scale, and even address/action languages like sed and awk have facets of multiple modes. LilyPond uses @lilypond tags in Texinfo to have examples written in LilyPond code (and embedded as images in the info files). Emacs can use text properties to switch syntax tables or categories or even keymaps in mid-buffer. Maybe switching the whole mode would be feasible in a similar manner. -- David Kastrup