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

[Eli Zaretskii]

> Date: Sun, 3 Dec 2017 21:20:40 +0000
> Cc: address@hidden, address@hidden, address@hidden,
>   address@hidden, address@hidden
> From: Alan Mackenzie <address@hidden>
> 
> > 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