Small improvements to ruby-mode

Small improvements to ruby-mode

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 2212 bytes --]

Hi guys, 

Here's a list of small improvements to ruby-mode that we might want to include in a future version of Emacs:

* Font-lock changes

Some of the Ruby "keywords" that are currently highlighted as keywords are not actually Ruby keywords, but plain methods - alias_method, module_function, throw, raise, private, protected, public. I feel that they should not be highlighted like this to keep the highlighting syntactically correct. Technically speaking true, false and self are also keywords, but given their semantics I guess the current highlighting is ok. 

On a related note I think that it would make sense to use font-lock-builtin-face for methods like  alias_method, module_function, throw, raise, private, protected, public and other keyword like methods for Kernel and Module. I feel that such a move would increase the readability of the Ruby source code.

* Treat more filenames/file extensions as Ruby code

Most Rubyists these days have to add the following in their Emacs config:

(add-to-list 'auto-mode-alist '("\\.rake\\'" . ruby-mode))
(add-to-list 'auto-mode-alist '("\\.ru\\'" . ruby-mode))
(add-to-list 'auto-mode-alist '("Gemfile\\'" . ruby-mode))
(add-to-list 'auto-mode-alist '("Guardfile\\'" . ruby-mode))
(add-to-list 'auto-mode-alist '("Capfile\\'" . ruby-mode))
(add-to-list 'auto-mode-alist '("\\.thor\\'" . ruby-mode))
(add-to-list 'auto-mode-alist '("Thorfile\\'" . ruby-mode))
(add-to-list 'auto-mode-alist '("Vagrantfile\\'" . ruby-mode))
(add-to-list 'auto-mode-alist '("\\.jbuilder\\'" . ruby-mode))

I think it's time the defaults in ruby-mode be updated to include them.

* Implement some ruby-tools like commands in ruby-mode

ruby-tools is a small package, that adds some extra code manipulation commands https://github.com/rejeep/ruby-tools

The commands there need a bit of polish, but are generally a step in the right direction IMO.
A least of a few of the commands there deserve to be part of ruby-mode itself, so more users would get to use them.

I have other crazier ideas, but I'll stop for now :-)

I'd like to hear what you think! 

I can make the necessary changes and provide patches if you think that my suggestions make sense. 

-- 
Cheers,
Bozhidar


[-- Attachment #2: Type: text/html, Size: 3845 bytes --]

Re: Small improvements to ruby-mode

[Stefan Monnier]

> * Font-lock changes
> Some of the Ruby "keywords" that are currently highlighted as keywords are
> not actually Ruby keywords, but plain methods - alias_method,
> module_function, throw, raise, private, protected, public. I feel that they
> should not be highlighted like this to keep the highlighting syntactically
> correct. Technically speaking true, false and self are also keywords, but
> given their semantics I guess the current highlighting is ok. 
> On a related note I think that it would make sense to use
> font-lock-builtin-face for methods like  alias_method, module_function,
> throw, raise, private, protected, public and other keyword like methods for
> Kernel and Module. I feel that such a move would increase the readability of
> the Ruby source code.

That all sounds fine to me, tho I never use Ruby, so my opinion doesn't
matter too much.

> * Treat more filenames/file extensions as Ruby code

> Most Rubyists these days have to add the following in their Emacs config:

> (add-to-list 'auto-mode-alist '("\\.rake\\'" . ruby-mode))
> (add-to-list 'auto-mode-alist '("\\.ru\\'" . ruby-mode))
> (add-to-list 'auto-mode-alist '("Gemfile\\'" . ruby-mode))
> (add-to-list 'auto-mode-alist '("Guardfile\\'" . ruby-mode))
> (add-to-list 'auto-mode-alist '("Capfile\\'" . ruby-mode))
> (add-to-list 'auto-mode-alist '("\\.thor\\'" . ruby-mode))
> (add-to-list 'auto-mode-alist '("Thorfile\\'" . ruby-mode))
> (add-to-list 'auto-mode-alist '("Vagrantfile\\'" . ruby-mode))
> (add-to-list 'auto-mode-alist '("\\.jbuilder\\'" . ruby-mode))

These should be consolidated into a single regexp and should probably be
made a bit tighter (e.g. don't put BadCapfile in ruby-mode).

I'm not too happy about having so many different patterns, tho (even if
consolidated into a single regexp).  Why are so many different namings
used?  It sounds like the Ruby people consider that all the world is
Ruby and other tools just have to deal with it.  Would it have been so
hard to add a .rb to all those <Foo>file ?

> * Implement some ruby-tools like commands in ruby-mode
> ruby-tools is a small package, that adds some extra code manipulation
> commands https://github.com/rejeep/ruby-tools

We could integrate it into ruby-mode, of course.


        Stefan

Re: Small improvements to ruby-mode

[Dmitry Gutov]

>> * Font-lock changes
>> Some of the Ruby "keywords" that are currently highlighted as keywords are
>> not actually Ruby keywords, but plain methods - alias_method,
>> module_function, throw, raise, private, protected, public. I feel that they
>> should not be highlighted like this to keep the highlighting syntactically
>> correct. Technically speaking true, false and self are also keywords, but
>> given their semantics I guess the current highlighting is ok. 
>> On a related note I think that it would make sense to use
>> font-lock-builtin-face for methods like  alias_method, module_function,
>> throw, raise, private, protected, public and other keyword like methods for
>> Kernel and Module. I feel that such a move would increase the readability of
>> the Ruby source code.

Good idea, done in revno 113128. I also added require, require_relative
and autoload to the second list. Should we add more, e.g. include,
attr_accessor, using, refine?

>> * Treat more filenames/file extensions as Ruby code
>
>> Most Rubyists these days have to add the following in their Emacs config:
>
>> (add-to-list 'auto-mode-alist '("\\.rake\\'" . ruby-mode))
>> (add-to-list 'auto-mode-alist '("\\.ru\\'" . ruby-mode))
>> (add-to-list 'auto-mode-alist '("Gemfile\\'" . ruby-mode))
>> (add-to-list 'auto-mode-alist '("Guardfile\\'" . ruby-mode))
>> (add-to-list 'auto-mode-alist '("Capfile\\'" . ruby-mode))
>> (add-to-list 'auto-mode-alist '("\\.thor\\'" . ruby-mode))
>> (add-to-list 'auto-mode-alist '("Thorfile\\'" . ruby-mode))
>> (add-to-list 'auto-mode-alist '("Vagrantfile\\'" . ruby-mode))
>> (add-to-list 'auto-mode-alist '("\\.jbuilder\\'" . ruby-mode))
>
> These should be consolidated into a single regexp and should probably be
> made a bit tighter (e.g. don't put BadCapfile in ruby-mode).

Also done, revno 113129 and 113130.

> I'm not too happy about having so many different patterns, tho (even if
> consolidated into a single regexp).  Why are so many different namings
> used?

These are for different tools, using different DSLs inside. Anyway, I
blame Make, they started it.

> It sounds like the Ruby people consider that all the world is
> Ruby and other tools just have to deal with it.  Would it have been so
> hard to add a .rb to all those <Foo>file ?

Most of (?) these work just as well if you add the extension, but nobody
actually does that.

>> * Implement some ruby-tools like commands in ruby-mode
>> ruby-tools is a small package, that adds some extra code manipulation
>> commands https://github.com/rejeep/ruby-tools
>
> We could integrate it into ruby-mode, of course.

I'm not so sure about re-implementing it, though. It's easy enough to
install in its current form, no?

Patches and suggestions on what polish we could provide exactly are
always welcome.

Re: Small improvements to ruby-mode

[Glenn Morris]

Dmitry Gutov wrote:

>>> (add-to-list 'auto-mode-alist '("\\.rake\\'" . ruby-mode))
>>> (add-to-list 'auto-mode-alist '("\\.ru\\'" . ruby-mode))
>>> (add-to-list 'auto-mode-alist '("Gemfile\\'" . ruby-mode))
>>> (add-to-list 'auto-mode-alist '("Guardfile\\'" . ruby-mode))
>>> (add-to-list 'auto-mode-alist '("Capfile\\'" . ruby-mode))
>>> (add-to-list 'auto-mode-alist '("\\.thor\\'" . ruby-mode))
>>> (add-to-list 'auto-mode-alist '("Thorfile\\'" . ruby-mode))
>>> (add-to-list 'auto-mode-alist '("Vagrantfile\\'" . ruby-mode))
>>> (add-to-list 'auto-mode-alist '("\\.jbuilder\\'" . ruby-mode))
>>
>> These should be consolidated into a single regexp and should probably be
>> made a bit tighter (e.g. don't put BadCapfile in ruby-mode).
>
> Also done, revno 113129 and 113130.

Please just write the regexp by hand, rather than using regexp-opt.
Otherwise:

Loading loaddefs.el (source)...
Attempt to autoload regexp-opt while preparing to dump
make[1]: *** [emacs] Error 1

Re: Small improvements to ruby-mode

[Dmitry Gutov]

On 22.06.2013 3:45, Glenn Morris wrote:
> Dmitry Gutov wrote:
>
>>>> (add-to-list 'auto-mode-alist '("\\.rake\\'" . ruby-mode))
>>>> (add-to-list 'auto-mode-alist '("\\.ru\\'" . ruby-mode))
>>>> (add-to-list 'auto-mode-alist '("Gemfile\\'" . ruby-mode))
>>>> (add-to-list 'auto-mode-alist '("Guardfile\\'" . ruby-mode))
>>>> (add-to-list 'auto-mode-alist '("Capfile\\'" . ruby-mode))
>>>> (add-to-list 'auto-mode-alist '("\\.thor\\'" . ruby-mode))
>>>> (add-to-list 'auto-mode-alist '("Thorfile\\'" . ruby-mode))
>>>> (add-to-list 'auto-mode-alist '("Vagrantfile\\'" . ruby-mode))
>>>> (add-to-list 'auto-mode-alist '("\\.jbuilder\\'" . ruby-mode))
>>>
>>> These should be consolidated into a single regexp and should probably be
>>> made a bit tighter (e.g. don't put BadCapfile in ruby-mode).
>>
>> Also done, revno 113129 and 113130.
>
> Please just write the regexp by hand, rather than using regexp-opt.
> Otherwise:
>
> Loading loaddefs.el (source)...
> Attempt to autoload regexp-opt while preparing to dump
> make[1]: *** [emacs] Error 1

Sorry, fixed.

Re: Small improvements to ruby-mode

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 4009 bytes --]

On Saturday, June 22, 2013 at 2:31 AM, Dmitry Gutov wrote:
> > > * Font-lock changes
> > > Some of the Ruby "keywords" that are currently highlighted as keywords are
> > > not actually Ruby keywords, but plain methods - alias_method,
> > > module_function, throw, raise, private, protected, public. I feel that they
> > > should not be highlighted like this to keep the highlighting syntactically
> > > correct. Technically speaking true, false and self are also keywords, but
> > > given their semantics I guess the current highlighting is ok. 
> > > On a related note I think that it would make sense to use
> > > font-lock-builtin-face for methods like alias_method, module_function,
> > > throw, raise, private, protected, public and other keyword like methods for
> > > Kernel and Module. I feel that such a move would increase the readability of
> > > the Ruby source code.
> > > 
> > 
> 
> 
> Good idea, done in revno 113128. I also added require, require_relative
> and autoload to the second list. 
> 
> 


Great! Thanks a lot of the quick response!
 
> 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.

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
catch
eval
exec
exit
exit!
fail
fork
format
p
print
printf
putc
puts
rand
sleep
spawn
sprintf
srand
syscall
system
trap
warn 
> 
> > > * Treat more filenames/file extensions as Ruby code
> > 
> > > Most Rubyists these days have to add the following in their Emacs config:
> > 
> > > (add-to-list 'auto-mode-alist '("\\.rake\\'" . ruby-mode))
> > > (add-to-list 'auto-mode-alist '("\\.ru\\'" . ruby-mode))
> > > (add-to-list 'auto-mode-alist '("Gemfile\\'" . ruby-mode))
> > > (add-to-list 'auto-mode-alist '("Guardfile\\'" . ruby-mode))
> > > (add-to-list 'auto-mode-alist '("Capfile\\'" . ruby-mode))
> > > (add-to-list 'auto-mode-alist '("\\.thor\\'" . ruby-mode))
> > > (add-to-list 'auto-mode-alist '("Thorfile\\'" . ruby-mode))
> > > (add-to-list 'auto-mode-alist '("Vagrantfile\\'" . ruby-mode))
> > > (add-to-list 'auto-mode-alist '("\\.jbuilder\\'" . ruby-mode))
> > > 
> > 
> > 
> > These should be consolidated into a single regexp and should probably be
> > made a bit tighter (e.g. don't put BadCapfile in ruby-mode).
> > 
> 
> 
> Also done, revno 113129 and 113130.
Fantastic! 
> 
> > I'm not too happy about having so many different patterns, tho (even if
> > consolidated into a single regexp). Why are so many different namings
> > used?
> > 
> 
> 
> These are for different tools, using different DSLs inside. Anyway, I
> blame Make, they started it.
> 
> > It sounds like the Ruby people consider that all the world is
> > Ruby and other tools just have to deal with it. Would it have been so
> > hard to add a .rb to all those <Foo>file ?
> > 
> 
> 
> Most of (?) these work just as well if you add the extension, but nobody
> actually does that.
> 
> > > * Implement some ruby-tools like commands in ruby-mode
> > > ruby-tools is a small package, that adds some extra code manipulation
> > > commands https://github.com/rejeep/ruby-tools
> > > 
> > 
> > 
> > We could integrate it into ruby-mode, of course.
> 
> 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 and suggestions on what polish we could provide exactly are
> always welcome.
> 
> 



[-- Attachment #2: Type: text/html, Size: 6305 bytes --]

Re: Small improvements to ruby-mode

[Dmitry Gutov]

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.

> 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.

>> 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.

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.

Re: Small improvements to ruby-mode

[Stefan Monnier]

>>> I'm not so sure about re-implementing it, though. It's easy enough to
>>> install in its current form, no?

I've asked the author for a copyright assignment.


        Stefan

Re: Small improvements to ruby-mode

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 3844 bytes --]



-- 
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.

[-- Attachment #2: Type: text/html, Size: 5489 bytes --]

Re: Small improvements to ruby-mode

[Dmitry Gutov]

On 23.06.2013 10:20, Bozhidar Batsov wrote:
>> 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.

That makes sense, but should we highlight them the same way as 
keyword-like methods (which I've roughly defined for myself as stuff 
having to do with control flow, code generation and loading)?

>> 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 :-)

Well, it's in the style guide you're maintaining, and I haven't seen 
this exact phrasing elsewhere, IIRC. And there are enough popular 
projects that contradict or ignore it.

> The toggling between string and symbol is pretty useful.

Yes, I could've used it myself just the other day. It's not something I 
do too often either, though.

> 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.

Not exactly sure what you mean, so yes, more details would be helpful. 
But please try the current trunk first.

Re: Small improvements to ruby-mode

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 2843 bytes --]


On Sunday, June 23, 2013 at 3:30 PM, Dmitry Gutov wrote: 
> On 23.06.2013 10:20, Bozhidar Batsov wrote:
> > > 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.
> > 
> 
> 
> That makes sense, but should we highlight them the same way as 
> keyword-like methods (which I've roughly defined for myself as stuff 
> having to do with control flow, code generation and loading)?
> 
> 

Those methods are only different in our minds - in the end of the time they are in the same bucket. That said we have two options:

1. Introduce some extra face for keyword-like built-in methods, that inherits from the keyword or built-in face by default and leave it to theme authors to make it distinct.  
2. Treat all built-ins as just built-ins.

I'm fine with both options, but if it were up-to-me I'd probably go with option 2, since I don't like to introduce additional complexity and option 2 corresponds more closely with the actual state of affairs.
> 
> > > 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 :-)
> > 
> 
> 
> Well, it's in the style guide you're maintaining, and I haven't seen 
> this exact phrasing elsewhere, IIRC. And there are enough popular 
> projects that contradict or ignore it.
> 
> > The toggling between string and symbol is pretty useful.
> 
> Yes, I could've used it myself just the other day. It's not something I 
> do too often either, though.
> 
> > 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.
> > 
> 
> 
> Not exactly sure what you mean, so yes, more details would be helpful. 
> But please try the current trunk first.
> 
> 

