For some unknown reason, the react-native start command, while running for a while, opens an editor with the following message:
Opening ../node_modules/react-native/Libraries/Renderer/src/renderers/shared/stack/reconciler/ReactChildReconciler.js with vim
Not an issue (it still works), but more of an annoyance and I was wondering why it was doing this and that maybe it's a features I'm missing out, like stack traces after an error.
The editor opens when you click a line in the stack trace on the "red screen". Pretty easy to unknowingly do if you're running an emulator and are using the mouse to bring focus to it. It appears this is intended behavior (https://github.com/facebook/react-native/issues/6103)
You can work around it by using a launch line like EDITOR=true react-native start, while it will still "open an editor" that instantly exits, it wont break your shell.
Related
I am using IntelliJ Idea for developing scala and Java programs. I am also a screen reader user.
One of the most useful features that IDEs provide is code linting and displaying error and warnings in your code, along with descriptions. I understand if you are a sighted user, you can just hover your mouse over an erroneous line of code and you get a tooltip with the description.
I haven't been able to figure out how to access this description as a screen reader users. So far, to review errors/warnings I would just build the program and look at the command line output, however this is pretty inefficient compared to just hovering over line of code.
Could someone share a better way of reviewing errors/warnings in IntelliJ using a screen reader? Ideally how to access the error tooltip, or how to access a better UI for reviewing them instead of looking at raw command line output.
I'm not sure about warnings however errors can be accessed in two ways:
Firstly when the caret is moved into a line with error the error text is written into the status bar - the problem with this approach is that for JAB applications screen readers are generally unable to find it, so in case of NVDA object navigation has to be used.
The second way requires your caret to be exactly at the point with error - generally it would be set in the proper place if you've navigated to the line with F2. After that you need to press CTRL+f1 - focus moves to the unnamed pane and the error text is its first descendant so once again you need to employ object navigation. I haven't found any reasonable way to access error texts with JAWS sadly.
Importantly, make sure to turn on screen reader support:
settings (ctrl + alt + S) > appearance and behaviour > Appearance > Support screen readers (requires restart)
Then when your caret is on an error/warning, you can press ctrl + F1 and a dialogue will pop up with the description. Press escape to close it.
If you want to make sure the caret is on an error/warning, use F2 to jump to next error/warning.
As noted by lukaszgo1 in his answer, the description is also printed to status bar, but NVDA cant find it using its normal command, because JAB GUI applications are lacklustre in their implementation of accessibility, however if you want to access the status bar of IntelliJ to read the description you can use an NVDA addon which I developed, that adds a command for reading IntelliJ status bar and fixes list items not being labelled properly.
I actually forgot I asked this until I got an answer recently.
Thanks to lukaszgo1 for his answer.
This is a little thing that annoys me. When I run a test case, output console is flooded by messages (especially when testing Spring beans). When test finishes, I see the red bar appearing, I see that there is a stacktrace somewhere down, but the output is immediately moved to the top.
I know that there is a 'Scroll to the end' button, but I have to click it. I want the end of a test output to be displayed automatically.
I'm using IntelliJ CE, 2018.3.2
I'm attaching a screenshot that shows my console after executing a failing test. Despite a 'Scroll to the end' button is enabled, output is "rewind" to top.
Ok, I found some kind of solution. In the test run tab, there is an icon for test settings. In there there is an option 'Track running test'. I noticed that when I change this setting, my console output stays at the botton and it's not being rewind. You can see that on a screenshot below.
I'm not sure if this is IntelliJ's feature or a bug, but maybe someone will find this post useful.
For me (in webstorm 2020) the solution was to click the cog wheel, then select Scroll to Stack Trace. I'm sure in all the Jetbrains products this is the solution.
I have IntelliJ IDEA 2016.3.2 on OSX.
I understand ⌥F12 allows us to toggle between embedded terminal and editor, but in this way the terminal disappears when focus moves to editor. Sometimes I'd like to switch focus from and to terminal with shortcut keys and still have the terminal opened so that I can tail logs.
My current workaround is to use both Terminal.app and IntelliJ IDEA and switch over by ⌘+Tab, but to me it's handy if I can do both in IntelliJ IDEA. Probably the embedded terminal and its use cases are designed to suite lightweight task that requires minimal attention, though.
Your problem here is that the ⌥+F12 shortcut isn't toggle focus, but toggle open. So essentially you are just opening and closing it.
After opening the terminal you should use the same command you use to switch between tabs in the editor (I believe it's ⌘+` on OSX).
Your window mode is correct though - docked mode keeps it attached to the side/bottom of the window, and pinned mode keeps it from collapsing when losing focus, so keep those set.
This will probably sound like a minor issue, but it's completely messing up my workflow:
I have a microservice that I restart frequently to refresh changes. I start in Debug mode, and use the curvy arrow in the upper left of the Debug tool window to stop/start the process.
In the Debug window, there are 2 tabs, Debugger and Console. For weeks, I've kept this on Console, and I can see the service run through startup, and I know when to start hitting endpoints. All of a sudden, whenever I start up, it switches to the Debugger tab, which means I have to manually switch back.
No documentation on this, and didn't find anything with a Google search. Does anyone have something to try?
Thank you
Update:
I start with the focus on Console (the right tab) and it switches to Debugger (the left tab). There is a "Focus on startup" in the context menu for Console, but it has no effect.
I'm not sure this is exactly what you're looking for. If it's not, could you please add some screenshots to the question which might better illustrate the problem? But if it is, here is what I found:
In the Debug tool window you have tabs like Output and Variables, which are probably the tabs you are talking about. You can right click any of these tabs and select Focus On Startup. You probably have this option selected for the wrong tab. So try selecting it for the Output tab.
You can toggle the Focus On Startup behavior for other tabs in the Debug tool window too.
When I run a test in IntelliJ IDEA 13.01 Ultimate, with any luck it just passes. In those rare cases (ha!) when I get an exception, though, it displays that exception on the right side of the Run context, as is shown below:
The up and down arrows between the two panes can walk you through the stack trace, which is great. And they claim to have a keyboard shortcut, ctrl+alt+down and ctrl+alt+up. But these shortcuts do not seem to work with any obvious workflow, and I always wind up forced to use my mouse. This is, in fact, the only time I have to use my mouse in my IntelliJ IDEA workflow. What am I doing wrong?
shift-alt-F10 to select the test case I want to see.
The image below appears, except the two blue arrows are grayed out. This is true whether the editor window contains a relevant source file or not.
Using the mouse, click on an item in the stack trace.
The two arrows are now colored, and can be used by clicking on them. Their keyboard shortcuts, however, cannot be used.
The keyboard shortcuts seem to work occasionally, under conditions that I do not understand.
I am using the ideavim plugin--could that be an issue?
It's a known problem, feel free to vote for VIM-176.