From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Matt DeBoard Newsgroups: gmane.emacs.devel Subject: Re: SMIE Date: Thu, 10 Jul 2014 00:22:44 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1404976426 28051 80.91.229.3 (10 Jul 2014 07:13:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Jul 2014 07:13:46 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 10 09:13:41 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X58Xz-0001ot-5A for ged-emacs-devel@m.gmane.org; Thu, 10 Jul 2014 09:13:39 +0200 Original-Received: from localhost ([::1]:36196 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X582Z-0005tv-Hd for ged-emacs-devel@m.gmane.org; Thu, 10 Jul 2014 02:41:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48015) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X55tG-0004yx-Mj for emacs-devel@gnu.org; Thu, 10 Jul 2014 00:23:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X55tF-0005uA-DS for emacs-devel@gnu.org; Thu, 10 Jul 2014 00:23:26 -0400 Original-Received: from mail-ie0-x229.google.com ([2607:f8b0:4001:c03::229]:40252) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X55tF-0005u6-8O for emacs-devel@gnu.org; Thu, 10 Jul 2014 00:23:25 -0400 Original-Received: by mail-ie0-f169.google.com with SMTP id rl12so7216396iec.28 for ; Wed, 09 Jul 2014 21:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ciC+Cg3aTR3B1QuzaEvZ9jpRsSKgL26OEwBW1422vGE=; b=X0JocGIx7+Cu2uqCAHxXpB2LyvVBGONXrh/1eN+UH20dqDhJy+pOhaql5GwSk9OXLs 9Ft3OahjegnVHnpFmQCVKulCsuaJrOS44/pY9aRFBfW8Eku+5F3No/QBZiNBLg3u8wLV Ou7LBBORNlOTRON+VIQKOa52S0NOVq/sioFPxvBPpdBkZBw9ZtRX+Evyq+RPm08OuMWL HGSWCRb1/Nop1s1wFTvYXojafCMEiT6KMg7sXslIItPNDqlMNkq9RHC9d6GviV0QCbYi 2Vsy/WvCO74XFyVapLJRUNo3NMLFNErFiQa2FLENiukPY9qX/F9uTthtpOJ8ySu3FsAv D3uQ== X-Received: by 10.50.25.130 with SMTP id c2mr18868995igg.7.1404966204619; Wed, 09 Jul 2014 21:23:24 -0700 (PDT) Original-Received: by 10.50.96.163 with HTTP; Wed, 9 Jul 2014 21:22:44 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c03::229 X-Mailman-Approved-At: Thu, 10 Jul 2014 02:40:35 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:172925 Archived-At: One final question. In the case of e.g. > Can't resolve the precedence cycle: .do < else:. < .do What does the placement of the dots (left of "do", right of "else:") mean? On Wed, Jul 9, 2014 at 11:02 PM, Stefan Monnier wrote: >> Hi there. As the subject line says I=E2=80=99m writing for help with SMI= E. > > Cool! > >> I am currently working on elixir-mode >> , having (apparently) takin= g >> over the mode as the latest in a line of contributors. > > I'd love to include this in GNU ELPA. Interested? > >> Specifically I=E2=80=99m having trouble understanding the mental model f= or how >> tokenisation & indentation works. For example, in this >> issue, indentati= on >> errors seem to crop up only after separating lines of code with blank >> lines. >> I have spent, seriously, hundreds of hours trying to sort out what=E2=80= =99s >> happening here and I am at my wits=E2=80=99 end. > > IIUC, Elixir syntax does not treat all whitespace as "irrelevant", > contrary to the default tokenizer of SMIE. > >> Does this issue ring any bells with issues you=E2=80=99ve dealt with in >> the past? > > Yes, indeed. Octave and sh are two other languages that use SMIE and > where some whitespace is syntactically significant. > > What you need to do is to change the tokenizer so that instead of > skipping all whitespace, it turns the syntactically-significant > whitespace into a token (you can name it any way you like; in the above > languages, it turns out to be syntactically equivalent to a semi-colon, > so we call it ";"). > > I know absolutely nothing about Elixir or its syntax, so I can't give > you specific details, but you can look at octave.el and sh-script.el > for examples. Feel free to email me back with more details if you need > further help. > >> Final question, how is it determined if a token is a :list-intro token? > > Not sure I understand the question. The issue is for the indentation > rules, when it sees two (or more) concatenated expressions (e.g. "exp1 > exp2"), should it assume that exp2 is something like an argument to the > exp1 function (and hence exp2 (and exp3, ...) should be indented like > a function argument) or are all those "expressions" just a list, where > the first is not more special than the second? > This usually depends on the context. E.g. in a situation like > > fun x1 x2 x3 =3D> > > x2 is not an argument passed to the function x1; Instead x1, x2, and x3 > are "siblings" and should be indented to the same level. So to decide > how to indent x2 and x3 w.r.t x1, SMIE calls the smie-rule-function with > (:list-intro . "fun") so smie-rule-function can tell it that "fun" > introduces a *list* of "things" rather than being followed by a "normal > expression". > > Does that make more sense? > >> I have read the SMIE manual ten times, at least, but I=E2=80=99m really >> struggling. I would truly appreciate your help. > > I'm not very good at writing manuals, sorry. But I promise to do my > best to help you get SMIE working well. In return, I would appreciate > if you could help me improve the doc by giving, if not actual patches, > at least suggestions of how to rewrite the doc, or what to add to it > (usually, you can only make such suggestions after you finally > understand what's going on, and at the same time it's > important/necessary/useful to try and remember what it was that you > didn't understand). > > > Stefan