I'm wondering if there is a way to detect if the source loaded is within a git context and, if so, either add to or create (prompting) the .gitignore to include .vscode folder - right now having to do that manually.

Log statments. [2022-08-23 19:24:04.796] [exthost] [error] Activating extension LordDurus.qb64 failed due to an error: [2022-08-23 19:24:04.796] [exthost] [error] Error: Cannot find module '@vscode/debugadapter'

QB64 will be migrating from .txt files to .md files for local help. These files will be named the same as they are on the wiki (as they will literally duplicated from the wiki). So would like to see the option of being able to open these within VSCode (F1). Additionally, would like to have the option, defaulting to enabled (view), for opening in either "view" mode or "edit" mode. I also think that the path should default to these files (under the QB64) folder - but, we should also have the ability to override this path so that, for those that are contributing to the wiki, can point it to a local repo of the actual wiki instead of the files in the QB64 folder.

... would be nice if it could determine the word that the cursor currently resides and utilize that word when launching help. Primary reason is as one is typing, navigating with cursor keys, etc. it feels more natural (to me, suspect others) to simply be able to press F1 to go to help instead of having to highlight the word first before doing so.

Write the lint output to the terminal window (leave it in the lint output window as well)

There will be a setting to control this: isLintToTerminalEnabled

It appears that the path seen (verified) is working, but when it is being combined in order to open the target file the root path is defaulting to the path used to open VSCode instead of the path of the opened .BAS file.

c:\bas <- launched VSCode c:\bas\qbint <- opened file in this folder c:\bas\qbint\includes <- include file is in this folder

I'm going to try to walk through this using the https://github.com/DualBrain/QuickPakPro/ project.

The folder structure of the project is setup such that the README.md and other "high level" stuff is in the root of the folder. The majority of the source code is located in a QB64 folder (this could easily be called something like SOURCE, but I have my reason(s)).

When I have this on my machine, I typically use GitHub Desktop to jump between different projects and it contains a nice feature "Open in Visual Studio Code". Doing so, it will open the root of this project folder in VSCode and this is where (I believe) the problem roots itself.

Inside of the QB64 folder, I then find my sample that I wish to work with. I then press F5... the problem though is that there is then a difference between what the sample executing sees as the current working folder versus if I launch the compiled executable outside of VSCode. What I mean is that the compiled executable is located in the same folder as the .BAS file... this is the desired result. However, if VSCode launches the compiled executable (as part of the F5 process), the executable things the starting folder is the root of the project... not the same folder as where the executable is. If, however, I was to double click on the executable in Windows... things are working as expected.

One key point here is that I am using CHDIR _STARTDIR$ in my code to "reset" the current "working" folder used by the file functionality to be the location specified as the start folder.

In my mind, this start folder should be the location of the executable (by default), not the root of the project.

Hover over a + 1 and you get a "The editor could not be opened due to an unexpected error: File is a directory" in an empty tab and an OK "button".

I'm encountering this because I'm using CTRL+C/CTRL+V/CTRL+X operations while highlighting things with a mouse and it started popping up a lot; I then took a moment to narrow it down to the most minimal repro I could find. CTRL+move mouse (hover?).

I did disable "Qb64: Is Hover Text File Enabled" and am still getting this happening (meaning, no difference in behavior).