From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls Date: Mon, 4 Dec 2017 16:23:49 +0000 Message-ID: <20171204162349.GB5101@ACM> References: <83d13x1j2s.fsf@gnu.org> <34abea95-c7f7-e8fa-8407-8c2fd2a4cfe1@yandex.ru> <83y3mkzw1n.fsf@gnu.org> <83mv2zzv7z.fsf@gnu.org> <643908a3-bec8-3ac1-38f7-4e73611478ef@yandex.ru> <20171203185946.GC5531@ACM> <83indnzka2.fsf@gnu.org> <20171203212040.GA3907@ACM> <83shcqxyn4.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1512405052 31453 195.159.176.226 (4 Dec 2017 16:30:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 4 Dec 2017 16:30:52 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: tom@tromey.com, dgutov@yandex.ru, monnier@iro.umontreal.ca, spinuvit@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 04 17:30:40 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eLtdY-0007Bw-Ef for ged-emacs-devel@m.gmane.org; Mon, 04 Dec 2017 17:30:32 +0100 Original-Received: from localhost ([::1]:44001 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLtde-00081h-8d for ged-emacs-devel@m.gmane.org; Mon, 04 Dec 2017 11:30:38 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51478) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLtd5-00081Y-7G for emacs-devel@gnu.org; Mon, 04 Dec 2017 11:30:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLtd0-0000PB-Rk for emacs-devel@gnu.org; Mon, 04 Dec 2017 11:30:03 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:40385 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1eLtd0-0000Or-HT for emacs-devel@gnu.org; Mon, 04 Dec 2017 11:29:58 -0500 Original-Received: (qmail 52018 invoked by uid 3782); 4 Dec 2017 16:29:57 -0000 Original-Received: from acm.muc.de (p548C7AC7.dip0.t-ipconnect.de [84.140.122.199]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 04 Dec 2017 17:29:56 +0100 Original-Received: (qmail 8026 invoked by uid 1000); 4 Dec 2017 16:23:49 -0000 Content-Disposition: inline In-Reply-To: <83shcqxyn4.fsf@gnu.org> 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 [fuzzy] X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:220704 Archived-At: Hello, Eli. On Mon, Dec 04, 2017 at 18:10:07 +0200, Eli Zaretskii wrote: > > Date: Sun, 3 Dec 2017 21:20:40 +0000 > > Cc: tom@tromey.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, > > spinuvit@gmail.com, dgutov@yandex.ru > > From: Alan Mackenzie > > > actually don't understand all the fuss about widening. With a chunk > > > of C code embedded in something that is not C, CC Mode cannot possibly > > > need to look outside of the chunk, so why would you need to widen > > > beyond that? > > There is a style of coding called "literate programming" (I know nothing > > more about it) where pieces of C code (in C Mode, obviously) alternate > > with explanatory text (in text mode). If point is at the start of a C > > defun, C-M-a will have to take it to either the start of the text mode > > block or the previous C defun. Either way CC Mode needs to access > > buffer pieces outside the current chunk. > Does MMM support Literate Programming? If not, this is a separate > project, and we don't have to solve its problems now. I would like > first to reach a more limited goal: allow editing C/C++ snippets > inside Yacc grammars, Awk snippets inside shell scripts, and other > similar use cases. OK. > Can we do that first, and worry about higher-hanging fruit later? OK2. > > No, my main reason is philosophical. > You don't need to accept the philosophy just yet. It is possible that > we will find in the future a solution that is more easily generalized, > perhaps even more elegant, when we consider the more complex features > and tasks. Right now, the issue at hand is whether CC Mode will > support MMM. It sounds wrong to me to have MMM support that excludes > CC Mode. And the solution doesn't sound hard, just a bit tedious, and > at least some of it (replacing the calls to 'widen') quite mechanical. > > In Lisp, we're supposed to have > > the entire language available at read, evaluation, and print time. With > > this proposal, that notion becomes complicated and ugly, once you > > qualify how everything but `widen' and `narrow-to-region' are available. > I think you exaggerate. We have already some features whose correct > use requires some discipline, and breaks if one doesn't exercise such > discipline. It's less than ideal, but sometimes the ideal is not very > practical. I've been worried about Emacs losing its generality - that major modes can increasingly only be written in one restricted way, that `widen' can only be used by supermodes, etc. Maybe I've been seeing something which isn't really there. > In any case, I'm not asking you to like this restriction, just help > bring CC Mode into the MMM framework, because I think without that the > feature will be woefully incomplete. I will do what I can. Could you tell me where to find MMM? ;-) [ .... ] > > > > Yesterday, Richard Stallman suggested as an alternative to the > > > > purloining of `widen' and `narrow-to-region' that a new "region" be > > > > implemented somehow which would be independent of the existing region > > > > and used solely by MMM super-modes. How about exploring this > > > > possibility? > > > We can do that if needed, but I don't see the need yet. > > Then we won't do it at all. > We will if we get to the point where the current proposal is too > restrictive, or cannot support some features we want. Compare this > with the line numbers: linum.el exists, and we still added a native > implementation in the display engine. > I suggest to take a good look at what it will take to adapt CC Mode to > MMM. If it turns out that there are fundamental obstacles to that > which we currently don't envision, at least we will have a list of > concrete problems to solve, and that will facilitate designing a > solution. Sorry for being so uncooperative over the last couple of days. I agree that CC Mode must work together with MMM, and I will do everything I can to facilitate that. > TIA -- Alan Mackenzie (Nuremberg, Germany).