OK, I'll do some tests and I'll get back to you on this one. 


[-- Attachment #2: Type: text/html, Size: 4219 bytes --]

Re: Small improvements to ruby-mode

[Dmitry Gutov]

On 24.06.2013 17:49, Bozhidar Batsov wrote:
> Those methods are only different in our minds - in the end of the time
> they are in the same bucket. That said we have two options:

Ok, I'm convinced, more or less. And option 2 is definitely the easier 
one, we can always add additional faces on a theme author's request.

By the way, do you have a reference for that Matz quote?

> OK, I'll do some tests and I'll get back to you on this one.

Any results?

Re: Small improvements to ruby-mode

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 992 bytes --]

On 1 July 2013 21:32, Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 24.06.2013 17:49, Bozhidar Batsov wrote:
>
>> Those methods are only different in our minds - in the end of the time
>> they are in the same bucket. That said we have two options:
>>
>
> Ok, I'm convinced, more or less. And option 2 is definitely the easier
> one, we can always add additional faces on a theme author's request.
>
> By the way, do you have a reference for that Matz quote?


Page 31 of the book he co-authored with David  Flanagan - "The Ruby
Programming Language". I can send you the scanned page if you don't have
the book around.
Btw, don't forget about the missing keywords BEGIN, END, __LINE__,
__ENCODING__ and __FILE__. Maybe __LINE__, __ENCODING__ and __FILE__ can be
highlighted as variables(like self, true and false)?

>
>
>  OK, I'll do some tests and I'll get back to you on this one.
>>
>
> Any results?
>

Got sidetracked by work and some other projects. Will try to do some
testing tomorrow.

[-- Attachment #2: Type: text/html, Size: 2197 bytes --]

Re: Small improvements to ruby-mode

[Dmitry Gutov]

On 02.07.2013 1:41, Bozhidar Batsov wrote:
> Page 31 of the book he co-authored with David  Flanagan - "The Ruby
> Programming Language". I can send you the scanned page if you don't have
> the book around.

No need, thanks. Found it at Google Books.

> Btw, don't forget about the missing keywords BEGIN, END, __LINE__,
> __ENCODING__ and __FILE__. Maybe __LINE__, __ENCODING__ and __FILE__ can
> be highlighted as variables(like self, true and false)?

Sure, I remember about those. Just wanted to bring this particular 
conversation to conclusion before making the changes, in bulk.

> Got sidetracked by work and some other projects. Will try to do some
> testing tomorrow.

Re: Small improvements to ruby-mode

[Dmitry Gutov]

Hmm, I don't see either of these problems with the current trunk. Have 
you checked for stale ruby-mode.elc or a rogue ruby-mode.el installed 
via ELPA?

I did encounter the following semi-known issue:

Putting the cursor on one of the 4 lines after "elsif" in the second 
example and pressing `C-M-p' moves it to the "add_offence" line.

And pressing `C-M-n' after that moves it to the "end" closing the 
"operands.each" block.

Pressing `C-M-p' or `C-M-n' on the `elsif' line misbehaves similarly.

I'll see about fixing that.

On 02.07.2013 19:46, Bozhidar Batsov wrote:
> Here's a bit of code:
>
>             operands.each do |op|
>                if LITERALS.include?(op.type)
>                  add_offence(:warning, op.loc.expression,
>                              format(MSG, op.loc.expression.source))
>
>                end
>              end
>
> Placing the cursor somewhere in the `if` yields totally crazy results
> (or even errors from time to time - "setq: Wrong type argument:
> number-or-marker-p, nil") when calling `ruby-beginning-of-block` and
> `ruby-end-of-block`. I'd expect `ruby-beginning-of-block` to go to the
> `each` line and `ruby-beginning-of-block` to go to the `end` of the
> block in question. There's also the question if constructs ending with
> an `end` should be treated as blocks as well - that might be useful to
> develop scope highlighting tools without a lot of custom code.

def-end, if-end, etc, are already treated as blocks.

> Regarding the other problem I mentioned - mark defun doesn't always work
> correctly:
>
>          def check_for_literal(node)
>            cond, = *node
>
>            # if the code node is literal we obviously have a problem
>            if LITERALS.include?(cond.type)
>              add_offence(:warning, cond.loc.expression,
>                          format(MSG, cond.loc.expression.source))
>            elsif [:and, :or].include?(cond.type)
>              # alternatively we have to consider a logical node with a
>              # literal argument
>              *operands = *cond
>              operands.each do |op|
>                if LITERALS.include?(op.type)
>                  add_offence(:warning, op.loc.expression,
>                              format(MSG, op.loc.expression.source))
>
>                end
>              end
>            end
>          end
>
> Place the cursor inside the innermost `if` near the end of the defun and
> try `C-M-h` there - you'll see that only a portion of the defun will be
> marked.

`mark-defun' call `beginning-of-defun' and `end-of-defun', and they work 
pretty reliably here.

Re: Small improvements to ruby-mode

[Dmitry Gutov]

On 02.07.2013 22:38, Dmitry Gutov wrote:
> Putting the cursor on one of the 4 lines after "elsif" in the second
> example and pressing `C-M-p' moves it to the "add_offence" line.
>
> And pressing `C-M-n' after that moves it to the "end" closing the
> "operands.each" block.
>
> Pressing `C-M-p' or `C-M-n' on the `elsif' line misbehaves similarly.

I've fixed the last one and left the other two in. For the most part, 
they're intentional, since we're not supposed to stop at "elsif" (it's 
not beginning or end of a block, after all).

As far as the keywords go, I've checked in the following patch:

=== modified file 'lisp/ChangeLog'
--- lisp/ChangeLog	2013-07-03 03:20:04 +0000
+++ lisp/ChangeLog	2013-07-03 15:45:17 +0000
@@ -1,3 +1,8 @@
+2013-07-03  Dmitry Gutov  <dgutov@yandex.ru>
+
+	* progmodes/ruby-mode.el (ruby-font-lock-keywords): Highlight more
+	keywords and built-ins.
+
  2013-07-03  Glenn Morris  <rgm@gnu.org>

  	* subr.el (y-or-n-p): Handle empty prompts.  (Bug#14770)

=== modified file 'lisp/progmodes/ruby-mode.el'
--- lisp/progmodes/ruby-mode.el	2013-07-03 01:02:18 +0000
+++ lisp/progmodes/ruby-mode.el	2013-07-03 15:36:27 +0000
@@ -1762,31 +1762,67 @@
               "yield")
             'symbols)
            "\\|"
-          ;; keyword-like methods on Kernel and Module
            (regexp-opt
-           '("alias_method"
+           ;; built-in methods on Kernel
+           '("__callee__"
+             "__dir__"
+             "__method__"
+             "abort"
+             "at_exit"
+             "autoload"
+             "autoload?"
+             "binding"
+             "block_given?"
+             "caller"
+             "catch"
+             "eval"
+             "exec"
+             "exit"
+             "exit!"
+             "fail"
+             "fork"
+             "format"
+             "lambda"
+             "load"
+             "loop"
+             "open"
+             "p"
+             "print"
+             "printf"
+             "proc"
+             "putc"
+             "puts"
+             "raise"
+             "rand"
+             "readline"
+             "readlines"
+             "require"
+             "require_relative"
+             "sleep"
+             "spawn"
+             "sprintf"
+             "srand"
+             "syscall"
+             "system"
+             "throw"
+             "trap"
+             "warn"
+             ;; keyword-like private methods on Module
+             "alias_method"
               "autoload"
               "attr"
               "attr_accessor"
               "attr_reader"
               "attr_writer"
-             "catch"
               "define_method"
               "extend"
-             "fail"
               "include"
-             "lambda"
-             "loop"
               "module_function"
+             "prepend"
               "private"
-             "proc"
               "protected"
               "public"
-             "raise"
               "refine"
-             "require"
-             "require_relative"
-             "throw"
               "using")
             'symbols)
            "\\)")
@@ -1794,12 +1830,16 @@
           '(if (match-beginning 4)
                font-lock-builtin-face
              font-lock-keyword-face))
