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

[Wedler, Christoph]

What is the status of the status of the discussion / my patch which has
addressed the following issue:

If multi-modes (for grammars with actions, literate programming, ...)
want to delegate the indentation of sub-mode specific code to the
corresponding functions of the sub-mode, they face the following issues

  a) the indentation engine of some major modes do a `widen', because
  they want to do the right thing if the user has used narrowing (but
  then it gets confused by the surrounding grammar code)

  b) if the indentation engine just looks at the visible part of the
  code, it will indent top-level lines at column 0.  This might not be
  the right thing for code snippets (grammar actions).

  There might be a workaround, but not for sub-languages with
  indentation-based block structures (Python, Haskell, ...), where the
  indentation works by cycling through all possible indentation
  positions.

  c) for the indentation of code-snippets to work properly, the
  indentation engine might need to know the context, e.g. as
  externally provided string (for grammars) or by a function which
  provides (previous) code blocks of the current buffer.


Potential solutions:

  1. no nothing

  2. (my approach/patch): dynamically bind a variable in the outer mode
  which specifies

    - the region for any potential `widen' in the sub-mode's indentation
      engine (the submode can just replace all their call of `widen' by
      `prog-widen')
    - the leftmost column for the indentation
    - the context for issue c above - this is optional for the sub-mode
      to support as it would require more substantial support by it

  3. require that all indentation engines to not call widen, do that in
  `indent-according-to-mode' and friends; passing the leftmost-column as
  parameter to the major-mode specific indentation functions, ...

I would vote for (2) and would like to hear suggestions for my
corresponding patch.
I fear that wanting (3) ends up BEING just the solution (1).

Regards,
Christoph