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

Change the default of cljr-favor-prefix-notation to false #363

Closed
expez opened this issue Feb 10, 2017 · 1 comment
Closed

Change the default of cljr-favor-prefix-notation to false #363

expez opened this issue Feb 10, 2017 · 1 comment

Comments

@expez
Copy link
Member

expez commented Feb 10, 2017

The default is currently t.

Back in the day my argument in favor of this was one of readability. Whenever I had to reference the ns form that job was made quicker by this grouping.

My arguments for changing it now are the following:

  • It reduces greppability because you can't easily find out where a namespace is in use by searching for its name.
  • cljs is now a thing and it doesn't support prefix notation at all, so we don't use it anyway in cljs files or in cljc files.
@jsab
Copy link

jsab commented Feb 15, 2017

This is in line with @stuartsierra's How to ns. It would be great if clj-refactor.el would support the format proposed in the article. At this time, I run the how-to-ns lein plugin after using clj-refactor.

dotemacs added a commit to dotemacs/clj-refactor.el that referenced this issue Apr 28, 2017
The reasoning is captured in the issue:

clojure-emacs#363

tl;dr: it allows for quicker searching and clj(s|c) files don't support
it
benedekfazekas pushed a commit that referenced this issue Apr 28, 2017
* Change prefix-notation to false

The reasoning is captured in the issue:

#363

tl;dr: it allows for quicker searching and clj(s|c) files don't support
it

* Updated the changelog

Updated it about the change to cljr-favor-prefix-notation default
behaviour.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants