Patch debug details

[AnonMiraj]

i tried to not refactor the code too much for this small change.
i have tested it and it works as intended

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.52%. Comparing base (3386073) to head (91b810a).
Report is 8 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #363   +/-   ##
=======================================
  Coverage   87.52%   87.52%           
=======================================
  Files          35       35           
  Lines        4760     4763    +3     
=======================================
+ Hits         4166     4169    +3     
  Misses        594      594           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[gnikit]

Good first crack at this but this does not really fix the issue.
The useful thing is communicating the final (i.e. combined CLI + config) initialisation settings of the LanguageServer. This only restates what the CLI and config inputs are, which the user can just retrieve from looking at their fortls settings. (Also, you shouldn't be using sys.argv to retrieve the CLI options).

The solution I had in mind was rearchitecting parts of the constructor and initialization methods. Generally, care must be taken since certain variables like root_path are only available from the RPC request of the serve_initialization and could not be delegated to the constructor of the class.

[AnonMiraj]

thanks for the advice.
i now understand what needs to be done
i will try implementing them accordingly

[AnonMiraj]

The solution I had in mind was rearchitecting parts of the constructor and initialization methods. Generally, care must be taken since certain variables like root_path are only available from the RPC request of the serve_initialization and could not be delegated to the constructor of the class.

quick question
since all the options are are already stored the class
cant we just log these values directly or write them to a json file so it is cleaner ?

{
    "root_path": "/home/nero/Documents/library/Programming/test/test",
    "workspace": "{}",
    "obj_tree": "{}",
    "link_version": "0",
    "_version": "0.1.dev1064+g3386073",
    "config": ".fortlsrc",
    "nthreads": "4",
    "notify_init": "False",
    "incremental_sync": "False",
    "sort_keywords": "False",
    "disable_autoupdate": "False",
    "preserve_keyword_order": "False",
    "debug_log": "True",
    "source_dirs": "{'/path/to/source'}",
    "incl_suffixes": "set()",
    "excl_suffixes": "set()",
    "excl_paths": "{'/path/to/exclude'}",
    "autocomplete_no_prefix": "False",
    "autocomplete_no_snippets": "False",
    "autocomplete_name_only": "False",
    "lowercase_intrinsics": "False",
    "use_signature_help": "False",
    "variable_hover": "False",
    "hover_signature": "False",
    "hover_language": "fortran90",
}

would this be correct or am i missing something?

[gnikit]

cant we just log these values directly or write them to a json file so it is cleaner ...
would this be correct or am i missing something?

Not quite, because that would be duplicating the CLI options inside the language server.
The idea of passing settings and then creating class attributes at runtime is to not have to explicitly write the options of the CLI in multiple places.

[gnikit]

After our discussion over at Fortran-lang I will be closing this PR now.