On 4/3/22 22:18, Guillaume Cogoni wrote:
Hello,
We don't know if we can revive this topic, but we still think that
it's a good idea
to talk more about "how it can be useful to use the debugging tool that gives
VS Code".
So, we make a patch about it.
We retrieve what Derrick Stolee did and add what we said in our previous mail.
Thanks,
Cogoni Guillaume and Jonathan Bressat
--------------------->8-----------------------------------
Subject: [PATCH 0/1] contrib/vscode/: debugging with VS Code and gdb
COGONI Guillaume (1):
contrib/vscode/: debugging with VS Code and gdb
How did you generate this patch? It doesn't apply with 'git am', I
suspect you copy-pasted incorrectly into your mailer. Using 'git
send-email' helps sending properly formatted patches.
> Remove "externalConsole" line in contrib/vscode/init.sh because it
> seems to not work for everyone, and after a discussion with Matthieu
> Moy and Derrick Stolee, we agreed that it is better to let the user
choose
> what to do with this line
I usually explain the problem first, and then the solution.
The externalConsole=true setting is broken for many users (launching the
debugger with such setting results in VS Code waiting forever without
actually starting the debugger). Also, this setting is a matter of user
preference, and is arguably better set in a "launch" section in the
user-wide settings.json than hardcoded in our script. Remove the line to
use VS Code's default, or the user's setting.
> (Add his own configuration).
Avoid using gender-specific formulation when not needed. It's easier to
do in English than in French.
> Add useful links in contrib/vscode/README.md to help the user to
> configure his VS Code and how to use the debugging feature.
Likewise.
> Add a mention to the README in Documentation/MyFirstContribution.txt
> and a part "To convince a newcomer that VS Code can help him".
Why use double-quotes here? You're not quoting anything, right?
--- a/Documentation/MyFirstContribution.txt
+++ b/Documentation/MyFirstContribution.txt
@@ -1265,3 +1265,15 @@ against the appropriate GitGitGadget/Git branch.
If you're using `git send-email`, you can use it the same way as before, but you
should generate your diffs from `<topic>..<mybranch>` and base your work on
`<topic>` instead of `master`.
+
+[[Bonus-useful-tools]]
+== Bonus - useful tools
+
+=== VS Code
+
+To see "how to use VS Code" read contrib/vscode/README.md.
Double-quotes look weird here too. And the document is not really about
using VS Code, but more specifically on how to use VS Code on Git's
codebase.
A set of scripts and instructions to use VS Code on Git's codebase is
available in `contrib/vscode/README.md`.
?
+If you want to try to understand "how git works internally", the debugging
+feature of VS Code can help you. It will not give you all the keys to
fully understand it, but
+it can give you an idea of "how the information travels inside the code".
+It can help you to isolate some parts of code, with this you are able
+to ask more precise questions when you are stuck. (See getting-help sections).
\ No newline at end of file
I'm reluctant to adding general programming tips in a Git-specific
document. Perhaps shorten it to eg. just "Using the integrated debugger
can be particularly helpful to understand how Git works internally"?
--- a/contrib/vscode/README.md
+++ b/contrib/vscode/README.md
@@ -8,6 +8,11 @@ code editor which runs on your desktop and is available for
[Linux](https://code.visualstudio.com/docs/setup/linux). Among other languages,
it has [support for C/C++ via an
extension](https://github.com/Microsoft/vscode-cpptools).
+To understand "how works the debugging part" read:
"How the debugging part works" to get words in the proper order.
But the flow would be more natural continuing the previous sentence IMHO:
it has [support for C/C++ via an
extension](https://github.com/Microsoft/vscode-cpptools) with [debugging
support](https://code.visualstudio.com/docs/editor/debugging).
+To get help about "how to personalize your settings" read:
+[How to set up your
settings](https://code.visualstudio.com/docs/getstarted/settings)
Why not, but I don't think it's necessary here. People familiar with VS
Code don't need such link, and people not familiar at all with is would
better read a tutorial.
Cheers,
--
Matthieu Moy
https://matthieu-moy.fr/