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: Mon, 17 Feb 2014 09:34:05 -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 1392647687 7244 80.91.229.3 (17 Feb 2014 14:34:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 17 Feb 2014 14:34:47 +0000 (UTC) Cc: Michael Welsh Duggan , Eli Zaretskii , Emacs developers To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 17 15:34:54 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 1WFPHX-0007HM-1b for ged-emacs-devel@m.gmane.org; Mon, 17 Feb 2014 15:34:51 +0100 Original-Received: from localhost ([::1]:41138 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFPHW-00066N-E9 for ged-emacs-devel@m.gmane.org; Mon, 17 Feb 2014 09:34:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41672) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFPHL-00065S-FA for emacs-devel@gnu.org; Mon, 17 Feb 2014 09:34:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WFPHC-000130-DE for emacs-devel@gnu.org; Mon, 17 Feb 2014 09:34:39 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:40693) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFPGz-0000uK-Im; Mon, 17 Feb 2014 09:34:17 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFMCo7M/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYHCxQYDSSIHgbBLZEKA4hhnBmBXoMV X-IPAS-Result: Av4EABK/CFFMCo7M/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYHCxQYDSSIHgbBLZEKA4hhnBmBXoMV X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="47870715" 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; 17 Feb 2014 09:34:05 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 717B4610C3; Mon, 17 Feb 2014 09:34:05 -0500 (EST) In-Reply-To: (Juanma Barranquero's message of "Mon, 17 Feb 2014 04:00:52 +0100") 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:169692 Archived-At: > For multi-modes representing dynamically generated content (PHP + > HTML, etc.) there's going to be fragments that will be hard or > impossible to indent meaningfully. Can't be avoided, I think. Indeed. Just as is the case with macros and preprocessors. If/when this problems turns out to be significant, we'll see if there's something we can try to do, but for now, this seems like a fairly remote problem. > What about code that deals with the buffer's major-mode? In a PHP + > HTML buffer, or a Literate Haskell source (assuming it's a multi-mode > buffer with text and Haskell submodes), what will (with-current-buffer > "my-multi-buffer" major-mode) return? Does it depend on `point'? If > you switch the buffer's major-mode, does it change for all fragments? I'm not sure. Maybe it will depend. I'm leaning towards having a "main" major mode and leaving `major-mode' pointing to that. As mentioned elsewhere, it might also be a better choice to let this main major mode control the keymap. Stefan