[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could w

From: Dmitry Gutov
Subject: Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please.
Date: Mon, 13 Jun 2016 18:36:56 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2

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:


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

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

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



    (let (hard-widen-limits)

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.

reply via email to

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