Termdebug porting to Vim9

[ubaldot]

Hello!

I am aware that this is a bit ambitious, but I had the plan to make some
changes to termdebug to fit my needs. Given that I only learned Vim9
script, I took the "zero" step of porting the plugin as-is from the
legacy vim language to vim9 language and then to modify it according to my
needs and taste with a language that I know better.

However, before starting to make my changes, I was thinking that it should be fair to
"give back" to the community "what I took from the community" and here is a
(almost) "as-is" Vim9 porting of termdebug (bugs included! :p).

I think that in this way the plugin should be easier to maintain and could
encourage developers to contribute as well.

I tested both manually and with the automated test from testdir/ folder.

FYI: regardless if the PR will be accepted or not (I would be perfectly fine
either ways!) I plan to make a hacked version of this work on my repo and I
was thinking to call it termdebug9 but I am not sure if such a name could
bother anyone. Let me know. :)

Any other feedback is also appreciated!

Best,
/Ubaldo

[chrisbra]

Thanks. I think that is nice. Is this feature complete to the existing termdebug plugin?

@neovim devs, does this cause any issues for you? I suppose you are probably already using some version which supports the proper Neovim features (or even lua completly) so it shouldn't be a problem if we merge this here?

[clason]

Thank you for the consideration! We have "soft-forked" this (adapting some code parts to Neovim-specific API) but are backporting updates (automatically where changes apply cleanly; manually where they don't). This would make this harder but not impossible. (Some people do prefer this to, say, DAP protocol plugins.)

In this regard, it would be helpful if the 1:1 rewrite and any actual changes were done in separate commits, otherwise go ahead however it suits you!

[ubaldot]

Thanks. I think that is nice. Is this feature complete to the existing termdebug plugin?

Yes. It is. If you visually compare this and the legacy version in a vertical split you can easily 1-1 compare each single function. I only tried to "translate" a language into another. That is all. The thinking behind has been to be as less as invasive as possible.

Nevertheless, If you are curious to see what changes I am implementing on top of that, take a look at ubaldot/experiments#1 (implementation are carried out in the 1-proposed-changes branch not in `main).

I didn't dare to add any of these change in the original version, but if you see some item in the list in ubaldot/experiments#1 that you think can be further integrated I can send other PR:s. However, be careful because some are breaking changes (yet another reason to keep features as-is with the legacy vim script version). :)

[ubaldot]

Thank you for the consideration! We have "soft-forked" this (adapting some code parts to Neovim-specific API) but are backporting updates (automatically where changes apply cleanly; manually where they don't). This would make this harder but not impossible. (Some people do prefer this to, say, DAP protocol plugins.)

If we had a pure vim9 well-done DAP plugin I would switch, but for now I stick to termdebug. :)

In this regard, it would be helpful if the 1:1 rewrite and any actual changes were done in separate commits, otherwise go ahead however it suits you!

Unfortunately the 1:1 conversion is not done in separate commits. It has been a one-man-band work so I skipped as much as overhead as possible, as you can see from the eloquent commit messages :p I was also thinking to squash all the commits before opening the PR but you know, time is always an issue when you grow up :)

[clason]

No, that's fine, I meant it the other way around: don't include "feature" changes in the first PR -- which is exactly what you are (not) doing. So all is well.

[chrisbra]

Yes it should be exaclty how you have done it. Feature changes can be done later (if they make sense).

[chrisbra]

thanks, I found a few minor issues:

diff --git a/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim b/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
index 1cc5c16c4..b04198948 100644
--- a/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
+++ b/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
@@ -286,7 +286,7 @@ enddef
 # IsGdbRunning(): bool may be a better name?
 def CheckGdbRunning(): string
   var gdbproc = term_getjob(gdbbuf)
-  var gdbproc_status = 'unknwown'
+  var gdbproc_status = 'unknown'
   if type(gdbproc) == v:t_job
     gdbproc_status = job_status(gdbproc)
   endif
@@ -362,7 +362,6 @@ def StartDebug_term(dict: dict<any>)

   # Adding arguments requested by the user
   gdb_cmd += gdb_args
-  echo "starting gdb with: " .. join(gdb_cmd)

   ch_log('executing "' .. join(gdb_cmd) .. '"')
   gdbbuf = term_start(gdb_cmd, {
@@ -1367,7 +1366,7 @@ enddef
 # :Evaluate - evaluate what is specified / under the cursor
 def Evaluate(range: number, arg: string)
   var expr = GetEvaluationExpression(range, arg)
-  echom "expr:" .. expr
+  #echom "expr:" .. expr
   ignoreEvalError = 0
   SendEval(expr)
 enddef

I have fixed those, you may want to merge them back into your copy. I also mention that you have done the conversion to Vim9 Script. Please feel free to send improvements later on. Actually you may even become maintainer of the plugin (if you want), if this turns out to be working well and you intend to maintain this plugin (and support the current interfaces).

[ubaldot]

Great that you correct the issues! And thanks for the mention!

In reality, I already added some changes (yesterday I added a Init function to initialize all the script local variables at startup along a SanityCheck() function to gather many errors handling that were scattered around, plus other things, code here.

Next, I plan to refactor the huge file into multiple files and exploit the import/export features of Vim 9 in combination with Funcrefs to separate concerns and to ease the extendibility in case someone wants to use add lldb support or even the even the more ambitious DAP (Bram found this idea interesting: see here).

Regarding the maintainer role I am honoured for the proposal, but let's discuss it later on. I don't feel skilled enough. :) Let me keep the role of contributor for a bit more and let's re-discuss the idea later on. Regarding the new PR:s they will come once I will have refactored the code and I wish that you guys at the Vim project carefully review.

[ubaldot]

@chrisbra I just noticed that at the beginning of the script there is wrong email: could you please replace the email domain from @volvo.com with @gmail.com? Or it is enough that I push another commit/PR with this change? I haven't noticed that I was logged with my work account... sorry!