How to support fish's special autoloaded enviornment variables?

[ndonfris]

👇 brainstorming ideas to support expansions of fish autoloaded variables

With the PR #41, we support node.process environment variable expansions in fish. This does not include fish's autoloaded environment variables like:

• echo $fish_complete_path
• echo $fish_function_path
• echo $__fish_config_dir

---

Important

Shown in test file test-data/fileOperations.test.ts:

• Check the commented out test, for fish specific autoloaded functions that are executed through fish's environment variables: echo $fish_function_path

• Supporting the behavior described, would likely build on the solution here. Expand environment variables when checking file strings #40 & feat: added expand environment variables to SyncFileHelper @PeterCardenas #41

• I am particularly unsure about how to provide a general solution that handles all of the autoloaded cases.

  # Example - Normal env Variable
  >_ ts-node --eval "console.log(process.env.HOME)"
  >_ echo $HOME 
  
  # Example - autoloaded env Variable
  >_ ts-node --eval "console.log(process.env.__fish_config_dir)" 
  >_ echo $__fish_config_dir

---

more info on this topic

• configuration-files
• command lookup

---

what this feature would allow

• faster startup time, don't have to index workspaces
• closer behavior to native fish shell experience
• general improvements to internal server handlers

[PeterCardenas]

i guess you could execute it at start and then cache it, and then run it again when you detect file changes (maybe workspace/didChangeWatchFiles?)

[ndonfris]

I agree with that approach.

Supporting workspaces has proven to be quite challenging due to the way fish lazy loads definitions.

If we could export the workspaces into the path someway, we might be able to use
the existing process.env solution which would be nice.

Anyways, here's some related stuff on how we could potentially implement workspaces in the future.

Notes about Commands

• get all functions && completions in autoloaded order:

  path sort --unique --key=basename $fish_function_path/*.fish
  path sort --unique --key=basename $fish_complete_path/*.fish 

• finding specific workspace files: fish $__fish_sysconf_dir/config.fish

  • sets up the variables:

    __fish_active_key_bindings, __fish_added_user_paths, __fish_bin_dir, __fish_config_dir, __fish_data_dir, __fish_help_dir, __fish_initialized, __fish_sysconf_dir, __fish_user_data_dir, __fish_vendor_completionsdirs, __fish_vendor_confdirs, __fish_vendor_functionsdirs

  • __fish_build_paths.fish builds the initial paths startup fish paths

    could write small script to export variables to $PATH, or use overrides

Notes about Workspaces

• the workspaces/* vscode-languageserver definition is available on both the server & client of a connection.

  • I have yet to see a language client not have support attaching lsp's via attaching it's by detecting the current filetype. This is because the server handlers expect, the {uri, position, ...} as parameters through json requests.

  • The server should be able to open client files, through something like this.connection.client.* or this.connection.workspace, or even this.conneciton.server.client in src/server.ts

    1. This would require resolving the absolute path file location for a dependency.
    2. Then it would have to construct the LspDocument on the server, and in the current workspace
    3. Lastly, it would have to open the new document in the client

• Providing workspace related code actions and diagnostics will be easier to implement after supporting these related improvements

[ndonfris]

More Context about this Discussion

Note

Having less $fish_lsp_max_background_files files, than total recursive file definitions throughout the entire array of workspace paths $fish_lsp_all_indexed_paths will cause errors. (files aren't resolved after initial server indexing)

⚠️ test this behavior ⚠️

# run interactively 
set fish_lsp_max_background_files 2
$EDITOR /tmp/foo.fish

### reset to default behaviour  
# set -e fish_lsp_max_background_files
# source $__fish_config_dir/config.fish

---

• Fish should theoretically make resolving more background files possible through its autoloading capabilities.

• This would probably have negative effects for supporting workspace renames, and other possible workspace related handlers, as a tradeoff to providing faster start times.