fix github issue links in documentation

docs/guide/dbgeng-ttd.md

@@ -42,7 +42,7 @@ So you will need to copy the entire WinDbg installation folder to a place that B
 - Search for the setting `debugger.x64dbgEngPath`
 - Put path `C:\Users\user_name\windbgx\amd64` in it
     - Do not forget to append `amd64` to the path of the folder
-- There is a plan to automate this process: https://github.com/Vector35/debugger/issues/486
+- There is [a plan](https://github.com/Vector35/debugger/issues/486) to automate this process.
 
 
 ## Record a TTD Trace
@@ -57,7 +57,7 @@ So you will need to copy the entire WinDbg installation folder to a place that B
     - The index will make it faster to work with the trace
 - Close WinDbg
 - Or check out the official guide at https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/time-travel-debugging-record
-- There is a plan to automate this process: https://github.com/Vector35/debugger/issues/485
+- There is [a plan](https://github.com/Vector35/debugger/issues/485) to automate this process.
 
 
 ## Configure the TTD Trace in Binary Ninja Debugger
@@ -86,7 +86,7 @@ So you will need to copy the entire WinDbg installation folder to a place that B
     - p-: step over back
     - t-: step into back
     - g-u: step out back
-    - There is a plan to add several new buttons that do reverse execution: https://github.com/Vector35/debugger/issues/484
+    - There is [a plan](https://github.com/Vector35/debugger/issues/484) to add several new buttons that do reverse execution.
 - The [!position](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/time-travel-debugging-extension-positions) command prints the `position` of all active threads
 - The [!tt](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/time-travel-debugging-extension-tt) command navigates to a `position` in the trace
     - E.g., `!tt 1A0:12F`
@@ -96,5 +96,5 @@ So you will need to copy the entire WinDbg installation folder to a place that B
 ## Feedback and Suggestions
 
 The TTD integration in Binary Ninja debugger is still in the beta stage so it will likely contain some bugs or lack certain features.
-The good news is the debugger is [open-source](https://github.com/Vector35/debugger) and we have a public issue repository for it: https://github.com/Vector35/debugger/issues/.
+The good news is the debugger is [open-source](https://github.com/Vector35/debugger) and we have a public issue repository for it: [https://github.com/Vector35/debugger/issues/](https://github.com/Vector35/debugger/issues/).
 Please feel free to file bug reports, and request new features, either specifically for the TTD or more generally for the debugger. Or even better, join our public [Slack](https://slack.binary.ninja/) and talk to the developers and users!

docs/guide/index.md

@@ -368,7 +368,7 @@ To avoid the need to manually force an update frequently, set `debugger.aggressi
 Any changes, e.g., annotations, comments, are lost after the target exits. This is because the debugger binary view is a separate binary view, and edits to it would not carry over to the original binary view.
 As a temporary workaround, try to apply changes to the original binary view, whose changes will always be carried over to the debugger binary view when the target launches.
 
-We are also working on https://github.com/Vector35/debugger/issues/213 which will resolve the problem by offering a viable way to selectively carry over some changes made to the debugger binary view to the original binary view.
+We are also working on [an issue](https://github.com/Vector35/debugger/issues/213) which will resolve the problem by offering a viable way to selectively carry over some changes made to the debugger binary view to the original binary view.
 
 
 ## Troubleshooting

docs/guide/windows-kd.md

@@ -107,9 +107,9 @@ System Uptime: 0 days 21:40:55.173
 
 ## Troubleshooting & Known Issues
 
-1. Running certain commands that takes a while to complete can lead to a brief hang: https://github.com/Vector35/debugger/issues/532
-2. When we end the remote kernel debugging, the guest system is always paused: https://github.com/Vector35/debugger/issues/533
-3. Once we have enabled kernel debugging with `kdnet`, the system will always wait for a kernel debugger to connect during boot. 
+1. Running certain commands that takes a while to complete can lead to a [brief hang](https://github.com/Vector35/debugger/issues/532)
+2. When we end the remote kernel debugging, the guest system is [always paused](https://github.com/Vector35/debugger/issues/533)
+3. Once we have enabled kernel debugging with `kdnet`, the system will always wait for a kernel debugger to connect during boot.
 It would hang if we do not attach a kernel debugger, even if we do not plan to do kernel debugging at all.
 To avoid this, I highly recommend taking a snapshot of the VM before attempting to do kernel debugging.
-If you know there is a way to reset the kernel debugging status and let the system boot in the normal way, please let me know!
+If you know there is a way to reset the kernel debugging status and let the system boot in the normal way, please let me know!