Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please.

[Alan Mackenzie <acm@muc.de>]

Hello, Dmitry.

On Mon, Jun 13, 2016 at 06:36:56PM +0300, Dmitry Gutov wrote:
> On 06/13/2016 03:28 PM, Alan Mackenzie wrote:

[ .... ]

> > I've glanced through that, and I found the doc string you've referred
> > to.  It's some help.

> Also see the new widen's docstring. It's the whole proposal.

So the way it is to be used would be another proposal.  Given how it would
have the capacity to damage even the user interface, some considerable
care would be required in that use.

> >> If you take a shovel and remove its blade, the result will look very
> >> simple. That doesn't mean it's appropriate for any interesting task.

> > So, you consider widen and narrow-to-region in their current form as
> > being as useless as a detached shovel blade?

> Maybe a dinner utensil with fork on one side and spoon on the other 
> (thus lacking a handle) would be a better illustration.

> >> Nowhere does narrow-to-region's documentation say it should only be used
> >> in major modes.

> > Of course not.  As I've said, it's a general purpose tool used
> > univerally in Emacs.  I would like to keep it that way.

> It wouldn't go anywhere. Its usages, however, would better convey the 
> intended use.

Its uses are currently unconstrained.  I don't know what you mean by
"convey the intended use": the intended use is to restrict the accessible
portion of the buffer.

> >> It's been a known problem for a while, and it has come up in multiple
> >> discussions over the last years.

> > "It's been known"?  To whom?  The only discussion I have seen on the
> > topic has been between Stefan, yourself, and Vitalie.  Apologies if I've
> > missed anything.

> See this discussion, for example: 
> https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg01104.html

> This subject has come up in virtually every discussion related to mixed 
> modes.

OK.  One tentative conclusion from that is that narrowing is not the
ideal core concept for implementing multiple major modes.  I assert that
new core facilities are needed to implement these properly.

[ .... ]

> I've been thinking about it for years now, on and off, and changing 
> narrowing looks like the best realistic idea so far.

> > Nothing we do here is going to be simple, admittedly.  There might well
> > be a way of doing things which is a bit like the "islands" proposal but
> > without its main disadvantage (the huge effort to implement it), and
> > also a bit like the complexification of narrowing, but without its
> > disadvantages.

> You are welcome to think about and present such a design.

I've already presented one!  The implementation of that is not outside
the bounds of possibilities, but it would need more people than just me
working on it.  So far nobody else seems enthused enough.

> > Ah, I see!  It wasn't clear to me that you were talking just about a
> > single defun in that file.  I'm not accustomed to reading and
> > interpreting long URLs.  That was a function which fontifies a number of
> > regions.  I've forgotton why I should be interested in it.  ;-(

> Is it too hard for you to go back a couple of emails are re-read what 
> you wrote yourself?

Not just once, no.  But continually having to jump to a web client to
chase up old emacs-devel discussions, and continually having to go
backwards in the current thread (because the necessary context has
already been snipped from the current post) makes things very tedious.

This is like why some code is difficult to understand and follow.  It
happens because of the need continually to look somewhere else.

> Do you need a recommendation for a better email client?

No.

[ .... ]

> > There's nothing in particular that "leaves me confused".  It's that
> > there no coherent description.  To try and pick everything up from a few
> > discussions on emacs-devel going arbitrarily far back would take me
> > several days, and even then I couldn't be sure I'd not missed anything.

> There are about 10-15 short messages in there. That's maybe 20 minutes 
> of reading. Certainly less than we've spent on this thread by now.

In where?  The context has been snipped already.  It might be 20 minutes
of reading.  And then several hours trying to tie up all the loose ends,
trying to work out what the participants have been taking for granted,
tying the disjointed pieces together into some sort of whole.

> > The original messages aren't readable enough for this purpose; some
> > things are said many times - other things are left out altogether.  The
> > whole discussion is an incoherent jumble.

> It doesn't look that way to me. And if it does to you, it's quite likely 
> that a summary I would present would look just the same.

Not at all.  You're quite a good writer.  ;-)

> > Why do you think I put so much effort into getting
> > the "islands" proposal coherent - everything said once, and as far as
> > the flow of the ideas would allow, only once?

> Because you wanted to make your own thoughts clear?

I wanted to stimulate fruitful discussion.  This actually happened to a
significant extent.

> > What I'm not asking you to rehash is other people's arguments - only the
> > salient technical points, "one per line".

> So that you comment on them, ignoring the previous discussions, and we 
> rehash the points that have already been made, yet again?

Yes, of course.

> Let me make one thing clear: it's not my design, and I'm not working on 
> that patch. Maybe Vitalie would like to describe the current state of 
> the proposal, you should ask him.

I'll wait for Vitalie to reappear.

> > One of these has a patch, which looks fairly simple.  One thing which
> > isn't simple is replacing

> >     (widen)

> > with

> >     (let (hard-widen-limits)
> >       (widen))

> > in all the places needed.  (I've counted ~705 uses of `widen' in our C
> > and Lisp sources.)

> None of those places need to be updated.

That's a very "brave" thing to say.  Picture a function which saves a
buffer's contents, and which first widens to get the buffer's
boundaries....

> CC Mode worries about visual narrowings, right? It should keep
> hard-widen-limits in place.

I don't know what you mean by "visual narrowings".  CC Mode uses
narrow-to-region and widen, full stop, as do its users.  Whether it
leaves hard-widen-limits in place depends on how they have been set.
Which all comes back to the current uncertainty surrounding the proposal.

-- 
Alan Mackenzie (Nuremberg, Germany).