RE: forward-comment and syntax-ppss

[Drew Adams]

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

Not a problem for me.  And doesn't have to be a problem for
vanilla Emacs users either, if the proper commands are added.

For me, narrowing (and widening) pushes the current buffer
limits to a list.  And it is trivial to return to any previous
restriction (including fully wide).

In my case:
1. `C-x n n' to "focus on reading" a paragraph in the node.
2. `C-x n x' to return to the full node (not all of Info).
End of story.

or:
1. `C-x n w' to see all of the Info file (for context or whatever).
2. `C-x n x' to return to seeing just the node.

or:
`C-x n n' here and `C-x n n' there, any number of times & places,
followed by `C-x n x' with a prefix arg, to choose any of those
restrictions again.  Or just cycle among them by repeating
`C-x n x'.  Either within a buffer or across buffers.

----
  zz-narrow-repeat is an interactive compiled Lisp function in
  `zones.el'.  It is bound to C-x n x.

  (zz-narrow-repeat ARG)

  Cycle to the next buffer restriction (narrowing).
  This is a repeatable version of `zz-narrow'.

  Note that if the value of `zz-izones-var' is not buffer-local
  then you can use this command to cycle among regions in multiple
  buffers.
----

It's a repeatable version of `zz-narrow' (prefix arg acts the same):

----
  zz-narrow is an interactive compiled Lisp function in `zones.el'.

  (zz-narrow ARG &optional MSGP)

  Widen to a previous buffer restriction (narrowing).
  The candidates are the zones in the current `zz-izones-var'.

  With no prefix arg, widen to the previous narrowing.
  With a plain prefix arg (`C-u'), widen completely.
  With a zero  prefix arg (`C-0'), widen completely and reset (empty)
   the list of zones for this buffer.
  With a numeric prefix arg N, widen abs(N) times (to the abs(N)th
   previous narrowing).  Positive and negative args work the same,
   except that a negative arg also pops entries off the ring: it removes
   the ring entries from the most recent back through the (-)Nth one.
----

`C-x n x' is simple, but it goes a long way.

If better control of restrictions by users is what you're after,
then the code in `zones.el' is a good start, IMO.

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

I can't speak to that (too vague for me).  But a wild guess might
be that maybe "the framework" should _not_ blindly so delegate.
IOW, if it hurts, don't do it.  Maybe a better sauce is needed
for the recipe.  Or maybe the delegate itself needs to be
improved, before it can be delegated this way.

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

Then maybe that should be fixed.  Or maybe the fix should be in
the calling code.  Seems like font-lock etc. code should be able
to do whatever narrowing it needs to do (modulo, perhaps,
communicating what it's done).  If that is wrong for a potential
caller then the caller might need to do something different.

Anyway, font-lock, indentation, and syntax-ppss are hardly your
average bits of code.  Perhaps some communication is in order,
between them and potential callers, so that they can be properly
or more easily used in more contexts.

That's a far cry from wanting to simply replace narrowing for
users with some kind of invisible-text hack.

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

So create environments for them - quarantine them.  Or fix them
so whatever they do to wrt buffer restriction is benign outside
them.