I'm somewhat reluctant to create an issue, but I could not find an other way to communicate.
I'm using
Neovim v0.4.3 with
LanguageClient-neovim 0.1.157
python 3.8.2 and
pynvim version 0.4.1
deoplete (master sha 921688)
I can't get the autocompletion to work (at least for constants in a package that is included with use). Actually I've also tried it out with VSCode and had the same issue. I've used the described setup from the examples. Packages are found, and the rest works but autocompletion just does not show up for [LC]
I'm somewhat reluctant to create an issue, but I could not find an other way to communicate.
I'm using
- Neovim v0.4.3 with
- LanguageClient-neovim 0.1.157
- python 3.8.2 and
- pynvim version 0.4.1
- deoplete (master sha 921688)
I can't get the autocompletion to work (at least for constants in a package that is included with use). Actually I've also tried it out with VSCode and had the same issue. I've used the described setup from the examples. Packages are found, and the rest works but autocompletion just does not show up for [LC]
Do you see other completions from VHDL-TOOL? For example, if you type the beginning of a signal name VHDL-TOOL should complete it with the rest of the signal name, and show its declaration.
I see from your other issue that you are using OSVVM. VHDL-Tool currently cant handle the protected types used by that package. It likely can't even parse the package that declares the constants. We are currently working on adding support for protected types to VHDL-Tool.
Do you see other completions from VHDL-TOOL? For example, if you type the beginning of a signal name VHDL-TOOL should complete it with the rest of the signal name, and show its declaration.
I see from your other issue that you are using OSVVM. VHDL-Tool currently cant handle the protected types used by that package. It likely can't even parse the package that declares the constants. We are currently working on adding support for protected types to VHDL-Tool.
I actually do not see any completion suggestions for any signal names. The only way I currently can get suggestions is through ctags (what I've already used in the past).
I actually do not see any completion suggestions for any signal names. The only way I currently can get suggestions is through ctags (what I've already used in the past).
Funnily enough it gives instance snippet suggestions for entities.?.
I observe the same behaviour in vscode. However the snippet expansion does not work correctly in neovim, but that could be my setup. I'm using UltiSnips, maybe they interfere.
Funnily enough it gives instance snippet suggestions for entities.?.
I observe the same behaviour in vscode. However the snippet expansion does not work correctly in neovim, but that could be my setup. I'm using UltiSnips, maybe they interfere.
Is there a possibility to write a log file from vhdl-tool?
I might have to mention, that my project consists of 1850 files, but for the snippet expansion this does not seem to have any influence.
Is there a possibility to write a log file from vhdl-tool?
I might have to mention, that my project consists of 1850 files, but for the snippet expansion this does not seem to have any influence.
I've just noticed that signals that are in the open buffer are actually correctly suggested for completion. So it is only for things like constants from a used package, that do not show up...
Sorry closed it by mistake...
I've just noticed that signals that are in the open buffer are actually correctly suggested for completion. So it is only for things like constants from a used package, that do not show up...
Other language server functionality works, right? Like syntax checking and hover information.
When the completions show up in vim does it show the text "[LC]" (for language client) next to the completion? If so that means that the completions you see are actually coming from vhdl-tool, not deoplete's built in completion.
Is it possible that the package with the constants uses protected types and therefore cant even be parsed by vhdl-tool? btw - im releasing a version with protected type support very soon.
Logging is possible but only in a debug build. I'll add the ability to configure that in the next release.
Lastly, I recommend getting things going in vscode initially. I have found vscode to be much simpler and more robust with language servers. There's just fewer moving parts compared to vim where you have to install a whole lot of plugins to get things to work.
Other language server functionality works, right? Like syntax checking and hover information.
When the completions show up in vim does it show the text "[LC]" (for language client) next to the completion? If so that means that the completions you see are actually coming from vhdl-tool, not deoplete's built in completion.
Is it possible that the package with the constants uses protected types and therefore cant even be parsed by vhdl-tool? btw - im releasing a version with protected type support very soon.
Logging is possible but only in a debug build. I'll add the ability to configure that in the next release.
Lastly, I recommend getting things going in vscode initially. I have found vscode to be much simpler and more robust with language servers. There's just fewer moving parts compared to vim where you have to install a whole lot of plugins to get things to work.
Actually, I forgot, there is currently logging functionality that is part of VScode.
Go to "file > preferences > settings". Type "language server" in the search bar. Click on "VHDL-Tool" on the left and set the trace level to verbose.
Then, go back to your VHDL source, click on "output" next to "problems", then select "Language Server VHDL" from the drop-down menu at the top right of the output window.
Actually, I forgot, there is currently logging functionality that is part of VScode.
Go to "file > preferences > settings". Type "language server" in the search bar. Click on "VHDL-Tool" on the left and set the trace level to verbose.
Then, go back to your VHDL source, click on "output" next to "problems", then select "Language Server VHDL" from the drop-down menu at the top right of the output window.
Other language server functionality works, right? Like syntax checking and hover
information.
Yes, goto definition and hover work
When the completions show up in vim does it show the text "[LC]" (for language client) next
to the completion? If so that means that the completions you see are actually coming from
vhdl-tool, not deoplete's built in completion.
It only shows [LC] for things like instances or keywords and constants defined in the same file, but not for constants from packages or signals defined within the active buffer.
Is it possible that the package with the constants uses protected types and therefore
cant even be parsed by vhdl-tool? btw - im releasing a version with protected type
support very soon.
No the package does not use any protected types.
> Other language server functionality works, right? Like syntax checking and hover
information.
Yes, goto definition and hover work
> When the completions show up in vim does it show the text "[LC]" (for language client) next
to the completion? If so that means that the completions you see are actually coming from
vhdl-tool, not deoplete's built in completion.
It only shows [LC] for things like instances or keywords and constants defined in the same file, but not for constants from packages or signals defined within the active buffer.
> Is it possible that the package with the constants uses protected types and therefore
cant even be parsed by vhdl-tool? btw - im releasing a version with protected type
support very soon.
No the package does not use any protected types.
So I've checked in VSCode and it behaves the same (Ubuntu 19.04)
I've found out, that for signals from the same file they aren't auto completed at all if I start with capital letters. So a signal called CycleEnable will not be expanded if I start typing Cycle, but it is expanded if I start to write cycle. But I've still no luck with constants from a package.
Maybe the code base is to big, or the mixture with packages that contain protected types confuses vhdl-tool ...
So I've checked in VSCode and it behaves the same (Ubuntu 19.04)
I've found out, that for signals from the same file they aren't auto completed at all if I start with capital letters. So a signal called CycleEnable will not be expanded if I start typing Cycle, but it is expanded if I start to write cycle. But I've still no luck with constants from a package.
Maybe the code base is to big, or the mixture with packages that contain protected types confuses vhdl-tool ...
Yeah, looks like completion is broken for upper case signals and constants. Thanks a lot for finding that. It will be fixed in the next release, which should be in a couple of weeks.
I've released a new version that supports protected types (0.0.14), which is available from the download page. That might help with the missing constant autocompletions, but probably not.
VHDL-Tool is used on codebases with >500K lines of code with no problems. So, I would hope it would be able to handle yours too.
Yeah, looks like completion is broken for upper case signals and constants. Thanks a lot for finding that. It will be fixed in the next release, which should be in a couple of weeks.
I've released a new version that supports protected types (0.0.14), which is available from the download page. That might help with the missing constant autocompletions, but probably not.
VHDL-Tool is used on codebases with >500K lines of code with no problems. So, I would hope it would be able to handle yours too.
I'm somewhat reluctant to create an issue, but I could not find an other way to communicate. I'm using
I can't get the autocompletion to work (at least for constants in a package that is included with use). Actually I've also tried it out with VSCode and had the same issue. I've used the described setup from the examples. Packages are found, and the rest works but autocompletion just does not show up for [LC]
Do you see other completions from VHDL-TOOL? For example, if you type the beginning of a signal name VHDL-TOOL should complete it with the rest of the signal name, and show its declaration.
I see from your other issue that you are using OSVVM. VHDL-Tool currently cant handle the protected types used by that package. It likely can't even parse the package that declares the constants. We are currently working on adding support for protected types to VHDL-Tool.
I actually do not see any completion suggestions for any signal names. The only way I currently can get suggestions is through ctags (what I've already used in the past).
Funnily enough it gives instance snippet suggestions for entities.?. I observe the same behaviour in vscode. However the snippet expansion does not work correctly in neovim, but that could be my setup. I'm using UltiSnips, maybe they interfere.
Is there a possibility to write a log file from vhdl-tool? I might have to mention, that my project consists of 1850 files, but for the snippet expansion this does not seem to have any influence.
Sorry closed it by mistake...
I've just noticed that signals that are in the open buffer are actually correctly suggested for completion. So it is only for things like constants from a used package, that do not show up...
Hi, do you have any input on my comments? Is this what you would expect, or could you hint me in what direction to investigate?
Other language server functionality works, right? Like syntax checking and hover information.
When the completions show up in vim does it show the text "[LC]" (for language client) next to the completion? If so that means that the completions you see are actually coming from vhdl-tool, not deoplete's built in completion.
Is it possible that the package with the constants uses protected types and therefore cant even be parsed by vhdl-tool? btw - im releasing a version with protected type support very soon.
Logging is possible but only in a debug build. I'll add the ability to configure that in the next release.
Lastly, I recommend getting things going in vscode initially. I have found vscode to be much simpler and more robust with language servers. There's just fewer moving parts compared to vim where you have to install a whole lot of plugins to get things to work.
Actually, I forgot, there is currently logging functionality that is part of VScode. Go to "file > preferences > settings". Type "language server" in the search bar. Click on "VHDL-Tool" on the left and set the trace level to verbose.
Then, go back to your VHDL source, click on "output" next to "problems", then select "Language Server VHDL" from the drop-down menu at the top right of the output window.
Yes, goto definition and hover work
It only shows [LC] for things like instances or keywords and constants defined in the same file, but not for constants from packages or signals defined within the active buffer.
No the package does not use any protected types.
So I've checked in VSCode and it behaves the same (Ubuntu 19.04) I've found out, that for signals from the same file they aren't auto completed at all if I start with capital letters. So a signal called CycleEnable will not be expanded if I start typing Cycle, but it is expanded if I start to write cycle. But I've still no luck with constants from a package.
Maybe the code base is to big, or the mixture with packages that contain protected types confuses vhdl-tool ...
Yeah, looks like completion is broken for upper case signals and constants. Thanks a lot for finding that. It will be fixed in the next release, which should be in a couple of weeks.
I've released a new version that supports protected types (0.0.14), which is available from the download page. That might help with the missing constant autocompletions, but probably not.
VHDL-Tool is used on codebases with >500K lines of code with no problems. So, I would hope it would be able to handle yours too.
I have released vhdl-tool version 0.15, which fixes some case sensitivity issues with autocompletion, any may fix the issues you are seeing.