new rinari release (big changes)
Eric Schulte
I'm recently back from vacationing and I've made some changes to
rinari, which I hope you can test out. The movement functions in
rinari have been bothering me for a while, as they are large, messy
and generally unreliable and un-extensible. To (hopefully) fix this I
wrote jump.el
http://github.com/eschulte/jump.el/tree/master
which provides tools for defining movement functions using a simple
template. Having just ported rinari's movement functions to use
jump.el I believe they are now more stable, more easily customizable
and certainly more numerous.
jump.el should also allow for the easy creation of movement functions
for any projects with structured directories similar to Rails (Merb,
Ramaze, maybe java frameworks), possibly making rinari applicable to
these other frameworks as well (at least the ruby ones).
Finally, as jump.el uses findr.el (no dependency on the unix `find'
command) for it's file searching, it should bring rinari closer to
working on windows (I still don't have access to a windows machine, so
If anyone really wants to use rinari on windows I'll need some help
testing)
So anyways, please try out the new version
http://github.com/eschulte/rinari/tree/master
and let me know what you think. If you all like it, I will push it
out to rinari.rubyforge.org
Thanks -- Eric
--
schulte
Steve Purcell
I experienced an error trying to check out jump.el:
.emacs.d/site-lisp/rinari% git-submodule update --init util/jump
Initialized empty Git repository in /Users/steve/.emacs.d/site-lisp/
rinari/util/jump/.git/
ERROR: Permission to eschulte/jump.el denied to purcell.
fatal: The remote end hung up unexpectedly
Clone of 'g...@github.com:eschulte/jump.el.git' into submodule path
'util/jump' failed
Not sure if that's a problem with the contents of the .gitmodules
file. I worked around it by cloning jump.el directly, and copying it
to util/jump.
Will your changes make it more feasible to support other view types,
such as HAML? The old code had a bunch of ".rhtml" strings hard-coded
in a number of places, which put me off the task of working up a
patch...
Thanks for all this great work!
-Steve
Eric Schulte
>
> Seems to basically work for me, after a cursory check.
>
> I experienced an error trying to check out jump.el:
Ah, thanks for catching that, I had used a private git url for
util/jump, I just switched it to public, so that problem should be
fixed.
>
> Will your changes make it more feasible to support other view types,
> such as HAML? The old code had a bunch of ".rhtml" strings hard-coded
> in a number of places, which put me off the task of working up a
> patch...
yes, it is now possible to use regexps for specifying paths.
Currently any file located in the views directory regardless of ending
should count as a view file, so no patch should be required.
Steve Purcell
That does indeed work beautifully for me now with my HAML templates,
and 'ido' makes it super-fast to select between completion targets
when the jump target is ambiguous.
Only rinari-rgrep is still hard-coded to scan for .rhtml and other
specific file types. I wonder if it would be possible to instead use
a list of files/paths to exclude, e.g. RAILS_ROOT/tmp etc. The
current default search is so narrow that I always just use "M-x rgrep"
instead.
-Steve
Eric Schulte
> That does indeed work beautifully for me now with my HAML templates,
> and 'ido' makes it super-fast to select between completion targets
> when the jump target is ambiguous.
great
> Only rinari-rgrep is still hard-coded to scan for .rhtml and other
> specific file types. I wonder if it would be possible to instead use
> a list of files/paths to exclude, e.g. RAILS_ROOT/tmp etc. The
> current default search is so narrow that I always just use "M-x rgrep"
> instead.
>
My main purpose when initially including rinari-rgrep was
proselytizing rgrep :) I've now changed it so that you can select
which file endings to include in searches by setting
rinari-rgrep-file-endings, which defaults to all files. As for
excluding directories, I can't think of a way to implement that which
would be much of an improvement over simply calling rgrep directly.
--
schulte