Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatically created test namespace is wrong when nested source dir #311

Closed
yatesco opened this issue Jul 29, 2015 · 4 comments
Closed

Comments

@yatesco
Copy link

yatesco commented Jul 29, 2015

Assume I have src/cljc/a/b/c.cljc. If I navigate in dired to test/cljc/a/b and then C-x C-f new_test.cljc then a new buffer is helpfully created (ns cljc.a.b.new_test) (filed in #310). However, it also requires:

(:require [cljc.a.b.new :refer :all]
            [clojure.test :refer :all])

(In terms of style I would suggest it is actually [a.b.new :as sut] for consistency, but that is a personal style issue).

Namespaces are setup correctly so src/cljc is a source path and test/cljc is a test path according to project.clj.

Libraries are Clojure 1.7.0 and snapshot cider.

@bbatsov
Copy link
Member

bbatsov commented Jul 29, 2015

Hmm, this definitely not in clojure-mode. @expez I'm assuming this is coming from clj-refactor, right?

P.S. I also dislike the usage of :refer :all.

@expez
Copy link
Member

expez commented Jul 29, 2015

The broken function is clojure-expected-ns which is the cause of this: #310

clj-refactor uses that same function to create the test namespace which prompted this issue to be created

expez added a commit to expez/clojure-mode that referenced this issue Jul 29, 2015
…c/cljc

When the source path is src/{clj,cljc,cljs} instead of just src/
clojure-expected ns would create namespaces like clj.my-project.my-ns
whereas what's wanted is my-project.my-ns.

Reading boot.clj or project.clj to find out the user's src dirs is out
of scope for clojure-mode, so we use the simply heuristic that no
namespace should start with clj, cljc or cljs because these are the
idiomatic source directories in multi-source projects.

When improving clojure-expected-ns I extracted out two utilities,
clojure-project-dir and clojure-project-relative-path.  These
utilities already exist in clj-refactor so I opted to make them public
rather than private, as they are generally useful.
expez added a commit to expez/clojure-mode that referenced this issue Jul 29, 2015
…c/cljc

When the source path is src/{clj,cljc,cljs} instead of just src/
clojure-expected ns would create namespaces like clj.my-project.my-ns
whereas what's wanted is my-project.my-ns.

Reading boot.clj or project.clj to find out the user's src dirs is out
of scope for clojure-mode, so we use the simply heuristic that no
namespace should start with clj, cljc or cljs because these are the
idiomatic source directories in multi-source projects.

When improving clojure-expected-ns I extracted out two utilities,
clojure-project-dir and clojure-project-relative-path.  These
utilities already exist in clj-refactor so I opted to make them public
rather than private, as they are generally useful.
expez added a commit to expez/clojure-mode that referenced this issue Jul 29, 2015
…c/cljc

When the source path is src/{clj,cljc,cljs} instead of just src/
clojure-expected ns would create namespaces like clj.my-project.my-ns
whereas what's wanted is my-project.my-ns.

Reading boot.clj or project.clj to find out the user's src dirs is out
of scope for clojure-mode, so we use the simply heuristic that no
namespace should start with clj, cljc or cljs because these are the
idiomatic source directories in multi-source projects.

When improving clojure-expected-ns I extracted out two utilities,
clojure-project-dir and clojure-project-relative-path.  These
utilities already exist in clj-refactor so I opted to make them public
rather than private, as they are generally useful.
expez added a commit to expez/clojure-mode that referenced this issue Jul 29, 2015
…c/cljc

When the source path is src/clj{,c,s,x} instead of just src/
clojure-expected ns would create namespaces like clj.my-project.my-ns
whereas what's wanted is my-project.my-ns.

Reading boot.clj or project.clj to find out the user's src dirs is out
of scope for clojure-mode, so we use the simply heuristic that no
namespace should start with clj, cljc or cljs because these are the
idiomatic source directories in multi-source projects.

When improving clojure-expected-ns I extracted out two utilities,
clojure-project-dir and clojure-project-relative-path.  These
utilities already exist in clj-refactor so I opted to make them public
rather than private, as they are generally useful.
expez added a commit to expez/clojure-mode that referenced this issue Jul 29, 2015
…c/cljc

When the source path is src/clj{,c,s,x} instead of just src/
clojure-expected ns would create namespaces like clj.my-project.my-ns
whereas what's wanted is my-project.my-ns.

Reading boot.clj or project.clj to find out the user's src dirs is out
of scope for clojure-mode, so we use the simply heuristic that no
namespace should start with clj, cljc or cljs because these are the
idiomatic source directories in multi-source projects.

When improving clojure-expected-ns I extracted out two utilities,
clojure-project-dir and clojure-project-relative-path.  These
utilities already exist in clj-refactor so I opted to make them public
rather than private, as they are generally useful.
expez added a commit to expez/clojure-mode that referenced this issue Jul 29, 2015
…c/cljc

When the source path is src/clj{,c,s,x} instead of just src/
clojure-expected ns would create namespaces like clj.my-project.my-ns
whereas what's wanted is my-project.my-ns.

Reading boot.clj or project.clj to find out the user's src dirs is out
of scope for clojure-mode, so we use the simply heuristic that no
namespace should start with clj, cljc or cljs because these are the
idiomatic source directories in multi-source projects.

When improving clojure-expected-ns I extracted out two utilities,
clojure-project-dir and clojure-project-relative-path.  These
utilities already exist in clj-refactor so I opted to make them public
rather than private, as they are generally useful.
bbatsov added a commit that referenced this issue Jul 29, 2015
@expez
Copy link
Member

expez commented Jul 29, 2015

This can be closed too, was hoping github would understand multiple issues closed by same commit

@bbatsov bbatsov closed this as completed Jul 29, 2015
@yatesco
Copy link
Author

yatesco commented Jul 29, 2015

Thanks for the quick response guys.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants