emacs-devel
[Top][All Lists]
Advanced

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

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


From: Wedler, Christoph
Subject: RE: antlr-mode.el - need some support by python.el
Date: Mon, 16 Feb 2015 14:38:45 +0000

> Thanks, see comments below.

Thanks for the comments - below the updated patch for prog-mode.el.  I
use START/END as in `narrow-to-region'.

>> Instead, I added a paragraph in the doc string that sub modes can define
>> their own `SUB-extra-indentation-context', which would have the
>> additional advantage that the variable content is documented.

> Since this is a specific to a particular submode and both the inner-mode
> and the outer-mode will need to agree on it, there's no need to document
> it in the generic part of the interface.

Hm, I actually like these kind of cross-links in comments.  Otherwise,
someone could read this docstring and ask themselves "...and where can I
specify that my code snippet is a sequence of statements and not a seq
of declarations?".  With the comment they know that the sub mode might
specify such a possibility if they are lucky.

But it is up to you whether you include this paragraph.

>>>> [...] that would require them to create a temporary buffer for the
>>>> indent calculation.
>>> Not necessarily: the submode can just go to the end of the previous
>>> chunk, compute some state at that position and use that state as initial
>>> context at MIN.
>> ... if scan-lists, mode-specific skip-comments etc are prepared for this.

> That's the responsibility of the sub-mode.

To get support by the authors of potential sub-modes, I would really
like to keep the effort for the sub-modes small.
Given that the indentation code of many prog-modes is probably the most
complex part, I would understand if the authors do not want to change it
considerably just to support some special-topic major mode.

>> as the previous chunks are not part of the ANTLR grammar buffer (but
>> of the ANTLR code generation code) - I could just fake some context
>> _string_. (Providing the context as a string would be actually the
>> easiest for me.)

> Hmm.. you mean you'd specify the c-extra-indentation-context as
> a "pseudo previous chunk of code"?  That's a nice idea, in that it would
> not encode specific knowledge about CC-mode, only specific knowledge
> about the C language, so it'd be fairly generic.  So maybe
> prog-indentation-context could come with a PREVIOUS value which could
> either be a string (so the indentation should pretend that the code was
> preceded by this string) or some other value (e.g. a function, or a list
> of buffer positions) which gives access to the previous chunks.

Yes, I like to see some generic support in the future, both for literate
programming and my use case.  To get it, the path to that future should
be easy for the authors of the sub-mode.  Therefore, I think that it
will involve some mode-specific `SUB-extra-indentation-context', whose
exact format will just be of lesser importance in later stages.

I would see the following stages of support by the major mode SUB:

 1. SUB supports START/END and LEFTMOST-COL in 'prog-indentation-context'

 2. SUB provides a function which sets the syntax table and all
    variables which are necessary to properly run its indentation code and
    functions used as font-lock highlight functions (and does not set
    variables which are not necessary for these tasks)

 3. SUB supports `SUB-extra-indentation-context' (with a format which is
    most easily to consume by SUBs indentation code)

 4. SUB provides a function which creates a valid value for
    `SUB-extra-indentation-context' - valid arguments for that function
    would either be a string, or a list of buffer ranges.

    For C (assuming that a valid value for `c-extra-indentation-context'
    would look like the return value of `c-guess-basic-syntax'), this
    function could simply put the string / buffer chunks into a
    temporary buffer and call `c-guess-basic-syntax' at eob.

    In my use case, I would run this function once - in the literate
    programming case, you would run it whenever you delegate the
    indentation to the sub mode.

 5. If SUB decides that it can support the "multi-chunk case" directly
    in the indentation code (e.g. for performance improvements), it can
    do so without any change in the call by the main mode - the function
    introduced in stage 4 would then simply return the buffer-positions.

    Christoph





diff -c prog-mode.el.\~24.4\~ prog-mode.el
*** prog-mode.el.~24.4~ 2014-04-27 19:41:16.000000000 +0000
--- prog-mode.el        2015-02-16 14:26:58.376762000 +0000
***************
*** 41,46 ****
--- 41,76 ----
      map)
    "Keymap used for programming modes.")
  
+ (defvar prog-indentation-context nil
+   "Non-nil while indenting lines considered as belonging to a sub mode.
+ There are languages where part of the code is actually written in
+ a sub language, e.g., a Yacc/Bison or ANTLR grammar also consists
+ of plain C code.  This variables enables the major mode of the
+ main language to use the indentation function of the sub language
+ for lines belonging the code of the sub language.
+ 
+ When a major mode of such a main language decides to delegate the
+ indentation of a line/region to the indentation engine of the sub
+ mode, it is supposed to bind this variable to non-nil around the call.
+ 
+ The non-nil value looks as follows
+    ((START . END) LEFTMOST-COL)
+ 
+ START to END is the region consisting of code of the sub mode.
+ LEFTMOST-COL is the minimum column the indentation engine of the
+ sub mode should choose (instead of 0).
+ 
+ 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.
+ 
+ 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'.")
+ 
  (defun prog-indent-sexp (&optional defun)
    "Indent the expression after point.
  When interactively called with prefix, indent the enclosing defun



reply via email to

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