:Termdebug returns E1012: Type mismatch (expected string got list<string>) if g:termdebugger set about vim

[chrisbra]

Hm, I think this patch should do it, no?

diff --git a/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim b/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
index d00cdded2..8f2e331ef 100644
--- a/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
+++ b/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
@@ -248,11 +248,13 @@ enddef

 # Get the command to execute the debugger as a list, defaults to ["gdb"].
 def GetCommand(): list<string>
-  var cmd = 'gdb'
+  var cmd: any
   if exists('g:termdebug_config')
     cmd = get(g:termdebug_config, 'command', 'gdb')
   elseif exists('g:termdebugger')
     cmd = g:termdebugger
+  else
+    cmd = 'gdb'
   endif

   return type(cmd) == v:t_list ? copy(cmd) : [cmd]

@ubaldot please :)

[errael]

Only loosely related. I wonder if it's work copying all plain config globals, like

if exists('g:termdebugger')
    g:termdebug_config.command = g:termdebugger
endif

during startup, and then only use g:termdebug_config in the mainline code.

[accellarando]

Just wrote a quick fix for myself, I have not tested what happens if g:termdebug_config is set though.

# Get the command to execute the debugger as a list, defaults to ["gdb"].
def GetCommand(): list<string>
  var cmd = ['gdb']
  if exists('g:termdebug_config')
    cmd = get(g:termdebug_config, 'command', ['gdb'])
  elseif exists('g:termdebugger')
    cmd = g:termdebugger
  endif

  return type(cmd) == v:t_list ? copy(cmd) : [cmd]
enddef

[ubaldot]

Hm, I think this patch should do it, no?

diff --git a/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim b/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
index d00cdded2..8f2e331ef 100644
--- a/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
+++ b/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
@@ -248,11 +248,13 @@ enddef

 # Get the command to execute the debugger as a list, defaults to ["gdb"].
 def GetCommand(): list<string>
-  var cmd = 'gdb'
+  var cmd: any
   if exists('g:termdebug_config')
     cmd = get(g:termdebug_config, 'command', 'gdb')
   elseif exists('g:termdebugger')
     cmd = g:termdebugger
+  else
+    cmd = 'gdb'
   endif

   return type(cmd) == v:t_list ? copy(cmd) : [cmd]

@ubaldot please :)

Thanks, I am going to add it in #15057 (review)

[ubaldot]

Only loosely related. I wonder if it's work copying all plain config globals, like

if exists('g:termdebugger')
    g:termdebug_config.command = g:termdebugger
endif

during startup, and then only use g:termdebug_config in the mainline code.

This is indeed very elegant, I personally like it. :)

TBH 100% honest, I would add a deprecation warning saying that configuring variables of the form g:termdebugger will be ditched at some point in the future, inviting the user to read the :h termdebug to get guidance on how to update their configurations. That would clean up the code. But I don't know if this is inline with Vim vision. :)

[errael]

TBH 100% honest, I would add a deprecation warning saying that configuring variables of the form g:termdebugger will be ditched at some point in the future, inviting the user to read the :h termdebug to get guidance on how to update their configurations. That would clean up the code. But I don't know if this is inline with Vim vision. :)

I'm in enough trouble without commenting on this. ;)

[chrisbra]

But I don't know if this is inline with Vim vision. :)

We don't usually do this. But we can try it out in a plugin and see how people react 🙈. It's not something I'd recommend for core Vim, but for a plugin it should be fine. We should still support the deprecated version for half a year at least.

[ubaldot]

But I don't know if this is inline with Vim vision. :)

We don't usually do this. But we can try it out in a plugin and see how people react 🙈. It's not something I'd recommend for core Vim, but for a plugin it should be fine. We should still support the deprecated version for half a year at least.

I was actually thinking exactly the same thing: for the core I am pretty sure it is a no-no, but perhaps for a plugin it may be allowed. I was also thinking exactly the same: 6-12 months as time window for keeping the deprecation warning before deprecating some feature/setting/whatever.

We may try with termdebug for like six months and see how many people will complain. We won't remove anything, just display a warning message. The sanity-check function looks like a good place to add such a warning. I may work on it during next week.

Loosely related: it would be great if we manage to separate the "frontend" and the "backend" of termdebug but it may be hard and time consuming. At the moment as "backend" we only have gdb, but it would be nice to be able to use also other debuggers (lldb, debugpy, etc.) or implement DAP. Well, food for thoughts...