From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov 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 19:21:51 +0200 Message-ID: <87zjlpslhs.fsf@yandex.ru> References: <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 1392657741 1664 80.91.229.3 (17 Feb 2014 17:22:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 17 Feb 2014 17:22:21 +0000 (UTC) Cc: Michael Welsh Duggan , Juanma Barranquero , Eli Zaretskii , Emacs developers To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 17 18:22:29 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 1WFRtk-00069g-N3 for ged-emacs-devel@m.gmane.org; Mon, 17 Feb 2014 18:22:28 +0100 Original-Received: from localhost ([::1]:43017 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFRtk-0005fx-7a for ged-emacs-devel@m.gmane.org; Mon, 17 Feb 2014 12:22:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60903) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFRtP-0005JE-JP for emacs-devel@gnu.org; Mon, 17 Feb 2014 12:22:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WFRtK-00028k-8R for emacs-devel@gnu.org; Mon, 17 Feb 2014 12:22:07 -0500 Original-Received: from mail-ea0-x22e.google.com ([2a00:1450:4013:c01::22e]:54462) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFRtJ-00026b-QU; Mon, 17 Feb 2014 12:22:02 -0500 Original-Received: by mail-ea0-f174.google.com with SMTP id z10so4063057ead.33 for ; Mon, 17 Feb 2014 09:22:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=90k9laBeYqw6Kw1btdq2Nnw5ANXhUrv8pVq285cpPQw=; b=skE/OpQ7Ri3tSZJO4jaNZM1magJ9BwnFgRuDSGQRAA87cqv7cNzvZIvhDzyQf0helJ SlcQNWuAX/gktK3zO7lzUIdVCd762e6PSFga5ILT03Bl/to6TS/5NQfEvVexXOoKkk9l SG6cVxmvUj7FFRdeAJrtozlVXoM8P0J3QdfpuX73mzTrkLjrRks+sTqHuWIboG1qknJZ UCdudbkxtAaUwpxUwzPiCZR/tLFhDmpECpwkTpFSy2p1X31kd6pW1jKAuApV5gfc1DcG aD62g5cDo+At8geLTXmGhqOID2G3JSrZTs8xm6o2602dH0/7HaWUQ4Rw82t2pvZj+zcF i26w== X-Received: by 10.14.205.3 with SMTP id i3mr28085941eeo.23.1392657720793; Mon, 17 Feb 2014 09:22:00 -0800 (PST) Original-Received: from axl (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by mx.google.com with ESMTPSA id g1sm59604631eet.6.2014.02.17.09.21.58 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 17 Feb 2014 09:21:59 -0800 (PST) In-Reply-To: (Stefan Monnier's message of "Mon, 17 Feb 2014 09:34:05 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::22e 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:169707 Archived-At: Stefan Monnier writes: > I'm not sure. Maybe it will depend. I'm leaning towards having > a "main" major mode and leaving `major-mode' pointing to that. It could be best. Any code that depends on a major mode will likely break in multi-mode environment if it's not aware of it. Maybe have a secondary local variable that would point to the current submode (like mmm-current-mode). > As mentioned elsewhere, it might also be a better choice to let this > main major mode control the keymap. I'd rather not do that. Some modes override common commands via the keymap, rather than some `-function[s]' hook. What about submode-local minor modes and their keymaps? Do we prohibit those?