VSCode GoToDefinition behaviour - can't just go to next nest - visual-studio-code

When you have to work with STM32 HAL you know, there is many macros and sometimes you want to know where is implemented this one. In my example, in line 40 i use F12 on label PROSTE_MAKRO (F12 is GoToDefinition). In my case this function directs me to line 30, where is defined macro SRC, not my PROSTE MAKRO what i expect. It looks like this VSCode function GotoDefinition think to much how to (NOT!) help me and evaluate my macro to basic forms. But half of code i have in HAL is macros and i expect gotoDefinition shoud redirect me by any (if is more than one) nested definition. I want it and this is how many IDE works.
I use Visual Studio Code with Plaftormio and C/C++ Microsoft extension. I have configure c_cpp_properties.json file with my configuration name, paths etc. I've made all toolchain from EmbeddedGeek yt video, but it all works good. (STM32F767 code generation and flashing is ok).
I have no idea wtf is wrong with VSCode but any day give me new reason to hate VSC.
I'm trying ask google about it but ofc i've reveive zero answer. I'm trying change goto behavior in general settings (13 setting found) but always it work wrong. I have record it on YT so you can watch it: https://www.youtube.com/watch?v=5FADq5yRp6g
And now i think SO is my last option.

In file: .vscode\c_cpp_properties.json in field:
"intelliSenseMode": "windows-msvc-x86",
"compilerArgs": [],
"compilerPath": ""
I have defined my toolchain compiler and it's args. VScode automatic recognize it and think it is something different than default and change Intellisense mode to other (in my case it was arm-gcc or so). And it is. I have delete my compliler path and compiler args and leave it empty. Now GoToDefinition (default F12) work good.
But be careful - if you change "intelliSenseMode" to windows-msvc-x86 but set compiler path and args VSCode will inform you that intelliSenseMode is different than you try set. In any case - don't touch it.

Related

Sublime fails to open new_file in macro

In Sublime (Version 3.2.2, Build 3211) (Ubuntu 18.04.5), I'd like to record a macro where I select-all, copy and paste the current content into another, unsaved file. And then do other commands as well, but I'm not even getting that far. The new-file step doesn't seem to work – neither new, nor new_window, newWindow, new_file, newFile seem to work; not even reopen_last_file. It should be new_file, though.
The console throws this:
Unknown macro command new_file
Which is weird. The command new_file works fine in other contexts: looking at the key-bindings settings, ctrl+n is bound to the same command and the hotkey has no issues.
Selecting all, copying – even this following bit works as intended:
{
"command": "insert",
"args": {"characters": "Hello, Friend!\n"}
}
In their forums, user "jps" writes:
With regards to the other console messages (unknown command, etc), don’t worry about them, they’re supposed to be there :slight_smile:
… but this doesn't seem to be right if it's obviously not working.
I have a project open but closing the project has no effect.
Is there maybe a package or something missing?
Macros in sublime can only capture and replay TextCommand commands; that is, commands that directly modify the content of a buffer or it's visual state. Examples including adding or removing text, changing the selection, moving the cursor around or changing view specific settings (like toggling word wrap or changing rulers, etc).
Commands like new_file, new_window or opening and closing projects are WindowCommand commands, which can't be captured via a macro.
In order to run a sequence of commands that includes a WindowCommand (or ApplicationCommand), you need to use a package. Two examples of that which are readily available on Package Control are Chain of Command and Multicommand.

vscode "lint ignore" for task output (languages that are not in-built into vscode - tasks.json/settings.json?)