+   ;; Perl-ish keywords
+   "\\_<\\(?:BEGIN\\|END\\)\\_>\\|^__END__$"
     ;; here-doc beginnings
     `(,ruby-here-doc-beg-re 0 (unless (ruby-singleton-class-p 
(match-beginning 0))
                                 'font-lock-string-face))
     ;; variables
     '("\\(^\\|[^.@$]\\|\\.\\.\\)\\_<\\(nil\\|self\\|true\\|false\\)\\>"
       2 font-lock-variable-name-face)
+   ;; keywords that evaluate to certain values
+   '("\\_<__\\(?:LINE\\|ENCODING\\|FILE\\)__\\_>" 0 
font-lock-variable-name-face)
     ;; symbols
 
'("\\(^\\|[^:]\\)\\(:\\([-+~]@?\\|[/%&|^`]\\|\\*\\*?\\|<\\(<\\|=>?\\)?\\|>[>=]?\\|===?\\|=~\\|![~=]?\\|\\[\\]=?\\|@?\\(\\w\\|_\\)+\\([!?=]\\|\\b_*\\)\\|#{[^}\n\\\\]*\\(\\\\.[^}\n\\\\]*\\)*}\\)\\)"
       2 font-lock-constant-face)

Re: Small improvements to ruby-mode

[Dmitry Gutov]

On 05.07.2013 13:56, Bozhidar Batsov wrote:
> The patch looks good with one minor problem - you've included `autoload`
> twice (the second time it's in Module's methods).

Thanks for the catch.

> While on the subject of small improvements here's a few more ideas:
>
> * replace cl with cl-lib (that should be done eventually I guess)

Yeah, I guess.

> * update the front-matter comment since it's pretty out-of-date

What exactly do you propose to change? If the file is installed 
manually, and if it's not autoloaded, the user has to add some 
auto-mode-alist entries.

> * run a whitespace cleanup on the code :-)

Untabify, you mean? It's the core's policy not to touch tabs vs. spaces 
until you meaningfully modify nearby code.

> * highlight yard and rdoc special syntax in comments - like Emacs Lisp does

Have you looked at https://github.com/pd/yard-mode.el/ ?

The only problem with it I can see is, it sets 
eldoc-documentation-function, so it can't be used outside of comments. I 
guess we'll eventually need eldoc-documentation-functions hook, like we 
have for completions.

> * make use of `font-lock-negation-char-face` for !

Uh, okay. Is it different from the default face, in any themes?

> * maybe make of use of new `font-log-regexp-grouping-construct-face` as well

I think highlighting backslash sequences is more important, and the two 
approaches are somewhat incompatible. See:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14481
https://github.com/dgutov/highlight-escape-sequences

P.S. Please try to keep emacs-devel in Cc.

Re: Small improvements to ruby-mode

[Stefan Monnier]

> The only problem with it I can see is, it sets eldoc-documentation-function,
> so it can't be used outside of comments.

I don't understand why setting eldoc-documentation-function would
prevent something from being used in comments.

> I guess we'll eventually need eldoc-documentation-functions hook, like
> we have for completions.

(add-function :around (local eldoc-documentation-function) ...)

should make eldoc-documentation-functions unnecessary.


        Stefan

Re: Small improvements to ruby-mode

[Dmitry Gutov]

On 05.07.2013 15:08, Stefan Monnier wrote:
>> The only problem with it I can see is, it sets eldoc-documentation-function,
>> so it can't be used outside of comments.
>
> I don't understand why setting eldoc-documentation-function would
> prevent something from being used in comments.

yard-mode's value of eldoc-documentation-function is only useful in 
comments. I'm maintaining another package, which sets a different value 
of eldoc-documentation-function that is only useful outside of comments. 
The two don't mesh.

>> I guess we'll eventually need eldoc-documentation-functions hook, like
>> we have for completions.
>
> (add-function :around (local eldoc-documentation-function) ...)
>
> should make eldoc-documentation-functions unnecessary.

Ah, good. Never having used `add-function' before, I assumed it wouldn't 
work when the "value at place" is nil, as eldoc-documentation-function 
is, by default.

I guess that means *-functions hooks are going away.

Re: Small improvements to ruby-mode

[Stefan Monnier]

> yard-mode's value of eldoc-documentation-function is only useful in
> comments. I'm maintaining another package, which sets a different value of
> eldoc-documentation-function that is only useful outside of comments. The
> two don't mesh.

Ok, thanks, makes sense now.

>>> I guess we'll eventually need eldoc-documentation-functions hook, like
>>> we have for completions.
>> (add-function :around (local eldoc-documentation-function) ...)
>> should make eldoc-documentation-functions unnecessary.
> Ah, good. Never having used `add-function' before, I assumed it wouldn't
> work when the "value at place" is nil, as eldoc-documentation-function is,
> by default.

Indeed when the value is nil, it doesn't work as well, so we should
little-by-little change those defaults to non-nil values.

> I guess that means *-functions hooks are going away.

Could be, indeed, tho I haven't really thought about it.


        Stefan

Re: Small improvements to ruby-mode

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 2725 bytes --]

On 5 July 2013 13:30, Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 05.07.2013 13:56, Bozhidar Batsov wrote:
>
>> The patch looks good with one minor problem - you've included `autoload`
>> twice (the second time it's in Module's methods).
>>
>
> Thanks for the catch.
>
>
>  While on the subject of small improvements here's a few more ideas:
>>
>> * replace cl with cl-lib (that should be done eventually I guess)
>>
>
> Yeah, I guess.
>
>
>  * update the front-matter comment since it's pretty out-of-date
>>
>
> What exactly do you propose to change? If the file is installed manually,
> and if it's not autoloaded, the user has to add some auto-mode-alist
> entries.
>
> I thought the manual installation instructions were leftovers from the old
ruby-mode. I was under the impression that since ruby-mode started using
SMIE it's not a good idea to distribute it separately, since it might not
behave appropriately on older Emacsen. Perhaps I'm wrong.

>
>  * run a whitespace cleanup on the code :-)
>>
>
> Untabify, you mean? It's the core's policy not to touch tabs vs. spaces
> until you meaningfully modify nearby code.


That's unfortunate. Files with tabs look like Christmas trees for most
whitespace-mode users.

>
>
>  * highlight yard and rdoc special syntax in comments - like Emacs Lisp
>> does
>>
>
> Have you looked at https://github.com/pd/yard-**mode.el/<https://github.com/pd/yard-mode.el/>?
>
> The only problem with it I can see is, it sets
> eldoc-documentation-function, so it can't be used outside of comments. I
> guess we'll eventually need eldoc-documentation-functions hook, like we
> have for completions.


Yes, I have - but I really feel that this is something that should be
handled by ruby-mode itself. After all around 90% of all ruby hackers have
to deal with yard and rdoc. It's better to have core functionality
built-in.

>
>
>  * make use of `font-lock-negation-char-face` for !
>>
>
> Uh, okay. Is it different from the default face, in any themes?


If more modes were actually using it more themes would have customised it.
I can assure you that zenburn and solarized will support it :-)

>
>
>  * maybe make of use of new `font-log-regexp-grouping-**construct-face`
>> as well
>>
>
> I think highlighting backslash sequences is more important, and the two
> approaches are somewhat incompatible. See:
>
> http://debbugs.gnu.org/cgi/**bugreport.cgi?bug=14481<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14481>
> https://github.com/dgutov/**highlight-escape-sequences<https://github.com/dgutov/highlight-escape-sequences>


I see.

>
>
> P.S. Please try to keep emacs-devel in Cc.
>

Sorry about that. I'm trying to use a new mail client these days and I'm
not totally used to it.

[-- Attachment #2: Type: text/html, Size: 5019 bytes --]

Re: Small improvements to ruby-mode

[Dmitry Gutov]

On 05.07.2013 17:01, Bozhidar Batsov wrote:
> I thought the manual installation instructions were leftovers from the
> old ruby-mode. I was under the impression that since ruby-mode started
> using SMIE it's not a good idea to distribute it separately, since it
> might not behave appropriately on older Emacsen. Perhaps I'm wrong.

SMIE is the way forward, but it still needs work, and it's disabled by 
default. Patches welcome, by the way.

ruby-mode doesn't run on older Emacsen, but it's not hard to fix.  Since 
earlier versions distributed via Marmalade and Tromey's archive seem to 
cause problems, perhaps we should make an effort and upload the current 
version to Marmalade, at least once. It stable enough, I think.

> That's unfortunate. Files with tabs look like Christmas trees for most
> whitespace-mode users.

Tabs are colored with whitish-yellow for me, which is the default 
whitespace-tab face. Noticeable, but not critical.

> Yes, I have - but I really feel that this is something that should be
> handled by ruby-mode itself. After all around 90% of all ruby hackers
> have to deal with yard and rdoc. It's better to have core functionality
> built-in.

We should contact Kyle, then, for the copyright assignment. Or, again, 
patches welcome. :)

>         * make use of `font-lock-negation-char-face` for !
>
>
>     Uh, okay. Is it different from the default face, in any themes?
>
> If more modes were actually using it more themes would have customised
> it. I can assure you that zenburn and solarized will support it :-)

Any idea how you're going to make it look?

Re: Small improvements to ruby-mode

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 2349 bytes --]

On 5 July 2013 17:15, Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 05.07.2013 17:01, Bozhidar Batsov wrote:
>
>> I thought the manual installation instructions were leftovers from the
>> old ruby-mode. I was under the impression that since ruby-mode started
>> using SMIE it's not a good idea to distribute it separately, since it
>> might not behave appropriately on older Emacsen. Perhaps I'm wrong.
>>
>
> SMIE is the way forward, but it still needs work, and it's disabled by
> default. Patches welcome, by the way.
>
> ruby-mode doesn't run on older Emacsen, but it's not hard to fix.  Since
> earlier versions distributed via Marmalade and Tromey's archive seem to
> cause problems, perhaps we should make an effort and upload the current
> version to Marmalade, at least once. It stable enough, I think.


I guess this makes sense. I've often seen complaints about the ruby-mode in
Marmalade being older than the one currently bundled in Emacs.

>
>
>  That's unfortunate. Files with tabs look like Christmas trees for most
>> whitespace-mode users.
>>
>
> Tabs are colored with whitish-yellow for me, which is the default
> whitespace-tab face. Noticeable, but not critical.


It's more annoying on a dark background. :-) Obviously that's not a big
issue, I'm just obsessed about all the details.

>
>
>  Yes, I have - but I really feel that this is something that should be
>> handled by ruby-mode itself. After all around 90% of all ruby hackers
>> have to deal with yard and rdoc. It's better to have core functionality
>> built-in.
>>
>
> We should contact Kyle, then, for the copyright assignment. Or, again,
> patches welcome. :)


I guess it'd be best of Stefan approached him?


>
>
>          * make use of `font-lock-negation-char-face` for !
>>
>>
>>     Uh, okay. Is it different from the default face, in any themes?
>>
>> If more modes were actually using it more themes would have customised
>> it. I can assure you that zenburn and solarized will support it :-)
>>
>
> Any idea how you're going to make it look?
>

A bold yellowish face seems like a nice option to me. Will make it clear
that !orax is not actually lorax for instance. Maybe it should simply
derive from the keyword face? On a related note - often && and || are
highlighted as keywords. Maybe ruby-mode should do the same for consistency
with `and` and `or`?

[-- Attachment #2: Type: text/html, Size: 3824 bytes --]

Re: Small improvements to ruby-mode

[Dmitry Gutov]

On 06.07.2013 9:31, Bozhidar Batsov wrote:
>     We should contact Kyle, then, for the copyright assignment. Or,
>     again, patches welcome. :)
>
>
> I guess it'd be best of Stefan approached him?

Not necessarily. IME, the hard part is to get the author to agree to 
this commitment.

> A bold yellowish face seems like a nice option to me. Will make it clear
> that !orax is not actually lorax for instance. Maybe it should simply
> derive from the keyword face?

