Re: antlr-mode.el - need some support by python.el

[Dmitry Gutov]

I have to say I don't like this:

On 02/16/2015 04:38 PM, Wedler, Christoph wrote:

> + (defvar prog-indentation-context nil

Submodes could just as well be in text-based modes (XML comes to mind). 
And the primary mode is quite often that (html-mode, for instance).

Since multi-mode machinery, in the general case, will require support 
from the "primary" major modes, too, I suppose prog-mode it's not the 
proper place for the facilitating code.

The variable itself looks, to me, like it's solving a non-problem:

> + The non-nil value looks as follows
> +    ((START . END) LEFTMOST-COL)

The first element tries to re-implement what's currently being handled 
with narrowing, successfully. Why?

Like you said: "I have avoided that for opascal and ruby via
`narrow-to-region', but Python's indentation calls `widen'." Then Python 
should avoid calling `widen'. And/or someone could try and solve the 
long-standing problem of separating "visibility" narrowing and 
"functional" narrowing. Indentation code, AFAIK, only ever intends to 
temporarily undo any interactive narrowing by the user.

LEFTMOST-COL, likewise, can by added by the calling function. No need to 
make the submode's indentation function be aware of it.

And overall, this change looks very specific to this one use case (Antlr 
and literate programming modes, I guess). On the other hand, it's not 
going to be of much help with the other trickier situation, quite common 
in web programming, when the primary mode indentation depends on the 
submode (and vice versa). Examples:

ERB:

<div id='flash'>
  <% flash.each do |key, value| -%>
    <div id='flash_<%= key %>'><%=h value %></div>
  <% end %>
</div>

Handlebars:

<div class="entry">
  {{#if author}}
    <h1>{{firstName}} {{lastName}}</h1>
  {{else}}
    <h1>Unknown Author</h1>
  {{/if}}
</div>

> + It is the task of the calling main mode to (temporarily) set the
> + syntax table and related variables to values suitable for the sub
> + mode, and to call `syntax-ppss-flush-cache' if necessary.

These instructions would be better suited for a doc for writing 
multi-mode-support facilities.

> + If the indentation engine of the sub mode SUB depends on some
> + global context, it may introduce a variable named
> + `SUB-extra-indentation-context', which is to be bound like this
> + variable by the main major mode.  For example, cc-mode might
> + define `c-extra-indentation-context' which is to be bound to a
> + list of SYNTACTIC-SYMBOL as explained in `c-offsets-alist'.")

This, I guess, might be useful. But until many modes intend to use it, 
what stops you from just keeping a small alist of (MAJOR-MODE . 
OFFSETS-ALIST-VAR)?