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

[Stefan Monnier]

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

We could place it elsewhere.  E.g. indent.el.

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

Narrowing sucks, so no it's not a viable alternative.

> And/or someone could try and solve the long-standing problem of
> separating "visibility" narrowing and "functional" narrowing.

If/when someone solves this, we could try and make sure that this
solution can also be used to solve this problem.  But until that happens
we need something else.

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

Yes and no: currently, the standard API to indentation is just
indent-line-function which performs the indentation directly, rather
than returning an indentation column.  So implementing LEFTMOST-COL
"outside" means re-indenting after you called the indentation function.

Furthermore, I can imagine some cases where the inner mode may still
want to indent to a column smaller than LEFTMOST-COL for good reasons.

> And overall, this change looks very specific to this one use case (Antlr and
> literate programming modes, I guess).

It's definitely not the end of the story, indeed.  But I don't think
anyone knows what a good general solution looks like, right now
(especially if "good" includes "can be made to work OK without
re-implementing the indentation algorithm of all submodes").

We've been waiting for such a magic bullet for a long time, and I don't
expect it to come any time soon.  This proposed prog-indentation-context
is just a very small step along the way, but at least it's making
some progress.

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

We can try to handle this case as a second step.  There are many other
problems to solve (e.g. interaction with syntax-ppss, font-lock, eldoc,
...), tho, so time will tell which step will come second.

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

Agreed.

> 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)?

As discussed earlier in the thread, I'm not really sure what this "extra
context" should/will ideally look like.  I think we need more experience
before we can usefully give guidance.


        Stefan