emacs-devel
[Top][All Lists]
Advanced

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

Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-pp


From: Eli Zaretskii
Subject: Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch
Date: Fri, 14 Feb 2014 16:38:13 +0200

> From: Stefan Monnier <address@hidden>
> Cc: Dmitry Gutov <address@hidden>,  address@hidden
> Date: Fri, 14 Feb 2014 09:10:47 -0500
> 
> I've been following those multiple major mode thingies for quite a few
> years now.  I don't think we really need a significant new
> infrastructure at the C level.

Please explain why you think so.

My line of reasoning was that since fontification happens on the
display engine level, we need to have a way to call a different
fontification function for different portions of text.  And similarly
with indentation and other mode-specific behavior.

> What we need instead is some conventions that major modes need to
> follow to play well in things like mmm-mode or mumamo.

Like what?

> E.g. I don't think "pseudo-narrowing" to magically pretend that only the
> current "code chunk" exists is going to fly: it will break major modes
> that don't follow pretty much the same conventions.

Examples, please: which conventions are those?  There's almost no code
in Emacs that ignores the buffer restrictions (everything uses BEGV
and ZV).  Even the display engine itself does that.  The text outside
these restrictions simply does not exist, as far as Emacs is
concerned.

> As for whether multiple major modes are frequent: I consider comments
> and strings as being "text-mode" chunks.  Not sure if we'll ever get to
> the point of integrating the handling of strings/comments with the
> handling of other forms of multi-major-modes, tho.

Literate programming is impossible without multi-mode support.
Org-style notes and documents are another frequent use case.  And I'm
sure people will come with more.

So I think these are quite important, and we should support them
reasonably well, not through kludges.



reply via email to

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