debugprint.nvim
debugprint.nvim copied to clipboard
Make treesitter queries language-specific and adjust variable_name query for PHP
Issue
The php default fileformat would show variable value twice and no variable name. Here's an example ( also a screenshot with treesitter highlight attached for better visibility)
$branchCode = 'au';
fwrite(STDERR, "DEBUGPRINT[1]: test.php:7: $branchCode=$$branchCode\n");
Which will output in:
DEBUGPRINT[1]: test.php:7: au=$au
proposal result
I tried to use the template below which will output: DEBUGPRINT[1]: test.php:7: $branchCode=au%
I saw in the readme that issue is preferred so I decide not to create a PR.
["php"] = {
left = "fwrite(STDERR, '",
right = "\\n');",
mid_var = "' . ",
right_var = ");",
},
Will output:
fwrite(STDERR, 'DEBUGPRINT[1]: test.php:7: $branchCode=' . $branchCode);
Note
I did change the double quote to single quote as I did not find a way to output the following:
fwrite(STDERR, "DEBUGPRINT[1]: test.php:7: \$branchCode=$branchCode\n");
// ^ No idea how to add the back slash here.
@RayGuo-ergou thanks for bringing this to my attention! I don't work with PHP much and hadn't noticed. I'll fix this.
@RayGuo-ergou actually, I cannot recreate your problem.
I started with this:
<?php
$branchCode = 'au';
?>
With my cursor sitting over branchCode
, I hit g?v
and it prompts for the variable, with branchCode
correctly prefilled. I hit enter and I get this:
<?php
$branchCode = 'au';
fwrite(STDERR, "DEBUGPRINT[3]: test.php:2: branchCode=$branchCode\n");
?>
This seems to be work as expected. I've also tried g?p
and that seems to work too.
So I'm a bit confused; what's the issue you are seeing?
My cursor was on $
, and if my cursor is on branchCode
then hit g?v
, neovim takes me to command mode, see image below.
And upon exit, a warning says "No variable name entered".
Maybe because neovim's version?
here's my version
NVIM v0.10.0-dev-2745+g5a5d26b4a
Build type: RelWithDebInfo
LuaJIT 2.1.1710088188
Compilation: /usr/bin/cc -O2 -g -Og -g -flto -fno-fat-lto-objects -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wvla -Wdouble-promotion -Wmissing-noreturn -Wmissing-format-attribute -Wmissing-prototypes -fsigned-char -fstack-protector-strong -Wno-conversion -fno-common -Wno-unused-result -Wimplicit-fallthrough -fdiagnostics-color=auto -DUNIT_TESTING -DHAVE_UNIBILIUM -D_GNU_SOURCE -DINCLUDE_GENERATED_DECLARATIONS -I/home/raydev/git/neovim/.deps/usr/include/luajit-2.1 -I/home/raydev/git/neovim/.deps/usr/include -I/home/raydev/git/neovim/build/src/nvim/auto -I/home/raydev/git/neovim/build/include -I/home/raydev/git/neovim/build/cmake.config -I/home/raydev/git/neovim/src -I/usr/include
system vimrc file: "$VIM/sysinit.vim"
fall-back for $VIM: "/usr/local/share/nvim"
Run :checkhealth for more info
Might related to treesitter
, tried to set ignore_treesitter = true
, then the cursor sitting on both $
and branchCode
takes me to the command mode.
I have record a gif, hope this makes sense.
Sorry for spamming messages but I believe this is the root cause:
https://github.com/andrewferrier/debugprint.nvim/blob/76a7c785598ac3a9f81cdc83e9b4a03c00a8b510/lua/debugprint/utils.lua#L145
Thus, add this additional condition works for me.
or parent_node_type == "variable_name"
@RayGuo-ergou aha, I understand now, and yes I can recreate the same behavior. In PHP the $
is not really part of the variable name but the logic here is too simplistic, I'm looking for variable_name
for another language, the Treesitter checks really need to be language-specific.
I'll work on that, but in the meantime you can work around this by moving one char to the right before you hit g?v
.
Thanks for your hard work in tracking it down more specifically by the way :)
Thank you!
Could be helpful: https://www.youtube.com/watch?v=86sgKa0jeO4
FYI, this issue has now been resolved permanently with some of the recent internal changes I've made to debugprint
to pick up Treesitter variables more accurately. I've also introduced a test specifically for this case to avoid it reoccurring.
Thanks again for your input on this issue.
Thank you so much!