emacs-devel
[Top][All Lists]
Advanced

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

Re: forward-comment and syntax-ppss


From: Dmitry Gutov
Subject: Re: forward-comment and syntax-ppss
Date: Fri, 16 Dec 2016 22:06:01 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Thunderbird/50.0

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.



reply via email to

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