From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bozhidar Batsov Newsgroups: gmane.emacs.devel Subject: Re: Problem case for ruby-mode indentation Date: Mon, 4 Nov 2013 15:44:07 +0200 Message-ID: References: <52777DD7.1020305@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b471e6a2d833104ea5a1c6b X-Trace: ger.gmane.org 1383572651 8311 80.91.229.3 (4 Nov 2013 13:44:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Nov 2013 13:44:11 +0000 (UTC) Cc: Steve Purcell , emacs-devel To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 04 14:44:16 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 1VdKRy-0005YR-0e for ged-emacs-devel@m.gmane.org; Mon, 04 Nov 2013 14:44:14 +0100 Original-Received: from localhost ([::1]:49992 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VdKRx-0004Vz-Lx for ged-emacs-devel@m.gmane.org; Mon, 04 Nov 2013 08:44:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37159) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VdKRu-0004VZ-3S for emacs-devel@gnu.org; Mon, 04 Nov 2013 08:44:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VdKRs-00068P-Dm for emacs-devel@gnu.org; Mon, 04 Nov 2013 08:44:10 -0500 Original-Received: from mail-ob0-x235.google.com ([2607:f8b0:4003:c01::235]:54483) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VdKRs-00068C-6o for emacs-devel@gnu.org; Mon, 04 Nov 2013 08:44:08 -0500 Original-Received: by mail-ob0-f181.google.com with SMTP id wp4so6952156obc.26 for ; Mon, 04 Nov 2013 05:44:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Zr/Wd/KfNWLJwsyG5p6s5ii3Q6bA74Z1qKlqEtLqt4k=; b=Ef47CKWFFGLV5UsG5oWlL9dQKn+zv0//B0gpU7qNMn9uYc61bkdD6gra+CL0P+CaFr MEYfIPNSmTWoZrlDdrSIf6TTJss2/wJ09haxONhozg3jC8C3ie2LCWmXizq0Mu20XGAA kBpqw+8brt8N3qql0/Zhni/TkEMPMARoQOejVSF/t7en1uIASeFvCINDgHOR0Nxq6gnq udLEPYo2BOts5AOu70G2myjYl2EQj0hr2XlHWvECvUsazDC+L3ctnbHBRWHVCK8OracK IfRvd3ZhcajklaO81/rWvgitRWnY3E4iGleXfAHCLRAo3+E7VapH2e9lezOkH9PLS4xg HTbw== X-Received: by 10.60.134.230 with SMTP id pn6mr1430564oeb.52.1383572647541; Mon, 04 Nov 2013 05:44:07 -0800 (PST) Original-Received: by 10.76.131.116 with HTTP; Mon, 4 Nov 2013 05:44:07 -0800 (PST) In-Reply-To: <52777DD7.1020305@yandex.ru> X-Google-Sender-Auth: zAmII5aAG6ouL7p-s6L0O3sEPXU X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c01::235 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:164922 Archived-At: --047d7b471e6a2d833104ea5a1c6b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'll probably start testing more extensively the smie indentation logic soon. So far things are looking pretty good, I'm sure that by the time 24.4 gets released we'll have the best indentation implementation ruby-mode has ever had. On 4 November 2013 12:58, Dmitry Gutov wrote: > Hi Steve, > > On 03.11.2013 15:22, Steve Purcell wrote: > >> I noticed a case in which heredoc indentation gets messed up with >> ruby-mode from Emacs HEAD: >> >> if something_wrong? # ruby-move-to-block-skips-heredoc >> ActiveSupport::Deprecation.warn(<<-eowarn, foo) >> boo hoo >> end (bah) >> eowarn >> foo >> end >> >> Seems like it=E2=80=99s the parens inside the heredoc which confuse matt= ers. It=E2=80=99s >> the same with/without `ruby-use-smie`. >> > > You probably didn't switch major mode after changing the value of > `ruby-use-smie'. It only takes effect in `ruby-mode' function, so you'd > have to `M-x text-mode', `M-x ruby-mode'. I do see different indentation > with SMIE enabled than with it disabled. > > Should be fixed now, in 114935 (with SMIE). Although, as usual, I'm not > sure whether that solution is the best one. > > Here=E2=80=99s another example from some proprietary code, which seems t= o confirm >> that issue: >> >> connection.execute sanitize_sql_array([<<-end_sql, charity.id, >> Markup.db_regexp_for_references("charity", charity.all_names), charity.i= d >> ]) >> INSERT INTO charities_news_items (charity_id, news_item_id) >> SELECT ? AS charity_id, id AS news_item_id >> FROM news_items WHERE text ~ ? >> AND id NOT IN (SELECT news_item_id FROM charities_news_items WHERE >> charity_id =3D ?) >> end_sql >> >> (Make sure you view this with a monospaced font, of course.) >> > > Also looks fixed now. > > To be fair, this has never really worked perfectly, but I think this is = a >> little more broken than I remember it. :-) >> > > The old indentation engine reinvents parse-partial-sexp, poorly, so it > doesn't really consider the insides of heredoc as a string. SMIE has its > difficulties, but it handles syntax entities better. > > P.S. Please do use `M-x report-emacs-bug', or at least write to > emacs-devel. I'm not the only person taking care of ruby-mode now. There'= s > at least Stefan, and looks like Bozhidar is also joining the fray. > > --047d7b471e6a2d833104ea5a1c6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'll probably start testing more extensively the smie = indentation logic soon. So far things are looking pretty good, I'm sure= that by the time 24.4 gets released we'll have the best indentation im= plementation ruby-mode has ever had.


On 4 November= 2013 12:58, Dmitry Gutov <dgutov@yandex.ru> wrote:
Hi Steve,

On 03.11.2013 15:22, Steve Purcell wrote:
I noticed a case in which heredoc indentation gets messed up with ruby-mode= from Emacs HEAD:

if something_wrong? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # ruby-move-t= o-block-skips-heredoc
=C2=A0 =C2=A0ActiveSupport::Deprecation.warn(<<-eowarn, foo) =C2=A0 =C2=A0boo hoo
end =C2=A0(bah)
eowarn
foo
end

Seems like it=E2=80=99s the parens inside the heredoc which confuse matters= . It=E2=80=99s the same with/without `ruby-use-smie`.

You probably didn't switch major mode after changing the value of `ruby= -use-smie'. It only takes effect in `ruby-mode' function, so you= 9;d have to `M-x text-mode', `M-x ruby-mode'. I do see different in= dentation with SMIE enabled than with it disabled.

Should be fixed now, in 114935 (with SMIE). Although, as usual, I'm not= sure whether that solution is the best one.

Here=E2=80=99s another example from some proprietary code, which seems to c= onfirm that issue:

=C2=A0 =C2=A0 =C2=A0connection.execute sanitize_sql_array([<<-end_= sql, charity.id, Ma= rkup.db_regexp_for_references("charity", charity.all_names= ), charity.id])
=C2=A0 =C2=A0 =C2=A0INSERT INTO charities_news_items (charity_id, news_item= _id)
=C2=A0 =C2=A0 =C2=A0SELECT ? AS charity_id, id AS news_item_id
=C2=A0 =C2=A0 =C2=A0FROM news_items WHERE text ~ ?
=C2=A0 =C2=A0 =C2=A0AND id NOT IN (SELECT news_item_id FROM charities_news_= items WHERE charity_id =3D ?)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 end_s= ql

(Make sure you view this with a monospaced font, of course.)

Also looks fixed now.

To be fair, this has never really worked perfectly, but I think this is a l= ittle more broken than I remember it. :-)

The old indentation engine reinvents parse-partial-sexp, poorly, so it does= n't really consider the insides of heredoc as a string. SMIE has its di= fficulties, but it handles syntax entities better.

P.S. Please do use `M-x report-emacs-bug', or at least write to emacs-d= evel. I'm not the only person taking care of ruby-mode now. There's= at least Stefan, and looks like Bozhidar is also joining the fray.


--047d7b471e6a2d833104ea5a1c6b--