ruby mode additional packages

ruby mode additional packages

[Grant Shangreaux]

hello emacs-devel,

i've recently been re-rolling a configuration using only ELPA and
non-gnu ELPA package archives. i primarily work with ruby in my
day-to-day work, and was a bit surprised that many of the packages i've
grown accustomed to are not available, particularly inf-ruby.

i understand that much of it comes from copyright assignment issues, but
i was curious if there is any work to bring some of the ruby support
packages into non-gnu ELPA? i am sort of the de-facto maintainer of the
minitest-emacs package, though i did not write it. i would be
interested in organizing what it takes to get it into non-gnu ELPA.

in addition to that, i started trying to make my own inferior ruby based
off of comint-mode, and while its very basic right now, it does
work. would there be any desire to add a FSF assigned new version of
inferior ruby to ELPA or Emacs proper? what considerations are required
for something like that? i do not want to detract from the work people
put into the existing inf-ruby. i also do not want to cause any issues
with copyright or licensing, for example, using inf-ruby as a basis
to write a new package.

i do have my FSF paperwork in order, and i'd love to contribute what i
can. since i'm in ruby land most often i thought i would ask here to see
where the effort would best be placed. thank you!

-- 
Tokṡa ake
Grant Shangreaux

Re: ruby mode additional packages

[Philip Kaludercic]

Grant Shangreaux <grant@churls.world> writes:

> hello emacs-devel,
>
> i've recently been re-rolling a configuration using only ELPA and
> non-gnu ELPA package archives. i primarily work with ruby in my
> day-to-day work, and was a bit surprised that many of the packages i've
> grown accustomed to are not available, particularly inf-ruby.
>
> i understand that much of it comes from copyright assignment issues, but
> i was curious if there is any work to bring some of the ruby support
> packages into non-gnu ELPA? i am sort of the de-facto maintainer of the
> minitest-emacs package, though i did not write it. i would be
> interested in organizing what it takes to get it into non-gnu ELPA.

All that is needed is a link to the repository, then it can be added.
If you and all the contributors have signed the CA, then it could even
be added to GNU ELPA.

> in addition to that, i started trying to make my own inferior ruby based
> off of comint-mode, and while its very basic right now, it does
> work. would there be any desire to add a FSF assigned new version of
> inferior ruby to ELPA or Emacs proper? what considerations are required
> for something like that? i do not want to detract from the work people
> put into the existing inf-ruby. i also do not want to cause any issues
> with copyright or licensing, for example, using inf-ruby as a basis
> to write a new package.

ruby-mode is maintained by Dmitry Gutov, so I've CC'ed him.  If it is an
uncontroversial upgrade, I wouldn't expect any resistance, otherwise I
think it might be better to add it to GNU ELPA.

> i do have my FSF paperwork in order, and i'd love to contribute what i
> can. since i'm in ruby land most often i thought i would ask here to see
> where the effort would best be placed. thank you!

Re: ruby mode additional packages

[Grant Shangreaux]

Philip Kaludercic <philipk@posteo.net> writes:

> All that is needed is a link to the repository, then it can be added.
> If you and all the contributors have signed the CA, then it could even
> be added to GNU ELPA.

ok great! i'm afraid i came to maintain minitest-emacs after most of it
was written, so i'm quite unsure about how it would go with the other
contributors. i did start a discussion there to ask about it.

before i submit the link for the repository, i'm also proposing it is
rehosted on a different forge, but i will follow up soon. thank you.

-- 
Tokṡa ake
Grant Shangreaux

Re: ruby mode additional packages

[Dmitry Gutov]

Hi!

On 07.07.2022 16:50, Grant Shangreaux wrote:
> i've recently been re-rolling a configuration using only ELPA and
> non-gnu ELPA package archives. i primarily work with ruby in my
> day-to-day work, and was a bit surprised that many of the packages i've
> grown accustomed to are not available, particularly inf-ruby.

> i understand that much of it comes from copyright assignment issues, but
> i was curious if there is any work to bring some of the ruby support
> packages into non-gnu ELPA? i am sort of the de-facto maintainer of the
> minitest-emacs package, though i did not write it. i would be
> interested in organizing what it takes to get it into non-gnu ELPA.

There's nothing barring inf-ruby from being featured in NonGNU ELPA. Now 
that you have voiced the question, we can get it added.

> in addition to that, i started trying to make my own inferior ruby based
> off of comint-mode, and while its very basic right now, it does
> work. would there be any desire to add a FSF assigned new version of
> inferior ruby to ELPA or Emacs proper? what considerations are required
> for something like that? i do not want to detract from the work people
> put into the existing inf-ruby. i also do not want to cause any issues
> with copyright or licensing, for example, using inf-ruby as a basis
> to write a new package.

