In Atom-Nuclide for simple errors (indentation, semicolons, const etc) it appears a tooltip with a button to fix it automatically.
This is very useful but still a bit time consuming.
Is there a way to automate it with a command or a macro that simulates clicking on all the fix buttons?
Alt+Shift+A does what you want (default on Linux).
The command is called "Nuclide Diagnostics: Fix all errors in current file", I found it using the command-palette.
Related
I often code functions in the following way by creating a basic function, entering debug mode, and then writing the function in debugmode. E.g.,
myfun <- function(x) print(x)
debugonce(myfun)
myfun("test")
The benefits of this is that I can get real time feedback on whether my code is working with the arguments passed to it.
However RStudio appears to have recently changed it's behaviour to make this more difficult. I recently upgraded to 2021.09.0 Build 351.
Previously, it would open the Source Editor when you call this command.
But if you closed this screen, you could return to your code, edit the code, evaluate code, and so on without the viewer re-appering.
However, now it seems to reappear every time you evaluate your code.
For instance, if I close the viewer, go back to my main script, and evaluate x, the Viewer opens back up.
This is super annoying for someone used to editing and evaluating code while in debugmode using the source script file.
Is there any way of entirely disabling the Source Editor view in Rstudio? Or alternatively, is there a way of being able to edit and evaluate code without the Source Editor constantly re-appearing in Rstudio (like how it used to work)?
My current fix is to downgrade to Version 1.3.1093, where you could edit and evaluate code without the Viewer constantly re-appearing. But it would be a shame to miss out on future upgrades.
This issue was principally a bug that has now been fixed.
At time of posting, downloading a daily build fixes the issue, but eventually this fix will be incorporated into beta and standard builds.
https://github.com/rstudio/rstudio/issues/9943
I'm sharing a small but annoying issue that sometimes pops up when I'm using shortcuts to insert operators while working on a markdown file in R : the operator either does not get written, or even worse gets written on another file.
So let's say I am working on the file "report.rmd", and I want to insert the pipe operator using Ctrl+Maj+M, or the assignment operator using "Alt+-", and I have the file "test.R" opened. Well, I therefore type the aforementioned shortcuts and...nothing happens on my markdown file. But some nice operators that had nothing to do there get written on my test.R file.
The only way I found to solve this problem is to close and reopen RStudio (restarting unfortunately doesn't solve the issue).
While this is quite a minor problem, it's incredibly annoying. Did it ever happen to anyone of you, and if so do you know where it comes from and how to solve it?
Edit:
Although I am still running into this issue (without being able to reproduce it consistently) I came into a somewhat lighter solution. Instead of restarting R, simply closing all tabs (closing just the problematic one doesn't work) solves the problem. I hope this helps narrowing down the possible origins of the problem.
Short Answer
re-define the key combo to Ctrl+Shift+ \ , assuming this does not create a conflict
Background
I've had a similar problem for a while, too. In my case, the shortcut never works. I can not find the source. I even found a conflict with Ctrl+Shift+M assigned to 2 Editor functions.
Image:Screen Capture 2 conflicting hotkey assignments
However, a simple key reassignment of the one that is not the pipe operator ("Expand to Matching")
Image:screen capture showing the hotkey conflict solveddidn't solve the issue in my case.
Solution
Here's what did the job for me
I managed to assign a different combo (that hasn't been assigned yet) and that is comfortable enough in the sense of its location on the keyboard
go to Tools → Modify Keyboard Shortcuts...
In the filter box, write "Pipe"
Direct the cursor to the text box showing the current shortcut, and press the new combo (e.g. Ctrl+Shift+ \ ), then Enter.
Remember to hit Apply
Make sure the new Combo isn't a duplicate of another command, by going back to step 1 and sorting the list by Shortcut, then scrolling down to find your new one. if there is an ovelap, consider changing one of them.
0.7 warns to use revise.jl, but on its documentation I just can't find a command to just say "clean it all".
Yes, I can sure just restart Julia, but in an IDE is several clicks away, while sometimes I just want to clean all variables/modules previously defined..
Yes, I can sure just restart Julia, but in an IDE is several clicks away
Assuming you are using Juno,
press Ctrl+j then Ctrl+k.
Docs
This kills the julia process, which will then automatically restart.
It is fairly fast
One possibility is to work with your code inside a module MyModule, then use Atom/Juno's inbuilt ability to define the working module in the left-most part of the bottom bar. Reevaluating the module should clear everything.
You can add this to your startup.jl file, and workspace() should work essentially the same as on previous Julia releases:
function workspace()
atexit() do
run(`$(Base.julia_cmd())`)
end
exit()
end
I use squish-4.2.2 for testing GUI of our tool and use purecov.i386_linux2.7.3 for covering them. Our tools are based on qt-4.7.4_qsci version of QT. After building our tools in Purecov mode, when we run our tests, they fail if tests contain operation with "popsup menu". Purecov cannot generate the result *.pcv file. Also I would like to note that our tools do not fail when they are run without Squish, however "Popsup Menu" opens not earlier than after 30-60 seconds (in normal mode it is done during 1-2 seconds).
So I have 2 issues:
1. when tests are run with Squish, they fail when tests contain operation with "Menu" item;
2. Purecov does not generate *.pcv file when tests fail.
I tried to find some interesting things on your site for resolving those problems, but I couldn't find anything related to my issues.
In my opinion, Squish failed because when I try to open "Menu" item, GUI runs faster than its logic part, and after opening "Menu" item, Squish considers that operation is done and kills my tool.
Could you please tell me what I can do with my tests or tools for resolving those problems?
Thanks.
I had a similar issue in the past, with clicking menus from my app.
I hope this helps you also!
Example:
I wanted to open a "File" menu, followed by a sub-menu (which is pop-up) "New". When I'm in record mode of Squish, Squish records the following code in python:
activateItem(waitForObjectItem(":MainWindowForm.m_poMainMenu_QMenuBar", "File"))
activateItem(waitForObjectItem(":MainWindowForm.menuFile_QMenu", "New..."))
Now, this didn't worked all the time, honestly I didn't managed to understand why :).
But, I found on their site, this a possible solution. So, I've replaced Symbolic names from the code above, and created a function that calls the objects after Real name properties:
def callMenu(menu_name, submenu_name):
activateItem(waitForObjectItem("{type='QMenuBar' visible='true'}", menu_name))
activateItem(waitForObjectItem("{type='QMenu' title='%s'}" % menu_name, submenu_name))
After I made this change, the tests run smooth, without anymore problems (at least from the menu side).
I'm doing development for Blackberry 10 using Cascades, which includes QT and QML. I find that I sometimes make mistakes in my QML file, but they don't get picked up at compilation time. How can I check whether I've made a syntax error, or mis-named a function call, or other typical errors?
QML is a dynamic language that is evaluated at Runtime. There is no compilation step and due to the nature of javascript and the dynamic nature of the global context there is no way for it to tell if what you are writing is correct/incorrect until it is evaluated. QtCreator can help with some of the QML errors you will find, but there is unfortunately no good way to get syntax errors about your javascript until it is evaluated and it explodes.
Personally, I have found good usage of the debugger to be the key to making these sort of fixes easy.
tldr; Keep your javascript clean and to a minimum there is no compile time checking.
open terminal in IDE connect your device or emulator using blackberry-SSH after connecting enter slog2info it show syntax and all typical error JavaScript with description and line NO.
If there are any mistakes it will show those lines in RED marks. It is dynamically checks there is no need to worry about compile.
If you done wrong you will not see the DESIGN CONSOLE correctly.