Official Status of emacs-rails?
Peter Jones
With the rubyforge page starting to age, and there being a few forks
of emacs-rails on github, I'm wondering what the official status is.
Has anyone assumed the role of maintainer? Where is the official
repository? Is there a release schedule?
I have a feeling that this project is getting a bit more public
attention than realized. Unfortunately, the project doesn't seem to
have a good public "face", or at least a unified one.
I'm generally not one to complain without offering help. Therefore
I'd like to help where I can. I think there are several people on
this mailing list who feel the same way, but just need someone to
organize their efforts.
So, will the maintainer please stand up and make yourself known.
--
Peter Jones, pmade inc.
http://pmade.com
Clinton R. Nixon
> Has anyone assumed the role of maintainer? Where is the official
> repository? Is there a release schedule?
>
Peter,
I'm fairly certain the maintainer is Phil Hagelberg
(http://technomancy.us/). He's also the author of rinari, another
Emacs library for Rails that he's disavowed, but I find way more
usable than emacs-on-rails.
- Clinton R. Nixon
Phil Hagelberg
> I'm fairly certain the maintainer is Phil Hagelberg
> (http://technomancy.us/). He's also the author of rinari, another
> Emacs library for Rails that he's disavowed, but I find way more
> usable than emacs-on-rails.
I suppose I should step in here.
I was offered the maintainership back in October, but soon after I got
pulled off my Rails project at work. I've been doing a small amount of
Rails work recently, but I don't think I use it enough day-to-day to
really be qualified as a maintainer. The other problem is I strongly
disagree with many conventions in the codebase, so if I took it over I
would waste a lot of time on cleanup without really getting much out
of it other than a more maintainable codebase.
And there's a lot of stuff in the package that I would never use: I'm
not interested in spending any effort to maintain
Windows-compatibility; I never use the menu bar, and I don't care much
for snippets. Plus there is the fact that nxhtml-mode now supports
RHTML, so much of the view-related code in rails.el is pretty
irrelevant.
Anyway, if anyone else wants to step up as maintainer, I think that
would be great. I'm currently busy working on a refactoring of
ruby-mode.el to clean it up and document it so it can be included in
the core Emacs distribution. Since I use Ruby by itself a lot more
than Rails these days, it makes much more sense for me to spend my
time there instead.
So I can pass on maintainership if anyone else is qualified and
willing. On the other hand, with source distributed via github
actually having one person or team designated "maintainer" is a lot
less important than it used to be in the Rubyforge days. As long as
there's communication between the hackers working on it, work can be
pulled across repositories ad-hoc.
If you do prefer a lighter approach than rails.el, I have extracted
and cleaned up rinari as its own project, which is naturally also up
on github: http://github.com/technomancy/rinari. If someone wants to
contribute to that instead let me know; I can give pointers and
advice. I believe it to be a lot more hackable since there's simply
vastly less code, but it still performs nearly all the functions that
I need.
Happy hacking,
Phil
mixandgo
the best of the two ?
On Jun 8, 7:21 pm, "Phil Hagelberg" <technoma...@gmail.com> wrote:
Phil Hagelberg
> how does rails.el and rinari comapre ? how do you use rinari ? whats
> the best of the two ?
rails.el is much more featureful, but in my daily experience most of
its features go unused. Rinari is only the stuff that I use day to
day. Because of this it's much lighter and easier to maintain, but some
people may find that they miss the features that it leaves out.
I won't say which is better overall since they are really targeted at
different audiences.
-Phil
Eric Schulte
>
> On Sat, Jun 7, 2008 at 4:02 AM, Clinton R. Nixon <crn...@gmail.com> wrote:
> > I'm fairly certain the maintainer is Phil Hagelberg
> > (http://technomancy.us/). He's also the author of rinari, another
> > Emacs library for Rails that he's disavowed, but I find way more
> > usable than emacs-on-rails.
>
> I suppose I should step in here.
>
> I was offered the maintainership back in October, but soon after I got
> pulled off my Rails project at work. I've been doing a small amount of
> Rails work recently, but I don't think I use it enough day-to-day to
> really be qualified as a maintainer. The other problem is I strongly
> disagree with many conventions in the codebase, so if I took it over I
> would waste a lot of time on cleanup without really getting much out
> of it other than a more maintainable codebase.
So I take it there is currently no-one maintaining the emacs-rails
mode page on ruby-forge. There doesn't seem to be any development
since May 2007.
> And there's a lot of stuff in the package that I would never use: I'm
> not interested in spending any effort to maintain
> Windows-compatibility; I never use the menu bar, and I don't care much
> for snippets. Plus there is the fact that nxhtml-mode now supports
> RHTML, so much of the view-related code in rails.el is pretty
> irrelevant.
I agree with every part of this paragraph. emacs-rails as it stands
now is about half cruft, and could benefit from some serious cleanup.
> Anyway, if anyone else wants to step up as maintainer, I think that
> would be great. I'm currently busy working on a refactoring of
> ruby-mode.el to clean it up and document it so it can be included in
> the core Emacs distribution. Since I use Ruby by itself a lot more
> than Rails these days, it makes much more sense for me to spend my
> time there instead.
I don't feel qualified to maintain the project, but I would certainly
be happy to help through testing, documentation, and contribution of
my fledgling elisp abilities.
> So I can pass on maintainership if anyone else is qualified and
> willing. On the other hand, with source distributed via github
> actually having one person or team designated "maintainer" is a lot
> less important than it used to be in the Rubyforge days. As long as
> there's communication between the hackers working on it, work can be
> pulled across repositories ad-hoc.
As Peter mentioned earlier it does seem important to have a good
unified public face. As most people who would want to use emacs for
rails development don't want to have to search through github and
cobble together their own custom solution. It seems important to
produce and maintain a useable tool which can easily be downloaded and
installed and most importantly is clearly labeled as the current best
choice for those just wishing to install the mode and get to work.
That said it sounds like emacs-rails has ramified into a number of
working suites with multiple rinari (lighter/cleaner/hackable) and
emacs-rails (heavier/feature-rich) versions. Given this it might not
make sense to try to force development into a single branch.
Does anyone have suggestions for a way forward? Or thoughts on
whether it makes sense to try to focus collectively on a single main
branch?
My own personal feeling would be that a middle road of emacs-rails
less the rhtml code, and maybe plus some simplifications (a single
rake function, and a single function for running tools in the script
directory as opposed to whole .el files of web-server and console
functions.) would begin to become acceptable to rinari users.
Thanks,
Eric
> If you do prefer a lighter approach than rails.el, I have extracted
> and cleaned up rinari as its own project, which is naturally also up
> on github: http://github.com/technomancy/rinari. If someone wants to
> contribute to that instead let me know; I can give pointers and
> advice. I believe it to be a lot more hackable since there's simply
> vastly less code, but it still performs nearly all the functions that
> I need.
thanks, I'm using this now and may start folding in some functions
from emacs-rails
> Happy hacking,
> Phil
--
schulte
Phil Hagelberg
> My own personal feeling would be that a middle road of emacs-rails
> less the rhtml code, and maybe plus some simplifications (a single
> rake function, and a single function for running tools in the script
> directory as opposed to whole .el files of web-server and console
> functions.) would begin to become acceptable to rinari users.
> thanks, I'm using this now and may start folding in some functions
> from emacs-rails
This sounds like it would be a good compromise approach: take the
cleaner base of Rinari, and whenever you find yourself wishing it had
some feature that's only present in rails.el, just port it over and
clean it up in the process. It's certainly a much more manageable task
than performing a monolithic overhaul of rails.el, and it ensures that
only the stuff that's actually useful gets added to Rinari.
If this turns out to be an agreeable approach I don't mind continuing
maintainership of Rinari and simply accepting pull requests from other
people adding features to it. I'll be sure to review incoming code and
make suggestions about how things are implemented so as to try to
maintain a consistent coding style.
-Phil
Eric Schulte
On Tuesday, June 10, at 11:01, Phil Hagelberg wrote:
>
> "Eric Schulte" <schult...@gmail.com> writes:
>
> > My own personal feeling would be that a middle road of emacs-rails
> > less the rhtml code, and maybe plus some simplifications (a single
> > rake function, and a single function for running tools in the script
> > directory as opposed to whole .el files of web-server and console
> > functions.) would begin to become acceptable to rinari users.
>
> > thanks, I'm using this now and may start folding in some functions
> > from emacs-rails
>
> This sounds like it would be a good compromise approach: take the
> cleaner base of Rinari, and whenever you find yourself wishing it had
> some feature that's only present in rails.el, just port it over and
> clean it up in the process. It's certainly a much more manageable task
> than performing a monolithic overhaul of rails.el, and it ensures that
> only the stuff that's actually useful gets added to Rinari.
agreed
> If this turns out to be an agreeable approach I don't mind continuing
> maintainership of Rinari and simply accepting pull requests from other
> people adding features to it. I'll be sure to review incoming code and
> make suggestions about how things are implemented so as to try to
> maintain a consistent coding style.
That works for me. I'll keep working with your pared down rinari,
adding in functions from the old rinari and rails-mode as I need them
and they make sense. I can push these changes back to you from time
to time.
This still leaves unanswered the original question of this thread
regarding a cleaner public face for emacs and rails allowing users to
quickly get a feel for the lay of the land, and apply something to
their own emacs. Maybe that could be accomplished by something as
simple as updating a couple of key pages...
- http://www.emacswiki.org/cgi-bin/wiki/RubyOnRails
- http://wiki.rubyonrails.org/rails/pages/HowtoUseEmacsWithRails
Best, Eric
> -Phil
--
schulte
Phil Hagelberg
>> If this turns out to be an agreeable approach I don't mind continuing
>> maintainership of Rinari and simply accepting pull requests from other
>> people adding features to it. I'll be sure to review incoming code and
>> make suggestions about how things are implemented so as to try to
>> maintain a consistent coding style.
>
> That works for me. I'll keep working with your pared down rinari,
> adding in functions from the old rinari and rails-mode as I need them
> and they make sense. I can push these changes back to you from time
> to time.
Excellent. Github pull requests are probably best unless you feel like
discussing a change, in which case posting here would be better.
> This still leaves unanswered the original question of this thread
> regarding a cleaner public face for emacs and rails allowing users to
> quickly get a feel for the lay of the land, and apply something to
> their own emacs. Maybe that could be accomplished by something as
> simple as updating a couple of key pages...
>
> - http://www.emacswiki.org/cgi-bin/wiki/RubyOnRails
> - http://wiki.rubyonrails.org/rails/pages/HowtoUseEmacsWithRails
Well it sounds like my github should be the canonical source then. I
will try to update these pages once I get a chance. For now git cloning
or tarball downloading should be the preferred distribution method, but
eventually I would love to get it packaged as a gem. I know Jim Weirich
is working on something to this end, though it's for more than just
Rinari. I'll be sure to follow up with him once he's got something
ready.
There's also the question of dependencies. I am not too fond of the idea
of making users have to separately download third-party dependencies, so
I've bundled versions of most things with Rinari. The exception is
nxhtml-mode because it's so huge. Of course the correct approach here is
to use something like ELPA to automatically track dependencies the way
rubygems or apt-get does, but I haven't got a chance to look into this
and see how it works. Is anyone on this list familiar with it?
-Phil
Rob Christie
http://github.com/technomancy/rinari
As of last month tomtt was taking pull requests in his fork
http://github.com/tomtt/emacs-rails/tree/master
and it looks like he is also a developer on the project on ruby forge.
dima/tomtt - what are your plans for the emacs-rails mode?
Rob
ChandleWEi
migration to http://github.com/tomtt/emacs-rails/tree/master
and update use http://github.com/tomtt/emacs-rails/tree/master ？
is svn://rubyforge.com/var/svn/emacs-rails/trunk to discard ?
在 2008-06-10二的 22:27 -0400，Rob Christie写道：
tomtt
be so I gladly go along with his suggestion.
> dima/tomtt - what are your plans for the emacs-rails mode?
concerted effort into creating an authoritative and 'obviously best'
rails mode for emacs. I cloned to github because the project seemed
stale and I was hopeful I would have time to do some work on it while
learning better elisp in the process. Unfortunately I have not gotten
much further than applying some patches that were already on
sourceforge and pushing back bits and pieces that people have sent me
through github. I am willing to keep on pushing patches back into
http://github.com/tomtt/emacs-rails/tree/master until rinari is buff
enough to become the new 'rails for emacs mode'.
One problem I had developing for emacs-rails was a lack of tests.
Given how accustomed we rails people are to tests, should we not set
an example and write specs for our emacs mode as well? I believe that
would be a great boost for people to contribute to the mode without
fear of breaking other things they may not know about. Unfortunately
there is no ultimate testing package for emacs. I had a look at Phil's
elisp_behave code which has things about it that I really like. He has
told me he has gone on to better things since then and I'm not sure
what they are though :).
As for how to streamline the development process, maybe a lighthouse
account? What bug tracker integrates best with git these days?
I'm looking forward to contributing to a better emacs-rails!
Cheers, Tom.
Phil Hagelberg
> One problem I had developing for emacs-rails was a lack of tests.
> Given how accustomed we rails people are to tests, should we not set
> an example and write specs for our emacs mode as well? I believe that
> would be a great boost for people to contribute to the mode without
> fear of breaking other things they may not know about. Unfortunately
> there is no ultimate testing package for emacs. I had a look at Phil's
> elisp_behave code which has things about it that I really like. He has
> told me he has gone on to better things since then and I'm not sure
> what they are though :).
Agreed; testing for Emacs modes needs to be much better than it is now.
I've written two packages to support Elisp tests: the behave.el that you
mention and elunit. I really like both TDD and BDD; the important thing
is that the correctness of the code is easily programmatically
verifiable. But personally I think that focusing on unit tests is more
pragmatic for Elisp since testing is already a pretty hard sell in the
Emacs community (outside ruby), and introducing new terminology makes
things more complicated. It's been my experience that people will be
more accepting of unit tests; whereas with BDD I end up going into this
exposition about the philosophy and differences from TDD and even then
half the time they don't get it. Maybe someone else could explain it
better; I don't know. =)
I think elunit is a pretty simple core to base things off (226 LOC) for
unit tests. But really unit tests are a pretty small part of the picture
for Emacs modes; if you break up your functions correctly they are
almost always pretty easy to test even without a testing framework. I
think there's much more potential to benefit from an integration-level
testing framework. I've felt this need especially acutely while working
on refactoring ruby-mode.el--there's a lot of code in there I don't
fully understand. So I will be building another library on top of elunit
for such a purpose called mode-unit.el.
I'll be sure to check it into my Rinari repository once I've got
something that even approaches remotely usable; I would love to get some
feedback about this.
-Phil
Phil Hagelberg
> As for how to streamline the development process, maybe a lighthouse
> account? What bug tracker integrates best with git these days?
I've heard good thing about ditz[1]--it has the advantage of integrating
with git and tracking bugs correctly across branching and
merging--something a centralized bug tracker can never do. Unfortunately
it has the significant disadvantage of not having a web-based
interface--so bug reports must be checked in to a branch of the source
tree and merged to be tracked. But considering it's a tool that's
targeted towards developers, this may not be such a big deal. Has anyone
here used ditz? I'm also pretty fond of just keeping a TODO or BUGS file
and scattering TODO messages across the codebase; this has many of the
same advantages of ditz just without the slick reporting.
A middle ground may be to use the github wiki as a place to collect
issues before they get entered into the project. Reporting could happen
there for people who don't want to create a fork and get it merged, and
developers could periodically take bug reports and turn them into
failing tests or TODOs to check in.
If there are strong objections to either of these approaches we could
use a lighthouse project, but I would rather only use this if it's
necessary. Rinari used to use a basecamp account, and it felt pretty
cumbersome to keep the future plans in a separate place from the
code. But I do agree that having a prominent place to report issues is
very helpful, so it could be worth it.
> I'm looking forward to contributing to a better emacs-rails!
Thanks!
-Phil
mixandgo
could anyone describe the first steps of setting up rinari and some
erb mode (rhtml or anything else).
Should we have a different topic for this ?
mixandgo
Phil Hagelberg
> I agree to the idea of starting with rinari and building it up. So
> could anyone describe the first steps of setting up rinari and some
> erb mode (rhtml or anything else).
I will work on updating the README included in Rinari once I get a
chance. The gist of it is to use nxhtml-mode, found at
http://ourcomments.org/Emacs/nXhtml/doc/nxhtml.html
(autoload 'nxhtml-mode "nxml/autostart" "" t)
(autoload 'nxml-mode "nxml/autostart" "" t)
(add-to-list 'auto-mode-alist '("\\.html$" . nxhtml-mode))
(add-to-list 'auto-mode-alist '("\\.rhtml$" . nxhtml-mode))
(add-to-list 'auto-mode-alist '("\\.html\\.erb$" . nxhtml-mode))
(add-to-list 'load-path "~/.emacs.d/rinari")
(require 'rinari)
-Phil
Peter Jones
> I will work on updating the README included in Rinari once I get a
> chance. The gist of it is to use nxhtml-mode, found at
> http://ourcomments.org/Emacs/nXhtml/doc/nxhtml.html
Phil, are you really happy with nXhtml? I tried it for about 3
minutes and then erased it from my hard drive with a smile on my face.
Some of my complaints:
1. It's huge
2. It completely whacked up my color scheme
3. It filled my *Messages* buffer faster than an ERC buffer can
4. Did I mention it's huge?
5. Seems to be heavily influenced by MS Windows
Does someone actually like nXhtml, and want to steer me straight?
--
Peter Jones, http://pmade.com
pmade inc. Louisville, CO US
mixandgo
happy with. I wish I could use nxhtml though as it's got some nice
features and makes working with html really easy, but unless it's well
integrated with *a* rails mode, it's of no use. I'd prefer the stable/
working html-mode to a broken nxhtml.
mixandgo
On Jun 11, 11:28 am, Phil Hagelberg <technoma...@gmail.com> wrote:
> > I agree to the idea of starting with rinari and building it up. So
> > could anyone describe the first steps of setting up rinari and some
> > erb mode (rhtml or anything else).
>
> I will work on updating the README included in Rinari once I get a
Phil Hagelberg
> Phil, are you really happy with nXhtml? I tried it for about 3
> minutes and then erased it from my hard drive with a smile on my face.
I'll agree that the first impressions can be a bit weird, but I think
this has more to do with poor default settings than anything intrinsic
wrong with the code. The first thing you want to do is add this:
(setq mumamo-chunk-coloring 'submode-colored
nxhtml-skip-welcome t
rng-nxml-auto-validate-flag nil)
The welcome is annoying and silly, and the auto-validation stuff is only
good when you're working on full XML documents, not for rails views.
> Some of my complaints:
>
> 1. It's huge
It's huge because it's a Real XML Parser. Most Emacs modes are small(ish)
because they use heuristic regular expressions to do font-locking and
indentation, but they are also quite frequently wrong. Writing a real
parser is a lot of work (and a lot of code) but it guarantees correct
results. The kind of things you can do with a full AST of the code you're
editing is amazing; it makes a whole new class of functionality
available. This is the same approach as Steve Yegge's js2-mode, which is
fairly awesome and enables quick feedback in a way that you could never
get with a regular font-locking mode.
There is also an accurate ruby parser written in elisp, but it hasn't
been tied into indentation and font-locking yet. But this is very
definitely the best way to go about it.
> 2. It completely whacked up my color scheme
It uses different colors than the regular xml-mode, but for highlighting
ruby code it is consistent with ruby-mode.el. I believe this is tied
into the fact that since it uses a real parser it can't use regular
font-lock rules, but I'm not sure.
> 3. It filled my *Messages* buffer faster than an ERC buffer can
The only message I see in regular use is a "Switched to major-mode"
line. While I agree this is useless for anything but debugging purposes,
it's hardly a reason to not use the software. If you're seeing other
messages it's probably because you haven't turned off validation.
> 5. Seems to be heavily influenced by MS Windows
What does this mean? I've never seen any evidence of this other than the
fact that the screenshots in the documentation are from Windows.
> Does someone actually like nXhtml, and want to steer me straight?
Well, if you want to try writing a parser for rhtml, you're welcome to
it. I have tried, and it's extremely difficult to do accurately,
especially if you rely on regular expression-based heuristics and Emacs'
built-in font-locking. And if you don't rely on the faulty regex
approach, your mode will end up with tons of code too, which seems to be
your main gripe about nxhtml.
The other huge advantage of nxhtml-mode is that the author is extremely
responsive to help track down bugs and suggest fixes. He helped me find
a bug in ruby-mode.el that only surfaced when it was used with
nxhtml-mode and always responded to bug reports in a handful of
hours. He's also active on emacs-devel and I believe is planning on
contributing his code to Emacs core once nxml has been integrated.
It's certainly possible to go off and write your own mode for something
like this. I've done it. I would emphatically assert that it's not worth
it. Unless you're awesome at writing parsers and want to do a one-off
for this crazy bastard hybrid of HTML and Ruby, you'd end up frustrated.
-Phil
mixandgo
Phil Hagelberg
> Can you please share your setup ? I cannot make mine work !
I'll try to put some more info in the Rinari README, but until then you
can look at my exact setup:
http://github.com/technomancy/dotfiles
-Phil
Phil Hagelberg
> Agreed; testing for Emacs modes needs to be much better than it is now.
I remembered reading about a more comprehensive unit testing framework
from a post on emacs-devel a few months ago. It's called ert.el:
http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg01315.html
Has anyone used this? Thoughts on this vs elunit? It's definitely more
comprehensive, but I'm not sure if the extra complexity is justified.
-Phil
Peter Jones
> I'll agree that the first impressions can be a bit weird, but I think
> this has more to do with poor default settings than anything intrinsic
> wrong with the code.
I would agree with this. It seems as if the author of nXhtml assumes
his users are new with emacs.
> It's huge because it's a Real XML Parser.
nXML is moderately large because it's a real XML parser, which I think
is pretty neat. On the other hand, nXhtml is huge because it includes
several other elisp packages in the distribution.
I understand the reasoning, but it does make the package somewhat
monolithic IMO.
>> 5. Seems to be heavily influenced by MS Windows
>
> What does this mean? I've never seen any evidence of this other than the
> fact that the screenshots in the documentation are from Windows.
I should have said that it's biased towards Windows. I feel that way
because:
1. The package is only available as a zip file
2. The zip package nxhtml-1.32-080612.zip expands to nxml
3. There are readme.txt files all over the place
4. There are no Makefiles to compile the elisp files
Issue 2 is a pet peeve of mine. It's customary to have archives
expand to the same name as the archive file, minus the archive
extension. Not only that, but it expands to the name of a completely
other package.
nXML is a package written by James Clark, which is being used by
nXhtml.
I'm not usually a complainer, so if I end up using nXhtml, I'll
probably submit patches to fix the above issues and then I'll shut my
big pie hole.
I think I'm just a bit unsure about nXhtml because my first experience
with it was so bad. It popped up some window telling me to use
customize, and then after I got that to go away it turned my
background color to blue and started filling my *Messages* buffer with
all kinds of error messages.
It's a completely different experience than when I first used
rhtml-mode, everything just worked (thanks Phil). The only complaint
that I actually have about rhtml-mode is that flyspell doesn't seem to
work with it.
However, if rhtml-mode is in the past, then I guess I'll stop being
nostalgic and spend some time getting nXhtml mode working correctly.