You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Engine version (could be located within Tabnine Hub): 3.3.108
Issue Details:
This is not really an issue, but I'd like to bring it up in hope of a change. Pardon me if there's any duplicate, since this title not easy to check.
About the title, this has been discussed in other places, like dirs-dev/directories-rs#62.
The basic idea is that this folder should only be interacted via macOS's native API, otherwise apps should use ~/Library/Application Support.
I'm aware that TabNine data is already stored in ~/Library/Application Support, but perhaps it can coexist with preferences (since most likely you are using a library to handle this), or ~/.config (XDG_CONFIG_HOME) could also be used as it's common for developer tools on macOS.
There are two other questions about TabNine that I don't feel like opening separate issues for them:
I noticed in recent VSCode extension updates, location of TabNine binaries has been moved to VSCode's global storage (<VSCode data directory>/User/globalStorage/tabnine.tabnine-vscode/binaries) from the extension directory (<VSCode extension directory>/binaries).
This is a welcoming change, but does this mean the VSCode extension will start to clean up old versions of binaries? Before the change, they would stack up in the extension directory, but it's not a problem since VSCode will clean old versions of extensions.
Obsolete lock files are stacking up in preferences directory. This won't cause any space shortage, but it would be good if they would also be cleaned up.
(However there maybe different versions of TabNine running across different editors/extensions, which may cause implementation issues for cleaning. If this is the case then it's fine!)
Regarding the general issue, thank you for bringing it to our attention, we will look into it.
Regarding the 1st point, we've implemented a delete mechanism for old versions a while ago, so it will only ever keep the last 3 versions of Tabnine locally.
Regarding the 2nd point, you are right, we need to make sure old lock files are removed as well.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
please complete the following information:
Issue Details:
This is not really an issue, but I'd like to bring it up in hope of a change. Pardon me if there's any duplicate, since this title not easy to check.
About the title, this has been discussed in other places, like dirs-dev/directories-rs#62.
The basic idea is that this folder should only be interacted via macOS's native API, otherwise apps should use
~/Library/Application Support
.I'm aware that TabNine data is already stored in
~/Library/Application Support
, but perhaps it can coexist with preferences (since most likely you are using a library to handle this), or~/.config
(XDG_CONFIG_HOME
) could also be used as it's common for developer tools on macOS.There are two other questions about TabNine that I don't feel like opening separate issues for them:
<VSCode data directory>/User/globalStorage/tabnine.tabnine-vscode/binaries
) from the extension directory (<VSCode extension directory>/binaries
).This is a welcoming change, but does this mean the VSCode extension will start to clean up old versions of binaries? Before the change, they would stack up in the extension directory, but it's not a problem since VSCode will clean old versions of extensions.
(However there maybe different versions of TabNine running across different editors/extensions, which may cause implementation issues for cleaning. If this is the case then it's fine!)
That's all, thanks for you amazing work on TabNine. 😃
The text was updated successfully, but these errors were encountered: