Skip to content

Clean symbol before doing look up #887

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

Closed

Conversation

tanzoniteblack
Copy link
Contributor

If you attempt to run cider-jump-to-var to find the definition of an
atom dereferenced with @, cider can't find the source location. If you remove
the @ cider has no issues finding the location. This allows for cleaning
non-variable components out of a symbol before doing the look up to prevent this
issue.

Possible fix for #886

@bbatsov
Copy link
Member

bbatsov commented Nov 21, 2014

I think it will be better to do the cleanup in cider-symbol-at-point.

@tanzoniteblack
Copy link
Contributor Author

@bbatsov agreed, that is a much better location for this logic. Updated the pull request to stick the new cider--clean-symbol into cider-interaction.el and to have this function called in cider-symbol-at-point instead.

@tanzoniteblack
Copy link
Contributor Author

Also, I'm using let* as a hacky way to allow conditional piping of changes (ala clojure's cond->), incase we find other string additions that prevent this from working in the future. If you have a better elisp suggestion for this, or think it's an unnecessary at this time and just doing the basic if statement would be better, let me know.

@bbatsov
Copy link
Member

bbatsov commented Nov 21, 2014

I think you can simply use a regexp to remove anything that's not a letter at the beginning of the symbol name.

@bbatsov
Copy link
Member

bbatsov commented Nov 21, 2014

P.S. You should also add a changelog entry and a couple of unit tests.

@tanzoniteblack
Copy link
Contributor Author

I'll add some tests and update the change log in a bit (and make sure all existing tests pass...which they don't).

Do we really want to strip anything that's not a letter from the beginning? That would cause a valid symbol like -var or _var to break. According to http://clojure.org/reader a symbol can start with any letter or a character from the list [*, +, !, -, _, ?]. I'll try to get the function to clean it up to consist of that, and make sure we don't break on unicode characters.

@bbatsov
Copy link
Member

bbatsov commented Nov 22, 2014

You're totally right; I should have thought a bit more about the problem. Your proposal is sound. Another alternative would be to strip just things we know we should strip (@, #', ', etc)

@tanzoniteblack
Copy link
Contributor Author

I prefer the stripping things we know we should strip specifically, rather than attempting to strip anything that doesn't look valid. It's an easier to problem to get right without odd bugs creeping up.

If you attempt to run `cider-jump-to-var` to find the definition of an
atom dereferenced with `@`, cider can't find the source location. If you remove
the `@` cider has no issues finding the location. This allows for cleaning
non-variable components out of a symbol before doing the look up to prevent this
issue.
@tanzoniteblack
Copy link
Contributor Author

I've fixed the failing test (by accounting for empty string causing substring to throw errors) and added a new one to specifically test for @item.

I can include #' and ' in the stripper if you want, but 1.) I'm not sure if it's invalid to send them to our symbol look up, and 2.) the way we get the symbol at point in Emacs causes these to not be counted as part of the word currently anyways.

@bbatsov
Copy link
Member

bbatsov commented Nov 22, 2014

the way we get the symbol at point in Emacs causes these to not be counted as part of the word currently anyways.

This leads me to be believe that clojure-mode's syntax table might need adjusting. Guess @ is treated as a word character and ' is not. Updating the syntax table should solve this without the need to do anything in cider itself.

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.

2 participants