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

VSCode: Support bundleGemfile locations relative to os.homedir #1974

Open
1 task done
SeanSith opened this issue Apr 25, 2024 · 2 comments
Open
1 task done

VSCode: Support bundleGemfile locations relative to os.homedir #1974

SeanSith opened this issue Apr 25, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@SeanSith
Copy link

I have checked that this feature is not already implemented

  • This feature does not exist

Use case

For those of us having to maintain multiple applications which use Ruby versions older than what ruby-lsp supports, we must use bundleGemfile to get the LSP to run. If we could define a bundleGemfile location using ~/[bundleGemfileDir]/Gemfile, that would support a use case where VSCode settings may be synchronized between multiple computers which maintain different home directory structures (e.g. between Linux and macOS or where different usernames are used).

Description

An augmentation of the bundleGemfile path searching to not only handle absolute paths and paths relative to the current project, but using the common UNIX convention of ~ to refer to the user's home directory. Note that currently customRubyCommand works with this convention if that helps.

Implementation

No response

@SeanSith SeanSith added the enhancement New feature or request label Apr 25, 2024
@vinistock
Copy link
Member

Thank you for the feature suggestion! Is there a reason why you cannot exclude this specific setting from sync and then configure the two machines differently?

@SeanSith
Copy link
Author

I've found that other extensions (e.g. Project Manager) implement the use of environment variables (like they do with $home in their git.baseFolders setting) to allow for similar situations. Maybe that is an option instead?

For those of us who try to have all of our environments operate in the same fashion, being able to define a configuration in one place and have it automatically synchronize to the other environments is ideal. Having to disable certain settings creates one-offs that need to be dealt with and maintained separately from the core workflow.

Unfortunately my experience with JS/TS is effectively nil, otherwise I'd have accompanied this with my hamfisted attempt at a PR. Thanks for considering the feature, though.

@aryan-soni aryan-soni removed their assignment Apr 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants