From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: ruby-mide, SMIE and token priority Date: Mon, 11 Nov 2013 14:56:58 +0200 Message-ID: <87bo1rqep1.fsf@yandex.ru> References: <527B069B.6020400@yandex.ru> <527B9163.3020102@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1384174658 19776 80.91.229.3 (11 Nov 2013 12:57:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 Nov 2013 12:57:38 +0000 (UTC) Cc: Stefan Monnier , emacs-devel To: Bozhidar Batsov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 11 13:57:42 2013 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 1Vfr3b-0001VY-Jn for ged-emacs-devel@m.gmane.org; Mon, 11 Nov 2013 13:57:31 +0100 Original-Received: from localhost ([::1]:36421 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vfr3b-0000z6-8i for ged-emacs-devel@m.gmane.org; Mon, 11 Nov 2013 07:57:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58206) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vfr3U-0000z0-Hg for emacs-devel@gnu.org; Mon, 11 Nov 2013 07:57:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vfr3N-0000rN-7z for emacs-devel@gnu.org; Mon, 11 Nov 2013 07:57:24 -0500 Original-Received: from mail-ea0-x22e.google.com ([2a00:1450:4013:c01::22e]:41432) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vfr3M-0000rJ-W0 for emacs-devel@gnu.org; Mon, 11 Nov 2013 07:57:17 -0500 Original-Received: by mail-ea0-f174.google.com with SMTP id n15so2177277ead.5 for ; Mon, 11 Nov 2013 04:57:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=TXStvcaadvO9CmWdM7iDnIJjsTRTIHSCVG226DlJbN4=; b=kFxBs2Tz4bBfXwUHGpaGIe/hUGeSgdUWYMTg5iy6FQoVIIfDlnbBz1aa2Hiw7GVMLa 4/gpYpKDkYdutNpARyGPQmccB196G8UWNuq/EXv23RVzVsno4Sxa3uPpi99vYc/O1sN+ FgYs+kJefyVhgYcivIMw0XUlugsd4PNlxMk+WtkwotgYUiRMc3eICu2g0DYRWenHYsNz Bl7uEtXBqgkWd86Uwx3qHxjHkZS9bUFjkLUfeq9EqSn3u527SwYQha9xiNP6gFLGA6K5 ogTErDUzOhWPyQOGUpv0rFbtCIB8TRXnAxzEu7KwwItIs79pBk4661ZsP648UV3n7hsD w/LA== X-Received: by 10.14.214.73 with SMTP id b49mr245119eep.89.1384174635964; Mon, 11 Nov 2013 04:57:15 -0800 (PST) Original-Received: from axl (93-245-142.netrun.cytanet.com.cy. [93.109.245.142]) by mx.google.com with ESMTPSA id i1sm62558418eeg.0.2013.11.11.04.57.11 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 11 Nov 2013 04:57:13 -0800 (PST) In-Reply-To: (Bozhidar Batsov's message of "Mon, 11 Nov 2013 11:14:15 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::22e 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:165162 Archived-At: Bozhidar Batsov writes: > I've just noticed that issue myself. Is there any progress on it? Yes. Try the latest trunk, and check out the examples in test/indent/ruby.rb. All of them currently work (or else there would be a comment saying that some don't). If you have any new broken examples or disagree with some of the choices in ruby.rb, please tell. > > On 7 November 2013 18:02, Stefan Monnier > wrote: > > >>> Is it at all possible to change the grammar this way? > >> You'd probably have to use a trick similar to the " @ " used on > the > >> space between the method name and the multiple-args. > > Ah, okay. Sounds not very efficient, performance-wise. > > > Could be. Every trick we add to the tokenizer is a potential > performance problem, indeed. On the contrary, code in the > rules-function is generally not performance sensitive. > > > Stefan > >