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

Inconsistency in generated open location between Code Completion and Code Fix #789

Open
Booksbaum opened this issue Jun 8, 2021 · 3 comments

Comments

@Booksbaum
Copy link
Contributor

Inconsistency in generated open location between Code Completion and Code Fix

When completing (Ctrl+Space) a type in an unopened Namespace, its open gets automatically generated. Alternatively the open can be generated via Code Fix (Ctrl+.) on a type in unopened namespace.

But currently these open get generated at different locations:

  • Code Completion: Nearest possible place (-> nearest module)
  • Code fix: Top level (-> root module)

Example:

module Root

module Nested =

  let foo () =
    Regex
  //     ^ cursor is here

open locations:

  • Code Completion:
    module Root
    
    module Nested =
      open System.Text.RegularExpressions 
    
      let foo () =
        Regex
  • Code fix:
    module Root
    open System.Text.RegularExpressions 
    
    module Nested =
    
      let foo () =
        Regex

These two should have same behaviour.

  • Default: probably Nearest (like it's currently with code completion)
  • Probably introduce a setting for default location
  • Choice for Code Fix (-> two open XXXX fixes with different open locations)
    • Default location (based on setting) should have higher priority in list (come before other location)

Additional by baronfel (#788 (comment)):

Regarding your note, I've noticed that myself and haven't yet come to a decision on how to handle it. I think it's safest to go to Nearest by default, but I do agree that we could easily make it an option for the user for the codefix. For code completion I think a user setting would be the correct way to go, which we would just need to add to the config DTO and flow down into other layers as appropriate.

Booksbaum added a commit to Booksbaum/FsAutoComplete that referenced this issue Jun 12, 2021
Note:
There's a function to compare the `open` location retrieved from code
completion (`textDocument/completion`) with the `open` location from
Quick Fix "open Namespace" (`textDocument/CodeAction`).
That's currently disable because these two methods `open` in different
locations:
* Code Completion: Nearest position (closest module/namespace)
* Code Quick: Top Level (most outer scope in file)

This might be useful for testing if/when these different behaviors are
unified (ionide#789)
baronfel pushed a commit that referenced this issue Jun 13, 2021
Note:
There's a function to compare the `open` location retrieved from code
completion (`textDocument/completion`) with the `open` location from
Quick Fix "open Namespace" (`textDocument/CodeAction`).
That's currently disable because these two methods `open` in different
locations:
* Code Completion: Nearest position (closest module/namespace)
* Code Quick: Top Level (most outer scope in file)

This might be useful for testing if/when these different behaviors are
unified (#789)
@baronfel
Copy link
Contributor

Closing as #788 (released in 0.46.2) fixed this.

@Booksbaum
Copy link
Contributor Author

#788 "just" fixes some cases where opens from Code Completions are inserted into invalid places (and such producing compiler errors).

But the basic behaviour of both wasn't changed: Code Completion still opens in nearest location, Code Fix in top level
-> this issue isn't solved

@baronfel
Copy link
Contributor

Oh of course, this was the issue you added specifically to address that inconsistency.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants