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

Consider pilfering functionality #181

Open
dabrahams opened this issue Nov 18, 2022 · 3 comments
Open

Consider pilfering functionality #181

dabrahams opened this issue Nov 18, 2022 · 3 comments

Comments

@dabrahams
Copy link

I was the primary developer of this file when I was on the Swift project, and there are some nice bits in there that might benefit your mode. In particular, the -skip- functions approximately parse swift pretty reliably and efficiently (I see you have your own code for that and I haven't tried to compare it, but the hangs with which-function mode make me suspect you might want to try a different approach), and there are useful functions for folding away the details of files when you want to easily understand an API.

I sucked those into my personal configuration so I could still use that functionality with your mode.

If there's any interest, I'm happy to help. OTOH, if you've already evaluated what's in there and decided none of it is useful, then, sorry for the noise!

@taku0
Copy link
Member

taku0 commented Nov 19, 2022

Our lexer needs to analyze the type of tokens and required to parse both forward and backward, rather than just skipping forward. It also needs to parse various constructs other than types.

Hiding bodies would be useful, but why not just use hs-hide-all or hs-hide-level? Those functions can handle other types of blocks and parenthesis. For example, swift-hide-bodies doesn't hide let definitions in Parser.swift while hs-hide-level handles parenthesized expressions well.

Besides, swift-hide-bodies needs some improvements:

  • swift-skip-type-name doesn't skip those types:

    • Types with attribute: @A B
    • Implicitly unwrapped optional types: Int!
    • Protocol composition types: P & Q
    • Opaque types: some P
    • Explicit existential types: any P
    • Async function types: (Int) async throws -> Int
    • Type names in backticks: `Int`
    • Type names with emoji: 😊
  • swift-hide-bodies mishandles:

    • Bare keyword as an identifier:

      class Foo {
        func `deinit`(f: () -> Void) -> Void {
          f()
        }
      }
      
      let foo = Foo()
      // we can use bare keyword as identifier after dot.
      let x = foo.deinit {
        print("aaa")
      }
    • var in case patterns:

      if case var x: Int=1 {
        print("aaa")
      }

      Note that swift-skip-type-name thinks Int=1 is a type name.

swift-hide-doc-comment-detail seems to be nice to incorporate. I'm not sure how to combine codes under Apache License v2.0 and GPLv3, though I know that Apache License v2.0 is compatible with GPLv3.

Other than that, Apple's swift-mode seems to be less accurate while concise and efficient; it doesn't handle those constructs:

  • Multiline string literals:

      let x = """
        aaa " aaa
        """
      let y = Foo()
  • Extended string literals: #"abc"def"#

  • String interpolations: "aaa \(/* " */ 1) bbb"

  • Regular expressions.

  • Nested multiline comments.

@dabrahams
Copy link
Author

dabrahams commented Nov 29, 2022 via email

@taku0
Copy link
Member

taku0 commented Dec 4, 2022

hs-hide-all hides too much (the methods and properties of every type); I was unable to make hs-hide-level do anything useful in my Swift file.

C-2 M-x hs-hide-level at the beginning of the Parser.swift will show you outline of the file.

? let definitions don’t ever have bodies in Swift. A body is a block surrounded by braces at the top level of a declaration.

Parser.swift has many let bindings with large expression, that is, functionDecl and followings. To grab the outline of the file, it should be hidden.

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

No branches or pull requests

2 participants