unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: Bozhidar Batsov <bozhidar@batsov.com>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
	emacs-devel <emacs-devel@gnu.org>
Subject: Re: [ruby-mode] Private/protected method definition layout in Ruby 2.1
Date: Thu, 16 Jan 2014 15:37:26 +0200	[thread overview]
Message-ID: <52D7E096.8000101@yandex.ru> (raw)
In-Reply-To: <CAM9Zgm1Nd1j4w-oyFZ4n5Ne0zHXVYbUG3JB7Qqf=AmQ3uDcb+g@mail.gmail.com>

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?



  reply	other threads:[~2014-01-16 13:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-15 14:41 [ruby-mode] Private/protected method definition layout in Ruby 2.1 Bozhidar Batsov
2014-01-15 16:24 ` Stefan Monnier
2014-01-15 18:18   ` Dmitry Gutov
2014-01-15 18:51     ` Stefan Monnier
2014-01-16  5:47 ` Dmitry Gutov
2014-01-16 10:15   ` Bozhidar Batsov
2014-01-16 13:37     ` Dmitry Gutov [this message]
2014-01-16 14:26       ` Bozhidar Batsov
2014-01-16 18:40         ` Dmitry Gutov
2014-01-16 19:38           ` Bozhidar Batsov
2014-01-17  3:17             ` Dmitry Gutov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52D7E096.8000101@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=bozhidar@batsov.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).