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

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Fri, Dec 01, 2017 at 11:26:08 -0500, Stefan Monnier wrote:
> >> To rephrase, don't widen in indent-line-function or
> >> beginning-of-defun-function.
> > This is an intolerable restriction.  The low level function mentioned
> > above cannot, should not, must not know whether it's being called
> > (indirectly) from indent-line-function or b-o-d-function.

> It's a change.  So, to make it work right, some code will need to adapt.
> As mentioned by Dmitry, this shouldn't introduce breakage in general:

That has yet to be shown.

> the code will only need to adapt *if* it wants to work with
> multi-major-mode solutions.  For the normal use case, you can still
> widen/narrow to your heart's content and nobody will be the wiser.

If we're going to have a multi-major-mode solution (and I think we
should), let's at least get it right.  I.e., it should work with _any_
major mode without grotesque restrictions on that mode.

I would very much like to have AWK Mode working inside a
shell-script-mode buffer.  Why not?  The MMM solution which appears to
be being proposed won't achieve this.

I would very much like the option of handling C buffers as MMM buffers,
where macros would be handled by a (slightly) different mode from normal
code.  I'm not sure whether this is a good or practicable idea, but it
would be nice to have the option.

> There's nothing special here: any multi-major-mode solution will need to
> define some convention/protocol that major need to follow in order to
> work well.

No.  Our MMM solution should work without imposing restrictions on the
major modes.  All the awkwardness should be dealt with by the MMM.  This
is possible.

> Now if you worry that (after the code is adapted) the result is code
> that is too complex/brittle, time will tell, but I get the impression
> that it won't be too bad, likely no worse than any other solution.

As I keep saying, we should adapt a solution that doesn't place manacles
on hackers.

> The way your above situation would be handled is to say "the low level
> function mentioned above assumes that the buffer has already been
> properly widened".  This way, it doesn't need to know whether it's being
> called (indirectly) from indent-line-function or b-o-d-function.

Then it ceases to be a general low level function and becomes one that
can only be called in certain circumstances.  This effectively transmits
high level state to the low levels, and isn't good software engineering.

> But some of its callers may need to be changed to do the widening, and
> indeed, in order to know how far to widen, they'll need the help from
> the multi-major-mode package.

This is intolerable.  It will lead to twisted code.

Why should a major mode need to know "how far to widen"?  This is only
due to the proposal to misuse narrowing to control regions with
different syntax-tables, I think.  If these regions are controlled
without using narrowing, this and many other problems cease to exist.

> So maybe we need something like:

>     (defvar prog-widen-function #'widen)
>     (defun prog-widen () (funcall prog-widen-function))

No, we need

    (widen)

like we've had for many decades.

> [ And maybe for the same reason, we need a function (rather than
>   a variable) that returns the `first-column`, so we can get the info
>   anywhere/anytime rather than only during indentation.  ]


>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).