From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls Date: Mon, 04 Dec 2017 18:10:07 +0200 Message-ID: <83shcqxyn4.fsf@gnu.org> References: <83lgil1qme.fsf@gnu.org> <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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1512403950 21519 195.159.176.226 (4 Dec 2017 16:12:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 4 Dec 2017 16:12:30 +0000 (UTC) Cc: tom@tromey.com, dgutov@yandex.ru, monnier@iro.umontreal.ca, spinuvit@gmail.com, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 04 17:12:25 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 1eLtM0-0005Jr-9R for ged-emacs-devel@m.gmane.org; Mon, 04 Dec 2017 17:12:24 +0100 Original-Received: from localhost ([::1]:43899 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLtM7-0004jP-FW for ged-emacs-devel@m.gmane.org; Mon, 04 Dec 2017 11:12:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43255) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLtKP-0003uS-MK for emacs-devel@gnu.org; Mon, 04 Dec 2017 11:10:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLtKK-0006iF-Ns for emacs-devel@gnu.org; Mon, 04 Dec 2017 11:10:45 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57048) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLtK0-0006Uz-D3; Mon, 04 Dec 2017 11:10:20 -0500 Original-Received: from [176.228.60.248] (port=4295 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eLtJz-0005ny-F5; Mon, 04 Dec 2017 11:10:19 -0500 In-reply-to: <20171203212040.GA3907@ACM> (message from Alan Mackenzie on Sun, 3 Dec 2017 21:20:40 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:220700 Archived-At: > 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. Can we do that first, and worry about higher-hanging fruit later? > 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. 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. > > This can be taken care of with a more-or-less trivial wrapper and a > > variable. Right? > > I suppose so, but it will degrade such a function effectively into two, > one special purpose function which can only be called from > beginning-of-defun-function (etc.) and the other one called from > everywhere else. There will be confusion between them. I don't think I understand the need for two functions. Can you elaborate, please? > > > 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. TIA