Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls

[Alan Mackenzie <acm@muc.de>]

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 <acm@muc.de>

> > > 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).