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

[Dmitry Gutov <dgutov@yandex.ru>]

On 06/13/2016 03:28 PM, Alan Mackenzie wrote:

> It does not.  It contains a few relatively vague aspects, undefined
> terms, and "for full details, search!".  I'm not trying to slag off
> Vitalie here, because clearly he was in the middle of trying to figure
> things out, and was unclear about things.

There's no word "search" in the patch.

>> Here's a better link to the message:
>
>> http://lists.gnu.org/archive/html/emacs-devel/2016-03/msg01576.html
>
> 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.

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

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

> The right choice for multiple major modes might well be to use something
> other than narrowing.  As you know, I proposed something else a few
> weeks ago.

Something we're unlikely to ever get? That's not a good alternative.

>> Please go ahead and write up this proposal in detail.
>
> No, I was simply answering your question, giving you ideas for further
> ideas.

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.

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

Do you need a recommendation for a better email client?

>>> The use/non-use of narrowing is NOT a setting, any more than the
>>> use/non-use of cdr is.  They're just general purpose tools.
>
>> Turns out, they are not general purpose enough. That's the problem.
>
> That's an interpretation of the problem.  Your solution appears to be to
> make narrowing LESS general, specific to a single problem.

No, it would still serve the existing use cases, just better.

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

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

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

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

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.

> 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. CC Mode worries about visual 
narrowings, right? It should keep hard-widen-limits in place.

> And maybe, just maybe, we might somehow get back to discussing the
> actual topic of this thread which is a bug concerning syntax-ppss.

Not if you keep forgetting why the discussion went the way it went.