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: Small improvements to ruby-mode Date: Sun, 23 Jun 2013 09:20:16 +0300 Message-ID: References: <2A6700DEDCA640EF92B326002717596D@gmail.com> <87txkrm46t.fsf@yandex.ru> <6EF2AEF8D67840A2AF1C908AA3D0725F@gmail.com> <51C5A67A.2020002@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="51c693a0_5ec6afd4_238" X-Trace: ger.gmane.org 1371968438 2965 80.91.229.3 (23 Jun 2013 06:20:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 23 Jun 2013 06:20:38 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 23 08:20:38 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 1UqdfB-0000wy-EQ for ged-emacs-devel@m.gmane.org; Sun, 23 Jun 2013 08:20:37 +0200 Original-Received: from localhost ([::1]:49077 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UqdfA-0004wO-Lk for ged-emacs-devel@m.gmane.org; Sun, 23 Jun 2013 02:20:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56857) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uqdf1-0004wI-Mf for emacs-devel@gnu.org; Sun, 23 Jun 2013 02:20:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uqdeu-0001cX-F6 for emacs-devel@gnu.org; Sun, 23 Jun 2013 02:20:27 -0400 Original-Received: from mail-ea0-x22d.google.com ([2a00:1450:4013:c01::22d]:38805) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uqdeu-0001cL-4C for emacs-devel@gnu.org; Sun, 23 Jun 2013 02:20:20 -0400 Original-Received: by mail-ea0-f173.google.com with SMTP id g15so5444411eak.18 for ; Sat, 22 Jun 2013 23:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:message-id:in-reply-to:references:subject :x-mailer:mime-version:content-type; bh=xgP6npsA8q1QVFGl25d1y70VD+iO5+Th9yYjhHo858U=; b=AUOIZxVHO8epR8aqEvdcxJxrL9hX9FfklguAPzn25mdirkTYkTiNL/UczOL5CWJ2Eh hHqp6qTtW0KHoXaTr8ZvT1I+e9DXwJ3m38H9PrYabZ+fmv7DPzaA7k+tHg4ypKxQRdsn eKk2NcXDRGH2TYiMdbIBKbCy8Bs+X/nOYVDWkrPJg3lS5/27hcdhky102Q4dO2C9AhBH +9i9SaVOrmBpUH2tLp1sAJEsqSq/RxRrMalxJmwtl5qRMw2y89MD8e+Wf799EtdqLvGm aEotmy6rpNSgUbDltfkJpvQTtqZxwjTcPhWHrwCBQp7nKV9BBxcxYb067bqdxNuhA4Va Ik+Q== X-Received: by 10.15.94.142 with SMTP id bb14mr10183264eeb.112.1371968419021; Sat, 22 Jun 2013 23:20:19 -0700 (PDT) Original-Received: from [10.0.1.3] (93-152-182-45.ddns.onlinedirect.bg. [93.152.182.45]) by mx.google.com with ESMTPSA id n42sm19039861eeh.15.2013.06.22.23.20.17 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 22 Jun 2013 23:20:18 -0700 (PDT) In-Reply-To: <51C5A67A.2020002@yandex.ru> X-Mailer: sparrow 1.6.4 (build 1178) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::22d 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:160901 Archived-At: --51c693a0_5ec6afd4_238 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Cheers, Bozhidar On Saturday, June 22, 2013 at 4:28 PM, Dmitry Gutov wrote: > On 22.06.2013 11:05, Bozhidar Batsov wrote: > > > Should we add more, e.g. include, > > > attr_accessor, using, refine? > > > > > > > Yes, I think we should definitely add more. The ones you listed - for > > sure. We should also add fail (it's a synonym for raise), extend, etc. > > Btw catch is also a method, not a keyword. loop should also be on the > > second list, as should be proc and lambda IMO. > > > > > Ok, also done (except for etc :)), together with other attr* methods, > and define_method. > > Great! Btw, I now noticed that 'load' is missing from the list. I think that __dir__, __method__ and __callee__ should also be on the list. > > > I'd also suggest adding the "command-like" methods for Kernel that are > > usually used without an explicit receiver everywhere. There's not that > > many such commands: > > > > abort > > at_exit > > eval > > exec > > exit > > exit! > > fail > > fork > > format > > p > > print > > printf > > putc > > puts > > rand > > sleep > > spawn > > sprintf > > srand > > syscall > > system > > trap > > warn > > > > > I'm less sure about these. Every method on Kernel is usually called > without an explicit receiver, and there are more of them. > Let's wait for another opinion. > > There are more of them, but most of them exist only when ruby is invoked with -n/-p (for perl-like scripting) - normally chomp, chomp!, chop, etc are not bound, which means we should not add them to the built-in list, since nobody is actually wring Ruby applications using them. Matz himself recommends that all the command-like methods from Kernel be treated as reserved words - meaning it's considered a bad idea for someone to introduce variables or methods named this way. If they were highlighted properly fewer developers would fail to recognize their "special" status. Looking at the Kernel module's docs there are less than 30 such commands and they've barely changed in recent years. On a somewhat related matter - I've noticed that in the Ruby spec BEGIN, END, __LINE__, __ENCODING__ and __FILE__ are keywords as well. ruby-mode should highlight them accordingly. > > > > I'm not so sure about re-implementing it, though. It's easy enough to > > > install in its current form, no? > > > > > > > Sure - my point is that not all Emacs users would know about the > > package. I'd venture a guess saying most of them won't. The > > functionality in it seems a perfect fit for ruby-mode. Even if it has to > > be reimplemented - we're talking about a only a handful of not > > particularly complex commands. > > > > > Patches welcome. :) > > Personally, I haven't found myself using ruby-tools too often: > > 1) I don't subscribe to your principle of single quotes vs. double > quotes. So, when I'm adding an interpolation to a string, it's usually > double-quoted already. > > It's not exactly my principle :-) There are other useful commands there for toggling between a symbol and string and blanking strings at point. The toggling between string and symbol is pretty useful. > > 2) Automatic insertion of curly braces after "#" in strings is annoying > when you're actually trying to type "#", for example when writing a > method signature. I also disagree with "don't leave out {} around > instance and global variables". > > But as optional commands with less invasive bindings ("C-c #"?), they > would be fine. > > Yep, I dislike the current behavior as well. Having it bound to a command that should be invoked manually would be much better indeed. Btw, Dmitry, I noticed something strange about ruby-mode (at least in 24.3) - the calculations for method and block boundaries seem to be off. I'm not sure if you're aware of the problem or you need a more detailed report. --51c693a0_5ec6afd4_238 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline


-- 
Cheers,
=
Bozhidar

=20

On Saturday, June 22, = 2013 at 4:28 PM, Dmitry Gutov wrote:

On 22.06.2013 11:05, Bozhidar Ba= tsov wrote:
Should we add more, e.g. include,
attr=5Facce= ssor, using, refine=3F
Yes, I think we shoul= d definitely add more. The ones you listed - for
sure. We shoul= d also add fail (it's a synonym for raise), extend, etc.
Btw ca= tch is also a method, not a keyword. loop should also be on the
second list, as should be proc and lambda IMO.
<= div>
Ok, also done (except for etc :)), together with other= attr* methods,
and define=5Fmethod.
<= /blockquote>
Great=21 Btw, I now noticed that 'load' is missing from = the list. I think that =5F=5Fdir=5F=5F, =5F=5Fmethod=5F=5F and =5F=5Fcall= ee=5F=5F should also be on the list.

I'd also suggest adding the =22command-like=22 methods for = Kernel that are
usually used without an explicit receiver every= where. There's not that
many such commands:

abort
at=5Fexit
eval
exec
e= xit
exit=21
fail
fork
format
p
print
printf
putc
puts
rand
sleep
spawn
sprintf
= srand
syscall
system
trap
warn

I'm less sure about these. Ever= y method on Kernel is usually called
without an explicit recei= ver, and there are more of them.
Let's wait for another opinion= .
There are more of them, but m= ost of them exist only when ruby is invoked with -n/-p (for perl-like scr= ipting) - normally chomp, chomp=21, chop, etc are not bound, which means = we should not add them to the built-in list, since nobody is actually wri= ng Ruby applications using them. Matz himself recommends that all the com= mand-like methods from Kernel be treated as reserved words - meaning it's= considered a bad idea for someone to introduce variables or methods name= d this way. If they were highlighted properly fewer developers would fail= to recognize their =22special=22 status. Looking at the Kernel module's = docs there are less than 30 such commands and they've barely changed in r= ecent years.

On a somewhat related matter - I've= noticed that in the Ruby spec BEGIN, END, =5F=5FLINE=5F=5F, =5F=5FENCODI= NG=5F=5F and =5F=5F=46ILE=5F=5F are keywords as well. ruby-mode should hi= ghlight them accordingly. 

I'm not so sure about re-implem= enting it, though. It's easy enough to
install in its current f= orm, no=3F
Sure - my point is that not all E= macs users would know about the
package. I'd venture a guess sa= ying most of them won't. The
functionality in it seems a perfec= t fit for ruby-mode. Even if it has to
be reimplemented - we're= talking about a only a handful of not
particularly complex com= mands.

Patches welcome. :)

Personally, I haven't found myself using ruby-tool= s too often:

1) I don't subscribe to your princi= ple of single quotes vs. double
quotes. So, when I'm adding an= interpolation to a string, it's usually
double-quoted already= .
It's not exactly my principle= :-) There are other useful commands there for toggling between a symbol = and string and blanking strings at point. The toggling between string and= symbol is pretty useful.

2) Automatic insertion of curly = braces after =22=23=22 in strings is annoying
when you're actu= ally trying to type =22=23=22, for example when writing a
meth= od signature. I also disagree with =22don't leave out =7B=7D around
instance and global variables=22.

But as o= ptional commands with less invasive bindings (=22C-c =23=22=3F), they
would be fine.
Yep, I d= islike the current behavior as well. Having it bound to a command that sh= ould be invoked manually would be much better indeed.

Btw, Dmitry, I noticed something strange about ruby-mode (at least = in 24.3) - the calculations for method and block boundaries seem to be of= f. I'm not sure if you're aware of the problem or you need a more detaile= d report.
--51c693a0_5ec6afd4_238--