I don't think it should: in the default theme, purple negation char 
would look odd.

 > On a related note - often && and || are
> highlighted as keywords. Maybe ruby-mode should do the same for
> consistency with `and` and `or`?

I don't think I've ever seen that (e.g. python-mode and coffee-mode 
don't). These are not particularly different from other operators, and I 
don't think we should highlight them all.

Re: Small improvements to ruby-mode

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 1414 bytes --]

On 6 July 2013 12:37, Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 06.07.2013 9:31, Bozhidar Batsov wrote:
>
>>     We should contact Kyle, then, for the copyright assignment. Or,
>>     again, patches welcome. :)
>>
>>
>> I guess it'd be best of Stefan approached him?
>>
>
> Not necessarily. IME, the hard part is to get the author to agree to this
> commitment.


Hopefully most authors are delighted by the prospect of their work getting
into Emacs :)

>
>
>  A bold yellowish face seems like a nice option to me. Will make it clear
>> that !orax is not actually lorax for instance. Maybe it should simply
>> derive from the keyword face?
>>
>
> I don't think it should: in the default theme, purple negation char would
> look odd.


 Fair point.


>
> > On a related note - often && and || are
>
>> highlighted as keywords. Maybe ruby-mode should do the same for
>> consistency with `and` and `or`?
>>
>
> I don't think I've ever seen that (e.g. python-mode and coffee-mode
> don't). These are not particularly different from other operators, and I
> don't think we should highlight them all.
>

Well, they are different in a way - they have different argument evaluation
strategies and cannot be overridden.  I don't know about other major modes,
but I seem to recall they were highlighted in SublimeText, RubyMine, etc.
Don't think that this is something of particular importance, just sharing
my thoughts.

[-- Attachment #2: Type: text/html, Size: 2555 bytes --]

Re: Small improvements to ruby-mode

[Dmitry Gutov]

On 06.07.2013 16:23, Bozhidar Batsov wrote:
> Hopefully most authors are delighted by the prospect of their work
> getting into Emacs :)

Some are, but some are indifferent or have an aversion to these kinds of 
agreements, seems like. Non-US people are usually unhappy about the 
snail mail delivery times.

Anyway, I won't be contacting this author, because he doesn't seem to be 
a talkative type (https://github.com/pd/inf-ruby-bond/issues/1, 
https://github.com/mooz/js2-mode/pull/100), and I don't like chasing people.

> Well, they are different in a way - they have different argument
> evaluation strategies and cannot be overridden.  I don't know about
> other major modes, but I seem to recall they were highlighted in
> SublimeText, RubyMine, etc.

Sublime is generally more colorful, it highlights all operators the 
same, and also number and char literals, in a different color.
Same with RubyMine, I think.

Re: Small improvements to ruby-mode

[Stefan Monnier]

>> SMIE comes with Emacs since 23.4 and ruby-mode doesn't use SMIE:
> I'm interested in working on this, but I'm not sure how soon I'll be able
> to fit it in my schedule.

Please do send along any question you might have about SMIE.

>> >> * make use of `font-lock-negation-char-face` for !
>> Why have a special face for the negation char?  What's so special about
>> this char?
> As the face description says it's pretty easy to overlook an ! attached to
> some identifier(like !ol - you can mistake the this for lol).

Hmm... never thought of it as a problem.  So presumably this face
wouldn't be used for variants like "¬" or "not", right?

>> ruby-mode doesn't run on older Emacsen, but it's not hard to fix.  Since
>> earlier versions distributed via Marmalade and Tromey's archive seem to
>> cause problems, perhaps we should make an effort and upload the current
>> version to Marmalade, at least once. It stable enough, I think.

More generally, we could sync up the Emacs trunk code with the
ruby-mode in http://svn.ruby-lang.org/repos/ruby/trunk/misc.

> I guess this makes sense. I've often seen complaints about the ruby-mode in
> Marmalade being older than the one currently bundled in Emacs.

As long as it doesn't cause people to fork (i.e. start contributing new
features to some older version of ruby-mode such as the one in
svn.ruby-lang.org, it's not really a problem.

>> We should contact Kyle, then, for the copyright assignment. Or, again,
>> patches welcome. :)
> I guess it'd be best of Stefan approached him?

I can't see any email address.  Could you ask him to get in touch with me?


        Stefan

Re: Small improvements to ruby-mode

[Dmitry Gutov]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>> ruby-mode doesn't run on older Emacsen, but it's not hard to fix.  Since
>>> earlier versions distributed via Marmalade and Tromey's archive seem to
>>> cause problems, perhaps we should make an effort and upload the current
>>> version to Marmalade, at least once. It stable enough, I think.
>
> More generally, we could sync up the Emacs trunk code with the
> ruby-mode in http://svn.ruby-lang.org/repos/ruby/trunk/misc.

a. Ruby trunk has some objectionable code, which I believe we shouldn't
merge, and noone seems to be interested in discussing or reverting it:
http://bugs.ruby-lang.org/issues/6854

b. They've had a bug about removing ruby-mode.el for months now:
http://bugs.ruby-lang.org/issues/6823 Again, no movement there.

c. No ELPA repositories are tracking Ruby trunk anymore. We just have
some older versions uploaded to Marmalade and Tromey's archive a while
back.

>> I guess this makes sense. I've often seen complaints about the ruby-mode in
>> Marmalade being older than the one currently bundled in Emacs.
>
> As long as it doesn't cause people to fork (i.e. start contributing new
> features to some older version of ruby-mode such as the one in
> svn.ruby-lang.org, it's not really a problem.

True, just a potential problem for users with Emacs 24.2 and earlier.

Re: Small improvements to ruby-mode

[Stefan Monnier]

> a. Ruby trunk has some objectionable code, which I believe we shouldn't
> merge, and noone seems to be interested in discussing or reverting it:
> http://bugs.ruby-lang.org/issues/6854

"deep-indent", huh?  I don't give it a name in SMIE, but I use the
"hanging-p" name for the test to choose between doing it or not (which
seems to be pretty much the same test you use in the current
ruby-mode.el).

> b. They've had a bug about removing ruby-mode.el for months now:
> http://bugs.ruby-lang.org/issues/6823 Again, no movement there.

Maybe making the trunk code work in 23.4 (for example) would help
convince people to drop it from ruby-lang.  I encourage people to post
a "vote to remove as well" to this bug-tracker.

> c. No ELPA repositories are tracking Ruby trunk anymore.  We just have
> some older versions uploaded to Marmalade and Tromey's archive a while
> back.

That's good.  So we should indeed upload a newer version (or better
yet, remove those out dated versions).


        Stefan

Re: Small improvements to ruby-mode

[Dmitry Gutov]

On 08.07.2013 13:22, Stefan Monnier wrote:
>> a. Ruby trunk has some objectionable code, which I believe we shouldn't
>> merge, and noone seems to be interested in discussing or reverting it:
>> http://bugs.ruby-lang.org/issues/6854
>
> "deep-indent", huh?

Yep. Cryptic name and docstring, plus no comments in the code. All par 
for the course. :)

> I don't give it a name in SMIE, but I use the
> "hanging-p" name for the test to choose between doing it or not (which
> seems to be pretty much the same test you use in the current
> ruby-mode.el).

I'm not sure what piece of logic in ruby-mode you mean exactly, but if 
SMIE does indentation similar to e.g. js-mode (indentation inside parens 
depends on whether the opener is followed by a newline), then that's 
behavior I prefer and have in my config via defadvice. ruby-mode 
currently picks between "deep" and "not-so-deep" indent based on whether 
the current opener is in `ruby-deep-indent-paren'.

In practice, with SMIE in ruby-mode enabled, I would expect

foo(
     1,
     2,
     3)

to be indented as

foo(
   1,
   2,
   3)

which doesn't happen.

>> b. They've had a bug about removing ruby-mode.el for months now:
>> http://bugs.ruby-lang.org/issues/6823 Again, no movement there.
>
> Maybe making the trunk code work in 23.4 (for example) would help
> convince people to drop it from ruby-lang.  I encourage people to post
> a "vote to remove as well" to this bug-tracker.

Maybe it would. I posted a "me too" there.

>> c. No ELPA repositories are tracking Ruby trunk anymore.  We just have
>> some older versions uploaded to Marmalade and Tromey's archive a while
>> back.
>
> That's good.  So we should indeed upload a newer version (or better
> yet, remove those out dated versions).

https://github.com/nicferrier/marmalade/issues/55

I'm not sure if I should Cc Tom Tromey, after all, his repository is 
supposed to be completely out of use.

Re: Small improvements to ruby-mode

[Stefan Monnier]

> In practice, with SMIE in ruby-mode enabled, I would expect

> foo(
>     1,
>     2,
>     3)

> to be indented as

> foo(
>   1,
>   2,
>   3)

> which doesn't happen.

That's not automatic.  You have to specify it explicitly in
ruby-smie-rules with something like (taken from sml-mode.el):

  (case kind
    (:before
     (cond
      ((member token '("let" "(" "[" "{"))
       (if (smie-rule-hanging-p) (smie-rule-parent)))

>> That's good.  So we should indeed upload a newer version (or better
>> yet, remove those out dated versions).
> https://github.com/nicferrier/marmalade/issues/55

Thanks,


        Stefan

Re: Small improvements to ruby-mode

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 2291 bytes --]

On 9 July 2013 03:40, Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 08.07.2013 13:22, Stefan Monnier wrote:
>
>> a. Ruby trunk has some objectionable code, which I believe we shouldn't
>>> merge, and noone seems to be interested in discussing or reverting it:
>>> http://bugs.ruby-lang.org/**issues/6854<http://bugs.ruby-lang.org/issues/6854>
>>>
>>
>> "deep-indent", huh?
>>
>
> Yep. Cryptic name and docstring, plus no comments in the code. All par for
> the course. :)
>
>
>  I don't give it a name in SMIE, but I use the
>> "hanging-p" name for the test to choose between doing it or not (which
>> seems to be pretty much the same test you use in the current
>> ruby-mode.el).
>>
>
> I'm not sure what piece of logic in ruby-mode you mean exactly, but if
> SMIE does indentation similar to e.g. js-mode (indentation inside parens
> depends on whether the opener is followed by a newline), then that's
> behavior I prefer and have in my config via defadvice. ruby-mode currently
> picks between "deep" and "not-so-deep" indent based on whether the current
> opener is in `ruby-deep-indent-paren'.
>
> In practice, with SMIE in ruby-mode enabled, I would expect
>
> foo(
>     1,
>     2,
>     3)
>
> to be indented as
>
> foo(
>   1,
>   2,
>   3)
>
> which doesn't happen.
>
>
>  b. They've had a bug about removing ruby-mode.el for months now:
>>> http://bugs.ruby-lang.org/**issues/6823<http://bugs.ruby-lang.org/issues/6823>Again, no movement there.
>>>
>>
>> Maybe making the trunk code work in 23.4 (for example) would help
>> convince people to drop it from ruby-lang.  I encourage people to post
>> a "vote to remove as well" to this bug-tracker.
>>
>
> Maybe it would. I posted a "me too" there.


Me too. Hopefully someone will have a look at the issue at some point.


>
>
>  c. No ELPA repositories are tracking Ruby trunk anymore.  We just have
>>> some older versions uploaded to Marmalade and Tromey's archive a while
>>> back.
>>>
>>
>> That's good.  So we should indeed upload a newer version (or better
>> yet, remove those out dated versions).
>>
>
> https://github.com/nicferrier/**marmalade/issues/55<https://github.com/nicferrier/marmalade/issues/55>
>
> I'm not sure if I should Cc Tom Tromey, after all, his repository is
> supposed to be completely out of use.
>

[-- Attachment #2: Type: text/html, Size: 3982 bytes --]

Re: Small improvements to ruby-mode

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 1937 bytes --]

