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

Removal of s.el as a dependency #372

Merged
merged 31 commits into from
May 2, 2017

Conversation

dotemacs
Copy link
Contributor

@dotemacs dotemacs commented Apr 27, 2017

This PR based on the this issue #293 "Removal of s.el as a dependency".

The dependency on s.el has now been removed.

Please provide your feedback about the work I've done so far.


Regarding the PR etiquette below, I've crossed out the sections that I don't think are applicable.

Before submitting a PR make sure the following things have been done (and denote this
by checking the relevant checkboxes):

  • The commits are consistent with our contribution guidelines
  • You've added tests (if possible) to cover your change(s)
  • The new code is not generating byte compile warnings (run cask exec emacs -batch -Q -L . -eval "(progn (setq byte-compile-error-on-warn t) (batch-byte-compile))" clj-refactor.el)
  • All tests are passing (run ./run-tests.sh)
    - [ ] You've updated the changelog (if adding/changing user-visible functionality)
    - [ ] You've updated the readme (if adding/changing user-visible functionality)

Thanks!

dotemacs added 18 commits April 25, 2017 14:51
As per clojure-emacs#293
replacing s.el with subr-x.el

All the `thread-last' got unwound due to the re-write as s.el's `s-join'
expected separator first then the strings. Whereas subr-x.el's
`string-join' expects strings and then the separator.
As per clojure-emacs#293
replacing s.el with subr-x.el
As per clojure-emacs#293
replacing s.el with subr-x.el
As per clojure-emacs#293
replacing s.el with subr-x.el
As per clojure-emacs#293
replacing s.el functions with the ones that come as default with Emacs
As per clojure-emacs#293
replacing s.el functions with the ones that come as default with Emacs
As per clojure-emacs#293
replacing s.el functions with the ones that come as default with Emacs
As per clojure-emacs#293
replacing s.el functions with the ones that come as default with Emacs
As per clojure-emacs#293
replacing s.el functions with the ones that come as default with Emacs
As per clojure-emacs#293
replacing s.el functions with the ones that come as default with Emacs
When using cljr--project-dir with the stock Emacs function
string-remove-prefix, like this:

  (string-remove-prefix (cljr--project-dir) path)

instead of s.el's s-chop-prefix:

  (s-chop-prefix (cljr--project-dir) path)

it'll bomb out because cljr--project-dir will return nil, like it does
when running the tests.

But if it returns a blank string, then there is no issue.
As part of the removal of s.el as per
clojure-emacs#293 using
functions that come as part of Emacs
As per clojure-emacs#293
replacing s.el functions with the ones that come as default with Emacs
As per clojure-emacs#293
replacing s.el functions with the ones that come as default with Emacs
As per clojure-emacs#293
replacing s.el functions with the ones that come as default with Emacs
clj-refactor.el Outdated
(while (not (eobp))
(subword-forward)
(insert " "))
(mapconcat 'identity (split-string (downcase (buffer-string))) "-")))
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think of this?

I'm a bit undecided.

In one way it only uses functions that come as part of Emacs and relies on subword mode. But a bit unsure about it... suggestions welcome.

Copy link
Member

@expez expez Apr 27, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks OK to me. If it works as it should, I don't see a huge point in bikeshedding implementation details we can change at will :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks OK to me.

Cool, glad that you approve :)

As part of the drive to replace the dependency on the functions from
s.el replacing s-dashed-words with function that relies only on
functions that come as part of Emacs release.
thread-last seems to be doing the same thing and is part of Emacs'
subr-x.el whereas s-with is part of s.el
As part of the attempt to remove the dependency on s.el, replaced
s-slice-at with a simpler/cruder function.
Removed the unnecessary parenthesis within thread-last macros
Replacing it with split-string, but with the parameter taken from
s-lines
As per the issue
clojure-emacs#293 removed s.el
so that there is one less dependency for this mode that isn't part of
the standard Emacs release.
@dotemacs
Copy link
Contributor Author

I've removed all the functions from s.el and used stock ones from Emacs.

I've updated the PR description with some comments, please read that first as there are a few outstanding issues that I require your feedback on.

Then please review the code.

Thank you :)

@dotemacs dotemacs changed the title No more s.el Removal of s.el as a dependency Apr 27, 2017
@benedekfazekas
Copy link
Member

to address your comments above in bold:

contributing guidelines here: https://github.com/clojure-emacs/clj-refactor.el/blob/master/.github/CONTRIBUTING.md perhaps the link is wrong in the PR template?!

the README also has the (correct) link

tests: this is internal refactoring i guess we need to rely on our existing test set to catch regressions... don't think you need to add new unit like tests for this.

clj-refactor.el Outdated
@@ -573,7 +573,7 @@ list of (fn args) to pass to `apply''"