I don't know, I feel like most of the stuff in inf-ruby is fairly 
essential (if I do say so myself, having written or re-written a 
significant part of it).

If you want to reimplement the parts written by people without copyright 
assignment, be my guest, I guess. Maybe to get it in ELPA, or maybe into 
Emacs proper.

But according to my observations, people have asked for the reverse: to 
have the latest version of ruby-mode in some ELPA archive, to be able to 
use it from any Emacs release.

So from where I'm sitting, having inf-ruby in NonGNU ELPA would solve 
99% of everyone's needs.

> i do have my FSF paperwork in order, and i'd love to contribute what i
> can. since i'm in ruby land most often i thought i would ask here to see
> where the effort would best be placed. thank you!

I personally think the effort is best placed improving the existing 
packages.

Not to discourage you from writing ones from scratch, though. That can 
be fun and useful too.

Re: ruby mode additional packages

[Grant Shangreaux]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Hi!
>
> There's nothing barring inf-ruby from being featured in NonGNU
> ELPA. Now that you have voiced the question, we can get it added.
>

oh great! i have simply taken for granted all these years that inf-ruby
was "part of Emacs", but only recently have i become aware of the
distinctions between the various package archives.

>> in addition to that, i started trying to make my own inferior ruby based
>> off of comint-mode, and while its very basic right now, it does
>> work. would there be any desire to add a FSF assigned new version of
>> inferior ruby to ELPA or Emacs proper?

> I don't know, I feel like most of the stuff in inf-ruby is fairly
> essential (if I do say so myself, having written or re-written a
> significant part of it).

i'm certain it is :) i've perused the package and i definitely had not
considered support for multiple implementations across many versions of
Ruby, IRB, Pry etc. i realized the issue i'd been having recently was
actually an IRB problem and i could not blindly rely on --inf-ruby-mode
as a flag.

> If you want to reimplement the parts written by people without
> copyright assignment, be my guest, I guess. Maybe to get it in ELPA,
> or maybe into Emacs proper.
>
> But according to my observations, people have asked for the reverse:
> to have the latest version of ruby-mode in some ELPA archive, to be
> able to use it from any Emacs release.
>
> So from where I'm sitting, having inf-ruby in NonGNU ELPA would solve
> 99% of everyone's needs.

yeah this is interesting to think about. i've been attempting to
approach Emacs again as a beginner, and since myself and my colleagues
primarily work with Ruby, that has been one of my focuses when working
on a configuration. to simplify things, i wanted to rely on what a new
user would get "out of the box" with Emacs 28. having ruby-mode baked in
felt like a Good Thing. needing a package just to get basic language
support would feel bad, especially when Ruby and Emacs have such a
history together. i think i was a bit surprised that inf-ruby was not
included, since it feels like a natural extension of ruby-mode

but you're absolutely right, getting inf-ruby in NonGNU ELPA /would/
solve 99% of everyone's needs (including mine :) ). 

>> i do have my FSF paperwork in order, and i'd love to contribute what i
>> can. since i'm in ruby land most often i thought i would ask here to see
>> where the effort would best be placed. thank you!
>
> I personally think the effort is best placed improving the existing
> packages.
>
> Not to discourage you from writing ones from scratch, though. That can
> be fun and useful too.

i agree. while i was having some fun digging into comint-mode and IRB,
there is a lot of effort in inf-ruby i would rather continue
supporting. i do have a romantic notion about getting it into ELPA and
Emacs proper, but your point about people asking for a package version
of ruby-mode feels more practical. bringing inf-ruby to NonGNU ELPA
feels like the right step, and if there is desire to get it assigned to
the FSF someday and into ELPA, i'd be happy to help.

thank you!

-- 
Tokṡa ake
Grant Shangreaux

Re: ruby mode additional packages

[Dmitry Gutov]

On 08.07.2022 06:17, Grant Shangreaux wrote:

>> There's nothing barring inf-ruby from being featured in NonGNU
>> ELPA. Now that you have voiced the question, we can get it added.
>>
> 
> oh great! i have simply taken for granted all these years that inf-ruby
> was "part of Emacs", but only recently have i become aware of the
> distinctions between the various package archives.

I've added it to NonGNU ELPA now. Successfully, I hope.