On 8 July 2013 00:56, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> >> SMIE comes with Emacs since 23.4 and ruby-mode doesn't use SMIE:
> > I'm interested in working on this, but I'm not sure how soon I'll be able
> > to fit it in my schedule.
>
> Please do send along any question you might have about SMIE.
>
> >> >> * make use of `font-lock-negation-char-face` for !
> >> Why have a special face for the negation char?  What's so special about
> >> this char?
> > As the face description says it's pretty easy to overlook an ! attached
> to
> > some identifier(like !ol - you can mistake the this for lol).
>
> Hmm... never thought of it as a problem.  So presumably this face
> wouldn't be used for variants like "¬" or "not", right?
>

Yep, I'm pretty sure the idea is to use it just for !.

>
> >> ruby-mode doesn't run on older Emacsen, but it's not hard to fix.  Since
> >> earlier versions distributed via Marmalade and Tromey's archive seem to
> >> cause problems, perhaps we should make an effort and upload the current
> >> version to Marmalade, at least once. It stable enough, I think.
>
> More generally, we could sync up the Emacs trunk code with the
> ruby-mode in http://svn.ruby-lang.org/repos/ruby/trunk/misc.
>
> > I guess this makes sense. I've often seen complaints about the ruby-mode
> in
> > Marmalade being older than the one currently bundled in Emacs.
>
> As long as it doesn't cause people to fork (i.e. start contributing new
> features to some older version of ruby-mode such as the one in
> svn.ruby-lang.org, it's not really a problem.
>
> >> We should contact Kyle, then, for the copyright assignment. Or, again,
> >> patches welcome. :)
> > I guess it'd be best of Stefan approached him?
>
> I can't see any email address.  Could you ask him to get in touch with me?
>

I saw this email on his GitHub profile pd@krh.me

>
>
>         Stefan
>

[-- Attachment #2: Type: text/html, Size: 3466 bytes --]

Re: Small improvements to ruby-mode

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 2510 bytes --]

I noticed a couple of more font locking problems that we might want to
address. They are related to method names. Consider this code


def self.some_name ....

def SomeClass.some_name ...

self and SomeClass are currently highlighted with the same face as the
method name, although they are not actually part of the method name. self
should be highlighted with the variable face and class/modules with the
type face.



On 8 July 2013 12:33, Bozhidar Batsov <bozhidar@batsov.com> wrote:

> On 8 July 2013 00:56, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>> >> SMIE comes with Emacs since 23.4 and ruby-mode doesn't use SMIE:
>> > I'm interested in working on this, but I'm not sure how soon I'll be
>> able
>> > to fit it in my schedule.
>>
>> Please do send along any question you might have about SMIE.
>>
>> >> >> * make use of `font-lock-negation-char-face` for !
>> >> Why have a special face for the negation char?  What's so special about
>> >> this char?
>> > As the face description says it's pretty easy to overlook an ! attached
>> to
>> > some identifier(like !ol - you can mistake the this for lol).
>>
>> Hmm... never thought of it as a problem.  So presumably this face
>> wouldn't be used for variants like "¬" or "not", right?
>>
>
> Yep, I'm pretty sure the idea is to use it just for !.
>
>>
>> >> ruby-mode doesn't run on older Emacsen, but it's not hard to fix.
>>  Since
>> >> earlier versions distributed via Marmalade and Tromey's archive seem to
>> >> cause problems, perhaps we should make an effort and upload the current
>> >> version to Marmalade, at least once. It stable enough, I think.
>>
>> More generally, we could sync up the Emacs trunk code with the
>> ruby-mode in http://svn.ruby-lang.org/repos/ruby/trunk/misc.
>>
>> > I guess this makes sense. I've often seen complaints about the
>> ruby-mode in
>> > Marmalade being older than the one currently bundled in Emacs.
>>
>> As long as it doesn't cause people to fork (i.e. start contributing new
>> features to some older version of ruby-mode such as the one in
>> svn.ruby-lang.org, it's not really a problem.
>>
>> >> We should contact Kyle, then, for the copyright assignment. Or, again,
>> >> patches welcome. :)
>> > I guess it'd be best of Stefan approached him?
>>
>> I can't see any email address.  Could you ask him to get in touch with me?
>>
>
> I saw this email on his GitHub profile pd@krh.me
>
>>
>>
>>         Stefan
>>
>
>

[-- Attachment #2: Type: text/html, Size: 4378 bytes --]

Re: Small improvements to ruby-mode

[Dmitry Gutov]

On 08.07.2013 13:37, Bozhidar Batsov wrote:
> I noticed a couple of more font locking problems that we might want to
> address. They are related to method names. Consider this code
>
>
> def self.some_name ....
>
> def SomeClass.some_name ...
>
> self and SomeClass are currently highlighted with the same face as the
> method name, although they are not actually part of the method name.
> self should be highlighted with the variable face and class/modules with
> the type face.

Should be fixed now. :) Along with the negation char fontification.

Re: Small improvements to ruby-mode

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]

Great!


On 9 July 2013 04:19, Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 08.07.2013 13:37, Bozhidar Batsov wrote:
>
>> I noticed a couple of more font locking problems that we might want to
>> address. They are related to method names. Consider this code
>>
>>
>> def self.some_name ....
>>
>> def SomeClass.some_name ...
>>
>> self and SomeClass are currently highlighted with the same face as the
>> method name, although they are not actually part of the method name.
>> self should be highlighted with the variable face and class/modules with
>> the type face.
>>
>
> Should be fixed now. :) Along with the negation char fontification.
>

[-- Attachment #2: Type: text/html, Size: 1094 bytes --]

Re: Small improvements to ruby-mode

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 1081 bytes --]

I've noticed two more font look issues (I guess I'm becoming annoying :-) ):

- ?c, ?x, ?\n, ?\C-\M-d, etc should be font-locked as strings I guess,
since from Ruby 1.9 the character literal syntax actually yields strings.

- there should be support for the new %I/%i literals from Ruby 2.0 - I
guess we should font-lock them as symbols


On 9 July 2013 15:55, Bozhidar Batsov <bozhidar@batsov.com> wrote:

> Great!
>
>
> On 9 July 2013 04:19, Dmitry Gutov <dgutov@yandex.ru> wrote:
>
>> On 08.07.2013 13:37, Bozhidar Batsov wrote:
>>
>>> I noticed a couple of more font locking problems that we might want to
>>> address. They are related to method names. Consider this code
>>>
>>>
>>> def self.some_name ....
>>>
>>> def SomeClass.some_name ...
>>>
>>> self and SomeClass are currently highlighted with the same face as the
>>> method name, although they are not actually part of the method name.
>>> self should be highlighted with the variable face and class/modules with
>>> the type face.
>>>
>>
>> Should be fixed now. :) Along with the negation char fontification.
>>
>
>

[-- Attachment #2: Type: text/html, Size: 1934 bytes --]

Re: Small improvements to ruby-mode

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]

On 9 July 2013 17:36, Bozhidar Batsov <bozhidar@batsov.com> wrote:

> I've noticed two more font look issues (I guess I'm becoming annoying :-)
> ):
>
> - ?c, ?x, ?\n, ?\C-\M-d, etc should be font-locked as strings I guess,
> since from Ruby 1.9 the character literal syntax actually yields strings.
>
> - there should be support for the new %I/%i literals from Ruby 2.0 - I
> guess we should font-lock them as symbols
>

And one more:

Currently we use the same face (font-lock-type-face) for both
classes/modules and constants. Classes and Modules are mandatory
CamelCase(although Camel_Case is also valid, albeit it's considered
extremely poor style) and just about everyone uses SCREAMING_SNAKE_CASE for
constants so I'd suggest to use font-lock-constant-face for constants.


>
>
> On 9 July 2013 15:55, Bozhidar Batsov <bozhidar@batsov.com> wrote:
>
>> Great!
>>
>>
>> On 9 July 2013 04:19, Dmitry Gutov <dgutov@yandex.ru> wrote:
>>
>>> On 08.07.2013 13:37, Bozhidar Batsov wrote:
>>>
>>>> I noticed a couple of more font locking problems that we might want to
>>>> address. They are related to method names. Consider this code
>>>>
>>>>
>>>> def self.some_name ....
>>>>
>>>> def SomeClass.some_name ...
>>>>
>>>> self and SomeClass are currently highlighted with the same face as the
>>>> method name, although they are not actually part of the method name.
>>>> self should be highlighted with the variable face and class/modules with
>>>> the type face.
>>>>
>>>
>>> Should be fixed now. :) Along with the negation char fontification.
>>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 2880 bytes --]

Re: Small improvements to ruby-mode

[Dmitry Gutov]

On 09.07.2013 20:07, Bozhidar Batsov wrote:
> Currently we use the same face (font-lock-type-face) for both
> classes/modules and constants. Classes and Modules are mandatory
> CamelCase(although Camel_Case is also valid, albeit it's considered
> extremely poor style) and just about everyone uses SCREAMING_SNAKE_CASE
> for constants so I'd suggest to use font-lock-constant-face for constants.

Oh, but we already use font-lock-constant-face. For symbols. :)

Considering that, in Ruby, class names are also constants, highlighting 
both with the same face doesn't look too bad.

I guess we can swap the two faces, but I'm kind of used to the way 
ruby-mode buffers look now. IOW, users may find it disruptive.

Re: Small improvements to ruby-mode

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]

On 9 July 2013 20:18, Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 09.07.2013 20:07, Bozhidar Batsov wrote:
>
>> Currently we use the same face (font-lock-type-face) for both
>> classes/modules and constants. Classes and Modules are mandatory
>> CamelCase(although Camel_Case is also valid, albeit it's considered
>> extremely poor style) and just about everyone uses SCREAMING_SNAKE_CASE
>> for constants so I'd suggest to use font-lock-constant-face for constants.
>>
>
> Oh, but we already use font-lock-constant-face. For symbols. :)
>

Yep, I'm aware of that. Lisp modes use `font-lock-constant-face` for
keywords (that are essentially the same as Ruby symbols) as well. I guess
ideally we would have a separate face for symbols that simply derives
`font-lock-constant-face` and give theme maintainers the ability to
override it. I think the only face we're not currently using is the
preprocessor face.


>
> Considering that, in Ruby, class names are also constants, highlighting
> both with the same face doesn't look too bad.
>

While class names are actually constants, the reverse is obviously not the
same - therefore my desire to separate them.


>
> I guess we can swap the two faces, but I'm kind of used to the way
> ruby-mode buffers look now. IOW, users may find it disruptive.
>

Since in a typical Ruby program class and module names are used much more
than "regular" constants I don't think the change would be particularly
disruptive.
classes and modules continue to use the type face, constants start using
the constant face, symbols continue to use the constant face (and
optionally there is the ability to customize it). In the long run such a
change would surely be beneficial.

[-- Attachment #2: Type: text/html, Size: 2561 bytes --]

Re: Small improvements to ruby-mode

[Dmitry Gutov]

On 09.07.2013 18:36, Bozhidar Batsov wrote:
> I've noticed two more font look issues (I guess I'm becoming annoying :-) ):

Not really. The novelty of seeing a Ruby user in emacs-devel still 
hasn't worn off. :)

You might want to start filing new reports as bugs, though.

> - ?c, ?x, ?\n, ?\C-\M-d, etc should be font-locked as strings I guess,
> since from Ruby 1.9 the character literal syntax actually yields strings.

It will be the right thing to do, but handling the backslashes and key 
chords looks kind of complicated.

> - there should be support for the new %I/%i literals from Ruby 2.0 - I
> guess we should font-lock them as symbols

I guess we should, but it's kind of complicated. The point of using 
percent literals is that you can put any stuff, at all, inside, and the 
only suitable Emacs syntax classes for that are strings and comments.

We should be able to overwrite that highlighting in 
ruby-font-lock-keywords, but I don't see a good way to do that, yet. 
This facility works with regexp-based search, and we need to effectively 
say "highlight from here and till the end of the string literal".

Re: Small improvements to ruby-mode

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]

On 9 July 2013 20:09, Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 09.07.2013 18:36, Bozhidar Batsov wrote:
>
>> I've noticed two more font look issues (I guess I'm becoming annoying :-)
>> ):
>>
>
> Not really. The novelty of seeing a Ruby user in emacs-devel still hasn't
> worn off. :)
>
> You might want to start filing new reports as bugs, though.


