Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch

[Eli Zaretskii]

> From: Dmitry Gutov <address@hidden>
> Cc: David Kastrup <address@hidden>,  address@hidden
> Date: Fri, 14 Feb 2014 16:08:42 +0200
> 
> Eli Zaretskii <address@hidden> writes:
> 
> > I agree that being able to support portions of a buffer that specify
> > their own major mode is an important feature.  I'm just saying that we
> > need a suitable infrastructure for that, instead of trying to exploit
> > unrelated features, which seem like "a good idea".
> 
> The first hint of a "suitable infrastructure" would be the adaptation of
> `syntax-ppss'. Where the information about region boundaries would come
> from, if not from mmm-mode? Text properties? Overlay properties? Where
> would they come from, if not from mmm-mode or similar package?

Sorry, I'm not sure I understand the questions.  What do you mean by
"adaptation of `syntax-ppss'"?

Information of region boundaries should surely come from the
application level, but I wasn't talking about that.  I was talking
about how this information is _used_.

> I guess adapting the default font-lock-fontify-region function and
> syntax-propertize to be aware of them would be good

To be aware of what?

> but that could be done later.

No, not "later", "sooner".  We need to design first and implement
later, not the other way around.

We need to define the list of mode-specific features (such as
indentation and fontification), and then design how these features
will be applied only to a region of the text.  One possibility would
be a special text property, whose value is the major mode in effect
for the text covered by that property.  (I'm not saying this is the
best idea, I'm just trying to explain what kind of infrastructure
would be needed.)

> > Yes, something like that.  Basically, somehow present to major-mode
> > features only a portion of the buffer (e.g., by narrowing internally).
> 
> This doest address primary mode regions, which a) need to see the
> previous chunks of the same mode, b) (for most functions) ignore the
> chunks of the submodes. But not for indentation: in some (!) mode
> combinations, the contents of submode regions influence indentation in
> the primary regions, namely in JSP, ERB and similar templates.

I never said the region(s) must be contiguous.  (Btw, explanation of
why a given chunk needs to be aware of the previous chunk would be
appreciated.)

But yes, all of what you mention, and more, need to be considered, and
the design should address these requirements.

My point is that we should come up with a list of the requirements,
and then design and implement the infrastructure which will support
them, instead of implementing multi-mode buffers by piggybacking
existing infrastructure, which was never designed to support such
features.