From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:] Date: Thu, 24 Mar 2016 17:44:04 +0000 Message-ID: <20160324174404.GA2721@acm.fritz.box> References: <8737riqouj.fsf@gmail.com> <221845e0-b194-433e-bfbc-105272ae5752@default> <87twjyp21k.fsf@gmail.com> <56F242E0.7060004@online.de> <877fgtpfrw.fsf@gmail.com> <20160323211605.GA5324@acm.fritz.box> <871t70onzf.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1458841299 26632 80.91.229.3 (24 Mar 2016 17:41:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Mar 2016 17:41:39 +0000 (UTC) Cc: Andreas =?iso-8859-1?Q?R=F6hler?= , emacs-devel@gnu.org, Stefan Monnier , Dmitry Gutov , Eli Zaretskii , Drew Adams To: Vitalie Spinu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 24 18:41:30 2016 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 1aj9GD-0007Dx-CZ for ged-emacs-devel@m.gmane.org; Thu, 24 Mar 2016 18:41:29 +0100 Original-Received: from localhost ([::1]:52068 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aj9G9-0000sU-74 for ged-emacs-devel@m.gmane.org; Thu, 24 Mar 2016 13:41:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46565) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aj9G5-0000s5-Ip for emacs-devel@gnu.org; Thu, 24 Mar 2016 13:41:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aj9G2-0007u4-Ky for emacs-devel@gnu.org; Thu, 24 Mar 2016 13:41:21 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:53198) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aj9G2-0007tt-Br for emacs-devel@gnu.org; Thu, 24 Mar 2016 13:41:18 -0400 Original-Received: (qmail 85981 invoked by uid 3782); 24 Mar 2016 17:41:16 -0000 Original-Received: from acm.muc.de (p579E9D87.dip0.t-ipconnect.de [87.158.157.135]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 24 Mar 2016 18:41:14 +0100 Original-Received: (qmail 4823 invoked by uid 1000); 24 Mar 2016 17:44:04 -0000 Content-Disposition: inline In-Reply-To: <871t70onzf.fsf@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 193.149.48.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:202188 Archived-At: Hello, Vitalie. On Wed, Mar 23, 2016 at 10:58:44PM +0100, Vitalie Spinu wrote: > > To transcend the "unwanted widen" problem, there will be a very special > > variable `restrict-to-island' or `restrict-to-span', > A second type of narrowing. That is what Stefan was insisting upon and that's > what I will provide next patch for. A type of narrowing is not a good way of thinking about it. > > Although the above vision implies a lot of development work, there is > > nothing there which is beyond our abilities to implement readily. It > > would give us a true multi major mode capability, yet the impact on > > individual major modes would be minimal. > A lot of development work is already happening in various generic multi-mode > engines. It's hard, but feasible and stuff mostly works without changing any of > the existing code. It "mostly" works, sort of, from what I can gather in threads like this one. My impression is that with better support in the Emacs core, it could work fully, without unlovely artifices. But nobody else has so far shown much interest, so it seems it won't happen. > Making parse-partial-sexp understand islands won't give much. That was not what my post, to which you are replying, was about. It was far more ambitious than that. > You can already do that well enough by advising syntax-ppss. I doubt that very much. syntax-ppss is just one of many ways of using parse-partial-sexp. But I'd love to see the code. Has it been committed, and if so, into which branch? > Vitalie -- Alan Mackenzie (Nuremberg, Germany).