[vim/vim] Added InitScriptVariables() function, refactor & bugfix. (PR #14980)
ubaldot
List of Changes and the Reasoning Behind Them:
- Introduction of InitScriptVariables() Function:
Reasoning: This function has been introduced to ensure that when you open and close Termdebug, and then open it again, there are no leftover script variable values from the previous session. Leftover values could potentially cause issues. The goal is for each Termdebug session to be independent of previous sessions. At startup, all script variables are initialized. The only exception is g:termdebug_loaded located at the very beginning of the script to prevent sourcing the script twice. The variables are declared at script level and defined in InitScriptVariables().
- More Descriptive Variable Names:
Reasoning: The names of variables have been made more comprehensive. Almost every Termdebug buffer now has a variable to indicate its name and another variable to indicate its number, improving code readability and maintainability. Due to the latest discussion around the &mousemodel option save/restore mechanism, perhaps some other variables shall be prepended with saved_.
- Consistent Naming for GDB Terminal Buffers:
Reasoning: The name of the GDB terminal buffer now matches the name of the GDB program being used, e.g., 'gdb', 'mygdb', 'arm-eabi-none-gdb', etc. This ensures clarity and consistency in identifying buffers.
- Other:
MovedEchoErr()on top, added another test, some refactoring, mainly changed several0and1totrueandfalse.
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/14980
Commit Summary
- 249c890 Added InitScriptVariables(), refactor & bugfix
- 845fe7d Dummy, for triggering github actions
- 714a669 Uncommented g:termdebug_loaded. I always forget it.
File Changes
(2 files)
Patch Links:
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
ubaldot
@ubaldot pushed 1 commit.
- a794465 Improved test
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
errael
Is it worth mentioning specifically what bug is fixed by this PR?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
@chrisbra commented on this pull request.
In runtime/pack/dist/opt/termdebug/plugin/termdebug.vim:
> if exists('g:termdebug_loaded')
- finish
+ Echoerr('Termdebug already loaded.')
typicaly we don't error out, if a script is sourced twice. We just silently ignore this.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
> endif running = 0 gdbwin = 0 enddef # IsGdbRunning(): bool may be a better name? -def CheckGdbRunning(): string - var gdbproc = term_getjob(gdbbuf) - var gdbproc_status = 'unknown' - if type(gdbproc) == v:t_job - gdbproc_status = job_status(gdbproc) - endif - if gdbproc == v:null || gdbproc_status !=# 'run' - var cmd_name = string(GetCommand()[0]) +def IsGdbStarted(): bool + # CHECKME: check this implementation
CHECKME
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
errael
@errael commented on this pull request.
So much stuff I'm not familiar with... And looks so much better.
In runtime/pack/dist/opt/termdebug/plugin/termdebug.vim:
> @@ -38,44 +38,61 @@ vim9script # The communication with gdb uses GDB/MI. See: # https://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI.html -# In case this gets sourced twice. +def Echoerr(msg: string) + echohl ErrorMsg | echom $'[termdebug] {msg}' | echohl None +enddef + +if !has('vim9script') || v:version < 900⬇️ Suggested change
-if !has('vim9script') || v:version < 900
+if !has('vim9script') || v:versionlong < 9010450
Given that termdebug ships with vim, could either tighten up the version check as shown, or take it out entirely. vim9script has evolved considerably since v9.0 was released; so unless you're planning to test against it...
In runtime/pack/dist/opt/termdebug/plugin/termdebug.vim:
> @@ -38,44 +38,61 @@ vim9script # The communication with gdb uses GDB/MI. See: # https://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI.html -# In case this gets sourced twice. +def Echoerr(msg: string) + echohl ErrorMsg | echom $'[termdebug] {msg}' | echohl None +enddef + +if !has('vim9script') || v:version < 900 + # Needs Vim version 9.0 and above + Echoerr("You need at least Vim 9.0") + finish +endif + +# Variables to keep their status among multiple instanced of Termdebug +# Avoid to source the script twice. if exists('g:termdebug_loaded')⬇️ Suggested change
-if exists('g:termdebug_loaded')
+if g:->get('termdebug_loaded', false)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
errael
@errael commented on this pull request.
In runtime/pack/dist/opt/termdebug/plugin/termdebug.vim:
> + var cmd_name = string(GetCommand()[0])
+ if gdbproc_status !=# 'run'
Echoerr($'{cmd_name} exited unexpectedly')
Seems no reason to compute cmd_name outside of the if and might as well have it directly as interpolated string
Echoerr($'{string(GetCommand()[0])} exited unexpectedly')
In runtime/pack/dist/opt/termdebug/plugin/termdebug.vim:
> endif running = 0 gdbwin = 0 enddef # IsGdbRunning(): bool may be a better name? -def CheckGdbRunning(): string - var gdbproc = term_getjob(gdbbuf) - var gdbproc_status = 'unknown' - if type(gdbproc) == v:t_job - gdbproc_status = job_status(gdbproc) - endif - if gdbproc == v:null || gdbproc_status !=# 'run' - var cmd_name = string(GetCommand()[0]) +def IsGdbStarted(): bool + # CHECKME: check this implementation + var gdbproc_status = job_status(term_getjob(gdbbufnr))
Is the job guaranteed to have been started?
If not, need an extra test
var gdbproc = term_getjob(gdbbufnr)
var gdbproc_status = gdbproc == null ? '' : job_status(gdbproc)
if gdbproc_status !=# 'run'
because job_status does not accept a null, it does accept a null_job; another expression of problematic null handling.
job_status(null_job) # WORKS
job_status(null) # FAIL E1218: Job Required for argument 1
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
ubaldot
@ubaldot commented on this pull request.
In runtime/pack/dist/opt/termdebug/plugin/termdebug.vim:
> if exists('g:termdebug_loaded')
- finish
+ Echoerr('Termdebug already loaded.')
True! I added it because when manually debugging one has to source the script many times and it often happens that the updated script is not sourced due to this guard and the developer may get mad to try to understand why a certain bug never go away. Adding this check considerably helped me. However, if you really want to remove it, no problems in removing it! Just let me know :)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
ubaldot
> @@ -38,44 +38,61 @@ vim9script # The communication with gdb uses GDB/MI. See: # https://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI.html
-# In case this gets sourced twice.
+def Echoerr(msg: string)
+ echohl ErrorMsg | echom $'[termdebug] {msg}' | echohl None
+enddef
+
+if !has('vim9script') || v:version < 900
Ooooops! :D
Shall we keep a check that always return true? Naaaaaa!
Good catch!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
ubaldot
> @@ -38,44 +38,61 @@ vim9script # The communication with gdb uses GDB/MI. See: # https://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI.html
-# In case this gets sourced twice.
+def Echoerr(msg: string)
+ echohl ErrorMsg | echom $'[termdebug] {msg}' | echohl None
+enddef
+
+if !has('vim9script') || v:version < 900
+ # Needs Vim version 9.0 and above
+ Echoerr("You need at least Vim 9.0")
+ finish
+endif
+
+# Variables to keep their status among multiple instanced of Termdebug
+# Avoid to source the script twice.
if exists('g:termdebug_loaded')
Hum, could you please elaborate why that is different? To be the devil's advocate I would say that the former is more readable :p
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
ubaldot
> + var cmd_name = string(GetCommand()[0])
+ if gdbproc_status !=# 'run'
Echoerr($'{cmd_name} exited unexpectedly')
It's just for a matter of readability.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
ubaldot
> endif running = 0 gdbwin = 0 enddef # IsGdbRunning(): bool may be a better name? -def CheckGdbRunning(): string - var gdbproc = term_getjob(gdbbuf) - var gdbproc_status = 'unknown' - if type(gdbproc) == v:t_job - gdbproc_status = job_status(gdbproc) - endif - if gdbproc == v:null || gdbproc_status !=# 'run' - var cmd_name = string(GetCommand()[0]) +def IsGdbStarted(): bool + # CHECKME: check this implementation + var gdbproc_status = job_status(term_getjob(gdbbufnr))
I remember that I tested it manually and I ended up with that convoluted implementation. That is why I added the CHECKME comment. If you have time, could you double check, please? Four eyes are better than two sometimes.
I saw that you opened: #14983
Feel free to adjust this function based on such a change.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
ubaldot
So much stuff I'm not familiar with... And looks so much better.
Thanks for the appreciation! I can tell you that there is still lot to do and it is very easy to spot, but I am sure that you will agree to proceed by smaller steps. ;-)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
ubaldot
@ubaldot commented on this pull request.
In runtime/pack/dist/opt/termdebug/plugin/termdebug.vim:
> endif running = 0 gdbwin = 0 enddef # IsGdbRunning(): bool may be a better name? -def CheckGdbRunning(): string - var gdbproc = term_getjob(gdbbuf) - var gdbproc_status = 'unknown' - if type(gdbproc) == v:t_job - gdbproc_status = job_status(gdbproc) - endif - if gdbproc == v:null || gdbproc_status !=# 'run' - var cmd_name = string(GetCommand()[0]) +def IsGdbStarted(): bool + # CHECKME: check this implementation
?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
ubaldot
Is it worth mentioning specifically what bug is fixed by this PR?
Line 1770: there where a leftover from legacy Vim that produce an error: let v:swapchoice = 'o' is now v:swapchoice = 'o'.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
errael
@errael commented on this pull request.
In runtime/pack/dist/opt/termdebug/plugin/termdebug.vim:
> @@ -38,44 +38,61 @@ vim9script # The communication with gdb uses GDB/MI. See: # https://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI.html
-# In case this gets sourced twice.
+def Echoerr(msg: string)
+ echohl ErrorMsg | echom $'[termdebug] {msg}' | echohl None
+enddef
+
+if !has('vim9script') || v:version < 900
+ # Needs Vim version 9.0 and above
+ Echoerr("You need at least Vim 9.0")
+ finish
+endif
+
+# Variables to keep their status among multiple instanced of Termdebug
+# Avoid to source the script twice.
if exists('g:termdebug_loaded')
This is sensitive to the value of termdebug_loaded, whereas exists() is not. Either way works as long as you don't care about the value. I'd say the latter makes more sense:)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
errael
> + var cmd_name = string(GetCommand()[0])
+ if gdbproc_status !=# 'run'
Echoerr($'{cmd_name} exited unexpectedly')
Mostly the comment was about putting
var cmd_name = string(GetCommand()[0])
inside the if !=# 'run'. There's no reason to run the code unless there's a problem. Putting the expr in string interpolate is just a matter of style. (and saving a few cycles, but I tend to way over optimize)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
errael
> endif running = 0 gdbwin = 0 enddef # IsGdbRunning(): bool may be a better name? -def CheckGdbRunning(): string - var gdbproc = term_getjob(gdbbuf) - var gdbproc_status = 'unknown' - if type(gdbproc) == v:t_job - gdbproc_status = job_status(gdbproc) - endif - if gdbproc == v:null || gdbproc_status !=# 'run' - var cmd_name = string(GetCommand()[0]) +def IsGdbStarted(): bool + # CHECKME: check this implementation + var gdbproc_status = job_status(term_getjob(gdbbufnr))
I saw that you opened: #14983
I closed that in favor of #14984 which is simpler and seems to make more sense.
With either of those fixes,
var gdbproc_status = job_status(term_getjob(gdbbufnr))
works whether or not gdbbufnr has a job associated with it.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Yegappan Lakshmanan
@yegappan commented on this pull request.
In runtime/pack/dist/opt/termdebug/plugin/termdebug.vim:
> @@ -38,44 +38,56 @@ vim9script # The communication with gdb uses GDB/MI. See: # https://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI.html -# In case this gets sourced twice. +def Echoerr(msg: string) + echohl ErrorMsg | echom $'[termdebug] {msg}' | echohl None +enddef + + +# Variables to keep their status among multiple instanced of Termdebug
Typo: "instanced" -> "instances"
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Yegappan Lakshmanan
@yegappan requested changes on this pull request.
In runtime/pack/dist/opt/termdebug/plugin/termdebug.vim:
> @@ -491,7 +548,7 @@ def StartDebug_prompt(dict: dict<any>)
prompt_setcallback(promptbuf, function('PromptCallback'))
prompt_setinterrupt(promptbuf, function('PromptInterrupt'))
- if vvertical
+ if vvertical == true
When using a Boolean variable, there is no need to it compare against true or false. The previous code is more readable.
In runtime/pack/dist/opt/termdebug/plugin/termdebug.vim:
> @@ -381,13 +438,13 @@ def StartDebug_term(dict: dict<any>) var counter_max = 300 var success = false while success == false && counter < counter_max - if CheckGdbRunning() != 'ok' - # Failure. If NOK just return. + if IsGdbStarted() == false
When using a Boolean variable, there is no need to it compare against true or false. Can you use !IsGdbStarted()?
In runtime/pack/dist/opt/termdebug/plugin/termdebug.vim:
> # Wait for the response to show up, users may not notice the error and wonder # why the debugger doesn't work. counter = 0 counter_max = 300 success = false while success == false && counter < counter_max - if CheckGdbRunning() != 'ok' + if IsGdbStarted() == false
When using a Boolean variable, there is no need to it compare against true or false. Can you use !IsGdbStarted()?
In runtime/pack/dist/opt/termdebug/plugin/termdebug.vim:
> @@ -646,13 +704,13 @@ def TermDebugSendCommand(cmd: string)
ch_sendraw(gdb_channel, $"{cmd}\n")
else
var do_continue = 0
- if !stopped
+ if stopped == false
When using a Boolean variable, there is no need to it compare against true or false. The previous code is more readable.
In runtime/pack/dist/opt/termdebug/plugin/termdebug.vim:
> #\ Note: GDB docs also mention hex encodings - the translations below work
#\ but we keep them out for performance-reasons until we actually see
#\ those in mi-returns
#\ \ ->substitute('\\0x\(\x\x\)', {-> eval('"\x' .. submatch(1) .. '"')}, 'g')
#\ \ ->substitute('\\0x00', NullRepl, 'g')
- \ ->substitute('\\\\', '\', 'g')
- \ ->substitute(NullRepl, '\\000', 'g')
- if !literal
+ ->substitute('\\\\', '\', 'g')
+ ->substitute(NullRepl, '\\000', 'g')
+ if literal == false
When using a Boolean variable, there is no need to it compare against true or false. Can you use !literal?
In runtime/pack/dist/opt/termdebug/plugin/termdebug.vim:
> @@ -1475,14 +1533,14 @@ def TermDebugBalloonExpr(): string
if v:beval_winid != sourcewin
return ''
endif
- if !stopped
+ if stopped == false
When using a Boolean variable, there is no need to it compare against true or false. The previous code is more readable.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
ubaldot
@ubaldot commented on this pull request.
In runtime/pack/dist/opt/termdebug/plugin/termdebug.vim:
> @@ -491,7 +548,7 @@ def StartDebug_prompt(dict: dict<any>)
prompt_setcallback(promptbuf, function('PromptCallback'))
prompt_setinterrupt(promptbuf, function('PromptInterrupt'))
- if vvertical
+ if vvertical == true
Correct. I get burned once with Python due to the truthy/falsy thing that I now tend to be explicit on pretty much everything. However, being Boolean variables, I agree that the == true and ==false are not needed. I'll fix it asap.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
@chrisbra commented on this pull request.
In runtime/pack/dist/opt/termdebug/plugin/termdebug.vim:
> endif running = 0 gdbwin = 0 enddef # IsGdbRunning(): bool may be a better name? -def CheckGdbRunning(): string - var gdbproc = term_getjob(gdbbuf) - var gdbproc_status = 'unknown' - if type(gdbproc) == v:t_job - gdbproc_status = job_status(gdbproc) - endif - if gdbproc == v:null || gdbproc_status !=# 'run' - var cmd_name = string(GetCommand()[0]) +def IsGdbStarted(): bool + # CHECKME: check this implementation
That checkme should be fixed before merged. So either the implementation is correct. Then we can merge it or it isn't then we shouldn't.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Thanks. All in all I like the approach this takes and the cleanup is valuable. Please address all the mentioned items.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
ubaldot
@ubaldot commented on this pull request.
In runtime/pack/dist/opt/termdebug/plugin/termdebug.vim:
> @@ -381,13 +438,13 @@ def StartDebug_term(dict: dict<any>) var counter_max = 300 var success = false while success == false && counter < counter_max - if CheckGdbRunning() != 'ok' - # Failure. If NOK just return. + if IsGdbStarted() == false
Done! I extended the process also in non-cited places that suffer of the same issue.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
ubaldot
> # Wait for the response to show up, users may not notice the error and wonder # why the debugger doesn't work. counter = 0 counter_max = 300 success = false while success == false && counter < counter_max - if CheckGdbRunning() != 'ok' + if IsGdbStarted() == false
Done! I extended the process also in non-cited places that suffer of the same issue.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
ubaldot
> @@ -646,13 +704,13 @@ def TermDebugSendCommand(cmd: string)
ch_sendraw(gdb_channel, $"{cmd}\n")
else
var do_continue = 0
- if !stopped
+ if stopped == false
Done! I extended the process also in non-cited places that suffer of the same issue.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
ubaldot
> #\ Note: GDB docs also mention hex encodings - the translations below work
#\ but we keep them out for performance-reasons until we actually see
#\ those in mi-returns
#\ \ ->substitute('\\0x\(\x\x\)', {-> eval('"\x' .. submatch(1) .. '"')}, 'g')
#\ \ ->substitute('\\0x00', NullRepl, 'g')
- \ ->substitute('\\\\', '\', 'g')
- \ ->substitute(NullRepl, '\\000', 'g')
- if !literal
+ ->substitute('\\\\', '\', 'g')
+ ->substitute(NullRepl, '\\000', 'g')
+ if literal == false
Done! I extended the process also in non-cited places that suffer of the same issue.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
ubaldot
> @@ -1475,14 +1533,14 @@ def TermDebugBalloonExpr(): string
if v:beval_winid != sourcewin
return ''
endif
- if !stopped
+ if stopped == false
Done! I extended the process also in non-cited places that suffer of the same issue.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
errael
@errael commented on this pull request.
In runtime/pack/dist/opt/termdebug/plugin/termdebug.vim:
> endif running = 0 gdbwin = 0 enddef # IsGdbRunning(): bool may be a better name? -def CheckGdbRunning(): string - var gdbproc = term_getjob(gdbbuf) - var gdbproc_status = 'unknown' - if type(gdbproc) == v:t_job - gdbproc_status = job_status(gdbproc) - endif - if gdbproc == v:null || gdbproc_status !=# 'run' - var cmd_name = string(GetCommand()[0]) +def IsGdbStarted(): bool + # CHECKME: check this implementation + var gdbproc_status = job_status(term_getjob(gdbbufnr))
#14984 is merged.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
ubaldot
@ubaldot commented on this pull request.
In runtime/pack/dist/opt/termdebug/plugin/termdebug.vim:
> + var cmd_name = string(GetCommand()[0])
+ if gdbproc_status !=# 'run'
Echoerr($'{cmd_name} exited unexpectedly')
I hear you :)
But in my opinion you lose readability: one thing is to read that you exited unexpectedly because of cmd_name, one is to read that you exited because of string(GetCommand()[0]). If we all agree, I would keep it as is. There is more room for optimization elsewhere. :)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
ubaldot
> endif running = 0 gdbwin = 0 enddef # IsGdbRunning(): bool may be a better name? -def CheckGdbRunning(): string - var gdbproc = term_getjob(gdbbuf) - var gdbproc_status = 'unknown' - if type(gdbproc) == v:t_job - gdbproc_status = job_status(gdbproc) - endif - if gdbproc == v:null || gdbproc_status !=# 'run' - var cmd_name = string(GetCommand()[0]) +def IsGdbStarted(): bool + # CHECKME: check this implementation + var gdbproc_status = job_status(term_getjob(gdbbufnr))
Perfect! Thanks for the PR!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
ubaldot
@chrisbra Is there anything else that you wish me to do before merging this PR? I think the points raised by @errael shall be discussed and the removal o f Echoerr('Termdebug already loaded.') at the beginning. But IMHO we can leave them as they are.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Yeah, I think its fine, if you could please remove the CHECKME now?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
ubaldot
Yeah, I think its fine, if you could please remove the CHECKME now?
Done!
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
errael
@errael commented on this pull request.
In runtime/pack/dist/opt/termdebug/plugin/termdebug.vim:
> + var cmd_name = string(GetCommand()[0])
+ if gdbproc_status !=# 'run'
Echoerr($'{cmd_name} exited unexpectedly')
My suggestion is putting the calculation of cmd_name inside the if
if gdbproc_status !=# 'run'
var cmd_name = string(GetCommand()[0])
Echoerr($'{cmd_name} exited unexpectedly')
I don't see how calculating a value that is almost never used improves things. If there is an issue with clarity, a comment should suffice.
(this is not about putting the expr in string interpolate, that's primarily a style issue)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
@chrisbra commented on this pull request.
In runtime/pack/dist/opt/termdebug/plugin/termdebug.vim:
> + var cmd_name = string(GetCommand()[0])
+ if gdbproc_status !=# 'run'
Echoerr($'{cmd_name} exited unexpectedly')
I'll adjust that when merging. Thanks!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
ubaldot
@chrisbra the master branch of my fork is still 7 commits ahead and I cannot sync with the upstram repo (I made thesee changes directly on the master branch in my own fork). It looks like this PR has not been merged yet... Can you confirm?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
errael
It is merged. Take a look at https://github.com/vim/vim/commits/master/ there's patch 9.1.0482: termdebug plugin needs more love
When I pulled from the main repo, I get it in my local clone, also when I update and pull from my fork.
I never update my master directly, always push a branch. Do you have merge conflicts?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
errael
@ubaldot I did have an accident a while back; I can't remember all the details, but...
I have "Branch protection rules", "require a pull request before merging" in my fork set to prevent direct changes to master.
I vaguely remember that after the accident, when my fork was screwed up, and I couldn't update,
there was a button under the "Sync Fork" pulldown in my fork. I don't remember what it said, but
it didn't work to clean things up. I had to temporarily disable the "require a pull request before
merging" and then the button (whatever it was called) worked and things got back in sync. It may
be that I had to repush some stuff from my local clone; don't remember.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
ubaldot
@errael In-fact I did the "mistake" of developing directly on (my fork) master and then push onto (upstream) master. Now I have this situation:
Whereas I expected to be only 32 commits behind. But I have now seen that my changes are included in a commit named "termdebug needs more love" so I assume I can safely discard these 7 commits.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.