all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* ruby mode additional packages
@ 2022-07-07 13:50 Grant Shangreaux
  2022-07-07 15:33 ` Philip Kaludercic
  2022-07-08  1:10 ` Dmitry Gutov
  0 siblings, 2 replies; 10+ messages in thread
From: Grant Shangreaux @ 2022-07-07 13:50 UTC (permalink / raw)
  To: emacs-devel


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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: ruby mode additional packages
  2022-07-07 13:50 ruby mode additional packages Grant Shangreaux
@ 2022-07-07 15:33 ` Philip Kaludercic
  2022-07-08  3:41   ` Grant Shangreaux
  2022-07-08  1:10 ` Dmitry Gutov
  1 sibling, 1 reply; 10+ messages in thread
From: Philip Kaludercic @ 2022-07-07 15:33 UTC (permalink / raw)
  To: Grant Shangreaux; +Cc: emacs-devel, Dmitry Gutov

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!



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: ruby mode additional packages
  2022-07-07 13:50 ruby mode additional packages Grant Shangreaux
  2022-07-07 15:33 ` Philip Kaludercic
@ 2022-07-08  1:10 ` Dmitry Gutov
  2022-07-08  3:17   ` Grant Shangreaux
  1 sibling, 1 reply; 10+ messages in thread
From: Dmitry Gutov @ 2022-07-08  1:10 UTC (permalink / raw)
  To: Grant Shangreaux, emacs-devel

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.



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: ruby mode additional packages
  2022-07-08  1:10 ` Dmitry Gutov
@ 2022-07-08  3:17   ` Grant Shangreaux
  2022-07-10  1:18     ` Dmitry Gutov
  0 siblings, 1 reply; 10+ messages in thread
From: Grant Shangreaux @ 2022-07-08  3:17 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: emacs-devel


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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: ruby mode additional packages
  2022-07-07 15:33 ` Philip Kaludercic
@ 2022-07-08  3:41   ` Grant Shangreaux
  0 siblings, 0 replies; 10+ messages in thread
From: Grant Shangreaux @ 2022-07-08  3:41 UTC (permalink / raw)
  To: Philip Kaludercic; +Cc: emacs-devel


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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: ruby mode additional packages
  2022-07-08  3:17   ` Grant Shangreaux
@ 2022-07-10  1:18     ` Dmitry Gutov
  2022-07-10 14:24       ` Stefan Monnier
  0 siblings, 1 reply; 10+ messages in thread
From: Dmitry Gutov @ 2022-07-10  1:18 UTC (permalink / raw)
  To: Grant Shangreaux; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: ruby mode additional packages
  2022-07-10  1:18     ` Dmitry Gutov
@ 2022-07-10 14:24       ` Stefan Monnier
  2022-07-10 18:13         ` Bozhidar Batsov
  0 siblings, 1 reply; 10+ messages in thread
From: Stefan Monnier @ 2022-07-10 14:24 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: Grant Shangreaux, emacs-devel

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

Looks that way:

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


-- Stefan




^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: ruby mode additional packages
  2022-07-10 14:24       ` Stefan Monnier
@ 2022-07-10 18:13         ` Bozhidar Batsov
  2022-07-11  1:07           ` Dmitry Gutov
  0 siblings, 1 reply; 10+ messages in thread
From: Bozhidar Batsov @ 2022-07-10 18:13 UTC (permalink / raw)
  To: Emacs Devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: ruby mode additional packages
  2022-07-10 18:13         ` Bozhidar Batsov
@ 2022-07-11  1:07           ` Dmitry Gutov
  2022-07-11  6:28             ` Bozhidar Batsov
  0 siblings, 1 reply; 10+ messages in thread
From: Dmitry Gutov @ 2022-07-11  1:07 UTC (permalink / raw)
  To: Bozhidar Batsov, Emacs Devel

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.



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: ruby mode additional packages
  2022-07-11  1:07           ` Dmitry Gutov
@ 2022-07-11  6:28             ` Bozhidar Batsov
  0 siblings, 0 replies; 10+ messages in thread
From: Bozhidar Batsov @ 2022-07-11  6:28 UTC (permalink / raw)
  To: Emacs Devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2022-07-11  6:28 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-07-07 13:50 ruby mode additional packages Grant Shangreaux
2022-07-07 15:33 ` Philip Kaludercic
2022-07-08  3:41   ` Grant Shangreaux
2022-07-08  1:10 ` Dmitry Gutov
2022-07-08  3:17   ` Grant Shangreaux
2022-07-10  1:18     ` Dmitry Gutov
2022-07-10 14:24       ` Stefan Monnier
2022-07-10 18:13         ` Bozhidar Batsov
2022-07-11  1:07           ` Dmitry Gutov
2022-07-11  6:28             ` Bozhidar Batsov

Code repositories for project(s) associated with this external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.