>>> in addition to that, i started trying to make my own inferior ruby based
>>> off of comint-mode, and while its very basic right now, it does
>>> work. would there be any desire to add a FSF assigned new version of
>>> inferior ruby to ELPA or Emacs proper?
> 
>> I don't know, I feel like most of the stuff in inf-ruby is fairly
>> essential (if I do say so myself, having written or re-written a
>> significant part of it).
> 
> i'm certain it is :) i've perused the package and i definitely had not
> considered support for multiple implementations across many versions of
> Ruby, IRB, Pry etc. i realized the issue i'd been having recently was
> actually an IRB problem and i could not blindly rely on --inf-ruby-mode
> as a flag.

Yeah. I don't think the --inf-ruby-mode flag has worked well enough for 
a while.

> yeah this is interesting to think about. i've been attempting to
> approach Emacs again as a beginner, and since myself and my colleagues
> primarily work with Ruby, that has been one of my focuses when working
> on a configuration. to simplify things, i wanted to rely on what a new
> user would get "out of the box" with Emacs 28. having ruby-mode baked in
> felt like a Good Thing. needing a package just to get basic language
> support would feel bad, especially when Ruby and Emacs have such a
> history together. i think i was a bit surprised that inf-ruby was not
> included, since it feels like a natural extension of ruby-mode
> 
> but you're absolutely right, getting inf-ruby in NonGNU ELPA /would/
> solve 99% of everyone's needs (including mine :) ).

Cool. To be sure, help improving inf-ruby is always welcome. Especially 
from someone who has already tinkered with Comint and IRB.

There are certainly bugs lurking there that could use rooting out.

>>> i do have my FSF paperwork in order, and i'd love to contribute what i
>>> can. since i'm in ruby land most often i thought i would ask here to see
>>> where the effort would best be placed. thank you!
>>
>> I personally think the effort is best placed improving the existing
>> packages.
>>
>> Not to discourage you from writing ones from scratch, though. That can
>> be fun and useful too.
> 
> i agree. while i was having some fun digging into comint-mode and IRB,
> there is a lot of effort in inf-ruby i would rather continue
> supporting. i do have a romantic notion about getting it into ELPA and
> Emacs proper, but your point about people asking for a package version
> of ruby-mode feels more practical. bringing inf-ruby to NonGNU ELPA
> feels like the right step, and if there is desire to get it assigned to
> the FSF someday and into ELPA, i'd be happy to help.

It doesn't have to be either/or.

My preference would be to focus on improving the existing functionality, 
but if you like to continue the rewrite, it's a solid direction, too.

Re: ruby mode additional packages

[Stefan Monnier]

> I've added it to NonGNU ELPA now. Successfully, I hope.

Looks that way:

    https://elpa.nongnu.org/nongnu/inf-ruby.html


-- Stefan

Re: ruby mode additional packages

[Bozhidar Batsov]

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

Perhaps it'd be good to add robe as well? (https://github.com/dgutov/robe)

On Sun, Jul 10, 2022, at 5:24 PM, Stefan Monnier wrote:
> > I've added it to NonGNU ELPA now. Successfully, I hope.
> 
> Looks that way:
> 
>     https://elpa.nongnu.org/nongnu/inf-ruby.html
> 
> 
> -- Stefan
> 
> 
> 

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

Re: ruby mode additional packages

[Dmitry Gutov]

On 10.07.2022 21:13, Bozhidar Batsov wrote:
> Perhaps it'd be good to add robe as well? 
> (https://github.com/dgutov/robe <https://github.com/dgutov/robe>)

Perhaps. :-)

I'm not sure how many users it has these days: LSP seems to be all the 
rage now.

Also it's behind on some infrastructure improvements (like Xref 
integration), not to mention a long-delayed general rewrite.

I should really get around to all this one of these days.

Re: ruby mode additional packages

[Bozhidar Batsov]

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

You're the boss. :-) I also know that LSP is all the rage, but solargraph was never a great LSP server (we'll see how Spopify will do with theirs) and I always liked the simplicity of tools like Robe. It's good to have options and alternatives IMO. 

On Mon, Jul 11, 2022, at 4:07 AM, Dmitry Gutov wrote:
> On 10.07.2022 21:13, Bozhidar Batsov wrote:
> > Perhaps it'd be good to add robe as well? 
> > (https://github.com/dgutov/robe <https://github.com/dgutov/robe>)
> 
> Perhaps. :-)
> 
> I'm not sure how many users it has these days: LSP seems to be all the 
> rage now.
> 
> Also it's behind on some infrastructure improvements (like Xref 
> integration), not to mention a long-delayed general rewrite.
> 
> I should really get around to all this one of these days.
> 
> 

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