From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: smie-next-sexp vs associative operators Date: Wed, 24 Oct 2012 10:24:42 -0400 Message-ID: References: <85lif9e7m8.fsf@member.fsf.org> <851uh0x59u.fsf@stephe-leake.org> <85ehktijxl.fsf@stephe-leake.org> <85hapnhnwy.fsf@member.fsf.org> <851ugoernt.fsf@member.fsf.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT X-Trace: ger.gmane.org 1351088698 26181 80.91.229.3 (24 Oct 2012 14:24:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Oct 2012 14:24:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 24 16:25:06 2012 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 1TR1tI-0006zW-Cf for ged-emacs-devel@m.gmane.org; Wed, 24 Oct 2012 16:25:04 +0200 Original-Received: from localhost ([::1]:45191 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TR1tA-0003n2-Ob for ged-emacs-devel@m.gmane.org; Wed, 24 Oct 2012 10:24:56 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:55280) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TR1t8-0003mb-0D for emacs-devel@gnu.org; Wed, 24 Oct 2012 10:24:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TR1sy-000325-5G for emacs-devel@gnu.org; Wed, 24 Oct 2012 10:24:53 -0400 Original-Received: from relais.videotron.ca ([24.201.245.36]:57756) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TR1sy-000321-0x for emacs-devel@gnu.org; Wed, 24 Oct 2012 10:24:44 -0400 Original-Received: from ceviche.home ([24.201.208.110]) by VL-VM-MR003.ip.videotron.ca (Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built Apr 21 2011)) with ESMTP id <0MCE00KNWIP7FMA0@VL-VM-MR003.ip.videotron.ca> for emacs-devel@gnu.org; Wed, 24 Oct 2012 10:24:43 -0400 (EDT) Original-Received: by ceviche.home (Postfix, from userid 20848) id 0E5E1660E0; Wed, 24 Oct 2012 10:24:43 -0400 (EDT) In-reply-to: <851ugoernt.fsf@member.fsf.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 24.201.245.36 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:154489 Archived-At: >>> That's not consistent, so it complicates my code, meaning more time >>> spent testing. >> Can you give me some detail about the complication? > I'd have to add special cases in the code, which means each special case > needs to be tested, and maintained. Without the specifics I can't see what you're referring to. > (goto-char (nth 1 (smie-backward-sexp (smie-default-forward-token)) I've almost never needed to write a call to smie-backward-sexp in SMIE indentation rules (yes, there are a few exceptions, but only for constructs that SMIE is unable to parse properly, or for indentation rules that do not follow the parse-tree structure, such as indentation of monadic-style code in OCaml). There's something wrong if you need to write that for indentation of the if..end construct. >>> With smie-skip-associative t, (smie-backward-sexp "exception") stops >>> with point before "declare", simplifying the code. >> But such a smie-skip-associative also suffers from inconvenients >> (e.g. it will make you look further back than needed for some >> indentation decisions > Not _me_, just the CPU. That's ok, that's what CPUs are for! as long as > it takes less than noticable time (which it does, so far, on my > admittedly very fast machine). And it gives that gain only for a very > small set of keywords (two out of 130 for Ada mode); from most of the > keywords in statements, smie-backward-sexp will parse back to the > statement start. Indentation of an ELSIF with your approach takes time proportional to the whole IF construct, thus leading to O(n^2) complexity when reindenting the whole IF construct, whereas if you only go back to the previous ELSIF, the total complexity stays at O(n). But admittedly, the problem is not really performance. > Do you have any examples of when smie-skip-associative nil is useful for > actual indentation issues? As mentioned: It is good for graceful degradation (when we misparse some part of the code). It's also useful when the user doesn't like the auto-indentation's choice, since we use the user's choice of where to indent the previous `elsif'. E.g., we have the following code: case foo of | 1 => toto | 2 => titi | 3 => tata Assuming that the indentation rule for "| in case" says to align | with "case" when hitting TAB on the last line, should we leave the line unchanged or should align it with the previous line? SMIE will usually align it with the previous line, on the principle that the user's choice on previous lines takes precedence over the indentation rules. After all, if the user doesn't like it, she can first reindent the other lines, so there's no loss of functionality. > The comments imply that's why the special treatment was introduced in > the first place. It's also handy to hit M-C-t with point on a | to swap two branches of the above "case" (admittedly, it won't work for your ELSIFs because M-C-t currently makes unwarranted assumptions and hence only behaves that way for infix operators that have "punctuation syntax" in the syntax table). Or to hit M-C-SPC to select a branch (or a few branches, if you repeat it). >> but if you really want to do that, I'd rather do it with a new >> function (ideally written on top of smie-next/backward/forward-sexp) >> than with a configuration variable. > Can you explain a little more about the downside of having this choice > provided as a configuration option? It's not a _user_ option, just a > language programmer option. It doesn't significantly complicate smie! Because it breaks the above desirable properties. So if you need it for particular indentation rules, that's OK, but it should not affect general movement behavior. > Since the right value for smie-skip-associative is tied to the language, I still don't believe it to be the case. I think if you should start from "smie-skip-associative is not an option", you'll soon see that life isn't that bad after all. Stefan