Mirror of forum.nim-lang.org

6838 :: Modelling projects for VS Code Extension

• saem (orginal) [2020-09-19T08:29:34+02:00] view original

  I've been plugging away at porting the TypeScript VS Code extension into Nim. There are a number of design issues I'm running into and they're centered around how to reason about nim files, projects, and determining what the user most likely intends. I'd like to avoid IDE specific config and instead keep things as light as possible, the nim/nims/cfg/nimble files and directory layouts should do the heavy lifting.

  Without solving too much at once, I'm trying to get a mental model around a "project". The most burning question I believe that would answer is how to reason about nimsuggest usage. Influencing:

  • how many processes of nimsuggest and which nim file to start with
  • which ones to query (priority order) for context
  • how the IDE should internally reason about scopes/user intention
  • influence all sorts of parameters for various run commands etc...
  • defines and dependencies that are or are not in play

  As far as any IDE is concerned, one of two things happens:

  1. a user opens a singular file (easy to tell project)

  2. a user opens a folder and then all sorts of projects might exist In the second case there is a requirement for a deep model.

  What follows is my attempt at building up a model as I haven't really found anything online that does this.

  Single nim file project directory, with:

  • only foo.nim
  • only foo.nim and foo.nim.cfg

  Single nimscript file project

  • only foo.nims

  Single nim file project and nimscript config

  • only foo.nim and foo.nims

  Single nim file project, nimscript config, and project .nim.cfg

  • only foo.nim and foo.nims and foo.nim.cfg

  Many nim files and project foo -- other details handled by above

  • many *.nim(s) and one foo.nim(s) as an executable
  • many *.nim(s) and one foo.nim(s) and a foo.nim.cfg
  • many *.nim(s) and one foo.nim(s), foo.nims, and a foo.nim.cfg

  Many nim files, foo.nim project, bar.nim is queried via nimsuggest foo.nim but that's probably not right if we try to run bar.nim just by itself?

  • many *.nim(s) and one bar.nim, and a foo.nim.cfg and/or foo.nims

  These are things that I know will be required, but I haven't modeled.

  TODO nimble based project:

  • simple project, flat hierarchy (deprecated style?)
  • simple project with src and/or test dir --srcDir and --path in nim.cfg
  • private module
  • multiple modules
  • libraries

  Also very much ignoring:

  • dependencies
  • versions
  • tasks

  My current concern is that I'm not seeing strong delineations and a very large degree of variance is allowed -- that's rather frightening. I'm hoping that's entirely my newness.

---