# -*- mode: org -*-
# 
#+TITLE:     TODO
#+SEQ_TODO:  TODO PARTIAL MAYBE WAITING | DONE CANCELLED
#+DRAWERS:   SNIP
 
List of pending/completed tasks for rinari
 
for background see http://groups.google.com/group/emacs-on-rails
 
* TODO inf-ruby enhancement
 
found an example of an error that the
`inferior-ruby-error-regexp-alist' in inf-ruby.el doesn't match
 
this was the error line
 
:SNIP:
SyntaxError: /home/eschulte/united/org/work/arf/arf/lib/cluster.rb:35: syntax error, unexpec
:END:
 
* TODO make `rinari-find-view' which will follow forms (maybe w/prefix?)
 
works for the following cases
- default (goes to the view with the name of the action)
- follows redirect_to another controller and action
- follows renders
- follows redirects to partials
- render_partial
- multiple renders (for example from separate clauses in an if
  statement)
 
can follow multiple redirects
 
** DONE enhancement
sometimes an action will have multiple redirect statements, in which
case this function should ask the user (with completion) which one to
follow
 
 
** DONE better error if run outside of function
 
 
 
** TODO work with rails2-style view filenames
 
 
** MAYBE cleanup
 
this is current the largest set of functions in rinari.el
 
(hopefully it can be cleaner / less code)
 
* MAYBE define macro for ido completion
since we often want to check the availability of ido for completing
reads it would probably be worth writing a macro to do this.
 
also, it may be worthwhile breaking utility functions out into a
separate file...
 
* MAYBE Make rinari a minor mode that doesn't activate for regular ruby-mode.
  :PROPERTIES:
  :assignee: eschulte
  :END:
 
look at [[info:elisp:Minor%20Mode%20Conventions][info:elisp:Minor Mode Conventions]]
 
