PATCH: added new Test::Unit compiler plugin
djkea2 at mugca.its.monash.edu.au
Wed May 5 23:34:37 EDT 2004
On Wed, May 05, 2004 at 09:43:27AM -0400, Sam Roberts wrote:
> Wrote Doug Kearns <djkea2 at mugca.its.monash.edu.au>, on Wed, May 05, 2004 at 05:02:42PM +1000:
> > Well, why not set it to the genuine article?
> But I had it set to the genuine article, then the ruby support files
> changed it!
The 'support files' change all sorts of options that you might have
previously set - :help after-directory
A compiler plugin sets both 'efm' and 'makeprg' by definition. I don't
think you can make a case for there being a more appropriate default
'makeprg' for running Test::Unit than ruby - the only thing all users
have in common is a file containing tests which must eventually be run
by ruby. ruby will always be able to run the tests; make will not.
> I'm under the impression that these files are going to be part of vim6,
> part of the standard distribution, so should be useable as shipped for a
> wide variety of usage patterns. I don't think that the ruby file that a
> person would be editing will be "runnable" in any case other than very
> small projects, so most people will have to customize it.
That is why both of them require you to specify a target file when
> The only cases this would seem to be useable for is when:
> a - you are editing the tests,
No, you don't need to be editing the tests in order to run :make on them.
> and the tested code won't throw any
> exceptions, its just test that will fail
You seem to be missing my multiple previous statements that I agree that
the 'efm' needs to be fixed so that it supports errors as well as
failures, and it will be when I get to it, or sooner if someone else
> b - the file you are editing has the tests at the end using the if
> $0==__FILE__ trick
No, because _both_ compiler plugins are designed to be run with a target
file. For example, the current rubyunit compiler plugin should be run
where tests.rb is any file you like. You don't need to be editing it,
nor does it need to be loaded in a vim buffer.
> c - you're editing the "main" file of a ruby script, and the script
> is runnable with no arguments
No, see above. Why does it have to be runnable with no arguments?
-- foo.rb --
raise "Test compiler plugin"
% vim blah.txt
:make foo.rb Hello World
> In any other case (you're editing the file with the code that's causing
> the tests to fail, for example), makeprg=ruby won't work.
No, see above.
> So, I think setting makeprg to ruby only works for specific cases, it
> shouldn't be the default.
> My two bits, I'll stop bugging you guys (after this email).
That'll be boring. ;-)
> > :compiler rubyunit
> > :setlocal makeprg=make
> And I will do something like this, but I'll have to write my own
> compiler file, and figure out enough about error formats to merge
> the error formats in ruby.vim and rubyunit.vim.
Well, I'm going to have to do that if you don't! :-)
> > I only suggested it since you asked how to "modify the test/unit" which
> > I didn't quite understand but read to mean that you wanted to modify the
> > Test::Unit library. I assume this would probably be easier from Rake.
> Did I say this? Sorry, I don't want to do that! Though I confess that
> I've thought about it... if I could modify the console test runner to
> spit out errors in "<file>:<line>:<msg>" format, I wouldn't need
> to customize vim's error formats!
True, and it may well be worth your trouble. HTML Tidy actually has an
option, --gnu-emacs, to output an easy to parse error string.
> Again, I'm trying (unsuccesfully, apparently :-), to make the case that
> what ruby users have in common is that when they run ruby code, unit
> tests or some other code, that when ruby dies with an error or test/unit
> dies with an error, we would like vim to go to the error line, without
> needing any customization
Well you have to run :make and, therefore, 'makeprg' will _always_ need
to be customised. It's always going to have to set it to something
which will actually run the code or tests, to 'ruby tests.rb', 'make
test', 'rake test', 'aap test', 'cook test' or 'mybodgyshellscript'.
> other than "set filetype on".
OK, this one's for Gavin to comment on since he maintains the ftplugin
and currently it does not set the compiler.
> How we run our code is a local decision, there isn't a
> "one-solution-fits-many", so until the ruby world all starts using rake,
> or something, then makeprg should remain unset.
No but "default-solution-fits-some" is better than no solution at all.
The compiler plugin won't work for _anyone_, by default, if 'makeprg' is
left unset. Except those who have explicitly set it, or those who are
using make by default since 'makeprg' defaults to make. Surely selecting
a sensible (for some arbitrary value of sensible) default makes more
sense than leaving it unset. Even if you are using a makefile the
default 'makeprg' still allows you to run the tests by running :make
tests.rb - it _always_ works.
> > Compiler plugins are generally defined as a combination of 'efm' and
> > 'makeprg' settings. However these options _can_ be changed after setting
> > them with :compiler
> I grepped my /usr/share/vim... plugins, its not that general, some do,
> some don't, and tex.vim does it conditionally.
Sure, but to use this one you have to configure it with variables which
doesn't really seem much simpler...
> For a bunch it would seem like changing makeprg would be a good thing
> (if you're using bcc, msvc, or some fortran tool-chain, you likely do
> want to use the vendor-supplied make utility, though I'm sure there are
> folks who'd rather use GNU make). I don't think ruby falls into these
> case, I'm starting to repeat myself here...
> > > - by changing makepgr to ruby, it causes the appearance of a "hang"
> > > when
> > > one does ":make" (ruby, without arguments, tries to read stdin, so
> > > it
> > > just sits there).
Is this 'hang' really such a problem anyway. I would've thought it was
obvious what was happening given that the command line is displayed by
vim. For example:
:!/home/doug/opt/bin/ruby -w 2>&1| tee /tmp/v821542/1
> > Yes. I generally don't like setting the makeprg to something like
> > makeprg=command\ % because it lacks flexibility. I'm not sure what else
> > to do here. Any ideas?
> 1 - don't set makeprg
This will only work for people who are using makefiles or who have
explicitly set it to something else. I don't see why presetting
'makeprg' is any easier than overriding it. They both simply require one
line in one file.
> 2 - only set makeprg if there is no makefile
> (which is dicy, still, what if I have makeprg is set to "cook", and I
Ah, a fellow aegis user perhaps?
> have a cookfile? should the plugin have knowledge of all the worlds
> make programs built into it?)
No, that's why it just has a default which can be _easily_ overridden.
> 3 - if its possible in vim's script language, have the current file be
> the default argument to "ruby",
This might be worth adding and what I had in mind. I think it is
probably generally applicable too, so I'll take it up on vim-dev.
> but if somebody called ":make
> some_file", have some_file be the argument
This is how it currently works. See above.
> Ok, so in the time I've written this, maybe it would have been more
> productive for me to learn how to write my own errorformat commands, so
> that I can figure out how to merge the two error formats.
Quite probably. ;-)
PS. Don't worry about 'bugging' anyone. That's what the list is for!
More information about the vim-ruby-devel