[Feature request?] Using wildcard patterns in :root-dir?

[rodw]

(Awesome library, by the way. Much simpler than fighting with fof and its variants.)

Suppose I have several projects with a similar structure:

~/Projects/
~/Projects/foo/
~/Projects/foo/src/
~/Projects/foo/test/
~/Projects/bar/
~/Projects/bar/src/
~/Projects/bar/test/

Is there, or could there be, a way to use a wildcard within the :root-dir value of elements in the the tgt-projects list to add mutliple projects all at once?

In other words, something like:

(add-to-list 'tgt-projects '((:root-dir "~/Projects/*")
                             (:src-dirs "src")
                             (:test-dirs "test")))

that would be equivalent to:

(add-to-list 'tgt-projects '((:root-dir "~/Projects/foo")
                             (:src-dirs "src")
                             (:test-dirs "test")))
(add-to-list 'tgt-projects '((:root-dir "~/Projects/bar")
                             (:src-dirs "src")
                             (:test-dirs "test")))

[rags]

Hi Rod,
That is indeed a nice feature to have feature. I will see if this can be
easily incorporated.
Meanwhile an alternate way of doing this is:

(add-to-list 'tgt-projects '((:root-dir "~/Projects/")
                         (:src-dirs "foo/src" "bar/src")
                         (:test-dirs "foo/test" "bar/test")))

Maybe this is what you really need. No?

On Thu, Aug 15, 2013 at 2:02 AM, Rod Waldhoff notifications@github.comwrote:

(Awesome library, by the way. Much simpler than fighting with fof and its
variants.)

Suppose I have several projects with a similar structure:

~/Projects/
~/Projects/foo/
~/Projects/foo/src/
~/Projects/foo/test/
~/Projects/bar/
~/Projects/bar/src/
~/Projects/bar/test/

Is there, or could there be, a way to use a wildcard within the :root-dirvalue of elements in the the
tgt-projects list to add mutliple projects all at once?

In other words, something like:

(add-to-list 'tgt-projects '((:root-dir "~/Projects/*")
(:src-dirs "src")
(:test-dirs "test")))

that would be equivalent to:

(add-to-list 'tgt-projects '((:root-dir "/Projects/foo")
(:src-dirs "src")
(:test-dirs "test")))
(add-to-list 'tgt-projects '((:root-dir "/Projects/bar")
(:src-dirs "src")
(:test-dirs "test")))

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1
.

Rags

[rodw]

Thanks Rags. That's cleaner than declaring two projects.

But wouldn't that mean that tgt would match the test:

~/Projects/foo/test/test-util.rb

with the base class:

~/Projects/bar/src/util.rb

because they happen to have the same name? I woudn't want that: foo and bar really are separate projects.

Maybe this is what you really need. No?

In the most general sense, my wish is for tgt to "just work" in the sense that I don't need to explicitly declare each project. The wildcard approach seemed like the easiest way to approximate that.

My elisp skill are far too weak to do something like this quickly or easily, and I'm not nearly demanding enough to expect you to actually do this on my account, but since you asked, I imagine one way this could work is that one could somehow describe "patterns" or "templates" that tell tgt how to match source and test files (in a context in which the pattern is matched).

For example, I commonly work in a few different languages, each with slightly different idioms for identifying test cases. E.g., maybe I have a Ruby project like this:

~/Projects/ruby-eg/src/models/model.rb
~/Projects/ruby-eg/spec/models/model_rspec.rb

and a CoffeeScript project like this:

~/Projects/coffee-eg/lib/models/model.coffee
~/Projects/coffee-eg/test/models/test-model.coffee

