Skip to content

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

New issue

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

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

Already on GitHub? # to your account

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.

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

No branches or pull requests

3 participants