Skip to content

Latest commit

 

History

History
357 lines (263 loc) · 11.6 KB

TODO

File metadata and controls

357 lines (263 loc) · 11.6 KB

TODO

List of pending/completed tasks for rinari

for background see http://groups.google.com/group/emacs-on-rails

bundles

rhtml (from original rinari)

see

rdebug

snippets

see http://github.com/eschulte/yasnippets-rails/tree/master

full test coverage [1/2]

  • [X] movement tests
  • [-] compilation tests
    • [X] console
    • [X] web-server
    • [X] test
    • [ ] sql
    • [ ] script

rinari movement [0/1]

From anywhere, get to the related model/controller/test/view

where can you be?

  • view
  • controller
  • model
  • unit-test
  • functional-test
  • other

pending…

  • [X] still need to work on movement from OTHER places
  • [X] look at a better keybinding setup
  • [X] rails2 style view names
  • [ ] code refactor:

code refactor

actually I’m thinking that when I have time it would be worthwhile to remove toggle, and handle all of the movement through a new independent toggle-like tool say “toggle-hassle” which uses an alist like toggle, but instead of elements like

(“app/controllers/\1.rb#\2” . “test/functional/\1_test.rb#test_\2”)

it has elements like

(“app/controllers/\1_controller.rb#\2” ( (:model . “app/models/\1.rb#\2”) (:test . “app/test/functional/\1_controller_test.rb#\2”) (:view . “app/views/\1/\2.rhtml”) ) )

basically like toggle but more of a hassle to set up, and with enough functionality to subsume rinari-movement.el

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

SyntaxError: /home/eschulte/united/org/work/arf/arf/lib/cluster.rb:35: syntax error, unexpec

ruby-compilation enhancement

found a line which didn’t match the error-regexp-alist

test_create(QueriesControllerTest) [/home/eschulte/work/arf/arf/test/functional/queries_controller_test.rb:60]:

and another

/var/lib/gems/1.8/gems/mongrel-1.1.3/bin/mongrel_rails:281

windows support

ugh

add yaml,css,javascript,ruby pointers to the documentation

adjust eshell/shell environment to highlight ruby errors

not sure this is possible, at least not easily

write up some info documentation for Rinari

  • [X] making progress in doc/rinari.texi
  • [X] might want to add information for installing the documentation
  • [X] also post it up to rinari.ruby-forge.org

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…

Make rinari a minor mode that doesn’t activate for regular ruby-mode.

look at info:elisp:Minor Mode Conventions

define as a minor mode

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

add key-bindings for rinari minor mode

should follow emacs key bindings

see info:elisp:Key Binding Conventions

  • 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.

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

change toggle for incremental search

so something like search_incrementally will match search if incrementally isn’t available

also, push the “def “s into the variable in toggle.el to try to keep it language-agnostic

project-wide search and search/replace

I know you can do this with rgrep, but It would be nice to easily call it on the whole project (yml/rhtml/rb files), and it would help guide emacs noobs to the powers of rgrep

Danger here is cluttering up Rinari with thin wrappers around existing emacs tools…

rinari-rgrep

errors / tests

something to speed up the cycle of

  • code
  • test
  • review errors

this should probably cash out into two different functions…

rails-test-method

enhance toggle so that it can match up function names as well

see methods in toggle-buffer

rinari-test-function will now try to toggle if needed

see rinari-test-function

use the same mechanism as find view

maybe instead of using the current buffer-file change 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.

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

make rails-find-action follow forms and link_to[_remote]

see rinari-alist-from-view

rinari-rake uses ruby-compilation

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 rinari-console and rinari-server), also ruby-compilation has been added.

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

  1. 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:

> - 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.

launch web-browser to current view

add a quick command to view the current page in a web-browser

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

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)

revert and wrap find-file-in-project

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.

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

LocalWords: elsif elseif keybinding