Somewhat related: here is an example I am having trouble with: sml-smie.el: (require 'smie) (defconst sml-smie-grammar (smie-prec2->grammar (smie-bnf->prec2 '((exp (var) ("local" exp "in" exp "end")) (var)) ))) (defun sml-smie-rules (kind token) (pcase (cons kind token) (`(:elem . basic) 4) (`(:elem . args) 2) )) (define-derived-mode my-sml-mode sml-mode "My SML" (smie-setup sml-smie-grammar #'sml-smie-rules)) indented test.sml: local local a in a end in a end I set the basic and args indentation to different values to show the problem I am running in to. I am not sure how this is being interpreted. The desired interpretation would be something like (local (local a in a end) in a end) though I am not sure if I am thinking about this properly. I am not sure when SMIE interprets entries as function arguments. In the indentation of test.sml, it appears that the second occurrence of "local" and the first occurrence of "a" are interpreted as arguments to the first occurrence of "local". Also, in general: Does the equivalent S-expression representing the parse tree have terminals in order, or are they moved to the front - i.e. does 1 + 2 for grammar (number "+" number) become (1 + 2) or (+ 1 2)? Is there any special behavior that occurs when generating the parse tree (either actually generating it or acting on an implicit parse tree)? What does smie-rule-parent-p use to determine the parent of a token? Is it the first token above the S-expression the current token is contained in, e.g. in ("a" "b" ("c" "d" "e") "f"), the parent of "d" is "b"? Thank you for all of the help! Andy On Mon, Jun 6, 2016 at 9:25 PM, wrote: > > Date: Mon, 06 Jun 2016 20:54:48 -0400 > From: Stefan Monnier > To: emacs-devel@gnu.org > Subject: Re: Debugging SMIE by printing an S-expression > Message-ID: > Content-Type: text/plain > > > I am having some trouble understanding the indentation I'm getting for a > > simple SMIE grammar and set of indentation rules. It seems like it would > > be useful to be able to print out an S-expression of what is being > parsed - > > the buffer, whatever has been reduced, really, anything at all just to > give > > me some insight as to what I want to match against in the indentation > rules > > - but really, to make sure what I think the grammar should produce is > being > > produced. Is there an easy way to do this? > > Not really, no. I don't think it would necessarily require changes to > the existing code, but it would require a second implementation of > parsing which additionally builds an s-exp of what it parsed. > > Instead, the usual way I use to find out how things are parsed is with > C-M-f and C-M-b, which is somewhat crude but works fairly well in my > experience once you learn to figure out how to interpret its behavior. > > > Stefan > > > > > >