SUMMARY When starting from the GUI in MacOS, Language servers cannot be started, since Kate cannot find them in PATH STEPS TO REPRODUCE 1. Install bash-language-server via Homebrew 2. Open Kate from MacOS panel or via Finder 3. Browse to a Bash script file to start language server OBSERVED RESULT "Failed to find server binary: bash-language-server. Please check your PATH for the binary." EXPECTED RESULT bash-anguage-server would be started SOFTWARE/OS VERSIONS Kate: 24.11.70 / Nightly build: kate-master-7636-macos-clang-x86_64.dmg macOS: Ventura 13.6.7 Qt Version: 6.7.1 KDE Frameworks: 6.4.0 ADDITIONAL INFORMATION /etc/paths: contains /usr/local/bin, so it is added to PATH in Bash shell. When starting from bash shell: '/Applications/kate.app/Contents/MacOS/kate', the Language Server also starts OK. So this looks like a path setting issue and/or issue with starting other processes in macOS. WORKAROUNDS TRIED (but not leading to solution): 1. I tried setting the path into .plist file in Kate.app via LSEnvironment, but that did not help, or I could not make it properly effective. 2. Also, I tried setting the application path in the LSP settings to the JSON "path" attribute of bash-language-server, but still the same error message appeared about not able to locate bash-language-server in PATH 3. When setting the full path '/usr/local/bin/bash-language-server' to the "command" field in the User Server settings, I get a bit forward: "env: node: No such file or directory". Node would be in /usr/local/bin/node , too. So now it seems to progress up to the bash-language-server, but it cannot find node from the PATH. (Same problem would probably happen with almost all other LSP servers.) So the PATH should be somehow set to Kate.app , but I have not yet found a way.
Does something like this works: https://stackoverflow.com/questions/829749/launch-mac-eclipse-with-environment-variables-set ?
(In reply to Waqar Ahmed from comment #1) > Does something like this works: > https://stackoverflow.com/questions/829749/launch-mac-eclipse-with- > environment-variables-set ? I can check if there's something I haven't tried. Glancing quickly through, most of the comments are from 2009, so I am fairly certain those don't work. I tried some *.plist magic from instructions that were written 2017...2022, and those did not work either. Apple has changed / broken / jailed more stuff since then, so we'd probably need actual Mac-expertise to help with this, maybe.
I think it might make sense to add some way in the Kate config dialog to add directories to the paths we use, an on macOS that is all a pain. Will not hurt on other systems, too.
@Lassi Väätämöinen can you test: https://invent.kde.org/utilities/kate/-/merge_requests/1621 ?
(In reply to Waqar Ahmed from comment #4) > @Lassi Väätämöinen can you test: > https://invent.kde.org/utilities/kate/-/merge_requests/1621 ? I haven't been able to make MacOS builds happen. Is there some CI build that can be done? I know we have nightly builds, but those are off 'master' branch, I guess?
It can be triggered manually on the MR. I just triggered them so hopefully new binaries will appear soon
Ok, nice. I hope I'll have time to try it tonight.
(In reply to Waqar Ahmed from comment #4) > @Lassi Väätämöinen can you test: > https://invent.kde.org/utilities/kate/-/merge_requests/1621 ? Downloaded: https://invent.kde.org/utilities/kate/-/jobs/2286643 I was only able to start Kate off the command line. Starting from the GUI I only got a popup "kate is damaged and can't be opened. You should move it to Bin" So with this build I cannot try to verify if the reported issue is fixed.
I triggered a new build, perhaps other stuff was damaged there.
Git commit 7fccdf6e5085d1e90295c37ca7cb679463071aa9 by Christoph Cullmann, on behalf of Waqar Ahmed. Committed on 17/11/2024 at 11:56. Pushed by cullmann into branch 'master'. Try to have a PATH on macos when not launched from terminal M +19 -0 apps/lib/kateapp.cpp https://invent.kde.org/utilities/kate/-/commit/7fccdf6e5085d1e90295c37ca7cb679463071aa9
Git commit 233b944beb71720c0268abd726799c8126feb05f by Christoph Cullmann. Committed on 17/11/2024 at 12:02. Pushed by cullmann into branch 'release/24.12'. Try to have a PATH on macos when not launched from terminal (cherry picked from commit 7fccdf6e5085d1e90295c37ca7cb679463071aa9) Co-authored-by: Waqar Ahmed <waqar.17a@gmail.com> M +19 -0 apps/lib/kateapp.cpp https://invent.kde.org/utilities/kate/-/commit/233b944beb71720c0268abd726799c8126feb05f
Should be fixed with 24.12
Git commit 51097a672e627d776298b06e558104fb1224682e by Waqar Ahmed. Committed on 31/12/2024 at 07:43. Pushed by waqar into branch 'master'. Use path_helper utility on macos for setting PATH The old code builds a very basic path that excludes a lot of stuff like per user paths. M +16 -10 apps/lib/kateapp.cpp https://invent.kde.org/utilities/kate/-/commit/51097a672e627d776298b06e558104fb1224682e
Git commit 6956d8dee9d5fc9ac1ebe1221cc0e9f20735c446 by Waqar Ahmed. Committed on 31/12/2024 at 17:57. Pushed by waqar into branch 'master'. Allow the user to add paths to PATH var Kate relies heavily on external executables for a lot of functionality for e.g., LSP servers, formatters, linters, git etc. However, we dont provide any way to the user to provide a path where these programs can be found. As such the user has only 1 way to fix this which is to modify some global file and ensure the PATH is set there. On linux, things are messy in general so it kind of works sometimes. On windows you can change your PATH variable in settings. On mac, you can sort of edit /etc/paths. The problem with these approaches is that it forces the user to change things globally even if this functionality is only required by Kate on the whole system. This patch introduces a way to prepend paths to the existing PATH env var. M +61 -1 apps/lib/autotests/basic_ui_tests.cpp M +9 -0 apps/lib/kateapp.cpp M +63 -0 apps/lib/kateconfigdialog.cpp M +1 -0 apps/lib/kateconfigdialog.h M +3 -0 apps/lib/katemainwindow.cpp https://invent.kde.org/utilities/kate/-/commit/6956d8dee9d5fc9ac1ebe1221cc0e9f20735c446
*** Bug 504753 has been marked as a duplicate of this bug. ***