[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with co
From: |
Alan Mackenzie |
Subject: |
Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls |
Date: |
Fri, 1 Dec 2017 18:20:37 +0000 |
User-agent: |
Mutt/1.7.2 (2016-11-26) |
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).
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Alan Mackenzie, 2017/12/01
- [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Stefan Monnier, 2017/12/01
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Dmitry Gutov, 2017/12/01
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Alan Mackenzie, 2017/12/01
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Stefan Monnier, 2017/12/01
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls,
Alan Mackenzie <=
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Dmitry Gutov, 2017/12/01
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Stefan Monnier, 2017/12/01
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Dmitry Gutov, 2017/12/01
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Stefan Monnier, 2017/12/01
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Dmitry Gutov, 2017/12/02
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Stefan Monnier, 2017/12/02
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Eli Zaretskii, 2017/12/02
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Dmitry Gutov, 2017/12/03
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Eli Zaretskii, 2017/12/03
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Dmitry Gutov, 2017/12/04