(defun cljr--whitespacep (s)
"True if S contains only whitespace."
(s-blank? (string-trim s)))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

essential difference between s-blank? and string-blank-p that former is null safe latter is not. I don't think that causes any problem in this commit but you might want to dblcheck that..

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, added the null safety with 36a886b

clj-refactor.el Outdated
(locate-dominating-file default-directory "build.boot")))
(ignore-errors (file-truename
(locate-dominating-file default-directory "pom.xml"))))))
(if (null project-dir)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perhaps rather (or project-dir "")?

or in fact you can get rid of the let you introduced and just stick an empty string at the end of the original or expression as default?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point.

Changed it as per your comment.

I was more on the 'drive' to complete the whole task, so I've missed the obvious stuff like this. Thanks

clj-refactor.el Outdated
@@ -2689,9 +2689,9 @@ str/split => split"
(let ((name (cljr--normalize-symbol-name symbol)))
(cond
((string-match-p "\\w+\\.\\w+" name)
(thread-last name (s-split "\\.") last car cljr--symbol-suffix))
(thread-last name (split-string "\\.") last car cljr--symbol-suffix))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be thread-first as well, or?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch. Fixed.

Shame that the tests didn't catch this...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tests: indeed

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd happily add the test for this, but seeing as cljr--symbol-suffix is a non-interactive function and most of the tests are feature tests, should I have a step like this:

When I press "M-: (cljr--symbol-suffix \"java.util.Date\")"
Then I should see message "Date"

What are your thoughts?

Copy link
Member

@benedekfazekas benedekfazekas May 1, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we decided to go down the behavioural testing route not the unit testing one. which is was a good choice i think. so i suppose just leave it ;)

clj-refactor.el Outdated
@@ -2247,15 +2247,15 @@ See: https://github.com/clojure-emacs/clj-refactor.el/wiki/cljr-update-project-d
(insert name)
(mc/create-fake-cursor-at-point)))
(re-search-forward "\\[")
(when (s-present? locals)
(when (not (or (null locals) (string= "" locals)))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i would possibly rather go for
string-empty-p instead of string= "" for readability and perhaps factor this pred out in its own function? something like cljr--string-present-p?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Created cljr--string-present-p as per your comment...

@benedekfazekas
Copy link
Member

made couple of comments. hope they make sense. only one of those is a potential bug the rest is more like style etc things.

As part of the extraction of the dependencies on s.el, it was replaced
with Emacs native functions, but then it was deemed that their usage was
not straightforward enough, hence cljr--string-present-p
clj-refactor.el Outdated
(if (null project-dir)
""
project-dir)))
(or project-dir "")))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you need the let at all tho? you can just

(or (ignore-errors...)
     (ignore-errors...)
     (ignore-errors...)
     "")

or am i missing something?

@benedekfazekas
Copy link
Member

made one more comment. otherwise LGTM. great work!

@benedekfazekas
Copy link
Member

one more thing: cljr--string-present-p could be used at more places i am guessing. for example line 2264 and 3207

dotemacs added 5 commits May 1, 2017 23:09
Using it in a few more places
Onliner instead of if statement
It should have been a thread first since the switch from s.el's s-split
takes regexp as the first argument and the string as the last. Whereas
split-string takes the arguments the other way around.
After removing s-blank? from s.el, just using string-blank-p wasn't null
safe.

Added the null check on Benedek Fazekas' prompting.
No need for the let clause, removing it
@dotemacs
Copy link
Contributor Author

dotemacs commented May 1, 2017

Reused cljr--string-present-p where suitable... 1641730
Removed let c02c15f & reduced repetition 4c0b23b

See what you think of it now.

Thanks for the feedback

clj-refactor.el Outdated
(or
(thread-last '("project.clj" "build.boot" "pom.xml")
(mapcar 'cljr--locate-project-file)
(delete '"")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

really like this approach. but i think this line is wrong. cljr--locate-project-file returns nil not empty string if file is not present. should be (delete nil) instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, pushed it as part of c33fc5f

Used mapcar in order to avoid the repetition
@benedekfazekas benedekfazekas merged commit b6d0715 into clojure-emacs:master May 2, 2017
@benedekfazekas
Copy link
Member

great work @dotemacs ta!

@dotemacs dotemacs deleted the no-more-s branch May 2, 2017 18:43
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

Successfully merging this pull request may close these issues.

3 participants