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

Auto detect macos clangd #2161

Merged
merged 6 commits into from
Sep 11, 2020
Merged

Auto detect macos clangd #2161

merged 6 commits into from
Sep 11, 2020

Conversation

wyuenho
Copy link
Contributor

@wyuenho wyuenho commented Sep 10, 2020

Allow LSP to pick up the clangd that comes with Xcode or Developer Command Line Tools automatically without having the user to install LLVM with Homebrew or MacPorts.

clients/lsp-clangd.el Outdated Show resolved Hide resolved
clients/lsp-clangd.el Outdated Show resolved Hide resolved
@@ -1519,6 +1519,25 @@ BODY should never return `t' value."
download-in-progress?
buffers)

(defun lsp-clients-executable-find (find-command &rest args)
Copy link
Member

Choose a reason for hiding this comment

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

nit: Can't this be named something more generic? This doesn't even reassemble the execute-find, both in parameters and implementation.

I would imagine that this should be named (since it's already inside lsp-mode.el) like lsp-call-procecss and be documented as a wrapper of call-process which returns output instead of inserting it in a buffer.
Same thing like how lsp-async-start-process exists.

With helper function like this, more generic name covers more use cases and keeps us from re-inventing the wheel.

Copy link
Member

Choose a reason for hiding this comment

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

FTR there is shell-command-to-string

Copy link
Member

Choose a reason for hiding this comment

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

With helper function like this, more generic name covers more use cases and keeps us from re-inventing the wheel.

I think @kiennq have a good point here. Sometime I implemented a helper function that may work across all modules yet is hard for me to decide where to put it; especially, the function itself is for in very generic use. I wonder if there is a file that maybe we can place all our helper functions? (Sorry, I am quite new here. :P)

Copy link
Contributor Author

@wyuenho wyuenho Sep 10, 2020

Choose a reason for hiding this comment

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

I would imagine that this should be named (since it's already inside lsp-mode.el) like lsp-call-procecss and be documented as a wrapper of call-process which returns output instead of inserting it in a buffer.
Same thing like how lsp-async-start-process exists.

Scope creep. The crux of the implementation of this function is the (when (zerop (call-process...) bit. I really just want the path output from a process when it exits successfully. There are a bunch of path finding commands in all kinds of multiple environment CLI utils.

FTR there is shell-command-to-string

You can't get the exit status with shell-command-to-string. Command errors still returns output from that function.

if there is a file that maybe we can place all our helper functions?

I was wondering about the same thing. Every large project should have a utils file/module somewhere, but it's spread out all over the place in our case.

@yyoncho yyoncho merged commit 02c64e6 into emacs-lsp:master Sep 11, 2020
@yyoncho
Copy link
Member

yyoncho commented Sep 11, 2020

Thank you!

@kiennq I hope you are fine with the commit as it is.

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.

4 participants