Re: Bug #25608 and the comment-cache branch

[Alan Mackenzie]

Hello, Stefan.

On Sun, Feb 05, 2017 at 21:08:15 -0500, Stefan Monnier wrote:
> >> > The "alternative patch" didn't scan comments correctly all the time
> >> > when I looked at it, just as the current back_comment doesn't.

> Of course, there's an alternative way to look at this reality: your
> comment-cache changes the behavior in some cases where the AP patch doesn't.
> You claim that the new behavior is "correct" and the other one "wrong",
> but AFAIK these are borderline cases where both interpretations can be
> correct or wrong depending on what narrowing was used for.

I think that is a fundamental mistake in thinking.  The syntactic
significance of a buffer position is not changed by any narrowing in
force, no matter what the narrowing is "used for".  Any other
interpretation leads to the inconsistencies you've identified.

That one or more multiple-mode attempts attempt to use narrowing that
way is a fundamental problem in those modes which we should solve by
providing a better method.  (I suggested one such method last spring.)

> So while I don't claim that comment cache's behavior is *wrong*, it
> might break existing code.

> > In the following test case (same as in my other post) the "alternative
> > patch" doesn't work.  Narrow the buffer with point-min at the indicated
> > position.  Put point at EOL.  Try M-: (forward-comment -1).  This fails.

> >     char foo[] = "asdf asdf" "asdf"; /* "asdf" */ /*  */  /*   '"'"  */
> >                       ^

> For example here, your intention for narrowing is clear, ....

There's no "intention" involved here.  There's just narrowing.

> .... but Emacs currently doesn't keep track of the fact that the user
> put this narrowing (rather than some code like mmm-mode), so while in
> this case your comment-cache is probably right, in other cases it
> might give the wrong answer.  E.g. maybe in a case such as

>      char foo[] = "for (x = 0; x < n; x++) /* Loop header */\n";
>                    ^                                        ^

> where the user narrows to the string, then goes to EOL and does
> M-: (forward-comment -1)

Even if the user narrows to the string, it's still a string.  It's not a
comment, and can't be one.

Even if, traditionally, Emacs has treated this string portion as a
comment, that was merely for simplicity of implementation.  This is not
an important point, however, because moving back over comments is not a
user command, and major modes will have checked for a "safe place"
before attempting (forward-comment -1) or a backwards scan-lists.

> Really your comment-cache (just like the existing code) currently can't
> do much better, because to do better we need to fix the narrowing
> problem.

I don't think there is such a problem.

> So really, the problem to be solved is the problem of narrowing.
> Once that one is solved, AP and comment-cache should both be able to
> behave correctly in both cases (in the case of AP, this will happen
> without any changes to AP itself, because the fix will be in
> syntax-ppss).

As I pointed out to Dmitry, AP fails to clear the syntax-ppss cache when
syntax-table properties in a buffer are changed (which is _always_ done
with the change hooks disabled) or the current syntax table is changed,
or a different syntax table is made current.  comment-cache clears its
cache correctly in these scenarios.


>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).