[Top][All Lists]

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

Re: A vision for multiple major modes: some design notes

From: Dmitry Gutov
Subject: Re: A vision for multiple major modes: some design notes
Date: Fri, 22 Apr 2016 17:33:48 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0

Hello Alan,

Thank you for writing this expansive summary. I'll comment on a couple of the items below, but overall, if you're asking my personal opinion, we should put a pin in this for now, and first see where the hard-widen feature gets us.

After that, we could see whether it wouldn't be easier to extract certain individual pieces of this proposal in an independent fashion. The main two I see are:

- A way to assign buffer boundaries that make certain core primitives treat some buffer regions as whitespace, maybe with support for nesting. I don't know if that should be via text properties. As long as this feature is only used dynamically, it could be a list structure stored in a dynamic variable. That way the `in-islands' variable would become redundant.

- A way to quickly store and switch between sets of buffer-local variables.

If you go ahead with this proposal, though, I think it should be implemented in close collaboration with an author of a related package. Vitalie Spinu and Christoph Wedler (polymode and andlr-mode maintainers) would be good candidates, and neither has shown up at this discussion yet. Unfortunately, I don't have a lot of time to dedicate to mmm-mode lately (and it probably has the highest backward compatibility expectations out of the three anyway).

The main drawbacks of this, IMHO, are that it's big (like you mentioned yourself), and that it's fairly opinionated. Hence the two-item list above.

On 04/20/2016 10:44 PM, Alan Mackenzie wrote:

    * - The coordination of these bindings will be carried out by the
      mechanisms described below, without explicit coding in the super mode.

This seems a little too optimistic. For instance:

  o - To the user, the current major mode will be that of the island where
    point is.  All familiar commands will work without restriction.

Imenu, as one example, will require coordination from the super mode, or from the multi-mode framework. The user will normally want to see all of entries in the current buffer in the index, so something would have to merge them.

  o - To the writer of major modes, a minimal set of restrictions will apply:
    * - For some major mode commands, the mode will have to bind the variable
      `in-islands' (see below) to non-nil.

Ideally, the writers of the "island" major modes wouldn't do anything special to support multi-mode usage. It would be better if the "superior" major modes would have to do all the "special" things.

I.e., it's fine to have to introduce a new major mode for a templating language if it can easily use existing major modes for the code regions inside.

Here's a related question: would `indent-for-tab-command' bind `in-islands' to t, or not?

(iv) Islands.
  o - An island will be delimited in two complementary ways:
    * - It will be enclosed syntactically by characters with "open island" and
      "close island" syntax (see section (v)).  Both of these syntactic
      markers will include a flag "chain" indicating whether there is a
      previous/next island in the chain.  The cdr of the syntax value will be
      the island chain to which the island belongs.
    * - It will be covered by the text property `island', whose value will be
      the pertinent island or island chain (see section (ii)) (not yet
      decided).  Note that if islands are enclosed inside other islands, the
      value is the innermost island.  There is the possibility of using an
      interval tree independent of the one for text properties to increase

Going by the current implementation in mmm-mode, it would be handy if the islands could be distinguished using one text property only. Then we simply set it on all overlays that cover mmm-mode's subregions. But if all three elements are required, so be it.

reply via email to

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