emacs-devel
[Top][All Lists]
Advanced

[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: Sun, 3 Dec 2017 21:20:40 +0000
User-agent: Mutt/1.7.2 (2016-11-26)

Hello, Eli.

On Sun, Dec 03, 2017 at 21:25:09 +0200, Eli Zaretskii wrote:
> > Date: Sun, 3 Dec 2017 18:59:46 +0000
> > Cc: Eli Zaretskii <address@hidden>, address@hidden, address@hidden,
> >   address@hidden, address@hidden
> > From: Alan Mackenzie <address@hidden>

> > > > Convince Alan to do what?

> > > To adhere to the current proposal (avoid widening in 
> > > indent-line-function and font-lock-keywords, to start with).

> > I know Eli has asked to move on from the emotional to the technical
> > stuff, but that last paragraph belongs to the former, and I will deal
> > with it as such.

> And I would _really_ want to move to the technical stuff.  So...  I
> 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.

> > You mentioned today, I think, that writing an MMM is hard.  Well, CC
> > Mode is hard, too.  There are 30 calls to `widen' in CC Mode and 47 to
> > `narrow-to-region'.  They are all there for a reason.  It will be
> > grinding tedious work to sort out the whys and to remove them.

> Is that the only reason for your objections?  The need to tediously go
> through a few dozen of calls to 'widen' and 'narrow-to-region', and
> take care of each one of them as appropriate?  Or are there more
> substantial problems in adapting CC Mode to non-widening MMM?

No, my main reason is philosophical.  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.

Using the region to do this is an abuse.  This isn't what point-min and
point-max were designed for.  Programmers are going to carry on using
`widen', and this will lead to possibly difficult to debug bugs.  I am
sure that this use of the region is going to lead to other nasty
problems, even though I can't forsee in any detail what these will be.

> > so many of the `widen' calls are in low level functions called from
> > "everywhere".

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

> > 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.  Once all the effort has been put into
making MMM work with the region, nobody will bother with putting the
(substantial) effort into "new region".  We'll lose the opportunity for
a possibly better solution.

> (And a proposal to do something along these lines was put forward by
> Vitalie some time ago.)

I didn't know that.  Respect, Vitalie!

> > Last February, I suggested extensions to the syntax code ("syntactic
> > islands") which would allow operations such as parse-partial-sexp to
> > work essentially without restriction in buffers with several syntax
> > tables.

> What problems does this solve?  The problem with 'widen' or some other
> problem(s)?

The idea is to render the use of the region by MMM unnecessary, though
it will need other code, too.  The need to use parse-partial-sexp in any
progmode buffer seems obvious, and having to do this in bits (as at the
moment) seems an obvious enough inconvenience to make syntactic islands
worthwhile.  To be honest, I've no exact use case for them at the
moment.  They would allow, for example, syntax-ppss to work in an entire
MMM buffer.

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]