Then maybe I could use something like this:

 (add-to-list 'tgt-templates '((:src-patterns '("src", "\.rb$"))       ;; a list of src-dir,  src-filename-pattern pairs
                               (:test-patterns '("spec", "\.rb$"))     ;; a list of test-dir, test-filename-pattern pairs
                               (:test-suffixes "_spec")))              ;; test-suffixes, just like today

 (add-to-list 'tgt-templates '((:src-patterns '("lib", "\.coffee$"))   ;; a list of src-dir,  src-filename-pattern pairs
                               (:test-patterns '("test", "\.coffee$")) ;; a list of test-dir,  test-filename-pattern pairs
                               (:test-prefixes "test-")))              ;; test-prefixes, just like today

to indicate something like:

• if the current file ends in .rb and is found under a directory named src then it is a Ruby source file (and the corresponding test file lives under the directory spec that is a sibling of src, and has the suffix _spec added, just like tgt works today).
• if the current file ends in .rb and is found under a directory named spec then it is a Ruby test file (and the corresponding source file lives under the directory src that is a sibling of spec, and has the suffix _spec removed, just like tgt works today).
• if the current file ends in .coffee and is found under a directory named lib then it is a CoffeeScript source file (and the corresponding test file lives under the directory test that is a sibling of lib and has the prefix test- added just like tgt works today).
• if the current file ends in .coffee and is found under a directory named test then it is a CoffeeScript test file (and the corresponding source file lives under the directory lib that is a sibling of test and has the prefix test- removed, just like tgt works today).

In that way, I only have to define the naming idiom once and tgt "magically" recognizes the appropriate idiom for the current context.

I guess that's a bit similar to the way find-other-file works, save that I seem to have a lot more trouble getting find-other-file to manage file prefixes as well as suffixes, and getting it to transverse directories appropriately. toggle-test seems to that part exactly right.

Just a thought.

[rags]

respone inline....

On Fri, Aug 16, 2013 at 12:13 AM, Rod Waldhoff notifications@github.comwrote:

Thanks Rags. That's cleaner than declaring two projects.

But wouldn't that mean that tgt would match the test:

~/Projects/foo/test/test-util.rb

with the base class:

~/Projects/bar/src/util.rb

raghu>> Yes this will match. But there is no way to avoid this unless
you declare "foo" and "bar" as separate project. Once you have test-util
for both "foo" and "bar" modules you will be shown a list to pick from
(This is very similar to what Jetbrains IDE would do).

because they happen to have the same name? I woudn't want that: foo and
bar really are separate projects.

Maybe this is what you really need. No?

In the most general sense, my wish is for tgt to "just work" in the sense
that I don't need to explicitly declare each project. The wildcard approach
seemed like the easiest way to approximate that.

My elisp skill are far too weak to do something like this quickly or
easily, and I'm not nearly demanding enough to expect you to actually do
this on my account, but since you asked, I imagine one way this could work
is that one could somehow describe "patterns" or "templates" that tell tgt
how to match source and test files (in a context in which the pattern is
matched).

For example, I commonly work in a few different languages, each with
slightly different idioms for identifying test cases. E.g., maybe I have a
Ruby project like this:

~/Projects/ruby-eg/src/models/model.rb
~/Projects/ruby-eg/spec/models/model_rspec.rb

and a CoffeeScript project like this:

~/Projects/coffee-eg/lib/models/model.coffee
~/Projects/coffee-eg/test/models/test-model.coffee

raghu>> Look at the advanced example in the docs, which sets up a
projecs with java, scala modules. Your ruby/coffeescript example is very
similar to that

Then maybe I could use something like this:

(add-to-list 'tgt-templates '((:src-patterns '("src", ".rb$")) ;; a list of src-dir, src-filename-pattern pairs
(:test-patterns '("spec", ".rb$")) ;; a list of test-dir, test-filename-pattern pairs
(:test-suffixes "_spec"))) ;; test-suffixes, just like today

(add-to-list 'tgt-templates '((:src-patterns '("lib", ".coffee$")) ;; a list of src-dir, src-filename-pattern pairs
(:test-patterns '("test", ".coffee$")) ;; a list of test-dir, test-filename-pattern pairs
(:test-prefixes "test-"))) ;; test-prefixes, just like today

to indicate something like:

if the current file ends in .rb and is found under a directory named
src then it is a Ruby source file (and the corresponding test file
lives under the directory spec that is a sibling of src, and has the
suffix _spec added, just like tgt works today).
-

if the current file ends in .rb and is found under a directory named
spec then it is a Ruby test file (and the corresponding source file
lives under the directory src that is a sibling of spec, and has the
suffix _spec removed, just like tgt works today).
-

if the current file ends in .coffee and is found under a directory
named lib then it is a CoffeeScript source file (and the
corresponding test file lives under the directory test that is a
sibling of lib and has the prefix test- added just like tgt works
today).
-

if the current file ends in .coffee and is found under a directory
named test then it is a CoffeeScript test file (and the corresponding
source file lives under the directory lib that is a sibling of testand has the prefix
test- removed, just like tgt works today).

In that way, I only have to define the naming idiom once and tgt
"magically" recognizes the appropriate idiom for the current context.

I guess that's a bit similar to the way find-other-file works, save that I
seem to have a lot more trouble getting find-other-file to manage file *
prefixes* as well as suffixes, and getting it to transverse directories
appropriately. toggle-test seems to that part exactly right.

Just a thought.

raghu>> What you are talking about is being able to specify coding
conventions independent if project (And not specify a project at all?). The
main reason tgt took the project approach is:

1. You want to limit the number of directories you look into to find a match
2. I did not want to make the assumption that will always be a
   sibling of (look at he advanced example where integration-specs
   are outside the "play" module)
3. The assumption I made when I coded 'tgt' was that you add projects and
   modules less often than files itself. Its a one time effort to add a
   tgt-project or add a module to existing tgt-project. This assumption makes
   the code simple and small. I would like to keep it that way unless there is
   a compelling use-case that breaks this assumption

Having said that being able to specify coding convention at a "global"
level and having project level config override is a good idea, that can
save some typing. I will look into this sometime (I wont promise you this
anytime soon).

Finally about globing:
I have been thinking about the wildcard match idea. Here's is my take on
it. It is not enough to just provide globing for root-dir, to make it
consistent I will have to add it to "src-dirs" and "test-dirs" also. There
is also the question of supporting '**' pattern. This just adds to the
complexity. I will put this on the back burner for now.

I really appreciate all your ideas(I will continue toying with them). Hope
my responses made sense.

—

Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-22720727
.

Rags