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-mode] Private/protected method definition layout in Ruby 2.1 Date: Thu, 16 Jan 2014 15:37:26 +0200 Message-ID: <52D7E096.8000101@yandex.ru> References: <0E94BE5F9874463D9B4C2A039A3C24E9@gmail.com> <87r4884gx6.fsf@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1389879467 20407 80.91.229.3 (16 Jan 2014 13:37:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Jan 2014 13:37:47 +0000 (UTC) Cc: Stefan Monnier , emacs-devel To: Bozhidar Batsov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 16 14:37:53 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 1W3n8p-0002vG-Nt for ged-emacs-devel@m.gmane.org; Thu, 16 Jan 2014 14:37:51 +0100 Original-Received: from localhost ([::1]:60850 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3n8p-0004sI-Ah for ged-emacs-devel@m.gmane.org; Thu, 16 Jan 2014 08:37:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48617) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3n8f-0004rX-LJ for emacs-devel@gnu.org; Thu, 16 Jan 2014 08:37:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3n8V-0001YY-TP for emacs-devel@gnu.org; Thu, 16 Jan 2014 08:37:41 -0500 Original-Received: from mail-ea0-x231.google.com ([2a00:1450:4013:c01::231]:35888) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3n8V-0001YG-MO for emacs-devel@gnu.org; Thu, 16 Jan 2014 08:37:31 -0500 Original-Received: by mail-ea0-f177.google.com with SMTP id n15so1147695ead.36 for ; Thu, 16 Jan 2014 05:37:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=HaNWHnunZznG9xtqPGmVCA0+JJF0xBRnbsA/BV8KztA=; b=gEMQvagxTHcbQ7gmTA5haObpGWkGg99rAZvN549Sa9yYSrMFOAx0gq6wgsLeXJRzVx lyyz/xzexrX5Zp84rJL/zJksSpzwpYQHayWAj8snlsKEU8ihAjLASN8ksduifhHeABzm KzOAyHTAly7PD9BYbRfYGNa04jbkg2vOiMeffTHIORg97bexe6Tz2uevskwTyG5MU5L4 PEtWtBmfjL5bgaNxFIM+HwSiTHyYFE3H2pLFQkFdg766ideCaMKykUT0dQ9zz9X8V74a nTIlotrEvapp2SJf33YtEVSASFEvaeXDku44qHiMyCozxdAQUIjfqyWnmnqHoHS/54Pl NgbA== X-Received: by 10.14.178.65 with SMTP id e41mr11661573eem.79.1389879450847; Thu, 16 Jan 2014 05:37:30 -0800 (PST) Original-Received: from [192.168.10.2] ([93.109.205.233]) by mx.google.com with ESMTPSA id l4sm18207332een.13.2014.01.16.05.37.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Jan 2014 05:37:30 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::231 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:168525 Archived-At: On 16.01.2014 12:15, Bozhidar Batsov wrote: > I'm OK with the patch, but it makes configuration a bit more difficult > since users should actually know all the alignable keywords. Why? The Customize interface will still show all possible values, and if the user looks at the definition of the variable directly, they should notice the use of `ruby-alignable-keywords'. > I guess we > can mention `ruby-alignable-keywords' in the docstring > of `ruby-align-to-stmt-keywords' and consider this a good enough hint > for the users. One problem with the current implementation is that it > won't play nice with assignments if you won't to treat them differently: Do you suggest to both apply the patch I suggested, *and* add a new user option? Because without the patch, there won't be a way to treat them "the same". > What I'm saying is that some people > might prefer to align `def` with a statement beginning only with access > modifier methods. What I'd like to know if you personally plan to use such user option. Adapting to a hypothetical user can wait until the release of 24.4, I'd say. And it'd be better to wait until a specific feature request anyway. > Of course, it seems unlikely that someone will assign > the value of a method def to a variable, but in the future a method > definition in MRI, The above sentence seems to be missing something. > but it makes sense in Rubinius for instance. Could you explain why?