Normally I'd have been doing that from the start, but I'm not extremely
fond of Emacs's "issue tracker". Despite my feelings for it I will start
using it, though.


>
>
>  - ?c, ?x, ?\n, ?\C-\M-d, etc should be font-locked as strings I guess,
>> since from Ruby 1.9 the character literal syntax actually yields strings.
>>
>
> It will be the right thing to do, but handling the backslashes and key
> chords looks kind of complicated.


Yep, the highlighting regexp won't be exactly pretty :-)

>
>
>  - there should be support for the new %I/%i literals from Ruby 2.0 - I
>> guess we should font-lock them as symbols
>>
>
> I guess we should, but it's kind of complicated. The point of using
> percent literals is that you can put any stuff, at all, inside, and the
> only suitable Emacs syntax classes for that are strings and comments.
>
> We should be able to overwrite that highlighting in
> ruby-font-lock-keywords, but I don't see a good way to do that, yet. This
> facility works with regexp-based search, and we need to effectively say
> "highlight from here and till the end of the string literal".

[-- Attachment #2: Type: text/html, Size: 2571 bytes --]

Re: Small improvements to ruby-mode

[Dmitry Gutov]

On 10.07.2013 10:09, Bozhidar Batsov wrote:
> Normally I'd have been doing that from the start, but I'm not extremely
> fond of Emacs's "issue tracker".

Me neither. It's better that no tracker at all, though.

 > While class names are actually constants, the reverse is obviously
 > not the same - therefore my desire to separate them.

Still, that's likely the original reason why they're highlighted with 
the same face. Class names are closer to constants than constants are to 
symbols.

 > Since in a typical Ruby program class and module names are used much
 > more than "regular" constants I don't think the change would be
 > particularly disruptive.
 > classes and modules continue to use the type face, constants start
 > using the constant face, symbols continue to use the constant face
 > (and optionally there is the ability to customize it). In the long
 > run such a change would surely be beneficial.

I meant that we would preserve the equality between module name and 
constants' faces. So, if they both switch to font-lock-constant-face, 
this will be noticeable, as, like you said, module names are used a lot.

Symbols can then use type-face, or preprocessor-face, the latter would 
be a smidgen less inappropriate.

If you do want class names and constants to have different faces, there 
is an obvious question of ambiguity. Is "C" a class or a constant? I 
don't like the idea of it changing color after I type the second letter.

ST2 doesn't seem to highlight either, at all. RubyMine, from what I can 
tell from a Youtube video, either doesn't highlight them, or, depending 
on the context, highlights them with the same color (and symbols, too): 
http://www.youtube.com/watch?v=LnN-JIxDRCg#t=1464s

Re: Small improvements to ruby-mode

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 2287 bytes --]

On 10 July 2013 21:09, Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 10.07.2013 10:09, Bozhidar Batsov wrote:
>
>> Normally I'd have been doing that from the start, but I'm not extremely
>> fond of Emacs's "issue tracker".
>>
>
> Me neither. It's better that no tracker at all, though.
>
>
> > While class names are actually constants, the reverse is obviously
> > not the same - therefore my desire to separate them.
>
> Still, that's likely the original reason why they're highlighted with the
> same face. Class names are closer to constants than constants are to
> symbols.
>
>
> > Since in a typical Ruby program class and module names are used much
> > more than "regular" constants I don't think the change would be
> > particularly disruptive.
> > classes and modules continue to use the type face, constants start
> > using the constant face, symbols continue to use the constant face
> > (and optionally there is the ability to customize it). In the long
> > run such a change would surely be beneficial.
>
> I meant that we would preserve the equality between module name and
> constants' faces. So, if they both switch to font-lock-constant-face, this
> will be noticeable, as, like you said, module names are used a lot.
>
> Symbols can then use type-face, or preprocessor-face, the latter would be
> a smidgen less inappropriate.
>
> If you do want class names and constants to have different faces, there is
> an obvious question of ambiguity. Is "C" a class or a constant? I don't
> like the idea of it changing color after I type the second letter.
>

Still, we should consider functions with names like Float. Currently they
are not highlighted correctly - Something(test) is highlighted as a
constant, when obviously it's not. I guess classes, constants and functions
like this could be font-locked after the first character that's not part of
the identifier name appears, to avoid the changing of the face after the
initial character.


> ST2 doesn't seem to highlight either, at all. RubyMine, from what I can
> tell from a Youtube video, either doesn't highlight them, or, depending on
> the context, highlights them with the same color (and symbols, too):
> http://www.youtube.com/watch?**v=LnN-JIxDRCg#t=1464s<http://www.youtube.com/watch?v=LnN-JIxDRCg#t=1464s>
>

[-- Attachment #2: Type: text/html, Size: 3145 bytes --]

Re: Small improvements to ruby-mode

[Dmitry Gutov]

On 11.07.2013 15:23, Bozhidar Batsov wrote:
> Still, we should consider functions with names like Float. Currently
> they are not highlighted correctly - Something(test) is highlighted as a
> constant, when obviously it's not.

Fixed, among other things, see the patch at the bottom. We don't 
highlight method calls, so I just disabled highlighting in this case.

 > I guess classes, constants and
> functions like this could be font-locked after the first character
> that's not part of the identifier name appears, to avoid the changing of
> the face after the initial character.

Function calls can be identified by having a paren after the name (no 
luck with parenless calls).

But there's really nothing that would distinguish a Math::E reference 
from Foo::C. Or from GC, IO, DL, IRB, URI, XML, HTML, etc.

=== modified file 'lisp/progmodes/ruby-mode.el'
--- lisp/progmodes/ruby-mode.el	2013-07-09 01:17:48 +0000
+++ lisp/progmodes/ruby-mode.el	2013-07-12 20:07:57 +0000
@@ -1351,7 +1351,7 @@
      (progn
        (eval-and-compile
          (defconst ruby-percent-literal-beg-re
-          "\\(%\\)[qQrswWx]?\\([[:punct:]]\\)"
+          "\\(%\\)[qQrswWxIi]?\\([[:punct:]]\\)"
            "Regexp to match the beginning of percent literal.")

          (defconst ruby-syntax-methods-before-regexp
@@ -1387,7 +1387,7 @@
            (funcall
             (syntax-propertize-rules
              ;; $' $" $` .... are variables.
-            ;; ?' ?" ?` are ascii codes.
+            ;; ?' ?" ?` are character literals (one-char strings in 1.9+).
              ("\\([?$]\\)[#\"'`]"
               (1 (unless (save-excursion
                            ;; Not within a string.
@@ -1518,7 +1518,7 @@
              (save-match-data
                (save-excursion
                  (goto-char (nth 8 parse-state))
-                (looking-at "%\\(?:[QWrx]\\|\\W\\)")))))))
+                (looking-at "%\\(?:[QWrxI]\\|\\W\\)")))))))

        (defun ruby-syntax-propertize-expansions (start end)
          (save-excursion
@@ -1848,8 +1848,11 @@
     '("\\(\\$\\|@\\|@@\\)\\(\\w\\|_\\)+"
       0 font-lock-variable-name-face)
     ;; constants
-   '("\\(?:\\_<\\|::\\)\\([A-Z]+\\(\\w\\|_\\)*\\)"
-     1 font-lock-type-face)
+ 
'("\\(?:\\_<\\|::\\)\\([A-Z]+\\(\\w\\|_\\)*\\)\\(?:\\_>[^\(]\\|::\\|\\'\\)"
+     1 (progn
+         (when (eq ?: (char-before))
+           (forward-char -2))
+         font-lock-type-face))
     '("\\(^\\s *\\|[\[\{\(,]\\s *\\|\\sw\\s 
+\\)\\(\\(\\sw\\|_\\)+\\):[^:]" 2 font-lock-constant-face)
     ;; expression expansion
     '(ruby-match-expression-expansion
@@ -1857,6 +1860,9 @@
     ;; negation char
     '("[^[:alnum:]_]\\(!\\)[^=]"
       1 font-lock-negation-char-face)
+   ;; character literals
+   ;; FIXME: Support longer escape sequences.
+   '("\\?\\\\?\\S " 0 font-lock-string-face)
     )
    "Additional expressions to highlight in Ruby mode.")

Re: Small improvements to ruby-mode

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 3657 bytes --]

Accidentally sent my last reply only to Dmitry instead of the emacs-devel.
Sorry about that.


On 13 July 2013 13:23, Bozhidar Batsov <bozhidar@batsov.com> wrote:

> On 12 July 2013 23:31, Dmitry Gutov <dgutov@yandex.ru> wrote:
>
>> On 11.07.2013 15:23, Bozhidar Batsov wrote:
>>
>>> Still, we should consider functions with names like Float. Currently
>>> they are not highlighted correctly - Something(test) is highlighted as a
>>> constant, when obviously it's not.
>>>
>>
>> Fixed, among other things, see the patch at the bottom. We don't
>> highlight method calls, so I just disabled highlighting in this case.
>
>
> Great! Btw, shouldn't we highlight the conversion methods from Kernel
> (Float, Integer, etc) as built-ins?
>
>
>>
>>
>> > I guess classes, constants and
>>
>>> functions like this could be font-locked after the first character
>>> that's not part of the identifier name appears, to avoid the changing of
>>> the face after the initial character.
>>>
>>
>> Function calls can be identified by having a paren after the name (no
>> luck with parenless calls).
>>
>> But there's really nothing that would distinguish a Math::E reference
>> from Foo::C. Or from GC, IO, DL, IRB, URI, XML, HTML, etc.
>>
>
> Yep, I'm aware we can't distinguish all cases without the use of a proper
> parser, but I guess we should handle accordingly at least the scenarios
> which are deterministic.
>
>
>>
>> === modified file 'lisp/progmodes/ruby-mode.el'
>> --- lisp/progmodes/ruby-mode.el 2013-07-09 01:17:48 +0000
>> +++ lisp/progmodes/ruby-mode.el 2013-07-12 20:07:57 +0000
>> @@ -1351,7 +1351,7 @@
>>      (progn
>>        (eval-and-compile
>>          (defconst ruby-percent-literal-beg-re
>> -          "\\(%\\)[qQrswWx]?\\([[:punct:**]]\\)"
>> +          "\\(%\\)[qQrswWxIi]?\\([[:**punct:]]\\)"
>>            "Regexp to match the beginning of percent literal.")
>>
>>          (defconst ruby-syntax-methods-before-**regexp
>> @@ -1387,7 +1387,7 @@
>>            (funcall
>>             (syntax-propertize-rules
>>              ;; $' $" $` .... are variables.
>> -            ;; ?' ?" ?` are ascii codes.
>> +            ;; ?' ?" ?` are character literals (one-char strings in
>> 1.9+).
>>              ("\\([?$]\\)[#\"'`]"
>>               (1 (unless (save-excursion
>>                            ;; Not within a string.
>> @@ -1518,7 +1518,7 @@
>>              (save-match-data
>>                (save-excursion
>>                  (goto-char (nth 8 parse-state))
>> -                (looking-at "%\\(?:[QWrx]\\|\\W\\)")))))))
>> +                (looking-at "%\\(?:[QWrxI]\\|\\W\\)"))))))**)
>>
>>        (defun ruby-syntax-propertize-**expansions (start end)
>>          (save-excursion
>> @@ -1848,8 +1848,11 @@
>>     '("\\(\\$\\|@\\|@@\\)\\(\\w\\|**_\\)+"
>>       0 font-lock-variable-name-face)
>>     ;; constants
>> -   '("\\(?:\\_<\\|::\\)\\([A-Z]+\**\(\\w\\|_\\)*\\)"
>> -     1 font-lock-type-face)
>> + '("\\(?:\\_<\\|::\\)\\([A-Z]+\**\(\\w\\|_\\)*\\)\\(?:\\_>[^\(]**
>> \\|::\\|\\'\\)"
>> +     1 (progn
>> +         (when (eq ?: (char-before))
>> +           (forward-char -2))
>> +         font-lock-type-face))
>>     '("\\(^\\s *\\|[\[\{\(,]\\s *\\|\\sw\\s +\\)\\(\\(\\sw\\|_\\)+\\):[^:]
>> **" 2 font-lock-constant-face)
>>     ;; expression expansion
>>     '(ruby-match-expression-**expansion
>> @@ -1857,6 +1860,9 @@
>>     ;; negation char
>>     '("[^[:alnum:]_]\\(!\\)[^=]"
>>       1 font-lock-negation-char-face)
>> +   ;; character literals
>> +   ;; FIXME: Support longer escape sequences.
>> +   '("\\?\\\\?\\S " 0 font-lock-string-face)
>>     )
>>    "Additional expressions to highlight in Ruby mode.")
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 5479 bytes --]

