-
-
Notifications
You must be signed in to change notification settings - Fork 904
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
Auto detect macos clangd #2161
Conversation
@@ -1519,6 +1519,25 @@ BODY should never return `t' value." | |||
download-in-progress? | |||
buffers) | |||
|
|||
(defun lsp-clients-executable-find (find-command &rest args) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
Thank you! @kiennq I hope you are fine with the commit as it is. |
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.