scenario
Using vscode with COBOL and a task to compile the sources + a defined problemMatcher does:
execute the task correctly (all output shown in the Terminal pane)
parses errors and warnings correctly showing them in the Problems pane
issue
Some warnings are "unwanted" and decided to be ignored (not by the compiler, so they will still be raised and seen in the terminal), but they should not be shown in the Problems pane.
Moving the mouse over the error says "add a lint comment to ignore the warning, but clicking on it does not change the code (which I guess is what it is intended to do).
question
Is there an option to define rules to ignore warnings where the linter is not known to vscode (actually the "linter" is the problemMatcher defined in tasks.json), likely settings.json/tasks.json?
If nothing can be done directly it may be possible to define a problem-matcher to say "ignore"? If yes - how?
If that is still not possible then I'd define a fixed pattern to have these warnings matched as info - but I'd like to find a better solution.
The issue has been raised with the extension author and an answer to the specific questions can be found # https://github.com/spgennard/vscode_cobol/issues/216.
Most important:
The issue [...] observed was related to [a bug:] the linter being triggered for non-linter issues and this was resolved a months ago [in the extension]
You can add a negative lookahead to the problemmatcher:
(?!.*(?:sometextYouDontWant|otherTextNotWanted))here_the_original_regex

vscode c/c++ define configuration

I'm trying to get a c project configured in vscode. Basically, I'm on MacOS but IntelliSense thinks that the MS_WINDOWS macro is defined, so it's always trying to include the windows.h header. A few questions:
How can I see a list of macros that IntelliSense thinks are defined and where they come from?
How can I undefine the MS_WINDOWS macro in c_cpp_properties.json? I tried putting "MS_WINDOWS=0" in configurations.defines but that doesn't work because MS_WINDOWS is still defined.
may be:
"intelliSenseMode": "clang-x64"

Debugging expression evaluation

I'm using IntelliJ idea Community edition (with Scala) and I'm trying to evaluate an expression. I hit Alt-F8 to open it in debug mode and then switch to 'Code Fragment Mode'. However, I'm allowed to only evaluate variables that already exist in memory, and am not allowed to declare new. When I do so, I get- 'Evaluation of variables is not supported'. Is there a plugin that I can use in debug mode to evaluate arbitrary code?
EDIT: So that it's clear, no worksheets are not what I'm looking for. I want to evaluate expressions using variables existing at runtime.
Have you considered using a Scala Worksheet, which is a kind of editor supported REPL. You can create one in your project, import code from your project, execute it and see the results instantly. It wont let you debug to a piece of code though, if that is your primary intention.
It's an old question, but for now there is a good answer:
https://www.jetbrains.com/help/idea/2016.1/evaluating-expressions.html
TL;DR: During debugging, click on a stack frame, and you'll be able to evaluate expressions in the context of that frame: Run|Evaluate Expression, and you can click "Code Fragment Mode" to enter multi-line stuff. IntelliJ autocomplete features would work properly too!

Dr Racket fails when trying to create ]

I'm playing around a bit with DrRacket in the BSL language.
When I'm trying to create a comment like so:
;; Hi(10, 50]
The program fails in the moment when typing the ]. I can only end it via TaskManager. It uses 13 CPU in the TM.
Has anyone of you a solution for that? or is it simply not to use ].
Thank you
This is some bug that was reported several times recently, and there's no fix, yet. It's probably a result of some non-english keyboard layout (which was the case in these reports). Hopefully it will get fixed soon...
UPDATE: The bug was fixed for the next release, but in the meanwhile Matthew posted some instructions on how to do a temporary fix -- repeated here for reference:
We have tracked down a problem that occurs when the AltGr key is needed
to type ].
DrRacket gets stuck due to a bad implementation of an operation that is
intended to be bound to Alt-]. For most of you, though, the problem is
that you didn't want the Alt-] keybinding at all; you're just trying to
type ], and it's misinterpreted as Alt-].
You can work around the problem by placing the five lines at the end of
this message in a file, and then selecting the file via the
Edit -> Keybindings -> Add User-defined Keybindings...
menu item in DrRacket. Typing ] should work immediately after, and
typing [ will also give you just [ (instead of [ and ]).
Beware that after you select the file, it will be difficult to unselect
it. It turns out the the menu item to un-select a keybindings file is
also buggy! Your best bet is to put the file in a place that it can
stay. (You can still edit the file and restart DrRacket if you just
want to drop the bindings.)