Re: Small improvements to ruby-mode

[Dmitry Gutov]

On 13.07.2013 14:23, Bozhidar Batsov wrote:
> Great! Btw, shouldn't we highlight the conversion methods from Kernel
> (Float, Integer, etc) as built-ins?

Sure, it's now easier to do correctly. Done. :)

>     But there's really nothing that would distinguish a Math::E
>     reference from Foo::C. Or from GC, IO, DL, IRB, URI, XML, HTML, etc.
>
>
> Yep, I'm aware we can't distinguish all cases without the use of a
> proper parser, but I guess we should handle accordingly at least the
> scenarios which are deterministic.

But we have to highlight these abbreviation-named modules *somehow*. And 
we're bound to be wrong in 50% of these cases. That's why I don't think 
it's a good idea.

That difference in highlighting wouldn't convey much information anyway: 
uppercase text with underscores is easy to notice as it is.

Re: Small improvements to ruby-mode

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 955 bytes --]

On 13 July 2013 22:10, Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 13.07.2013 14:23, Bozhidar Batsov wrote:
>
>> Great! Btw, shouldn't we highlight the conversion methods from Kernel
>> (Float, Integer, etc) as built-ins?
>>
>
> Sure, it's now easier to do correctly. Done. :)


Thanks!


>
>
>      But there's really nothing that would distinguish a Math::E
>>     reference from Foo::C. Or from GC, IO, DL, IRB, URI, XML, HTML, etc.
>>
>>
>> Yep, I'm aware we can't distinguish all cases without the use of a
>> proper parser, but I guess we should handle accordingly at least the
>> scenarios which are deterministic.
>>
>
> But we have to highlight these abbreviation-named modules *somehow*. And
> we're bound to be wrong in 50% of these cases. That's why I don't think
> it's a good idea.
>
> That difference in highlighting wouldn't convey much information anyway:
> uppercase text with underscores is easy to notice as it is.
>

Fair enough :-)

[-- Attachment #2: Type: text/html, Size: 1789 bytes --]

Re: Small improvements to ruby-mode

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 1292 bytes --]

Btw, I think you've introduced a bug with one of your changes. Paste this
into Emacs:

return if safe_assignment?(cond) && safe_assignment_allowed?

"?(" and the last "?" are highlighted with the font-lock-string face.


On 15 July 2013 16:53, Bozhidar Batsov <bozhidar@batsov.com> wrote:

>
>
>
> On 13 July 2013 22:10, Dmitry Gutov <dgutov@yandex.ru> wrote:
>
>> On 13.07.2013 14:23, Bozhidar Batsov wrote:
>>
>>> Great! Btw, shouldn't we highlight the conversion methods from Kernel
>>> (Float, Integer, etc) as built-ins?
>>>
>>
>> Sure, it's now easier to do correctly. Done. :)
>
>
> Thanks!
>
>
>>
>>
>>      But there's really nothing that would distinguish a Math::E
>>>     reference from Foo::C. Or from GC, IO, DL, IRB, URI, XML, HTML, etc.
>>>
>>>
>>> Yep, I'm aware we can't distinguish all cases without the use of a
>>> proper parser, but I guess we should handle accordingly at least the
>>> scenarios which are deterministic.
>>>
>>
>> But we have to highlight these abbreviation-named modules *somehow*. And
>> we're bound to be wrong in 50% of these cases. That's why I don't think
>> it's a good idea.
>>
>> That difference in highlighting wouldn't convey much information anyway:
>> uppercase text with underscores is easy to notice as it is.
>>
>
> Fair enough :-)
>
>

