Re: forward-comment and syntax-ppss

[Dmitry Gutov]

On 16.12.2016 21:25, Alan Mackenzie wrote:

> > Why should some facilities ignore narrowing, then? E.g. font-lock and
> > indentation, which have traditionally done so.
>
> They don't.  No text outside of the visible region is indented

Why would the text outside be indented? indent-for-tab-command indents 
the current line. IOW, it ignores all the effect that narrowing could 
have (in some modes; others don't bother to widen).

> or
> fontified.

Yes, it is. Maybe not entirely, because of jit-lock, but the first thing 
font-lock-default-fontify-buffer does is call widen.

> But, if necessary, text outside the visible region is
> inspected to get the needed context for the operation within it.

Which, for many purposes, is as bad as ignoring the narrowing.

> I think it's quite a long time ago since anybody
> gave any examples of narrowing supposedly making things difficult.  A
> reminder of what these things are would be most welcome now.

Should that happen every couple of months, or so? We have search in the 
mailing list archives, you know.

1. Classical example of mixing narrowing for two different purposes, and 
how that backfires:

M-: (info "(elisp) Variables")

Select some region, and to focus on reading it better (or some other 
reason you use narrowing interactively for), narrow to it: C-x n n.

Finish reading it, try to get back to the node with `C-x n w'.

Instead, you see the whole elisp.info.

2. Multi-mode usage where the framework delegates to each subregion's 
major mode for fontification and indentation.

I'm not going to recap it all again now, but, suffice to say, font-lock 
rules, indentation functions and syntax-ppss ignoring the narrowing 
imposed on them by the calling code is highly inconvenient.

We don't want the JS indentation or highlighting rules to look at HTML 
code, and vice versa.