[Top][All Lists]

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

Re: SMIE documentation

From: Štěpán Němec
Subject: Re: SMIE documentation
Date: Sun, 28 Nov 2010 22:56:50 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Stefan Monnier <address@hidden> writes:

> While Savannah is down, maybe someone will feel like checking my attempt
> at documenting SMIE.  See patch below.  I intend to install it on the
> emacs-23 branch, in case it matters.


Thank you. A few nits I noticed:

> address@hidden @defvar smie-grammar
> address@hidden This variable is an alist specifying the left and right 
> precedence of
> address@hidden each token.  It is meant to be initialized with the use of one 
> of the
> address@hidden functions below.
> address@hidden @end defvar

Why is this commented out?


> +The returned @emph{prec2} table holds constraints between pairs of token, and
> +for any given pair only one constraint can be present, either: T1 < T2,
> +T1 = T2, or T1 > T2.


> +returns nil or an empty string, SMIE will try to handle the corresponding
> +text as an sexp according to syntax tables.


> address@hidden'((assoc "else" "then"))}.  It can also happen for cases where 
> the
> +conflict is real and cannot really be resolved, but it is unlikely to
> +pose problem in practice.


> +An other important concept is the notion of @emph{parent}: The
> address@hidden of a token, is the head token of the most closely
> +enclosing syntactic construct.  For example, the parent of an

What about "nearest enclosing" instead of "most closely enclosing"?


> +SMIE provides various functions designed specifically for use in the
> +indentation rules function (several of those function will break if used
> +in another context).  These functions all start with the prefix
> address@hidden


> address@hidden smie-rule-hanging-p
> +Return address@hidden if the current token is @emph{hanging}.
> +A token is @emph{hanging} if it is at the last token on the line
> +and if it is preceded by other tokens: a lone token on a line is not


> +By @emph{separator}, we mean here a token whose sole purpose is to
> +separate various elements within some enclosing syntactic construct, and
> +which does not have any semantic significance in itself (i.e. it would
> +typically no exist as a node in an abstract syntax tree).


reply via email to

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