On 16 January 2014 15:37, Dmitry Gutov wrote: > 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'. Fair enough, although in practice relatively few people use it. Anyways, this is a minor detail. > > > 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". By "current implementation" I meant the current patch. Yeah, I think that some way to have defs align to the start of an expression only for modifier expressions might be a good idea in the interest of maximum flexibility. > > > 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. It depends on whether I'd have to use the result of an method definition in an assignment. :-) Seems unlikely at this point, since I don't have strong feelings about this. > > > > 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. Can't believe I wrote something as crazy as this. I meant to say that in the current implementation of the feature in MRI assigning the result to a variable doesn't make much sense, but in the future that might change (if the return value becomes a method object instead of a symbol). > > > > but it makes sense in Rubinius for instance. > > Could you explain why? > In Rubinius defs have always returned an object: def foo; end => # I can assume that some people capture this object and manipulate it. Anyways, I think that the current patch will be good enough for most users. I was just pointing out some potential problems in case they were overlooked by you.