Comment Driven Behaviors

[JD-Howard]

Is your feature request related to a problem? Please describe. Lisp is generally quite dumb and I would like to solve that with comment annotations.

Describe the solution you'd like This would exist purely to enhance the overall intelligence that VSCode can give users. I would like to use a formalized comment system to provide:

• LSP file header reference(s) to another *.LSP that explicitly instructs VSCode to include those (now linked) document symbols in my autoComplete suggestions. Very similar to how TypeScript & C# uses the Import keyword to create a direct data coupling to an external file.
• SETQ headers that denote VSCode should refer to these variable names as enumerators.
• DEFUN headers that can provide signature and argument declaration information for user defined functions.

Additional context None of this is unique and the benefits would be quite the feature evolution for AutoLisp users. Many languages provide Attribute headers and ///@Param comment declarations. We would just need to formalize what we are doing and nudge VSCode to help the user follow those rules. I would probably suggest not going C# & XML on this. Thinking more like something resembling AutoLisp:

;(assert IMPORT "./utilities/pointHelpers.lsp")


;(assert ENUM (type STR) "optional usage description")
(setq goodChoice "UseExisting"
      badChoice  "StartFromScratch"
)


;(assert DEFUN (pt1 (type LIST)) (pt2 (type LIST)) (type LIST))
ALSO accept longer/cleaner versions of the header like:
;(assert DEFUN "optional usage statement"
;    (pt1 (type LIST) "optional definition statement")
;    (pt2 (type LIST) "optional definition statement")
;    (type LIST "optional return value summary statement"))
(defun XYZ:Midpoint (pt1 pt2 / x y z) 
  (setq x (/ (+ (car pt2) (car pt1)) 2.0)
        y (/ (+ (cadr pt2) (cadr pt1)) 2.0)
        z (/ (+ (caddr pt2) (caddr pt1)) 2.0)
  )
  (list x y z)
)

So, these examples represent a suggestion to rely on the syntax we already have. This will allow us to utilize existing parsing capabilities to extract this information. We would just have to define some comment system function/type names

[hualin-wu-2000]

Wow, It looks like this is a big one, we need to take some time to design and discuss it.

[JD-Howard]

Agreed on the careful design, but I really don't think this is fundamentally that complicated; its really just metadata. The VSCode limitations (stated below) may in fact make it slightly easier.

From what I can tell, the vscode.languages.registerCompletionItemProvider won't trigger within something VSCode has determined to be a comment.

I still want some version of this, but not so sure it can be assisted the way I wanted. Probably have to be more snippet based and maybe there is some way we can swoop in and contextually manipulate the inserted template or in the case of import prompt for a file.