** DONE define as a minor mode
** DONE when to enter rinari-minor-mode
this could be done through a hook that runs every time a .rb or .rhtml
file is loaded to check if it is inside of a rails project (using the
`rails-root' function or a .emacs-project file) and then to load
rinari-minor-mode appropriately
 
done with hooks on find-file and dired-mode
 
** DONE add key-bindings for rinari minor mode
should follow emacs key bindings
 
see [[info:elisp:Key%20Binding%20Conventions][info:elisp:Key Binding Conventions]]
 
:SNIP:
   * 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.
:END:
 
given the above, it seems like an ergonomic option would be to start
all our rinari key-bindings with \C-c-' with \C-c-'-' running
something similar to \C-c\C-c in org-mode
 
** MAYBE key-bindings could probably use improvement
** MAYBE good minor mode documentation
something to indicate functions and keybindings, like \C-hm for major
modes
 
* MAYBE Make rinari-browse-view smarter
 
So it
1) goes to the right place when called from a partial
2) and brings up a url in minibuffer if an id is needed
 
* DONE errors / tests
something to speed up the cycle of
 
- code
- test
- review errors
 
this should probably cash out into two different functions...
 
** DONE rails-test-method
 
*** DONE enhance toggle so that it can match up function names as well
see [[file:toggle.el::if%20string%20match%20new%20name][methods in toggle-buffer]]
 
*** DONE rinari-test-function will now try to toggle if needed
 
see [[file:rinari.el::defun%20rinari%20test%20function][rinari-test-function]]
 
*** CANCELLED use the same mechanism as find view
maybe instead of using the current buffer-file change
[[file:rinari.el::defun%20rails%20name%20components%20name][rails-name-components-name]] so it returns the last component as well,
then change the controller usage of this function to drop the last
list element.  That way this can be used to get model names when
calling which-function from models/model.rb files.
 
Also, if you don't have a test written for this particular method this
could insert the def...end for the test into the appropriate file, and
drop the point there.  Nothing wrong with a little bit of soft
paternalism.
* DONE add a function for running mysql
this would use the information in /conf/databases.yaml to log into the
application's database using sql-* functions from sql.el as
appropriate
 
* DONE make rails-find-action follow forms and link_to[_remote]
 
see [[file:rinari.el::defun%20rinari%20alist%20from%20view][rinari-alist-from-view]]
 
* DONE ruby-compilation enhancement
  
found a line which didn't match the error-regexp-alist
 
:SNIP:
test_create(QueriesControllerTest) [/home/eschulte/work/arf/arf/test/functional/queries_controller_test.rb:60]:
:END:
* DONE rinari-rake uses ruby-compilation
* DONE remove rails-script add ruby-compilation
 
it turns out most of the bulk of rails-script.el was supporting
running ruby processes with output going to compilation buffers.  So
rails-script.el is now removed (with two short functions in rinari.el
[[file:rinari.el::defun%20rinari%20console%20optional%20arg][rinari-console]] and [[file:rinari.el::defun%20rinari%20server][rinari-server]]), also ruby-compilation has been
added.
 
** DONE move through compilation buffers
 
redefine some keys buffers to make it easier to navigate.
 
n will go to the next line
p will go to the previous line
 
C-n next error line
C-p previous error line
 
M-n top of the next group of errors
M-p top of the previous group of errors [[file:rails-script.el::defun%20rails%20compilation%20previous%20error%20group][previous-group]]
 
so if you just saw an error on a web page, you can see that error in
three key commands
 
1) X-b *server*
p2) M-p
3) enter
 
*** old
a function which either...
1) goes to the error closest to point in the current compilation mode
   buffer
2) goes to the most recent error in the *server*, *console*, or *test*
   buffer
 
See this discussion below from the emacs-on-rails list...
 
email discussion:
:SNIP:
> - maybe add a command which can jump to the most recent error (either
>   in the server logs, or in the console)
 
>  > That's a great idea. find-file-at-point is pretty good at doing this
>  > from test failures in eshell, but you have to move your point up to the
>  > line containing the error message. Leveraging logs and console output
>  > would be a great addition as would looking for lines somewhere other
>  > than just under the point.
>
> So there are two different possible ways to approach this...
>
> 1) through a function which searches in known places (eshell, logs,
>    consoles, server buffers, in current buffer) and makes an educated
>    guess about what to present to the user, possibly allowing quick
>    switching to the other errors.
 
Hmm... now that I think about it more, I'm not sure it's a good idea to
make it really convenient to go around digging through server logs to
find errors. The right way to go about solving that kind of problem is
to write a test for it. If you make it easier to fix the problem without
writing a test, really what that amounts to is short-term benefit but
long-term problems since your fix isn't guaranteed to be caught by the
test suite.
 
So I would discourage integration with the dev mongrel logs. The bonus
side of that is if we only have to help jump to errors/failures in test
output it becomes a lot easier. There are in my mind three common ways
of running tests:
 
- In an emacs shell, whether that's eshell, M-x shell, or ansi-term
- With compile-mode, as per the ruby-test-file function in rinari
- In a shell outside Emacs
 
So if we check console output it will work in the first two cases but
not in the last. I think it's best to always check the test logs, since
problems are pretty much guaranteed to be found in there. This also
solves the integration test problem; when you're running those and you
get an exception, the only console output you see is that you expected a
200 response but you got a 500, which is totally useless. In those cases
you have to check the logs anyway.
 
We could probably base this functionality on compilation mode. It's
already built to go over output looking for something that looks like a
stack trace and provide jumping to the source of the error:
 
http://www.emacswiki.org/cgi-bin/wiki/CompilationMode
 
> 2) wrap console, and server processes in insertion-filters which could
>    notice whenever an error passes through them, and save a pointer to
>    the error in some global rails-errors variable which could be
>    queried by jump-to-my-last-error type function
>
> I was originally leaning towards the latter, but now that you mention
> it the former might be easier... not sure
 
Yeah, the second one sounds a lot harder.
:END:
 
* DONE launch web-browser to current view
  add a quick command to view the current page in a web-browser
 
* DONE unified runner for rails scripts
 
This is less a single runner, and more a single function from which
any rails/script can be executed associating the scripts with
appropriate buffers and modes.
 
Currently this
- runs console from a buffer in comint-mode
- runs server dumping output to a compilation-minor-mode buffer
- provides completion for generate/destroy
- runs all other scripts using shell-command-to-string dumping the
  output to a message
 
** DONE if web-server doesn't start change status message
currently there is no indication that the attempt to start the server
has failed
 
now has a sentinel, see [[elisp:(describe-function 'set-process-sentinel)]]
* DONE revert and wrap find-file-in-project
  :PROPERTIES:
  :assignee: eschulte
  :END:
 
revert to the .emacs-project version of find-file-in-project so that
the actual find-file-in-project.el file remains unchanged.  Then using
defadvice wrap the ffip function to find the project base using
(rails-root) as well as the .emacs-project file.
 
* DONE Name functions consistently
some global prefix for all of the function names, probably either
"rails" or "rinari"
 
going for rails for now
- easier to remember
- easy enough to change later
 
switching to rinari
 
while I'm doing this I'm going to rename rails-scripts.rl to
rails-script.el (minor)
 
easy enough