[-- Attachment #2: Type: text/html, Size: 2492 bytes --]

Re: Small improvements to ruby-mode

[Dmitry Gutov]

On 16.07.2013 17:18, Bozhidar Batsov wrote:
> Btw, I think you've introduced a bug with one of your changes. Paste
> this into Emacs:
>
> return if safe_assignment?(cond) && safe_assignment_allowed?
>
> "?(" and the last "?" are highlighted with the font-lock-string face.

Thanks for noticing. Fixed!

Re: Small improvements to ruby-mode

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

The author of ruby-tools informed me and Stefan that the copyright
assignment process has been completed so I guess you can copy the commands
from there and assign them new keybinding in ruby-mode.


On 16 July 2013 17:47, Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 16.07.2013 17:18, Bozhidar Batsov wrote:
>
>> Btw, I think you've introduced a bug with one of your changes. Paste
>> this into Emacs:
>>
>> return if safe_assignment?(cond) && safe_assignment_allowed?
>>
>> "?(" and the last "?" are highlighted with the font-lock-string face.
>>
>
> Thanks for noticing. Fixed!
>

[-- Attachment #2: Type: text/html, Size: 1071 bytes --]

Re: Small improvements to ruby-mode

[Dmitry Gutov]

On 08.08.2013 18:56, Bozhidar Batsov wrote:
> The author of ruby-tools informed me and Stefan that the copyright
> assignment process has been completed so I guess you can copy the
> commands from there and assign them new keybinding in ruby-mode.

Good! Any suggestions on the new keybindings for them?

How do C-c [':" #] sound to you?

ruby-tools binds `ruby-tools-clear-string' to `C-;', but `C-c ;' is 
already taken by Rinari. So it would be C-c <SPC>.

Re: Small improvements to ruby-mode

[Stefan Monnier]

> How do C-c [':" #] sound to you?

The Elisp coding conventions say:

   • Sequences consisting of ‘C-c’ followed by a control character or a
     digit are reserved for major modes.

   • Sequences consisting of ‘C-c’ followed by ‘{’, ‘}’, ‘<’, ‘>’, ‘:’
     or ‘;’ are also reserved for major modes.

   • Sequences consisting of ‘C-c’ followed by any other punctuation
     character are allocated for minor modes.  Using them in a major
     mode is not absolutely prohibited, but if you do that, the major
     mode binding may be shadowed from time to time by minor modes.


-- Stefan

Re: Small improvements to ruby-mode

[Dmitry Gutov]

On 09.08.2013 01:47, Stefan Monnier wrote:
>> How do C-c [':" #] sound to you?
>
> The Elisp coding conventions say:
>
>     • Sequences consisting of ‘C-c’ followed by a control character or a
>       digit are reserved for major modes.
>
>     • Sequences consisting of ‘C-c’ followed by ‘{’, ‘}’, ‘<’, ‘>’, ‘:’
>       or ‘;’ are also reserved for major modes.
>
>     • Sequences consisting of ‘C-c’ followed by any other punctuation
>       character are allocated for minor modes.  Using them in a major
>       mode is not absolutely prohibited, but if you do that, the major
>       mode binding may be shadowed from time to time by minor modes.

Thanks. I've read this before, but the list seems pretty arbitrary.

I don't know of any minor mode that uses the prefix `C-c #' (because it 
requires you to press Shift).

The rule says using other sequences is also allowed, so in practice, I 
think we'll just have a problem with, again, Rinari, which also binds 
`C-c '' as its prefix.

We could ask them to limit themselves to `C-c ;' by default, or, I 
guess, use prefix `C-c C-t' for all commands here.

Re: Small improvements to ruby-mode

[Stefan Monnier]

> Thanks. I've read this before, but the list seems pretty arbitrary.

It is arbitrary to a large extent, but it has the virtue of making it
clear who's stepping on who's foot when two packages's bindings conflict.

> I don't know of any minor mode that uses the prefix `C-c #' (because it
> requires you to press Shift).

That's lucky for those poor minor modes: it's always really difficult to
find good bindings for minor modes because there are very few bindings
reserved for them, and they have the added problem of having to cohabit
with other minor modes.

Usually major modes prefer to use bindings which start with C-c
C-<something>.  There are usually many such keys available and they're
pretty easy to type since you can just keep the control key pressed.


        Stefan

Re: Small improvements to ruby-mode

[Dmitry Gutov]

On 09.08.2013 17:52, Stefan Monnier wrote:
> That's lucky for those poor minor modes: it's always really difficult to
> find good bindings for minor modes because there are very few bindings
> reserved for them, and they have the added problem of having to cohabit
> with other minor modes.

I don't think it's that big of a problem. Minor minor modes either do, 
or should allow the user to customize the prefix. So they can change it 
in case of a conflict. And anyway, if a minor mode picks `C-c #' as its 
prefix, it's the major mode that is screwed, because minor mode bindings 
trump major mode ones.

> Usually major modes prefer to use bindings which start with C-c
> C-<something>.  There are usually many such keys available and they're
> pretty easy to type since you can just keep the control key pressed.

Ok, here's a possible set of bindings:

(define-key map (kbd "C-c C-'") 'ruby-tools-to-single-quote-string)
(define-key map (kbd "C-c C-\"") 'ruby-tools-to-double-quote-string)
(define-key map (kbd "C-c C-:") 'ruby-tools-to-symbol)
(define-key map (kbd "C-c C-;") 'ruby-tools-clear-string)
(define-key map (kbd "C-c C-#") 'ruby-tools-interpolate)

The last one is the most problematic: it's supposed to reduce the amount 
of keystrokes the user types, but typing `# { } C-b' is not that longer, 
and with `autopair-mode' enabled (or `electric-pair-mode', I suppose'), 
we only have to type `# {' anyway.
Maybe we should just drop it.

Here's another issue: ruby-tools comes with a suite of tests written 
using ecukes, which is not included with Emacs, and would be 
incompatible with the current test directory layout anyway.

Should they be rewritten using ERT? Or do we drop them and risk 
divergence from upstream and code breakage?

N.B.: Out of two similar repositories, one with tests and one without, 
it's natural for me to consider the former one as upstream.

Re: Small improvements to ruby-mode

[Stefan Monnier]

> Should they be rewritten using ERT? Or do we drop them and risk divergence
> from upstream and code breakage?

All these discussions should happen mostly with ruby-tools author.
He should be responsible for avoiding divergence.


        Stefan

Re: Small improvements to ruby-mode

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 2448 bytes --]

On 10 August 2013 14:45, Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 09.08.2013 17:52, Stefan Monnier wrote:
>
>> That's lucky for those poor minor modes: it's always really difficult to
>> find good bindings for minor modes because there are very few bindings
>> reserved for them, and they have the added problem of having to cohabit
>> with other minor modes.
>>
>
> I don't think it's that big of a problem. Minor minor modes either do, or
> should allow the user to customize the prefix. So they can change it in
> case of a conflict. And anyway, if a minor mode picks `C-c #' as its
> prefix, it's the major mode that is screwed, because minor mode bindings
> trump major mode ones.
>
>
>  Usually major modes prefer to use bindings which start with C-c
>> C-<something>.  There are usually many such keys available and they're
>> pretty easy to type since you can just keep the control key pressed.
>>
>
> Ok, here's a possible set of bindings:
>
> (define-key map (kbd "C-c C-'") 'ruby-tools-to-single-quote-**string)

(define-key map (kbd "C-c C-\"") 'ruby-tools-to-double-quote-**string)
> (define-key map (kbd "C-c C-:") 'ruby-tools-to-symbol)
> (define-key map (kbd "C-c C-;") 'ruby-tools-clear-string)
> (define-key map (kbd "C-c C-#") 'ruby-tools-interpolate)
>
> The last one is the most problematic: it's supposed to reduce the amount
> of keystrokes the user types, but typing `# { } C-b' is not that longer,
> and with `autopair-mode' enabled (or `electric-pair-mode', I suppose'), we
> only have to type `# {' anyway.
> Maybe we should just drop it.
>

The interpolate functionality seems redundant to me, so I'd suggest
dropping it.


>
> Here's another issue: ruby-tools comes with a suite of tests written using
> ecukes, which is not included with Emacs, and would be incompatible with
> the current test directory layout anyway.
>
> Should they be rewritten using ERT? Or do we drop them and risk divergence
> from upstream and code breakage?
>

Having ERT tests is never a bad idea. That said I don't think there will be
a risk of upstream divergence, since I'm pretty sure after ruby-tools is
merged into ruby-mode the existing project will be decommissioned.


>
> N.B.: Out of two similar repositories, one with tests and one without,
> it's natural for me to consider the former one as upstream.
>

But if our case there won't be to similar repos, as noted above - most
likely the current project will cease to exist.

[-- Attachment #2: Type: text/html, Size: 3693 bytes --]

Re: Small improvements to ruby-mode

[Dmitry Gutov]

On 11.08.2013 14:54, Bozhidar Batsov wrote:
> The interpolate functionality seems redundant to me, so I'd suggest
> dropping it.

Ok, good.

>     Here's another issue: ruby-tools comes with a suite of tests written
>     using ecukes, which is not included with Emacs, and would be
>     incompatible with the current test directory layout anyway.
>
>     Should they be rewritten using ERT? Or do we drop them and risk
>     divergence from upstream and code breakage?
>
>
> Having ERT tests is never a bad idea. That said I don't think there will
> be a risk of upstream divergence, since I'm pretty sure after ruby-tools
> is merged into ruby-mode the existing project will be decommissioned.

It was my own understanding also, but I'd rather have confirmation from 
Johan.

Then the risk is just code breakage down the line. The functionality is 
relatively simple, so maybe it won't even be a problem.

To be clear:
Would you like to port the tests to ERT yourself?
Do you suggest we just drop them?

Re: Small improvements to ruby-mode

[Johan Andersson]

[-- Attachment #1: Type: text/plain, Size: 1486 bytes --]

It's a shame that packages included in Emacs cannot use the current test
suite. Specially in this case since the tests are very good.

I don't think there's any idea to write these in Ert since the mode is
interactive and it would require a lot of mocking and stuff. On the other
hand, there are some tricky regexes that I would never touch without good
tests.


On Sun, Aug 11, 2013 at 3:08 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 11.08.2013 14:54, Bozhidar Batsov wrote:
>
>> The interpolate functionality seems redundant to me, so I'd suggest
>> dropping it.
>>
>
> Ok, good.
>
>      Here's another issue: ruby-tools comes with a suite of tests written
>>     using ecukes, which is not included with Emacs, and would be
>>     incompatible with the current test directory layout anyway.
>>
>>     Should they be rewritten using ERT? Or do we drop them and risk
>>     divergence from upstream and code breakage?
>>
>>
>> Having ERT tests is never a bad idea. That said I don't think there will
>> be a risk of upstream divergence, since I'm pretty sure after ruby-tools
>> is merged into ruby-mode the existing project will be decommissioned.
>>
>
> It was my own understanding also, but I'd rather have confirmation from
> Johan.
>
> Then the risk is just code breakage down the line. The functionality is
> relatively simple, so maybe it won't even be a problem.
>
> To be clear:
> Would you like to port the tests to ERT yourself?
> Do you suggest we just drop them?
>

[-- Attachment #2: Type: text/html, Size: 2142 bytes --]

Re: Small improvements to ruby-mode

[Dmitry Gutov]

On 11.08.2013 17:08, Johan Andersson wrote:
> It's a shame that packages included in Emacs cannot use the current test
> suite. Specially in this case since the tests are very good.
>
> I don't think there's any idea to write these in Ert since the mode is
> interactive and it would require a lot of mocking and stuff.

I don't think it would be that hard. For example, see 
`ruby-toggle-block-to-brace' and other tests, here:

http://bzr.savannah.gnu.org/lh/emacs/trunk/annotate/head:/test/automated/ruby-mode-tests.el#L288

Sure, they don't test keybindings, but I'd say it's not the most 
important part.

Re: Small improvements to ruby-mode

[Johan Andersson]

[-- Attachment #1: Type: text/plain, Size: 1052 bytes --]

Allright, that looks fine. I think some basic tests like that would be
great to have. I try to catch everything in my tests, but that might not be
necessary. Take a look at the tests I have written and migrate the ones you
seem useful.


On Sun, Aug 11, 2013 at 4:29 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 11.08.2013 17:08, Johan Andersson wrote:
>
>> It's a shame that packages included in Emacs cannot use the current test
>> suite. Specially in this case since the tests are very good.
>>
>> I don't think there's any idea to write these in Ert since the mode is
>> interactive and it would require a lot of mocking and stuff.
>>
>
> I don't think it would be that hard. For example, see
> `ruby-toggle-block-to-brace' and other tests, here:
>
> http://bzr.savannah.gnu.org/**lh/emacs/trunk/annotate/head:/**
> test/automated/ruby-mode-**tests.el#L288<http://bzr.savannah.gnu.org/lh/emacs/trunk/annotate/head:/test/automated/ruby-mode-tests.el#L288>
>
> Sure, they don't test keybindings, but I'd say it's not the most important
> part.
>

[-- Attachment #2: Type: text/html, Size: 1596 bytes --]

Re: Small improvements to ruby-mode

[Stefan Monnier]

> Allright, that looks fine.  I think some basic tests like that would
> be great to have.  I try to catch everything in my tests, but that
> might not be necessary.  Take a look at the tests I have written and
> migrate the ones you seem useful.

We could give you write access so you can help us directly.
And in the mean time, you can send patches.


        Stefan

Re: Small improvements to ruby-mode

[Johan Andersson]

[-- Attachment #1: Type: text/plain, Size: 630 bytes --]

Sure thing. I'm currently at vacation, so I will not be working on this for
a while anyways. Tell me when I got access and I will look at it when I get
home.


On Sun, Aug 11, 2013 at 6:56 PM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

> > Allright, that looks fine.  I think some basic tests like that would
> > be great to have.  I try to catch everything in my tests, but that
> > might not be necessary.  Take a look at the tests I have written and
> > migrate the ones you seem useful.
>
> We could give you write access so you can help us directly.
> And in the mean time, you can send patches.
>
>
>         Stefan
>

[-- Attachment #2: Type: text/html, Size: 1067 bytes --]

Re: Small improvements to ruby-mode

[Stefan Monnier]

> Sure thing. I'm currently at vacation, so I will not be working on
> this for a while anyways.  Tell me when I got access and I will look
> at it when I get home.

To get access, ask for it by requesting to be a member of the "emacs"
group, from your savannah.gnu.org account.


        Stefan

Re: Small improvements to ruby-mode

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 439 bytes --]

Any progress with the integration of ruby-tools?


On 12 August 2013 04:52, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > Sure thing. I'm currently at vacation, so I will not be working on
> > this for a while anyways.  Tell me when I got access and I will look
> > at it when I get home.
>
> To get access, ask for it by requesting to be a member of the "emacs"
> group, from your savannah.gnu.org account.
>
>
>         Stefan
>

[-- Attachment #2: Type: text/html, Size: 932 bytes --]

Re: Small improvements to ruby-mode

[Johan Andersson]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

I'm back from vacation so I can probably find some time.

Not sure what your plan is? I was asked to take a look at the tests. Are
you also expecting me to implement the code? I guess it makes sense if the
same person does it.

I should tell you that I have no experience working with bazaar so there
will be some overhead and take some more time.
On Sep 13, 2013 11:10 AM, "Bozhidar Batsov" <bozhidar@batsov.com> wrote:

> Any progress with the integration of ruby-tools?
>
>
> On 12 August 2013 04:52, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>> > Sure thing. I'm currently at vacation, so I will not be working on
>> > this for a while anyways.  Tell me when I got access and I will look
>> > at it when I get home.
>>
>> To get access, ask for it by requesting to be a member of the "emacs"
>> group, from your savannah.gnu.org account.
>>
>>
>>         Stefan
>>
>
>

[-- Attachment #2: Type: text/html, Size: 1611 bytes --]

Re: Small improvements to ruby-mode

[Stefan Monnier]

> I should tell you that I have no experience working with bazaar so there
> will be some overhead and take some more time.

There are also Git versions of Emacs's repository (and an Hg version as
well?), if you prefer.  Also you can just grab the latest version of
ruby-mode.el via the web interface
(http://bzr.savannah.gnu.org/lh/emacs/trunk/download/head:/rubymode.el-20091113204419-o5vbwnq5f7feedwu-8804/ruby-mode.el)
and then send patches.


        Stefan

Re: Small improvements to ruby-mode

[Johan Andersson]

[-- Attachment #1: Type: text/plain, Size: 601 bytes --]

Great, git mirror is fine!


On Fri, Sep 13, 2013 at 3:24 PM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

> > I should tell you that I have no experience working with bazaar so there
> > will be some overhead and take some more time.
>
> There are also Git versions of Emacs's repository (and an Hg version as
> well?), if you prefer.  Also you can just grab the latest version of
> ruby-mode.el via the web interface
> (
> http://bzr.savannah.gnu.org/lh/emacs/trunk/download/head:/rubymode.el-20091113204419-o5vbwnq5f7feedwu-8804/ruby-mode.el
> )
> and then send patches.
>
>
>         Stefan
>

[-- Attachment #2: Type: text/html, Size: 1179 bytes --]

Re: Small improvements to ruby-mode

[Stefan Monnier]

> I thought the manual installation instructions were leftovers from the old
> ruby-mode. I was under the impression that since ruby-mode started using
> SMIE it's not a good idea to distribute it separately, since it might not
> behave appropriately on older Emacsen. Perhaps I'm wrong.

SMIE comes with Emacs since 23.4 and ruby-mode doesn't use SMIE:
I installed a rough first cut at what could become SMIE support, but
since I don't use Ruby, I probably won't do it myself and it looks like
noone's interested to pick up the work.

> That's unfortunate.  Files with tabs look like Christmas trees for most
> whitespace-mode users.

If they have nothing better to do than watch the lights of the Xmas
tree, it's their choice.  IOW I think the problem is that those users
should get a life.

>> * make use of `font-lock-negation-char-face` for !

Why have a special face for the negation char?  What's so special about
this char?


        Stefan

Re: Small improvements to ruby-mode

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]

On 6 July 2013 01:35, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > I thought the manual installation instructions were leftovers from the
> old
> > ruby-mode. I was under the impression that since ruby-mode started using
> > SMIE it's not a good idea to distribute it separately, since it might not
> > behave appropriately on older Emacsen. Perhaps I'm wrong.
>
> SMIE comes with Emacs since 23.4 and ruby-mode doesn't use SMIE:
> I installed a rough first cut at what could become SMIE support, but
> since I don't use Ruby, I probably won't do it myself and it looks like
> noone's interested to pick up the work.
>

I'm interested in working on this, but I'm not sure how soon I'll be able
to fit it in my schedule.

>
> > That's unfortunate.  Files with tabs look like Christmas trees for most
> > whitespace-mode users.
>
> If they have nothing better to do than watch the lights of the Xmas
> tree, it's their choice.  IOW I think the problem is that those users
> should get a life.
>
> >> * make use of `font-lock-negation-char-face` for !
>
> Why have a special face for the negation char?  What's so special about
> this char?
>

As the face description says it's pretty easy to overlook an ! attached to
some identifier(like !ol - you can mistake the this for lol).
Unfortunately few major modes have bothered to use the face.

>
>
>         Stefan
>

[-- Attachment #2: Type: text/html, Size: 2277 bytes --]

Re: Small improvements to ruby-mode

[Dmitry Gutov]

On 06.07.2013 9:14, Bozhidar Batsov wrote:
>     SMIE comes with Emacs since 23.4 and ruby-mode doesn't use SMIE:
>     I installed a rough first cut at what could become SMIE support, but
>     since I don't use Ruby, I probably won't do it myself and it looks like
>     noone's interested to pick up the work.
>
>
> I'm interested in working on this, but I'm not sure how soon I'll be
> able to fit it in my schedule.

Likewise, I'd like to take this on sometime, but so far it's been low 
priority.